Technical Lab: Configure public and private DNS zones
Questions
Question 1 — Multiple Choice
A platform team needs virtual machines in a VNet to resolve names from the interno.contoso.corp domain without exposing any records publicly. The VNet is already linked to a private DNS zone with this name, but the VMs continue to fail at resolution.
What is the most likely cause of the problem?
A. The private DNS zone doesn't support domains with .corp suffix and requires .local
B. The VNet link to the private zone was created without enabling auto registration, which is mandatory for resolution
C. The link was created, but auto-registration is not related to resolution; it's missing enabling the Enable DNS resolution option in the VNet link configuration
D. VMs need to manually point to IP address 168.63.129.16 in their NIC DNS settings for the private zone to be queried
Question 2 — Technical Scenario
An architect is configuring DNS resolution for a hybrid environment. On-premises machines need to resolve records in an Azure private DNS zone (db.interno.azure). The on-premises DNS is a Windows Server 2019.
The team proposes the following solution:
On-premises DNS Server
└── Conditional Forwarder: db.interno.azure
└── Forwards to: 168.63.129.16
After configuration, the on-premises servers continue without resolving the names.
What is the error in the approach?
A. The .azure suffix is not supported in Azure private DNS zones
B. The address 168.63.129.16 can only be queried by resources within an Azure VNet; queries originating on-premises don't reach this resolver
C. Conditional Forwarders are not supported for private DNS zones; NS delegation is required
D. The private zone needs to have an explicit NS record pointing to 168.63.129.16 before accepting external queries
Question 3 — True or False
An Azure private DNS zone can be linked to VNets in different regions from the region where the zone was created, and name resolution will work normally in those remote VNets.
Question 4 — Technical Scenario
A company uses Azure public DNS for the contoso.com domain. The team needs to delegate the api.contoso.com subdomain to a separate DNS zone managed by another team, which has already created the api.contoso.com zone in Azure DNS.
The root team executes the following steps:
1. Gets the nameservers from the api.contoso.com zone:
ns1-05.azure-dns.com
ns2-05.azure-dns.net
ns3-05.azure-dns.org
ns4-05.azure-dns.info
2. Creates, in the contoso.com zone, an A record pointing
api.contoso.com to the IPs of these nameservers
The delegation doesn't work. What is the error made?
A. Subdomain delegation in Azure DNS requires both zones to be in the same subscription
B. The record created should be NS type, not A, pointing to the hostnames of the child zone's nameservers
C. Azure DNS nameservers cannot be used in internal delegations between zones from the same provider
D. The api.contoso.com zone should be a private zone, not public, to accept subdomain delegation
Question 5 — Multiple Choice
An organization has two VNets: VNet-A (East US) and VNet-B (West Europe). Both are linked to the same private DNS zone app.interno. Auto-registration is enabled on both links.
A VM called vm-web-01 is created in VNet-A. What behavior is expected?
A. An A record for vm-web-01.app.interno is created automatically, and VMs in VNet-B can resolve this name
B. An A record for vm-web-01.app.interno is created automatically, but only VMs in VNet-A can resolve it, since resolution between linked VNets is not supported
C. No record is created automatically because auto-registration only works when there is exactly one VNet linked to the zone
D. The A record is created, but with a fixed TTL of 10 seconds, making it unusable for production scenarios
Answer Key and Explanations
Answer Key — Question 1
Answer: C
The auto-registration option in a VNet link controls whether VMs in that VNet have their A/AAAA records created automatically in the private zone. It has no relation to resolution capability. What allows a VNet to resolve names from a private zone is the existence of the link (VNet link) itself, regardless of whether auto-registration is active.
The critical point here is that the link can be created correctly and resolution can still fail if the VMs' DNS is not using Azure's resolver. By default, VMs in a VNet query 168.63.129.16 automatically via DHCP, without needing manual configuration on the NIC. Therefore, alternative D represents a common misconception: manually configuring the NIC's DNS to this address would be redundant and doesn't solve the described problem.
The most likely error is that the VNet link wasn't created with the resolution option active or the VNet was configured with custom DNS pointing to another server, which doesn't forward to 168.63.129.16. Alternative C correctly describes the distinction between the two link controls.
Answer Key — Question 2
Answer: B
The address 168.63.129.16 is a virtual IP maintained by the Azure platform and accessible only from resources that traffic through Azure's network, i.e., within a VNet. DNS queries originating from on-premises servers arrive via internet or ExpressRoute/VPN connections, but still don't reach this resolver directly as an external endpoint.
The correct solution for hybrid resolution of private zones is to deploy an Azure DNS Private Resolver with an inbound endpoint in a VNet subnet. This endpoint receives a private IP accessible via VPN or ExpressRoute, and the on-premises conditional forwarder points to this IP, not to 168.63.129.16.
Alternatives A and D are distractors that introduce non-existent restrictions. Alternative C confuses the delegation mechanism with forwarding.
Answer Key — Question 3
Answer: True
Azure private DNS zones are global resources, not regional. The region selected during creation is only for billing metadata purposes and doesn't affect the zone's functional scope. A private zone can be linked to VNets in any Azure region, and name resolution works normally for resources in those VNets, as long as the link is configured.
This behavior is frequently underestimated: DNS resolution doesn't depend on geographic proximity between the zone and the linked VNet. This simplifies multi-region architectures that need a unified internal DNS namespace.
Answer Key — Question 4
Answer: B
Subdomain delegation in DNS works through NS (Name Server) records, which indicate which servers are authoritative for that child zone. Creating an A record pointing to nameserver IPs is technically incorrect: besides mixing the purpose of record types, Azure DNS nameservers don't have fixed and stable IPs for use in A records.
The correct process is: obtain the four NS hostnames from the api.contoso.com zone and create an NS record with the name api in the contoso.com zone, listing these hostnames as values. This instructs recursive resolvers to query the child zone's nameservers when they receive questions about *.api.contoso.com.
Alternatives A and C are false: there's no subscription restriction for delegation, and Azure DNS nameservers are perfectly valid in this context.
Answer Key — Question 5
Answer: A
When auto-registration is enabled on a VNet link, VMs in that VNet have their records created automatically in the private zone. Since the app.interno zone is linked to both VNet-A and VNet-B, both VNets share the same private DNS namespace.
This means that vm-web-01.app.interno will be visible and resolvable by any VM from any VNet linked to the same zone, regardless of region. This is exactly the purpose of linking multiple VNets to a single private zone: creating a shared namespace.
Alternative B represents a common misconception of confusing the scope of VNet peering (necessary for data traffic) with the scope of DNS resolution via shared private zone, which is independent of peering. Alternative C is false: the actual limit is up to 100 VNets with auto-registration per zone, not an exclusive VNet.