Technical Lab: Configure Azure DNS
Questions
Question 1 — Multiple Choice
A platform team needs to host the public DNS zone contoso.com in Azure DNS. After creating the zone and configuring the necessary records, external users report that names within the domain are not being resolved. The team verifies that the records exist in the Azure DNS zone and that the domain is registered with an external registrar.
What is the most likely cause of the problem?
A) The Azure public DNS zone requires the subscription to have the "DNS Resolver" feature enabled before accepting external queries.
B) The name servers (NS) of the zone created in Azure DNS were not configured in the external domain registrar.
C) The TTL of the A records is too high, preventing external resolver caches from being updated.
D) Azure public DNS does not accept queries from resolvers outside the Azure network without a DNS Forwarding rule.
Question 2 — Technical Scenario
An administrator needs resources within a VNet to automatically resolve the name vm-backend.internal.contoso.com to the private IP of a VM, without manually managing DNS records. They create a private DNS zone called internal.contoso.com and link the VNet to it.
After configuration, the VM originating the queries cannot resolve the name. The administrator verifies that the A record already exists in the private zone. Consider the configuration below:
Private zone: internal.contoso.com
VNet link: vnet-prod
- Auto-registration: Disabled
- Resolution: Enabled
What is the problem?
A) The VNet link has auto-registration disabled, which prevents any name resolution from the private zone in this VNet.
B) The VNet link with resolution enabled is sufficient to resolve names in the private zone, so the problem is elsewhere.
C) The private DNS zone needs to be in the same region as the VNet for the link to work correctly.
D) The A record was created manually, but since auto-registration is disabled, manual records are ignored by the private zone.
Question 3 — True or False
An Azure private DNS zone can be linked to VNets in different subscriptions, as long as the administrator performing the link has adequate permissions in both subscriptions.
True or False?
Question 4 — Technical Scenario
A company has the following DNS record structure in a public zone hosted in Azure DNS:
blog CNAME contoso.wordpress.com
@ A 20.10.50.100
www CNAME contoso.azurewebsites.net
The infrastructure team attempts to create the following additional record:
@ CNAME contoso.trafficmanager.net
The operation fails. What is the correct technical explanation?
A) Azure DNS does not support CNAME records in public zones; this record type is exclusive to private zones.
B) It's not possible to create a CNAME record for the zone apex (@) because the apex already contains NS and SOA records, and a CNAME cannot coexist with other records at the same name.
C) The problem is that there's already an A record for @; just remove the A record so the CNAME can be accepted.
D) Traffic Manager cannot be the target of a CNAME in zones hosted in Azure DNS; it's necessary to use an A record pointing to the profile's IP.
Question 5 — Multiple Choice
An administrator needs to delegate the subzone dev.contoso.com to a team that will manage their own DNS records in a separate Azure DNS zone. Which set of actions correctly represents the delegation process?
A) Create a zone called dev.contoso.com and add an A record in the parent zone contoso.com pointing to the IP of the child zone's DNS server.
B) Create a zone called dev.contoso.com, copy the name servers assigned to it, and create NS records in the parent zone contoso.com pointing to those servers.
C) Create a zone called dev.contoso.com and add a CNAME record in the parent zone contoso.com with the name dev pointing to the child zone's FQDN.
D) Create a zone called dev.contoso.com and enable the automatic delegation option in the parent zone settings in the Azure portal.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
When a public DNS zone is created in Azure DNS, the platform automatically assigns a unique set of name servers (NS) for that zone. For external resolvers to find and query this zone, the domain registrar needs to be updated to point to these Azure name servers. Without this update at the registrar, the hierarchical resolution chain never reaches the Azure zone, regardless of whether the internal records are correct.
The main misconception represented by the distractors is shifting the cause to Azure connectivity or internal configuration aspects, when the problem is external: delegation at the registrar. High TTL (C) would cause slowness in change propagation, not total failure in resolving a newly configured domain. Options A and D describe restrictions that don't exist in Azure public DNS.
Answer Key — Question 2
Answer: B
The VNet link with resolution enabled is, in fact, sufficient for VMs in that VNet to resolve names from a private DNS zone, including manually created records. Auto-registration only controls the automatic registration of VMs from the VNet in the private zone, not the resolution capability.
The central conceptual error in the question is confusing the two functions of the VNet link: resolution and automatic registration are independent. Alternative A represents this misconception directly, suggesting that disabling auto-registration blocks resolution, which is incorrect. Alternative D completely reverses the logic of auto-registration. Since the shown configuration is correct for resolution, the problem is elsewhere (for example, the A record might have the wrong name or IP, or there might be a connectivity issue with the application server).
Answer Key — Question 3
Answer: True
Azure DNS allows a private DNS zone to be linked to VNets in different subscriptions within the same Microsoft Entra ID tenant. The requirement is that the administrator performing the link operation has the necessary permissions in both the subscription containing the zone and the subscription containing the VNet. This behavior is relevant in hub-and-spoke architectures where the private zone is centralized in a connectivity subscription and the VNets are in separate workload subscriptions.
The non-obvious point here is that the scope of a private DNS zone is not limited by the subscription where it resides; access control is resolved through RBAC permissions, not subscription boundaries.
Answer Key — Question 4
Answer: B
The zone apex (represented by @) is the zone name itself, such as contoso.com. By definition of the DNS protocol (RFC 1034/1035), a CNAME record cannot coexist with any other record type at the same name. The apex always contains at least NS and SOA records, making it impossible to create a CNAME for it in any standard DNS implementation.
Azure DNS offers the alias record feature as a solution for this scenario: it allows pointing the zone apex to an Azure resource like Traffic Manager, Azure CDN, or public IP address, bypassing the CNAME limitation without violating the DNS standard.
Alternative C is the most dangerous distractor: even if the A record were removed, the NS and SOA records would remain at the apex, maintaining the incompatibility with CNAME. Alternative D is factually incorrect; Traffic Manager can indeed be the target of a CNAME at non-apex names.
Answer Key — Question 5
Answer: B
Subdomain delegation in DNS works through NS records in the parent zone that point to the authoritative name servers of the child zone. In Azure DNS, when creating the dev.contoso.com zone, the platform assigns a set of name servers to it. These servers need to be registered as NS records under the name dev in the parent zone contoso.com. When a resolver queries something.dev.contoso.com, it finds the NS records in contoso.com and is redirected to the child zone servers.
Alternative A confuses delegation with direct pointing via A record, which doesn't perform delegation and isn't how hierarchical DNS works. Alternative C is invalid because a CNAME to a zone name has no delegation semantics in DNS. Alternative D describes functionality that doesn't exist in Azure DNS; there's no automatic delegation between zones through the portal.