AZ-104 Implement and Manage Virtual Networking Practice Question
Exhibit
Hub VNet DNS server: 10.20.0.4 Spoke VNet DNS server setting: Azure-provided Test from spoke VM: ping 10.20.0.4 Success nslookup app01.corp.local Server failed to find app01.corp.local: NXDOMAIN Hub and spoke are already peered.
Based on the exhibit, VM name resolution works for IP addresses but fails for internal hostnames. What should the administrator configure on the spoke VNet?
⚠ Common exam trap
It's easy for candidates to assume Azure-provided DNS can resolve custom hostnames across peered VNets, but it only resolves names within the same VNet unless a custom DNS server or Azure Private DNS Zone is configured.
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.20.0.4 as a custom DNS server.
The hub VNet uses a custom DNS server at 10.20.0.4 (likely a Windows Server with DNS role) that can resolve internal hostnames like app01.corp.local. The spoke VNet is currently using Azure-provided DNS, which cannot resolve custom private DNS zones. By configuring the spoke VNet to use 10.20.0.4 as a custom DNS server, the spoke VMs will forward DNS queries to the hub DNS server, enabling hostname resolution for internal resources.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Keep Azure-provided DNS because the spoke can already reach the hub by IP.
Why it's wrong here
Even if a spoke VM can reach 10.20.0.4 by IP, its DNS client configuration still points to Azure-provided DNS (168.63.129.16). That service resolves only Azure-internal VNet names and public DNS names, not custom AD zones like corp.local. Therefore, the spoke's VM will not consult the hub DNS server unless you explicitly change the VNet's DNS servers to 10.20.0.4. Reachability by IP is irrelevant; the OS sends every name query to its configured resolver.
When this WOULD be correct
This option would be correct if the question stated that VM name resolution works for internal hostnames but fails for IP addresses, or if the requirement was to use Azure-provided DNS for name resolution without needing to resolve custom private DNS zones.
- ✓
Configure the spoke VNet to use 10.20.0.4 as a custom DNS server.
Why this is correct
The exhibit shows the hub has a custom DNS server at 10.20.0.4, but the spoke is still using Azure-provided DNS. To resolve internal names such as app01.corp.local, the spoke VNet must point to the custom DNS server that knows that zone. After that change, VMs in the spoke can use the hub DNS service for name resolution.
- ✗
Create a private endpoint for app01.corp.local in the spoke VNet.
Why it's wrong here
A private endpoint is intended to connect to specific Azure PaaS services (for example, Storage accounts or SQL Database) by giving them a private IP inside a VNet, and it works with Azure Private DNS zones that are scoped to those services. It cannot be created for an arbitrary VM hostname such as app01.corp.local because there is no underlying PaaS resource to attach to. Even if one existed, the core problem is that the spoke's VM is not using the custom DNS server at 10.20.0.4, so no DNS query for that name ever reaches the correct server. A private endpoint does not change DNS resolver configuration and would not resolve the issue here.
When this WOULD be correct
A question where an Azure service (e.g., Azure SQL Database) is hosted in a hub VNet and must be accessed privately from a spoke VNet without traversing the internet. The correct answer would be to create a private endpoint for that service in the spoke VNet.
- ✗
Enable a NAT gateway on the spoke subnet.
Why it's wrong here
A NAT gateway is used to provide outbound internet connectivity from a subnet by translating private source IPs to a public IP. It operates at Layer 3/4 and does not intercept or answer DNS queries, nor does it modify a VM's DNS server list. DNS resolution for app01.corp.local depends on the DNS resolver configured in the VM's TCP/IP stack, which remains unchanged regardless of NAT. Thus, enabling a NAT gateway cannot make the custom internal name resolvable.
When this WOULD be correct
In a scenario where VMs in a spoke VNet need to access the internet through a static public IP (e.g., for outbound traffic from a private subnet), enabling a NAT gateway on the spoke subnet 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.
✓Configure the spoke VNet to use 10.20.0.4 as a custom DNS server.Correct answer▾
Why this is correct
The exhibit shows the hub has a custom DNS server at 10.20.0.4, but the spoke is still using Azure-provided DNS. To resolve internal names such as app01.corp.local, the spoke VNet must point to the custom DNS server that knows that zone. After that change, VMs in the spoke can use the hub DNS service for name resolution.
✗Keep Azure-provided DNS because the spoke can already reach the hub by IP.Wrong answer — click to see why▾
Why this is wrong here
The issue is that internal hostname resolution fails, meaning the spoke VNet cannot resolve names like app01.corp.local. Keeping Azure-provided DNS does not resolve custom internal hostnames; it only provides Azure-assigned names. The spoke needs a custom DNS server (like the hub's DNS at 10.20.0.4) to forward queries to resolve those names.
★ When this WOULD be the correct answer
This option would be correct if the question stated that VM name resolution works for internal hostnames but fails for IP addresses, or if the requirement was to use Azure-provided DNS for name resolution without needing to resolve custom private DNS zones.
Why candidates choose this
Candidates may think that since IP connectivity works, DNS is fine, but they overlook that Azure-provided DNS cannot resolve custom internal hostnames without additional configuration like a custom DNS server or private DNS zones.
✗Create a private endpoint for app01.corp.local in the spoke VNet.Wrong answer — click to see why▾
Why this is wrong here
A private endpoint is used to securely access Azure PaaS services over a private IP, not to resolve internal hostnames like app01.corp.local. DNS resolution for custom domains requires a custom DNS server or Azure Private DNS zones, not a private endpoint.
★ When this WOULD be the correct answer
A question where an Azure service (e.g., Azure SQL Database) is hosted in a hub VNet and must be accessed privately from a spoke VNet without traversing the internet. The correct answer would be to create a private endpoint for that service in the spoke VNet.
Why candidates choose this
Candidates may confuse private endpoints with DNS resolution capabilities, thinking they can resolve any hostname privately, or they may misapply the concept of private endpoints for general name resolution instead of specific Azure PaaS services.
✗Enable a NAT gateway on the spoke subnet.Wrong answer — click to see why▾
Why this is wrong here
A NAT gateway provides outbound internet connectivity for VMs in a subnet, but it does not resolve internal hostnames. The issue is DNS resolution for internal names, which requires a DNS server, not NAT.
★ When this WOULD be the correct answer
In a scenario where VMs in a spoke VNet need to access the internet through a static public IP (e.g., for outbound traffic from a private subnet), enabling a NAT gateway on the spoke subnet would be correct.
Why candidates choose this
Candidates may confuse network address translation with DNS resolution, or think that enabling outbound connectivity somehow helps with name resolution, especially when the hub is reachable by IP but not by name.
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
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.