Technical Lab: Integrate Private Link and Private Endpoint with DNS
Questions
Question 1 — Multiple Choice
A platform team has configured a Private Endpoint for a storage account (mystorageaccount.blob.core.windows.net) in a VNet. After creation, virtual machines within the VNet still resolve the FQDN to the service's public IP address.
What is the most likely cause of this behavior?
A) The Private Endpoint was created in a subnet without delegation, preventing private resolution.
B) The private DNS zone privatelink.blob.core.windows.net is not linked to the VNet where the VMs are located.
C) The A record in the private DNS zone points to the public IP address instead of the endpoint's private IP.
D) Azure public DNS automatically overrides any private resolution when the service is internet-accessible.
Question 2 — Technical Scenario
An organization has the following architecture:
Hub VNet <---> Spoke VNet A
Spoke VNet B
Azure private DNS is centrally managed in the Hub. A Private Endpoint for Azure Key Vault was created in Spoke A. The privatelink.vaultcore.azure.net zone is linked only to the Hub VNet.
VMs in Spoke A resolve the FQDN correctly. VMs in Spoke B fail resolution and get the public IP.
What is the appropriate fix?
A) Create a second Private Endpoint in Spoke B pointing to the same Key Vault.
B) Link the private DNS zone privatelink.vaultcore.azure.net to Spoke B VNet as well.
C) Create a separate private DNS zone in Spoke B with the same name and an identical A record.
D) Enable the "DNS propagation" attribute on the peering between Hub and Spoke B.
Question 3 — True or False
When a Private Endpoint is created with automatic DNS integration enabled, Azure automatically creates an A record in the corresponding private DNS zone using the target resource name as the subdomain, without need for subsequent manual intervention.
True or False?
Question 4 — Technical Scenario
An engineer needs to ensure that on-premises clients (connected via ExpressRoute) resolve a Private Endpoint FQDN to the correct private IP, rather than the public IP. The environment uses its own on-premises DNS servers that do not delegate zones to Azure.
The engineer proposes the following solution:
On-premises DNS server
--> Conditional Forwarder: privatelink.blob.core.windows.net
--> IP: 168.63.129.16
Why will this approach not work as expected for on-premises clients?
A) The address 168.63.129.16 is only accessible from within an Azure VNet, not from on-premises networks.
B) Conditional Forwarders do not support privatelink.* zones due to Azure platform restrictions.
C) The on-premises DNS server would need to use TCP instead of UDP to forward queries to Azure DNS.
D) The privatelink.blob.core.windows.net zone cannot receive forwarded queries from outside Azure.
Question 5 — Multiple Choice
When configuring DNS for Private Endpoints in a multi-region environment with VNets in East US and West Europe, each region has its own Private Endpoint for the same service, with distinct private IPs. Both VNets need to resolve the same FQDN to the correct local IP.
Which DNS approach correctly meets this requirement?
A) Use a single global private DNS zone linked to all VNets, with two A records of the same name pointing to different IPs, relying on DNS round-robin.
B) Create a private DNS zone per region with the same name, each linked only to the respective region's VNets, containing the A record with the correct local IP.
C) Use the service's public DNS with zero TTL to force dynamic resolution based on geolocation.
D) Create a single private DNS zone with two A records of distinct names and configure each VNet to query the correct record by different fully qualified name.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Private resolution of Azure service FQDNs depends on two components working together: the existence of the private DNS zone with the correct A record, and the linking of that zone to the VNet where the client performs the query. Without the link (Virtual Network Link), Azure public DNS responds normally, returning the service's public IP.
The main error that distractors represent is confusing the existence of the private DNS zone with its accessibility by the VNet. The zone can exist and have the correct record, but if it's not linked to the VM's VNet, it's invisible to that DNS client. Option D represents a common myth: Azure public DNS does not override private resolution; it simply is what responds when the private zone is not linked.
Answer Key — Question 2
Answer: B
In hub-spoke architectures, the private DNS zone must be linked to all VNets that need to resolve FQDNs via private DNS, including the Spokes. Peering between VNets does not automatically propagate private DNS zone links. Spoke A resolves correctly because the zone is linked to the Hub and Spoke A uses the Hub's DNS via peering; Spoke B fails because it lacks the necessary link.
Option A is the most common error: creating a second Private Endpoint does not solve the DNS problem, as Spoke B would still resolve to the public IP without the zone link. Option C would create zone conflicts with the same name, which is not supported predictably. Option D describes a non-existent attribute on the platform.
Answer Key — Question 3
Answer: False
The statement contains a subtle but important misconception. When automatic DNS integration is enabled during Private Endpoint creation, Azure creates the A record using the target resource name as part of the record, but what is registered is the Private Endpoint's private IP, not a subdomain based on the resource name autonomously and permanently. More importantly: automatic integration only works correctly if the private DNS zone already exists or is created at that moment, and the record only persists while the Private Endpoint exists. If the endpoint is recreated or moved, the record is not automatically updated in all scenarios, especially in environments with centrally managed zones via policies (Azure Policy). Therefore, "without need for subsequent manual intervention" is incorrect in environments with centralized DNS governance.
Answer Key — Question 4
Answer: A
The address 168.63.129.16 is Azure's virtual DNS resolver, accessible exclusively from within Azure VNets. On-premises networks connected via ExpressRoute or VPN do not have a route to this IP, as it belongs to Azure platform's internal address space and is not advertised via BGP.
The correct solution for this scenario is to deploy an Azure DNS Private Resolver with an inbound endpoint that has a private IP accessible from the on-premises network. The on-premises forwarder should point to this IP, not to 168.63.129.16. Distractors B, C, and D describe non-existent platform restrictions and represent the error of confusing routing limitations with protocol or zone configuration limitations.
Answer Key — Question 5
Answer: B
To ensure each region resolves the FQDN to the local private IP, independent private DNS zones per region are needed, with the same name, each linked only to the respective region's VNets and containing the A record with the correct IP for that environment. Azure private DNS zones with the same name in different regions are separate entities and do not conflict, as long as they are linked to distinct VNets.
Option A fails because a single zone with two A records of the same name would result in non-deterministic round-robin: a VM in East US could receive the West Europe IP, causing latency or connectivity failure. Option C is not a private DNS solution and would expose traffic to the internet. Option D would break the functional requirement of using the same FQDN, which is especially problematic in scenarios with TLS certificates and SDKs that automatically construct the FQDN.