Hotspot Question You have an Azure App Service web app named Webapp1 that connects to an Azure SQL database named DB1. Webapp1 and DB1 are deployed to the East US Azure region. You need to ensure…

Question

Exhibit

Answer Area

• Create a virtual network that contains at least:
  1 subnet2 subnets3 subnets
• From the virtual network, configure name resolution to use:
  A private DNS zoneA public DNS zoneThe Azure DNS Private Resolver

Explanation

Answer Key

1. 2 subnets
2. A private DNS zone

Explanation

Dropdown 1 - Create a virtual network that contains at least: 2 subnets

To route traffic privately between App Service and Azure SQL, you need two Azure features, each requiring its own dedicated subnet:

These two subnets cannot be the same subnet - the Private Endpoint subnet cannot be delegated to App Service VNet Integration, and the VNet Integration subnet cannot host private endpoint resources. Azure enforces this separation.

Why the others are wrong:

• 1 subnet - Insufficient. You cannot place both the App Service VNet Integration delegation and a Private Endpoint in a single subnet due to Azure's resource constraints.
• 3 subnets - Not required. A third subnet adds unnecessary complexity for this scenario; two subnets satisfy all requirements.

Dropdown 2 - From the virtual network, configure name resolution to use: A private DNS zone

When a Private Endpoint is created for Azure SQL, the server's FQDN (e.g., db1.database.windows.net) must resolve to the private IP address of the endpoint - not its public IP. This requires a private DNS zone (specifically privatelink.database.windows.net) linked to the VNet.

Without this, DNS resolves the SQL server's FQDN to its public IP, and traffic bypasses the private connection entirely.

Why the others are wrong:

• A public DNS zone - Defeats the purpose. Public DNS resolves to the public endpoint IP, sending traffic over the internet rather than the private connection.
• Azure DNS Private Resolver - Overkill for this scenario. The DNS Private Resolver is designed for hybrid environments (on-premises <-> Azure DNS forwarding). A simple private DNS zone linked to the VNet is sufficient and is the standard pattern for Private Endpoint name resolution.

Core Concept

This architecture implements the Azure Private Endpoint + VNet Integration pattern:

[Webapp1 / App Service]
       ↓ (VNet Integration - Subnet A)
[Virtual Network]
       ↓ (Private Endpoint NIC - Subnet B)
[DB1 / Azure SQL - private IP only]

The private DNS zone is the "glue" that ensures DNS lookups return the private IP, keeping all traffic within the Microsoft backbone.

No community discussion yet for this question.