AZ-104 Implement and Manage Virtual Networking Practice Question
Exhibit
Topology summary: - HubVNet: 10.40.0.0/16 - VM dns01: 10.40.0.4 - DNS service on dns01 hosts the zone corp.contoso.local - HubVNet DNS servers: 10.40.0.4 - SpokeVNet: 10.41.0.0/16 - Peered with HubVNet - Allow virtual network access: Enabled - Allow forwarded traffic: Enabled - DNS servers: Azure-provided - Test results from app01 in SpokeVNet: - ping 10.40.1.10 => success - nslookup web01.corp.contoso.local => NXDOMAIN - nslookup www.microsoft.com => success
Based on the exhibit, what should the administrator configure so the VM in the spoke VNet can resolve internal hostnames that are hosted on the DNS server in the hub VNet?
The team has already verified that IP connectivity between the spoke VM and the hub VM works.
⚠ Common exam trap
Many candidates confuse VNet peering's gateway transit feature with DNS settings inheritance, but gateway transit only applies to network gateway routes, not DNS server configuration.
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 SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly.
Setting the SpokeVNet DNS server list to 10.40.0.4 (the IP of the DNS server in the hub VNet) configures the spoke VNet to forward all DNS queries to that custom DNS server. Since IP connectivity between the VNets is already verified, the spoke VM can resolve internal hostnames hosted on the hub DNS server. This is the standard method for cross-VNet DNS resolution when using a custom DNS server in a hub-and-spoke topology.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Set the SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly.
Why this is correct
The spoke already has network connectivity to the hub, so the remaining problem is name resolution. Azure VNet peering does not copy DNS settings from one VNet to another. By configuring the spoke to use the hub DNS server, queries for the internal zone are sent to the resolver that actually hosts or forwards that namespace.
- ✗
Create a private endpoint for web01.corp.contoso.local in the spoke VNet so DNS resolves automatically.
Why it's wrong here
A private endpoint changes how a specific Azure service is reached, but it does not fix general DNS for a custom internal zone hosted on a VM. The failure shown is about resolving an internal hostname, not reaching a PaaS resource through a private IP.
When this WOULD be correct
If the question asked how to resolve a private endpoint's FQDN (e.g., mystorage.privatelink.blob.core.windows.net) from a spoke VM without using a custom DNS server, creating a private endpoint in the spoke VNet would enable automatic DNS resolution via Azure-provided DNS.
- ✗
Enable gateway transit on the peering so the spoke inherits the hub VNet DNS configuration.
Why it's wrong here
Gateway transit is used to share a VPN or ExpressRoute gateway, not to inherit DNS server settings across a peering. The exhibit already shows successful IP connectivity, so the issue is not transit routing. DNS must still be configured explicitly in the spoke.
When this WOULD be correct
This option would be correct if the question asked how to enable the spoke VNet to use the hub's VPN gateway to connect to an on-premises network, or to allow the spoke to route traffic through the hub's gateway for hybrid connectivity.
- ✗
Add inbound and outbound NSG rules allowing UDP and TCP port 53 between the two VNets.
Why it's wrong here
The exhibit shows the spoke VM can reach the hub VM by IP, which makes a basic network block less likely. More importantly, DNS server selection is controlled by VNet DNS settings and name resolution configuration, not by opening NSG rules alone.
When this WOULD be correct
If the question described that the spoke VM cannot reach the hub DNS server due to NSG blocking port 53, and IP connectivity was not verified, then adding NSG rules for UDP/TCP 53 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 SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly.Correct answer▾
Why this is correct
The spoke already has network connectivity to the hub, so the remaining problem is name resolution. Azure VNet peering does not copy DNS settings from one VNet to another. By configuring the spoke to use the hub DNS server, queries for the internal zone are sent to the resolver that actually hosts or forwards that namespace.
✗Create a private endpoint for web01.corp.contoso.local in the spoke VNet so DNS resolves automatically.Wrong answer — click to see why▾
Why this is wrong here
A private endpoint resolves DNS for a specific Azure service (e.g., Storage, SQL) within a VNet, not for custom internal hostnames like web01.corp.contoso.local hosted on a VM DNS server.
★ When this WOULD be the correct answer
If the question asked how to resolve a private endpoint's FQDN (e.g., mystorage.privatelink.blob.core.windows.net) from a spoke VM without using a custom DNS server, creating a private endpoint in the spoke VNet would enable automatic DNS resolution via Azure-provided DNS.
Why candidates choose this
Candidates may confuse private endpoints with general DNS resolution, thinking they can resolve any internal hostname, or they may overestimate the scope of private endpoint DNS capabilities.
✗Enable gateway transit on the peering so the spoke inherits the hub VNet DNS configuration.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit is used to route traffic through a VPN gateway or ExpressRoute gateway in the hub to on-premises or other networks, not to propagate DNS server settings across a peering. DNS server configuration is a VNet property, not inherited via peering.
★ When this WOULD be the correct answer
This option would be correct if the question asked how to enable the spoke VNet to use the hub's VPN gateway to connect to an on-premises network, or to allow the spoke to route traffic through the hub's gateway for hybrid connectivity.
Why candidates choose this
Candidates may confuse 'gateway transit' with 'DNS propagation' because both involve sharing resources across peered VNets, leading them to think DNS settings can be inherited like gateway routes.
✗Add inbound and outbound NSG rules allowing UDP and TCP port 53 between the two VNets.Wrong answer — click to see why▾
Why this is wrong here
The question states IP connectivity already works, so NSG rules for port 53 are unnecessary. The issue is DNS resolution configuration, not network security.
★ When this WOULD be the correct answer
If the question described that the spoke VM cannot reach the hub DNS server due to NSG blocking port 53, and IP connectivity was not verified, then adding NSG rules for UDP/TCP 53 would be correct.
Why candidates choose this
Candidates often default to checking NSG rules for DNS issues, overlooking that the problem is DNS server configuration rather than network security.
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
VNet Peering and Global VNet Peering
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.
Key term
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
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.