AZ-104 Practice Question 29: Private DNS Autoregistration
Microsoft Azure Administrator Associate (AZ-104) · Test 3 · question 9 of 10
You create the private DNS zone corp.internal and link it to VNet-App. VMs in VNet-App must resolve one another by host name, and new VMs must start resolving without anyone touching DNS.
A week later the zone still contains no records, and nslookup vm-app-03.corp.internal fails from inside the virtual network. What should you do?
Show answer and explanation
Answer:
Linking a virtual network to a private zone makes the zone *resolvable* from that network, but records only appear on their own if the link was created with autoregistration: "when you link a virtual network with a private DNS zone with this setting enabled, a DNS record gets created for each virtual machine deployed in the virtual network. For each virtual machine, an address (A) record is created." It also keeps itself tidy: "when a virtual machine gets deleted or stopped, the autoregistered DNS records associated with this virtual machine are removed from the private DNS zone." Note the limit: "a specific virtual network can be linked to only one private DNS zone when automatic registration is enabled."
Option A is the manual work the feature removes, and it drifts the moment someone creates a VM outside the script. Manual records are the documented approach for resources autoregistration does not cover, such as internal load balancers, not for VMs.
Option B breaks name resolution. Private zones are not served by public name servers; virtual networks should keep the Azure-provided DNS (168.63.129.16), which is what consults the linked private zones.
Option C solves a different problem. A Private Resolver lets on-premises clients resolve Azure private zones and lets Azure forward to on-premises DNS. Clients *inside* the linked VNet already resolve the zone; the records simply do not exist yet.
Reference: What is the autoregistration feature in Azure DNS private zones?