AZ-104 Implement and Manage Virtual Networking Practice Question
A company has a hub virtual network that contains a custom DNS server at 10.20.0.4. A new spoke virtual network is peered to the hub. VMs in the spoke can reach other resources in Azure, but they cannot resolve internal names such as app01.corp.local. What should the administrator configure to fix name resolution for the spoke VMs?
⚠ Common exam trap
Test-takers frequently confuse DNS resolution with network connectivity (NSG rules or UDRs) or assume that VNet peering automatically propagates DNS settings, when in fact each VNet must be explicitly configured with its own DNS server.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set the spoke virtual network's custom DNS server to 10.20.0.4.
The spoke virtual network must be configured to use the hub's custom DNS server (10.20.0.4) as its own DNS server. Azure virtual networks do not automatically inherit DNS settings from a peered hub; each virtual network must explicitly specify its DNS server. By setting the spoke's custom DNS server to 10.20.0.4, VMs in the spoke will send DNS queries to that server, enabling resolution of internal names like app01.corp.local.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a user-defined route that sends DNS traffic to the hub virtual network.
Why it's wrong here
A user-defined route (UDR) controls the next hop for network packets, such as forcing traffic through an NVA or firewall, but it cannot alter the DNS resolver configuration of a virtual network or NIC. The custom DNS server setting is a separate control-plane property that must be set on the spoke VNet to direct queries to 10.20.0.4. Even if a UDR sent UDP/53 packets toward the hub's IP, the VM's configured DNS server remains Azure-provided, so resolution will not use the hub DNS server.
When this WOULD be correct
A UDR would be correct if the spoke VMs could not reach the custom DNS server at 10.20.0.4 due to missing routing, e.g., if the hub and spoke are in different regions and the DNS server is not reachable via the default route. In that case, a UDR with next hop to the hub's virtual appliance would fix connectivity.
- ✓
Set the spoke virtual network's custom DNS server to 10.20.0.4.
Why this is correct
This directs VMs in the spoke to query the hub DNS server for internal names. In a hub-and-spoke design, peering alone does not make Azure use a custom DNS server automatically. Configuring the spoke VNet to use 10.20.0.4 ensures clients send DNS queries to the server that already hosts the corporate zone records.
- ✗
Create an NSG rule that allows UDP port 53 from the spoke subnet to the hub subnet.
Why it's wrong here
An NSG rule that permits UDP 53 from the spoke subnet to the hub subnet only ensures that existing DNS packets are not filtered; it does not cause VMs to generate those packets to 10.20.0.4 in the first place. VM DNS clients use the DNS server address supplied by Azure, either the VNet-level custom DNS value or the default Azure DNS. Without explicitly configuring the spoke VNet with 10.20.0.4 as its custom DNS server, the NSG rule has no effect on which resolver is used.
When this WOULD be correct
If the spoke VMs could not resolve any names (including Azure internal names) and connectivity tests showed that traffic to the hub DNS server was blocked, then creating an NSG rule to allow UDP 53 from the spoke subnet to the hub subnet would be correct.
- ✗
Enable gateway transit on the hub peering so name resolution flows through the VPN gateway.
Why it's wrong here
Gateway transit in virtual network peering is a routing feature that lets a peered spoke VNet use a VPN/ExpressRoute gateway in the hub to reach on-premises networks. It does not set or change the DNS server address used by Azure VMs. DNS resolution in the spoke will still use the default Azure DNS unless the spoke VNet's custom DNS server property is explicitly set to 10.20.0.4, so this option fails to address name resolution.
When this WOULD be correct
If the question asked how to allow spoke VMs to access on-premises resources through the hub's VPN gateway, enabling gateway transit on the hub peering and using remote gateways on the spoke peering would be correct.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Set the spoke virtual network's custom DNS server to 10.20.0.4.Correct answer▾
Why this is correct
This directs VMs in the spoke to query the hub DNS server for internal names. In a hub-and-spoke design, peering alone does not make Azure use a custom DNS server automatically. Configuring the spoke VNet to use 10.20.0.4 ensures clients send DNS queries to the server that already hosts the corporate zone records.
✗Add a user-defined route that sends DNS traffic to the hub virtual network.Wrong answer — click to see why▾
Why this is wrong here
A user-defined route (UDR) controls traffic flow, not DNS resolution. The spoke VMs can already reach Azure resources, so routing is fine; the issue is that they are not using the custom DNS server at 10.20.0.4 for name resolution.
★ When this WOULD be the correct answer
A UDR would be correct if the spoke VMs could not reach the custom DNS server at 10.20.0.4 due to missing routing, e.g., if the hub and spoke are in different regions and the DNS server is not reachable via the default route. In that case, a UDR with next hop to the hub's virtual appliance would fix connectivity.
Why candidates choose this
Candidates may confuse DNS resolution with network routing, thinking that if VMs cannot resolve names, traffic to the DNS server must be routed differently, rather than configuring the DNS server address on the spoke virtual network.
✗Create an NSG rule that allows UDP port 53 from the spoke subnet to the hub subnet.Wrong answer — click to see why▾
Why this is wrong here
The issue is DNS resolution, not network connectivity. NSG rules control traffic flow, but the spoke VMs can already reach Azure resources, indicating connectivity exists. The problem is that the spoke VMs are not using the custom DNS server, so allowing UDP 53 does not fix the DNS configuration.
★ When this WOULD be the correct answer
If the spoke VMs could not resolve any names (including Azure internal names) and connectivity tests showed that traffic to the hub DNS server was blocked, then creating an NSG rule to allow UDP 53 from the spoke subnet to the hub subnet would be correct.
Why candidates choose this
Candidates often confuse DNS resolution issues with network security rules, assuming that blocking DNS traffic is the cause when the actual problem is incorrect DNS server configuration on the spoke virtual network.
✗Enable gateway transit on the hub peering so name resolution flows through the VPN gateway.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit is used to allow spoke VMs to use the hub's VPN gateway for outbound connectivity, not for DNS resolution. It does not configure DNS servers for the spoke virtual network.
★ When this WOULD be the correct answer
If the question asked how to allow spoke VMs to access on-premises resources through the hub's VPN gateway, enabling gateway transit on the hub peering and using remote gateways on the spoke peering would be correct.
Why candidates choose this
Candidates may confuse gateway transit with DNS forwarding, thinking that enabling transit allows DNS queries to flow through the hub's gateway to a DNS server on-premises.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
Virtual network
A virtual network is a software-based network that connects computers, servers, and devices over the internet or within a cloud environment, simulating a physical network without requiring dedicated hardware.
Key term
DNS
DNS is the system that translates human-friendly domain names like example.com into machine-readable IP addresses so computers can find each other on a network.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company has a hub virtual network with a DNS server VM at 10.50.0.4 that hosts internal names such as app01.corp.local. A spoke virtual network is already peered to the hub. VMs in the spoke can reach resources in the hub by IP address, but they cannot resolve the internal host names. The company wants to keep DNS centralized and avoid deploying another DNS server in the spoke. What should the administrator configure?
medium- A.Create a private DNS zone for corp.local and link it only to the spoke subnet.
- ✓ B.Set the spoke virtual network to use 10.50.0.4 as a custom DNS server.
- C.Add a user-defined route in the spoke to send DNS traffic to the hub VNet.
- D.Enable gateway transit on the peering and set use remote gateways on the spoke.
Why B: The spoke virtual network must be configured to use the hub DNS server (10.50.0.4) as a custom DNS server. This ensures that all VMs in the spoke send DNS queries to the hub server, which hosts the internal zone for corp.local. Since the hub and spoke are already peered, DNS traffic can flow over the peering connection without additional routing, keeping DNS centralized.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.