Which VNets must link to privatelink.database.windows.net for VM1 and VM2?
You have an Azure subscription that contains the resources shown in the following table.
You have an Azure App Service web app that contains the resources shown in the following table.
The virtual networks contain the resources shown in the following table.
You create an Azure Private DNS zone named privatelink.database.windows.net.
You need to ensure that VM1 and VM2 can resolve to Sql1.
Which virtual networks should you link to privatelink.database.windows.net?
Community Insight
It tests whether you map DNS zone links to the client VNets that need resolution; the trap is adding HubVNet because it is part of the topology or hosts the private endpoint.
This AZ-305 scenario tests private-endpoint DNS resolution in a hub-and-spoke topology: the privatelink.database.windows.net zone must be linked to the spoke VNets that host VM1 and VM2 so they can resolve Sql1. The correct scope is SpokeVNet1 and SpokeVNet2 only, not HubVNet.
Most candidates choose E and link all three VNets, assuming the hub must be linked for the private endpoint's DNS record or because peering is transitive; only the VNets whose workloads query Sql1 need the link.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Azure Private DNS resolution for a private endpoint is scoped by VNet links: a client VNet must be linked to privatelink.database.windows.net before Azure DNS in that VNet will return the private A record for Sql1. VM1 and VM2 are in SpokeVNet1 and SpokeVNet2, so linking those two spoke VNets is exactly what satisfies the requirement. VNet peering carries IP traffic but does not propagate private DNS zone links, which is why each client spoke needs its own link. The zone record itself is created when the SQL private endpoint is configured, so the hub link is not needed merely to make the record exist.Why the Other Options Are Wrong
A and B are incomplete because they link only one spoke, leaving the VM in the other spoke without private DNS resolution. C links only HubVNet; unless the hub hosts the clients that query Sql1, that does not make VM1 and VM2 resolve the private endpoint. E over-scopes the design by linking HubVNet as well, and while an extra link may not break name resolution, it is not required by the stated requirement and is the classic hub-and-spoke distractor. The exam expects the minimal set of VNets that contain the resolving clients.Community Comment Notes
mesloth's comment identifies the governing principle: private DNS zones "do not automatically propagate across VNets unless you explicitly link them." That is the reason peering alone is insufficient and why SpokeVNet1 and SpokeVNet2 must both be linked. However, the same principle does not force a link to HubVNet; a hub link is needed only if a hub-hosted client must resolve Sql1. The better reading of the requirement is therefore SpokeVNet1 and SpokeVNet2 only.Official Reference
Exam Strategy
For hub-and-spoke private DNS questions, first locate the client workloads (VM1 and VM2) and link the private DNS zone to their VNets, not to every VNet in the peering diagram. Then ask whether any hub-hosted service also performs DNS resolution; only that answer justifies adding HubVNet.
Frequently Asked Questions
Why link SpokeVNet1 and SpokeVNet2 but not HubVNet for Sql1 resolution?
Private DNS queries are answered in the client VM's VNet, so the zone link must exist on each spoke that hosts VM1 or VM2; HubVNet needs a link only if a hub workload also resolves Sql1.
Does a private endpoint's VNet need a DNS zone link to create the Sql1 record?
No. The A record is created in privatelink.database.windows.net when the private endpoint is configured; VNet links control which clients can resolve that record, not record creation.
Related Analysis
Practice All AZ-305 Questions
Access 95 questions with complete answers and detailed explanations.
View Full AZ-305 Practice Test →