This AZ-104 practice question tests your understanding of implement and manage virtual networking. This is a configuration task: choose the command set that satisfies every stated requirement. Small differences — like 'secret' vs 'password' or 'transport input ssh' vs 'all' — change whether the answer is correct. A key principle to apply: azure VNet peering provides IP connectivity, not DNS configuration inheritance.. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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.
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
A
Set the SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly.
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.
B
Create a private endpoint for web01.corp.contoso.local in the spoke VNet so DNS resolves automatically.
Why wrong: 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.
C
Enable gateway transit on the peering so the spoke inherits the hub VNet DNS configuration.
Why wrong: 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.
D
Add inbound and outbound NSG rules allowing UDP and TCP port 53 between the two VNets.
Why wrong: 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.
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.
Option A is correct because 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.
Key principle: Azure VNet peering provides IP connectivity, not DNS configuration inheritance.
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.
Related concept
Azure VNet peering provides IP connectivity, not DNS configuration inheritance.
✗
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 VPNgateway 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?”
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates often confuse VNet peering's gateway transit feature with DNS settings inheritance, but gateway transit only applies to network gateway routes, not DNS server configuration.
Trap categories for this question
Command / output trap
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.
Detailed technical explanation
How to think about this question
When you set a custom DNS server on a VNet (e.g., 10.40.0.4), Azure changes the DHCP option for VMs in that VNet to use that IP as the DNS resolver. For cross-VNet resolution, the hub DNS server must be configured as a forwarder or authoritative for the internal zone (e.g., corp.contoso.local). Azure DNS Private Resolver can also be used for hybrid scenarios, but in this case, a simple custom DNS server list on the spoke VNet is sufficient. Note that VNet peering does not automatically replicate DNS settings; each VNet maintains its own DNS configuration.
KKey Concepts to Remember
Azure VNet peering provides IP connectivity, not DNS configuration inheritance.
Each Azure VNet maintains its own independent DNS server settings.
To resolve custom internal hostnames, VMs must query the authoritative DNS server.
VNet DNS settings are configured at the VNet level and apply to all VMs within it.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Azure VNet peering provides IP connectivity, not DNS configuration inheritance.
Real-world example
How this comes up in practice
An e-commerce site experiences heavy traffic on Black Friday and near-zero traffic during off-peak weeks. Rather than provisioning permanent large VMs, the team uses auto-scaling groups that add capacity automatically under load and reduce it overnight. Questions like this test whether you understand elasticity, availability zones, and cloud compute scaling patterns.
Visual reference
Related glossary terms
Concepts from this question explained
These glossary pages explain the core terms tested in this AZ-104 question in full detail.
Review azure VNet peering provides IP connectivity, not DNS configuration inheritance., then practise related AZ-104 questions on the same topic to reinforce the concept.
Implement and Manage Virtual Networking — This question tests Implement and Manage Virtual Networking — Azure VNet peering provides IP connectivity, not DNS configuration inheritance..
What is the correct answer to this question?
The correct answer is: Set the SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly. — Option A is correct because 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.
What should I do if I get this AZ-104 question wrong?
Review azure VNet peering provides IP connectivity, not DNS configuration inheritance., then practise related AZ-104 questions on the same topic to reinforce the concept.
What is the key concept behind this question?
Azure VNet peering provides IP connectivity, not DNS configuration inheritance.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
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. Based on the exhibit, what configuration should the administrator change so VMs in the spoke can resolve internal names from the hub?
easy
A.Add a route table entry that points to the hub DNS server.
✓ B.Set the spoke VNet custom DNS server to 10.50.0.4.
C.Enable a service endpoint for Microsoft.Storage on the spoke subnet.
D.Create a private endpoint for the spoke VM subnet.
Why B: The hub VNet has a DNS server at 10.50.0.4 that is configured to resolve internal names. By setting the spoke VNet's custom DNS server to 10.50.0.4, VMs in the spoke will forward DNS queries to that server, enabling resolution of internal names from the hub. This overrides the default Azure-provided DNS and directs name resolution to the hub's DNS infrastructure.
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.