Technical Lab: Design and Implement Azure DNS Private Resolver
Questions
Question 1 — Multiple Choice
A network team needs to resolve Azure private DNS zone names from on-premises servers connected via ExpressRoute. The solution should avoid exposing public IP addresses and not require dedicated virtual machines to act as forwarders.
Which Azure DNS Private Resolver component directly meets this requirement?
A) An outbound endpoint configured with forwarding rules for Azure private zones
B) An inbound endpoint that receives DNS queries originated outside the virtual network and resolves them in the Azure context
C) A private DNS zone linked to the ExpressRoute Gateway virtual network with automatic registration enabled
D) A custom DNS server defined in the virtual network settings, pointing to address 168.63.129.16
Question 2 — Technical Scenario
An architect configured Azure DNS Private Resolver with the following topology:
- Hub VNet with an inbound endpoint (IP:
10.0.0.4) and an outbound endpoint - Spoke VNet linked to the same private DNS zone
- Forwarding ruleset associated with the outbound endpoint with a rule for
contoso.internalpointing to192.168.1.10(on-premises DNS server)
When testing the resolution of name app.contoso.internal from a VM in the Spoke VNet, the query fails. The VM in the Hub VNet resolves the same name without issues.
What is the most likely cause of the failure?
A) The outbound endpoint cannot forward queries from VNets different from the VNet where it's provisioned
B) The forwarding ruleset was not associated with the Spoke VNet, therefore VMs in that network are not affected by forwarding rules
C) The private DNS zone contoso.internal needs to be linked to the Spoke VNet for forwarding to work correctly
D) The on-premises DNS server IP address (192.168.1.10) must be configured directly in the DNS properties of the Spoke VNet
Question 3 — True or False
An outbound endpoint of Azure DNS Private Resolver can forward DNS queries to external destinations even when there is no DNS Forwarding Ruleset associated with it.
Question 4 — Technical Scenario
An organization operates multiple VNets across different regions, all connected to a Hub VNet via peering. The team wants to centralize DNS resolution using a single Azure DNS Private Resolver provisioned in the Hub VNet, so that VMs in all spoke VNets resolve Azure private DNS zones and forward queries to on-premises DNS.
The current configuration is described below:
Hub VNet
└── DNS Private Resolver
├── Inbound Endpoint: 10.1.0.4
└── Outbound Endpoint → Ruleset "corp-rules"
└── Rule: corp.local → 10.0.100.5
Spoke VNet A (peering with Hub)
└── DNS Server: 10.1.0.4 (Hub's inbound endpoint)
Spoke VNet B (peering with Hub)
└── DNS Server: Azure default
VMs in Spoke VNet A resolve corp.local correctly. VMs in Spoke VNet B do not resolve either Azure private zones or corp.local.
What should be corrected for Spoke VNet B to work as expected?
A) Associate the corp-rules ruleset with Spoke VNet B and configure its DNS server to point to 10.1.0.4
B) Provision a second exclusive DNS Private Resolver in Spoke VNet B with the same rulesets
C) Link the Azure private DNS zones to Spoke VNet B and configure its DNS server to 168.63.129.16
D) Create an additional inbound endpoint within Spoke VNet B and associate the corp-rules ruleset with that endpoint
Question 5 — Multiple Choice
When provisioning an inbound endpoint of Azure DNS Private Resolver, what is the expected behavior regarding the IP address assigned to it?
A) The IP address is dynamic and may change with each resolver restart, requiring periodic updates in on-premises forwarders
B) The IP address is static during the endpoint lifecycle and is allocated from the address space of the subnet dedicated to the inbound endpoint
C) The IP address is always assigned from the link-local range (169.254.0.0/16) and is not externally routable
D) The inbound endpoint IP address is shared with the outbound endpoint when both are in the same VNet, to reduce address consumption
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The inbound endpoint is the component designed exactly to receive DNS queries originated outside the Azure virtual network, such as on-premises servers connected via ExpressRoute or VPN. It exposes a private IP address routable through the hybrid network and resolves queries in the Azure context, including private DNS zones linked to the VNet.
Option A reverses the role of components: the outbound endpoint serves to forward queries from Azure to external destinations, not to receive queries from outside. Option C doesn't solve the problem because address 168.63.129.16 is not accessible from on-premises networks. Option D addresses zone peering, but doesn't create an externally accessible entry point without intermediate VMs.
Answer Key — Question 2
Answer: B
The DNS Forwarding Ruleset must be explicitly associated with each VNet that needs to apply forwarding rules. Associating the ruleset with the outbound endpoint is not sufficient: spoke VNets that don't have the ruleset associated with them will continue using Azure's default DNS resolution, without applying any of the defined rules.
Option A is incorrect because the outbound endpoint can serve spoke VNets, as long as the ruleset is associated with them. Option C confuses forwarding with private zone resolution: linking the zone to the Spoke VNet would resolve names in that zone, but not forwarding to on-premises DNS. Option D bypasses the Private Resolver architecture and introduces a failure point unrelated to the actual cause.
Answer Key — Question 3
Answer: False
The outbound endpoint, by itself, does not forward any queries. It is merely the egress interface from the virtual network. Effective forwarding depends on a DNS Forwarding Ruleset that contains explicit rules mapping domains to destination DNS servers. Without a ruleset associated with the outbound endpoint, it remains functionally inactive.
This is a common misconception: believing that the outbound endpoint has "generic forwarder" behavior by default. In practice, it only acts when a ruleset with valid rules is linked to it.
Answer Key — Question 4
Answer: A
Spoke VNet B's problem has two independent dimensions that need to be corrected together. First, Spoke VNet B's DNS server must point to the inbound endpoint (10.1.0.4) so that queries go through the centralized DNS Private Resolver. Second, the corp-rules ruleset must be associated with Spoke VNet B so that forwarding rules for corp.local are applied to VMs in that VNet.
Option B is inefficient and unnecessary: the hub-and-spoke design allows centralizing the resolver. Option C partially solves the Azure private zones problem, but doesn't address forwarding to corp.local. Option D confuses inbound with outbound: additional inbound endpoints don't distribute rulesets.
Answer Key — Question 5
Answer: B
The IP address of an inbound endpoint is statically allocated from the address space of the dedicated subnet configured for it at provisioning time. This behavior is fundamental to the architecture: on-premises DNS servers need a fixed and reliable destination to forward queries to, and any IP change would require reconfiguration in external forwarders.
Option A is false and would represent a serious operational risk if true. Option C describes link-local addresses, which don't apply to this context. Option D is technically incoherent: inbound and outbound endpoints require distinct subnets and have independent IPs, precisely to separate inbound and outbound traffic.