4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Design and implement name resolution
Pembury Health created a private DNS zone named privatelink.database.windows.net in subscription Sub-Platform and linked it to vnet-hub. A development team in subscription Sub-Dev created a private endpoint for an Azure SQL logical server in vnet-dev, which is peered with vnet-hub, and the DNS zone group added the A record to the zone. VMs in vnet-dev still resolve the server to its public IP address. The development team has only Contributor rights in Sub-Dev.
What should you do to fix resolution for vnet-dev?
- ACreate a virtual network link on the private DNS zone in Sub-Platform that targets vnet-dev, using an identity that has rights on both the zone and the virtual network.A private zone answers only for virtual networks it is linked to, and links can span subscriptions in the same tenant. The link must be created on the zone resource, which the Sub-Dev team cannot do alone.
- BEnable the Allow forwarded traffic and Allow gateway transit options on the peering between vnet-dev and vnet-hub.Peering options control packet forwarding and gateway sharing. They do not extend private DNS zone resolution from one virtual network to another.
- CCreate a second private DNS zone named privatelink.database.windows.net in Sub-Dev and link it to vnet-dev.A second zone would be empty of the existing record, and it duplicates the zone, splitting records across subscriptions. The existing DNS zone group already wrote the record to the Sub-Platform zone.
- DChange the DNS servers of vnet-dev to the private IP address of the private endpoint.A private endpoint for Azure SQL is not a DNS server; pointing the virtual network at it breaks all name resolution.
Why: Virtual network links are the mechanism that scopes a private DNS zone: only VMs in a linked virtual network receive answers from the zone, and peering does not propagate that scope. Links can target a virtual network in a different subscription as long as both are in the same Microsoft Entra tenant, and the identity performing the link needs permission on the zone and on the target virtual network. Because the record already exists in the central zone, the fix is a single link, not a new zone. Peering settings are the recurring distractor on DNS questions; they move packets, not names.
Design and implement name resolution
Wrexford Manufacturing has an on-premises Active Directory domain wrexford.local with DNS servers at 192.168.10.5 and 192.168.10.6, connected to vnet-hub (10.120.0.0/16) by ExpressRoute. Azure VMs in the hub and three peered spokes must resolve wrexford.local names, and on-premises clients must resolve Azure private endpoint names in privatelink zones linked to vnet-hub. The company will not deploy or manage DNS VMs in Azure and must not change the on-premises DNS platform other than adding a conditional forwarder.
Which three actions should you perform? Each correct answer presents part of the solution.
- ADeploy an Azure DNS Private Resolver in vnet-hub with an inbound endpoint in a dedicated subnet delegated to Microsoft.Network/dnsResolvers, and configure the on-premises DNS servers with a conditional forwarder for the privatelink zones that targets the inbound endpoint IP.The inbound endpoint gives on-premises resolvers a private IP inside Azure that can answer from the linked private DNS zones. The subnet must be dedicated and delegated to the resolver service.
- BCreate an outbound endpoint on the resolver, create a DNS forwarding ruleset with a rule that forwards wrexford.local. to 192.168.10.5 and 192.168.10.6, and link the ruleset to vnet-hub and each spoke virtual network.Outbound endpoints and forwarding rulesets send queries for specific domains to on-premises servers. Linking the ruleset to every virtual network that needs it makes the rule apply to VMs there using Azure-provided DNS.
- CSet the DNS servers of every spoke virtual network to 192.168.10.5 and 192.168.10.6.This sends all queries, including those for Azure private endpoints, to on-premises servers that cannot resolve privatelink zones, and bypasses the resolver entirely.
- DLink the privatelink private DNS zones to vnet-hub, where the resolver's inbound endpoint resides, so the resolver can answer for them.The inbound endpoint resolves using the private DNS zones linked to the virtual network it is deployed in. If a zone is not linked to vnet-hub, the resolver cannot answer for it.
- EDeploy two Windows Server DNS forwarder VMs in vnet-hub behind an internal load balancer and point the on-premises conditional forwarder at the load balancer.This is the legacy pattern that Private Resolver replaces, and the scenario explicitly forbids managing DNS VMs in Azure.
Why: Azure DNS Private Resolver is the managed replacement for DNS forwarder VMs and has two halves. The inbound endpoint exposes a private IP that on-premises DNS can conditionally forward to; it answers from the private DNS zones linked to the virtual network where the resolver lives, so those zones must be linked to vnet-hub. The outbound endpoint plus a DNS forwarding ruleset handles the other direction, forwarding selected domains such as wrexford.local to on-premises servers, and the ruleset must be linked to every virtual network whose VMs need the rule. Each endpoint needs its own dedicated subnet (minimum /28) delegated to Microsoft.Network/dnsResolvers. The deciding constraints are no DNS VMs and only a conditional forwarder change on-premises, which the two distractors violate.
Design and implement name resolution
Caldera Energy has a virtual network vnet-plant that is linked with auto-registration enabled to a private DNS zone named plant.caldera.internal. The company now wants VMs in vnet-plant to also register automatically into a second zone, corp.caldera.internal, and to resolve records in a third zone, shared.caldera.internal, that is maintained manually. When the team tries to create the second auto-registration link, the operation fails.
What is the cause of the failure, and what should you do?
- AA virtual network can be linked with auto-registration to only one private DNS zone. Keep auto-registration on plant.caldera.internal and link corp.caldera.internal and shared.caldera.internal as resolution-only links.A private DNS zone can have many registration virtual networks, but each virtual network can have only one registration zone. With resolution-only links, VMs in vnet-plant can query all three zones, but no records are created for them automatically in corp.caldera.internal; those must be added manually or by the team's own automation.
- BThe zone names overlap under caldera.internal. Rename corp.caldera.internal to a different parent domain and retry the registration link.Azure private DNS allows sibling zones under the same parent name, and overlapping names are not what blocks a second registration link.
- CAuto-registration requires custom DNS servers. Set the DNS servers of vnet-plant to 168.63.129.16 explicitly and retry.Auto-registration works with Azure-provided DNS by default and does not depend on the DNS server setting. Setting 168.63.129.16 explicitly changes nothing here.
- DThe zone is in a different subscription. Move corp.caldera.internal into the same subscription as vnet-plant and retry the registration link.Virtual network links, including registration links, can be created across subscriptions in the same tenant. Subscription boundaries are not the cause.
Why: Auto-registration and resolution are two different link types on a private DNS zone. A virtual network can be linked for resolution to as many zones as you need (up to the service limit), but it can carry auto-registration for only one zone, because each VM must have a single authoritative registration record. The deciding fact in the scenario is that one registration link already exists on vnet-plant, so the second one fails regardless of names or subscriptions. The design fix is to keep a single registration zone and link the other zones for resolution only, populating them manually or with automation.
Design and implement name resolution
Selwyn Outdoor hosts a public DNS zone selwyn-outdoor.com in Azure DNS. The website is published through an Azure Standard public IP named pip-web whose address may change if the deployment is rebuilt. Internal users in vnet-corp must resolve portal.selwyn-outdoor.com to the internal address 10.100.4.20 while internet users continue to receive the public address. The company wants the root (apex) name selwyn-outdoor.com to point to the public IP and to update automatically if the address changes.
Which configuration meets all the requirements?
- AIn the public zone, create an alias A record at the apex that targets the pip-web resource; create a private DNS zone also named selwyn-outdoor.com, link it to vnet-corp, and add an A record portal pointing to 10.100.4.20.An alias record at the apex can target an Azure public IP resource and follows address changes, which a CNAME at the apex cannot do. A private zone with the same name linked to vnet-corp gives split-horizon resolution for internal clients.
- BIn the public zone, create a CNAME record at the apex pointing to the DNS label of pip-web; add an A record portal with 10.100.4.20 to the same public zone.CNAME records are not permitted at the zone apex, and publishing 10.100.4.20 in the public zone exposes an internal address to the internet and gives internet users an unreachable answer.
- CIn the public zone, create a static A record at the apex with the current address of pip-web; link the public zone to vnet-corp and add the portal record there.A static A record does not follow address changes, and public DNS zones cannot be linked to virtual networks; only private DNS zones support virtual network links.
- DCreate a private DNS zone named selwyn-outdoor.com with an alias record at the apex targeting pip-web, link it to vnet-corp, and add the portal record there; delete the public zone.Deleting the public zone removes resolution for internet users entirely, and alias records that target Azure resources are a public zone feature.
Why: This scenario combines two configuration features. Alias records in Azure public DNS let an A or AAAA record, including one at the zone apex, reference an Azure resource such as a public IP, Traffic Manager profile or Front Door endpoint, so the record tracks the resource's address automatically, something a CNAME at the apex cannot do because the standard forbids it. Split-horizon DNS is achieved by creating a private DNS zone with the same name as the public zone and linking it to the virtual network; linked VMs query the private zone first and get the internal answer, while everyone else sees only the public zone. Public zones cannot be linked to virtual networks, which is the trap in option C.