AZ-104 Implement and Manage Virtual Networking Practice Question
A hub-and-spoke environment uses a DNS server VM in the hub VNet at 10.8.0.4 to resolve internal names such as app01.corp.local. The spoke VNet can reach hub VMs by IP after peering, but name resolution still fails from the spoke. What should the administrator configure so VMs in the spoke use the hub DNS server?
⚠ Common exam trap
Candidates often assume VNet peering automatically forwards DNS queries to the hub's DNS server, but peering only provides IP-level connectivity, not DNS configuration; the spoke VNet must be explicitly set to use the custom DNS server address.
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
✓
Configure the spoke VNet to use 10.8.0.4 as a custom DNS server.
In Azure, a spoke VNet must explicitly be configured with a custom DNS server address to use a non-default DNS resolver. By setting the spoke VNet's DNS server to 10.8.0.4, all VMs in the spoke will send their DNS queries to that hub VM, resolving internal names like app01.corp.local. Without this configuration, the spoke VNet uses Azure-provided DNS, which cannot resolve custom private DNS zones hosted on the hub VM.
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 an inbound NSG rule on the spoke subnet to allow UDP and TCP 53 to 10.8.0.4.
Why it's wrong here
An NSG rule on the spoke subnet that permits UDP/TCP 53 to 10.8.0.4 only ensures that inbound DNS queries can reach the hub server; it does not configure the spoke VMs' DNS client to send those queries there. Without a custom DNS setting on the spoke VNet, VMs will still use Azure's default DNS (168.63.129.16) or whatever they currently have, so name resolution continues to fail. The fix must change the DNS server assignment at the VNet or NIC level, not merely open a port.
When this WOULD be correct
This option would be correct if the spoke VNet already had the hub DNS server configured, but VMs in the spoke could not reach it due to network security rules blocking DNS traffic (UDP/TCP 53). In that scenario, adding an inbound NSG rule on the spoke subnet to allow traffic to 10.8.0.4 would resolve the connectivity issue.
- ✓
Configure the spoke VNet to use 10.8.0.4 as a custom DNS server.
Why this is correct
A spoke VNet can inherit DNS behavior from a custom DNS setting on the VNet itself. Once the spoke VNet is configured to use 10.8.0.4, its VMs will send name-resolution queries to the hub DNS server over the peering connection. This is the right fix when direct IP connectivity works but internal names do not resolve.
- ✗
Create a service endpoint for Microsoft.Storage on the spoke subnet.
Why it's wrong here
Creating a Microsoft.Storage service endpoint on the spoke subnet alters the source IP and routing path for storage traffic, allowing subnet identity to be used for access control, but it has zero effect on DNS client configuration or how the VM resolves hostnames across peered VNets. Service endpoints are service-specific and operate at the platform routing layer, not at the DNS resolver layer. This action is a common distractor because it involves networking, yet it cannot alter the spoke VNet's custom DNS server setting or internal name lookup behavior.
When this WOULD be correct
If the question were about securely accessing Azure Storage (e.g., a storage account) from a spoke VNet without using a public IP, configuring a service endpoint for Microsoft.Storage on the spoke subnet would be correct.
- ✗
Add a user-defined route for 10.8.0.4/32 pointing to the virtual network gateway.
Why it's wrong here
A user-defined route for 10.8.0.4/32 with next hop set to the virtual network gateway overrides the normal system route for that prefix, but it only manipulates packet forwarding; it does not change the VM's DNS server list. Since the spoke VNet is peered to the hub, traffic to 10.8.0.4 already travels over the peering connection without needing a gateway, and forcing it through a gateway may actually break connectivity if the gateway doesn't support next-hop forwarding for private IP traffic. The real issue is that the VM is not querying 10.8.0.4 at all, which only a custom DNS setting on the spoke VNet fixes.
When this WOULD be correct
This option would be correct if the spoke VNet could not reach the hub DNS server by IP due to asymmetric routing or a missing route. For example, if the hub and spoke are connected via a VPN gateway and the spoke needs a specific route to send DNS traffic through the gateway to the hub DNS server.
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.
✓Configure the spoke VNet to use 10.8.0.4 as a custom DNS server.Correct answer▾
Why this is correct
A spoke VNet can inherit DNS behavior from a custom DNS setting on the VNet itself. Once the spoke VNet is configured to use 10.8.0.4, its VMs will send name-resolution queries to the hub DNS server over the peering connection. This is the right fix when direct IP connectivity works but internal names do not resolve.
✗Add an inbound NSG rule on the spoke subnet to allow UDP and TCP 53 to 10.8.0.4.Wrong answer — click to see why▾
Why this is wrong here
The issue is that the spoke VNet is not configured to use the hub DNS server for name resolution; NSG rules control traffic filtering, not DNS server assignment. Since connectivity via IP already works, an NSG rule is unnecessary and does not address the DNS configuration.
★ When this WOULD be the correct answer
This option would be correct if the spoke VNet already had the hub DNS server configured, but VMs in the spoke could not reach it due to network security rules blocking DNS traffic (UDP/TCP 53). In that scenario, adding an inbound NSG rule on the spoke subnet to allow traffic to 10.8.0.4 would resolve the connectivity issue.
Why candidates choose this
Candidates may think that since DNS uses port 53, a firewall or NSG rule is needed to allow the traffic, overlooking that the actual problem is the VNet's DNS server setting, not network security.
✗Create a service endpoint for Microsoft.Storage on the spoke subnet.Wrong answer — click to see why▾
Why this is wrong here
Service endpoints for Microsoft.Storage are used to secure Azure Storage resources to a VNet, not to configure DNS resolution. They do not affect how VMs resolve internal names like app01.corp.local.
★ When this WOULD be the correct answer
If the question were about securely accessing Azure Storage (e.g., a storage account) from a spoke VNet without using a public IP, configuring a service endpoint for Microsoft.Storage on the spoke subnet would be correct.
Why candidates choose this
Candidates may confuse service endpoints with DNS configuration because both involve network connectivity and IP addresses, leading them to think a service endpoint can direct DNS traffic to a specific server.
✗Add a user-defined route for 10.8.0.4/32 pointing to the virtual network gateway.Wrong answer — click to see why▾
Why this is wrong here
A user-defined route for 10.8.0.4/32 pointing to the virtual network gateway would not help because name resolution fails due to the spoke VNet not being configured to use the hub DNS server, not due to routing issues. The spoke VMs can already reach 10.8.0.4 by IP after peering, so routing is fine.
★ When this WOULD be the correct answer
This option would be correct if the spoke VNet could not reach the hub DNS server by IP due to asymmetric routing or a missing route. For example, if the hub and spoke are connected via a VPN gateway and the spoke needs a specific route to send DNS traffic through the gateway to the hub DNS server.
Why candidates choose this
Candidates may think that name resolution failure is caused by network connectivity issues and that adding a route to the DNS server IP will fix it, overlooking that the real problem is the VNet's DNS configuration.
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
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
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
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.