Skip to main content

Technical Lab: Design private DNS zones

Questions​

Question 1 — Multiple Choice​

An architecture team needs to ensure that virtual machines in two distinct virtual networks, located in different regions, can resolve names from the same private DNS zone without depending on custom DNS servers.

What is the minimum requirement for name resolution to work correctly in both networks?

A) Both virtual networks must be connected via VNet Peering before being linked to the private DNS zone.

B) Each virtual network must be added as a virtual network link in the private DNS zone, with auto-registration enabled on both.

C) Each virtual network must be added as a virtual network link in the private DNS zone; auto-registration is optional and independent of resolution.

D) The private DNS zone must be deployed in the same region as the virtual networks for the links to work.

Question 2 — Technical Scenario​

An engineer configures a private DNS zone called internal.contoso.com and links the virtual network vnet-prod with auto-registration enabled. After deploying 120 virtual machines in this network, the engineer notices that records for some VMs don't appear in the zone.

What is the most likely cause of this behavior?

A) Auto-registration only works for VMs created before the virtual network link creation.

B) The limit of records generated by auto-registration in a single private DNS zone has been reached.

C) VMs with more than one NIC don't generate automatic records in private DNS zones.

D) Auto-registration requires the VM to be running at the time the link is created.

Question 3 — True or False​

A private DNS zone can be linked to a virtual network that already has a custom DNS server configured in the VNet settings, and both will coexist without conflict: the private zone will resolve names for which it has records, while the custom server will handle the others.

True or False?

Question 4 — Technical Scenario​

A company uses the following architecture:

vnet-hub (10.0.0.0/16)
  └── private DNS zone: services.internal
        └── virtual network link: vnet-hub (autoregistration: disabled)

vnet-spoke (10.1.0.0/16)
  └── no link with services.internal zone
  └── peering with vnet-hub configured

A VM in vnet-spoke tries to resolve api.services.internal and fails. The engineer argues that peering should automatically propagate DNS resolution.

What is the error in the engineer's approach?

A) VNet peering propagates routes but doesn't extend private DNS zone resolution; vnet-spoke needs its own virtual network link to the zone.

B) Peering only propagates DNS resolution when auto-registration is enabled on the source network link.

C) The services.internal zone uses an invalid suffix; private zones require at least two labels before the TLD.

D) VMs in spoke networks can never resolve private DNS zones linked to hub networks, regardless of configuration.

Question 5 — Multiple Choice​

When designing private DNS zones for private endpoints of Azure PaaS services, what is the main reason to use Microsoft-recommended zone names (e.g., privatelink.blob.core.windows.net) instead of zones with arbitrary names?

A) Zones with arbitrary names are blocked by Azure Policy by default in production environments.

B) The zone name determines which internal CNAME record the PaaS service uses to redirect resolution to the private endpoint; an incorrect name breaks this resolution chain.

C) Only zones with the privatelink prefix are accepted as virtual network links by Azure DNS.

D) Using arbitrary names prevents the creation of A records in the zone, limiting functionality to CNAME records.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

The name resolution mechanism in private DNS zones depends exclusively on virtual network links. Each virtual network that needs to resolve zone names must be linked to it, regardless of region or network topology. VNet peering is not required or sufficient for this.

Auto-registration is a separate functionality: when enabled, the zone automatically creates and removes A records for VMs in the linked network. It's not a condition for the network to use the zone as a resolver.

Option B is the most dangerous distractor: it confuses the concept of auto-registration with resolution, leading the candidate to think both features must always be active together. Option D is false; private DNS zones are global resources and have no region dependency.

Answer Key — Question 2​

Answer: B

Azure private DNS zones impose a limit of 10,000 records generated by auto-registration per zone. With 120 VMs, each potentially generating multiple records (one per NIC), it's plausible that this limit is reached, especially in environments with multiple NICs or accumulated records from previously deleted VMs whose records still exist.

The other options describe behaviors that don't exist: auto-registration works regardless of VM and link creation order (A is false), VMs with multiple NICs generate records for each NIC (C is false), and the VM's running state at link time is not a criterion (D is false).

The practical consequence of not identifying this limit is assuming the zone is malfunctioning when, in fact, the capacity ceiling has been reached and new records are silently discarded.

Answer Key — Question 3​

Answer: False

The statement describes a harmonious coexistence that doesn't occur automatically. When a VNet has a custom DNS server configured, DNS queries from VMs are directed to that server, not to Azure's recursive resolver (168.63.129.16). Since private DNS zone resolution must pass through Azure's resolver, a custom server that doesn't properly forward queries to 168.63.129.16 simply won't be able to resolve private zone names.

For both to coexist functionally, the custom DNS server must be configured as a conditional forwarder for private zone suffixes, pointing to 168.63.129.16. Without this explicit forwarding, the virtual network link exists, but resolution fails in practice.

Answer Key — Question 4​

Answer: A

VNet Peering establishes layer 3 connectivity between networks, allowing traffic to flow between them. It does not extend or share private DNS zone resolution. Each virtual network that needs to resolve names from a private zone must have its own virtual network link registered in that zone.

The correct architecture requires creating a link between vnet-spoke and the services.internal zone. Without this, VMs in vnet-spoke will use Azure's default DNS, which is unaware of the private zone.

Option B is false: auto-registration has no relation to resolution propagation between networks. Option C is false: services.internal is a valid private zone name (two labels). Option D is false and represents an absolute misconception; the hub-spoke topology with multiple links is a documented and supported pattern.

Answer Key — Question 5​

Answer: B

When a private endpoint is created for a PaaS service, Azure configures a CNAME record in public DNS that redirects the service's original name (e.g., contoso.blob.core.windows.net) to a name in the privatelink subdomain (e.g., contoso.privatelink.blob.core.windows.net). The private DNS zone with the exact name privatelink.blob.core.windows.net must contain the A record pointing to the private endpoint's IP.

If the zone has a different name, the resolution chain breaks: the public CNAME points to privatelink.blob.core.windows.net, but there's no private zone with that name to resolve the final step.

Options A, C, and D describe restrictions that don't exist in Azure DNS. There's no default Policy blocking, no requirement for the privatelink prefix for links, and A-type records work normally in zones with any valid name.