Skip to main content

Technical Lab: Link a private DNS zone to a VNet

Questions​

Question 1 — Multiple Choice​

A platform team created a private DNS zone called database.internal and linked it to a VNet called Hub-VNet. Virtual machines in this VNet can resolve names within the zone without issues. Later, a new VNet called Spoke-VNet was created and the VMs in it cannot resolve the same names.

What is the root cause of the problem?

A) The private DNS zone only allows a single linked VNet at a time, and Hub-VNet occupies that slot.

B) Spoke-VNet does not have a resolution link configured for the database.internal zone.

C) Peering between Hub-VNet and Spoke-VNet automatically propagates DNS links, but there is an expected synchronization delay.

D) DNS records need to be duplicated in the zone so that each VNet has its own set of entries.

Question 2 — Technical Scenario​

An engineer needs VMs in a VNet to automatically register their names in the private DNS zone corp.internal as they are provisioned. He configures the link between the zone and the VNet, but VM records do not appear in the zone after provisioning.

Link configuration snippet via CLI:

az network private-dns link vnet create \
  --resource-group rg-networking \
  --zone-name corp.internal \
  --name link-corp \
  --virtual-network Hub-VNet \
  --registration-enabled false

What is the problem and how to fix it?

A) The --zone-name parameter should include a trailing dot (corp.internal.) to indicate root zone.

B) The --registration-enabled parameter is set to false; it should be changed to true to enable automatic registration.

C) The link must be created in the Azure portal, as the CLI does not support the --registration-enabled parameter.

D) The VNet needs to have at least one subnet with delegation to Microsoft.Network/dnsResolvers before accepting automatic registration.

Question 3 — True or False​

A private DNS zone can be linked to a VNet with automatic registration enabled and, at the same time, that same VNet can have automatic registration enabled in a second different private DNS zone.

True or False?

Question 4 — Technical Scenario​

A company maintains the following architecture:

  • Private DNS zone: api.internal
  • Configured links: VNet-A (resolution only) and VNet-B (resolution only)
  • The VNets do not have peering between them

A VM in VNet-A manually creates an entry in the zone via portal. A VM in VNet-B tries to resolve that same name and succeeds. Then, the team removes the link from VNet-B and tries resolution again, but this time the query fails.

What behavior is being demonstrated by this sequence of events?

A) Removing the link interrupts resolution because VNet-B loses access to the private DNS zone's data plane.

B) The failure occurs because, without the link, Azure redirects queries to public DNS, where api.internal does not exist.

C) Removing the link automatically deletes all zone records that were created while the link was active.

D) Resolution fails because VNet-B loses the implicit peering with VNet-A that the private DNS link created.

Question 5 — Multiple Choice​

When planning links between private DNS zones and VNets in a hub-and-spoke topology, which statement correctly describes an operational service limit that directly impacts design?

A) A single private DNS zone can be linked to a maximum of 10 VNets, regardless of subscriptions or regions.

B) A VNet can be linked to multiple private DNS zones, but only one of them can have automatic registration enabled.

C) Resolution links are not allowed between VNets in different subscriptions within the same Microsoft Entra ID tenant.

D) Automatic registration only works in VNets located in the same region as the private DNS zone.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Access to resolution of a private DNS zone depends exclusively on the existence of a resolution link between the zone and the VNet. Peering between VNets does not propagate or inherit private DNS links: each VNet must have its own link configured in the zone. Alternative A is wrong because the actual limit is much higher than a single VNet. Alternative C represents a common misconception, as peering and DNS links are independent control planes. Alternative D is incorrect because DNS records are shared by all VNets linked to the zone.

Answer Key — Question 2​

Answer: B

Automatic registration of VMs in a private DNS zone depends on the --registration-enabled parameter being set to true in the link between the VNet and the zone. With the value false, the link exists only for resolution, not for registration. VMs are provisioned normally, but no A records are created automatically. Alternative A is incorrect as the CLI accepts the name without a trailing dot. Alternative C is false, the parameter is supported in the CLI. Alternative D confuses the private DNS Resolver resource, which is a distinct functionality and not a prerequisite for automatic registration.

Answer Key — Question 3​

Answer: False

A VNet can have automatic registration enabled in only one private DNS zone at a time. This is a service design limitation: allowing automatic registration in multiple zones simultaneously would create authority conflicts over which zone receives the canonical VM registration. It is perfectly valid to link the same VNet to multiple zones for resolution purposes, but automatic registration is restricted to a single zone per VNet.

Answer Key — Question 4​

Answer: A

The link between a VNet and a private DNS zone is what ensures access to the zone's resolution data plane. When removing the link, VNet-B loses the ability to send DNS queries that Azure's resolver will forward to that private zone. Alternative B is wrong because Azure does not automatically redirect to public DNS when removing a link: the query simply finds no resolution. Alternative C is incorrect: removing the link does not affect existing records in the zone. Alternative D confuses DNS link behavior with network connectivity, which are completely distinct planes.

Answer Key — Question 5​

Answer: B

The limit of a single zone with automatic registration per VNet is a real restriction and directly influences design in hub-and-spoke topologies, especially when there is a need to register VMs in different zones according to environment or function. Alternative A is incorrect: the link limit per zone is much higher than 10 and varies according to configuration. Alternative C is false: links between VNets from different subscriptions within the same tenant are supported. Alternative D is incorrect: the private DNS zone is a global resource and automatic registration has no region restriction between the zone and the linked VNet.