AZ-104 Implement and Manage Virtual Networking Practice Question
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?
⚠ Common exam trap
A common mix-up: candidates confuse DNS resolution with routing or gateway transit, thinking they need to add a UDR or enable gateway features to forward DNS queries, when the real fix is simply changing the DNS server setting on the spoke VNet to point to the hub's DNS server IP.
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 to use 10.50.0.4 as a custom DNS server.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a private DNS zone for corp.local and link it only to the spoke subnet.
Why it's wrong here
Creating a private DNS zone for corp.local and linking it only to the spoke subnet introduces a separate Azure DNS namespace that is resolved from the Azure provided resolver (168.63.129.16), not from your existing DNS VM. It would only answer records you manually create in that zone, and because the link is only on the spoke, hub VNets and on-premises cannot use the zone unless you add more links and configure hybrid resolution. Most importantly, if the spoke VMs are already configured to use 10.50.0.4 as their DNS server, they will ignore the private zone unless the hub DNS server is set to forward corp.local queries to Azure DNS; this option solves neither centralized resolution nor existing custom DNS integration.
When this WOULD be correct
If the company wanted to use Azure-provided DNS resolution for a custom domain (e.g., corp.local) without deploying a custom DNS server, they would create a private DNS zone for corp.local and link it to the spoke virtual network (or subnet) to enable automatic resolution via Azure DNS.
- ✓
Set the spoke virtual network to use 10.50.0.4 as a custom DNS server.
Why this is correct
Configuring the spoke VNet with the hub DNS server IP sends name-resolution requests to the centralized server. Because VNet peering already provides network connectivity, the spoke can query 10.50.0.4 directly for internal names without deploying a second DNS server.
- ✗
Add a user-defined route in the spoke to send DNS traffic to the hub VNet.
Why it's wrong here
A user-defined route only changes the next hop for packets; it does not change which DNS server address the OS uses to send name queries. If the spoke VNet's DNS servers remain set to Azure-provided DNS, each VM's resolver will target 168.63.129.16, and a route pushing that traffic toward the hub VNet will not make the queries reach 10.50.0.4 or cause that server to be consulted. To use the hub DNS VM, you must explicitly set the spoke VNet's custom DNS server list to 10.50.0.4; a route is irrelevant and cannot override DHCP-provided DNS settings.
When this WOULD be correct
A UDR would be correct if the spoke VMs needed to route traffic to a specific network appliance (e.g., firewall or NVA) in the hub for inspection, and the default route (0.0.0.0/0) or a specific subnet needed to be forced through that appliance.
- ✗
Enable gateway transit on the peering and set use remote gateways on the spoke.
Why it's wrong here
Enabling gateway transit on the peering and setting 'use remote gateways' on the spoke controls how traffic reaches on-premises networks through the hub's VPN/ExpressRoute gateway. It has no effect on DNS: it does not update the DNS server list on the spoke VNet, does not make the hub DNS VM resolvable to internal names, and does not alter how VMs resolve corp.local. In fact, 'use remote gateways' is only valid when the hub has a virtual network gateway and the spoke has no gateway; it is a routing feature for site-to-site connectivity, not a name-resolution setting.
When this WOULD be correct
An administrator needs to allow a spoke VNet to use a hub's VPN gateway to connect to on-premises networks. In that scenario, enabling gateway transit on the hub peering and setting 'Use 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 to use 10.50.0.4 as a custom DNS server.Correct answer▾
Why this is correct
Configuring the spoke VNet with the hub DNS server IP sends name-resolution requests to the centralized server. Because VNet peering already provides network connectivity, the spoke can query 10.50.0.4 directly for internal names without deploying a second DNS server.
✗Create a private DNS zone for corp.local and link it only to the spoke subnet.Wrong answer — click to see why▾
Why this is wrong here
A private DNS zone linked only to the spoke subnet would require a DNS server in the spoke to resolve names, but the company wants to keep DNS centralized on the hub's DNS server (10.50.0.4). This option does not direct DNS queries to the hub server.
★ When this WOULD be the correct answer
If the company wanted to use Azure-provided DNS resolution for a custom domain (e.g., corp.local) without deploying a custom DNS server, they would create a private DNS zone for corp.local and link it to the spoke virtual network (or subnet) to enable automatic resolution via Azure DNS.
Why candidates choose this
Candidates may think that a private DNS zone is the standard way to resolve custom domain names in Azure, but they overlook that the existing DNS server in the hub is already hosting those names and needs to be used as the DNS server for the spoke.
✗Add a user-defined route in the spoke to send DNS traffic to the hub VNet.Wrong answer — click to see why▾
Why this is wrong here
A user-defined route (UDR) controls network traffic paths, not DNS resolution. DNS traffic to 10.50.0.4 already works via the peering; the issue is that the spoke VMs are not configured to use that IP as their DNS server, so a UDR does not solve name resolution.
★ When this WOULD be the correct answer
A UDR would be correct if the spoke VMs needed to route traffic to a specific network appliance (e.g., firewall or NVA) in the hub for inspection, and the default route (0.0.0.0/0) or a specific subnet needed to be forced through that appliance.
Why candidates choose this
Candidates may confuse routing with DNS resolution, thinking that directing DNS traffic to the hub server via a route will enable name resolution, but DNS server configuration is required on the virtual network, not routing.
✗Enable gateway transit on the peering and set use remote gateways on the spoke.Wrong answer — click to see why▾
Why this is wrong here
Enabling gateway transit and using remote gateways is for routing traffic through VPN/ExpressRoute gateways, not for DNS resolution. This option does not configure the spoke VNet to use the hub's DNS server.
★ When this WOULD be the correct answer
An administrator needs to allow a spoke VNet to use a hub's VPN gateway to connect to on-premises networks. In that scenario, enabling gateway transit on the hub peering and setting 'Use remote gateways' on the spoke peering would be correct.
Why candidates choose this
Candidates may confuse the concept of gateway transit (used for routing) with DNS forwarding or resolution, thinking that enabling a transit mechanism will also forward DNS queries to the hub.
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
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.