Technical Lab: Configure private endpoints for Azure PaaS
Questions
Question 1 — Multiple Choice
A security team requires that an Azure Storage Account stop being accessible from the public internet, but remain available to virtual machines in a specific VNet. The administrator creates a private endpoint for the Storage Account and associates a Private DNS Zone (privatelink.blob.core.windows.net) to the VNet.
After configuration, VMs in the VNet can resolve the storage FQDN, but VMs in a peered VNet fail DNS resolution and cannot access the resource.
What is the most likely cause of the problem?
A. VNet peering does not support traffic to private endpoints due to platform limitations.
B. The Private DNS Zone is not linked to the peered VNet, so private name resolution does not occur there.
C. The Network Security Group (NSG) of the private endpoint subnet is blocking traffic from the peered VNet.
D. The private endpoint needs to be recreated within the peered VNet for VMs in that network to reach it.
Question 2 — Technical Scenario
An administrator runs the following command to create a private endpoint for an Azure SQL Database:
az network private-endpoint create \
--name pe-sqldb \
--resource-group rg-prod \
--vnet-name vnet-prod \
--subnet snet-pe \
--private-connection-resource-id "/subscriptions/.../servers/sql-prod" \
--group-id sqlServer \
--connection-name conn-sqldb
After creation, the administrator tries to connect to the SQL Server using the FQDN sql-prod.database.windows.net from a VM in the same subnet, but the connection goes to the public endpoint, not the private one.
Which step is missing to make DNS resolution direct traffic to the private endpoint?
A. Manually create an A record in corporate DNS pointing to the SQL Server's public IP.
B. Configure a Private DNS Zone privatelink.database.windows.net, link it to the VNet, and associate it with the private endpoint.
C. Disable the SQL Server public firewall in the resource "Networking" settings.
D. Add a UDR (User Defined Route) in the subnet to forward traffic to the endpoint's private IP.
Question 3 — True or False
A private endpoint assigns a private IP address to the PaaS resource within the indicated subnet, and this IP is dynamically allocated by Azure each time the private endpoint is recreated, and cannot be statically fixed by the administrator.
True or False?
Question 4 — Technical Scenario
A company has an Azure Key Vault configured with a private endpoint in snet-shared within vnet-hub. The application team reports that, even after creating the private endpoint, requests made by an App Service (hosted on a plan that supports VNet Integration) still reach the Key Vault's public endpoint.
The administrator verifies that:
- The App Service VNet Integration is correctly configured for
vnet-hub. - The Private DNS Zone
privatelink.vaultcore.azure.netexists and is linked tovnet-hub. - The App Service can ping other private resources in the same VNet.
What most likely prevents the App Service traffic from using the Key Vault private endpoint?
A. App Services with VNet Integration do not support access to private endpoints; an Azure Application Gateway is needed as an intermediary.
B. The WEBSITE_DNS_SERVER configuration or the App Service DNS is not pointing to Azure DNS (168.63.129.16), preventing Private DNS Zone resolution.
C. The Key Vault needs to have public access explicitly disabled to force the use of the private endpoint.
D. The private endpoint is in snet-shared, but should be in a subnet dedicated exclusively to the Key Vault to work with App Services.
Question 5 — Multiple Choice
When creating a private endpoint, the administrator needs to choose a subresource (group ID) during configuration. Considering an Azure Storage Account, which statement correctly describes the purpose and behavior of this choice?
A. The group ID defines which redundancy tier (LRS, GRS, ZRS) will be used by the private endpoint to replicate traffic.
B. Each group ID corresponds to a specific Storage Account service (such as blob, file, queue, table), and a single private endpoint covers only the selected subresource.
C. The group ID is optional; if omitted, Azure automatically creates private endpoints for all Storage Account subresources.
D. Selecting the blob group ID also automatically enables private access to the file and queue subresources of the same Storage Account.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The Private DNS Zone in Azure needs to be explicitly linked to each VNet that needs to resolve private names registered in it. VNet peering, by itself, does not propagate Private DNS Zone resolution: a VM in a peered VNet queries DNS from its own VNet, and if there is no link between the Private DNS Zone and that VNet, the query will return the resource's public IP, not the private endpoint IP.
The main misconception represented by the distractors is confusing network connectivity (which peering does propagate) with DNS resolution (which requires explicit Private DNS Zone linking). Alternatives A and D are incorrect because peering does support traffic to private endpoints normally, and it's not necessary to create an additional endpoint in the peered VNet. Alternative C could be an independent problem, but doesn't explain the specific DNS resolution failure described.
Answer Key — Question 2
Answer: B
Creating the private endpoint allocates a private IP in the subnet, but does not configure DNS automatically by default when the command is executed via CLI without the --private-dns-zone parameter. Without a Private DNS Zone privatelink.database.windows.net linked to the VNet, the FQDN sql-prod.database.windows.net continues to resolve to the server's public IP, and traffic bypasses the private endpoint.
Alternative C represents a common misconception: disabling public access is a complementary security best practice, but doesn't solve the DNS resolution problem. Alternative D is also incorrect because UDRs operate at the IP routing layer, they don't solve DNS problems. Alternative A points to the wrong solution (public IP) and contradicts the private endpoint usage objective.
Answer Key — Question 3
Answer: False
The private IP of a private endpoint can be specified statically by the administrator at creation time, using the --ip-config parameter (via CLI) or the equivalent field in the portal. When not specified, Azure allocates an available IP in the subnet dynamically. However, after allocation, this IP remains fixed to the private endpoint while it exists: there is no dynamic reassignment on recreations unless the administrator explicitly allows it.
The non-obvious behavior here is that "dynamic" in the context of private endpoints does not imply IP volatility: it behaves stably after creation, similar to what happens with VM NICs with dynamic allocation but IPs that don't change in practice.
Answer Key — Question 4
Answer: B
App Services with VNet Integration use the DNS server configured in the environment to resolve names. If the App Service is resolving names via an external or custom DNS that doesn't forward queries to Azure DNS (168.63.129.16), the Private DNS Zones linked to the VNet are never consulted. The result is that the Key Vault FQDN resolves to the public IP, bypassing the private endpoint.
The solution is to ensure the App Service uses Azure DNS as resolver, which can be done via the app setting configuration WEBSITE_DNS_SERVER=168.63.129.16. Alternative A is incorrect: App Services with VNet Integration support private endpoints without needing Application Gateway. Alternative C is a valid security measure, but is not what prevents private name resolution. Alternative D is incorrect because there is no exclusive subnet restriction for private endpoints to work with App Services.
Answer Key — Question 5
Answer: B
An Azure Storage Account exposes multiple independent services (blob, file, queue, table, web, dfs), and each has its own subresource (group ID). A private endpoint created for blob allocates a private IP and configures DNS resolution only for the blob endpoint (*.blob.core.windows.net), without affecting other services. To have private access to file and queue, for example, it's necessary to create additional private endpoints with the corresponding group IDs.
Alternative A confuses the concept of group ID with data redundancy, which are completely different layers. Alternative C is incorrect: the group ID is mandatory for resources with multiple subresources. Alternative D represents the most dangerous misconception: assuming that a single private endpoint covers all Storage Account services can result in file or queue traffic continuing to flow through the public endpoint without the administrator noticing.