AZ-104 Implement and Manage Virtual Networking Practice Question
A company wants to peer a new spoke virtual network with an existing hub VNet. The hub uses 10.20.0.0/16. The spoke was created with 10.20.1.0/24 because that range was still available in the IPAM spreadsheet. VNet peering creation fails. What should the administrator do first?
⚠ Common exam trap
A common mix-up: candidates think overlapping address spaces can be resolved by routing or DNS changes, but Azure explicitly prohibits peering with overlapping ranges, and no configuration workaround exists—the address space must be changed.
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
✓
Change the spoke VNet address space to a non-overlapping range, then recreate or update peering.
VNet peering in Azure requires that the address spaces of the peered virtual networks do not overlap. The hub uses 10.20.0.0/16, and the spoke uses 10.20.1.0/24, which is a subset of the hub's range. This overlap causes the peering creation to fail. The administrator must first change the spoke's address space to a non-overlapping range (e.g., 10.21.0.0/24) and then recreate or update the peering.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable gateway transit on the hub and retry the peering.
Why it's wrong here
Gateway transit and remote gateway settings are optional peering features that allow a spoke to use the hub's VPN/ExpressRoute gateway for outbound connectivity; they do not change the requirement that peered VNets have distinct CIDR ranges. Enabling these flags on either side does not relax the address-space validation performed during peering creation. You must first resolve the overlap by renumbering the spoke, then recreate the peering and optionally enable gateway transit.
When this WOULD be correct
In a scenario where the hub VNet has a VPN gateway and the spoke VNet needs to access on-premises resources through the hub, but the spoke does not have its own gateway. Enabling gateway transit on the hub and configuring the spoke to use remote gateways would be the correct first step.
- ✗
Add a route table to the spoke subnet so the networks can communicate.
Why it's wrong here
A route table on the spoke subnet controls how traffic is forwarded via next-hop settings, but it is only relevant after peering establishes a working path. Overlapping address spaces cause the peering to fail during validation, long before any UDR could take effect. Even if a custom route forced traffic toward the hub, Azure's peering engine would still reject the configuration because the 10.20.1.0/24 range is contained within the hub's 10.20.0.0/16, making the address space disjointness check fail.
When this WOULD be correct
In a scenario where VNet peering is already established but traffic is not flowing between subnets, adding a route table with a user-defined route (UDR) to direct traffic to the peered VNet's gateway or appliance would be the correct first step.
- ✓
Change the spoke VNet address space to a non-overlapping range, then recreate or update peering.
Why this is correct
VNet peering requires the two virtual networks to have non-overlapping IP address spaces. Because the hub already uses 10.20.0.0/16, the spoke cannot use 10.20.1.0/24. The administrator must renumber the spoke to a different range, such as 10.21.0.0/16 or another approved block, before peering can succeed.
- ✗
Configure a custom DNS server in the spoke to translate the overlapping range.
Why it's wrong here
A custom DNS server in the spoke maps hostnames to IP addresses, but it cannot alter the network layer addressing used by peering. If the spoke's 10.20.1.0/24 overlaps the hub's 10.20.0.0/16, Azure still sees two VNets claiming the same prefix, so no peering link can be created. DNS would only provide name resolution—and if it returns overlapping addresses, it could actually cause traffic to be sent to the wrong VNet—so it cannot fix the underlying CIDR conflict.
When this WOULD be correct
This option would be correct in a scenario where VNet peering is successful but resources in the spoke cannot resolve names from the hub (or vice versa) due to default Azure DNS not handling custom domains, requiring a custom DNS server to enable name resolution across peered VNets.
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.
✓Change the spoke VNet address space to a non-overlapping range, then recreate or update peering.Correct answer▾
Why this is correct
VNet peering requires the two virtual networks to have non-overlapping IP address spaces. Because the hub already uses 10.20.0.0/16, the spoke cannot use 10.20.1.0/24. The administrator must renumber the spoke to a different range, such as 10.21.0.0/16 or another approved block, before peering can succeed.
✗Enable gateway transit on the hub and retry the peering.Wrong answer — click to see why▾
Why this is wrong here
The peering fails because the spoke VNet (10.20.1.0/24) overlaps with the hub VNet (10.20.0.0/16). Enabling gateway transit does not resolve address space overlap; it only allows the spoke to use the hub's VPN gateway for connectivity to on-premises networks.
★ When this WOULD be the correct answer
In a scenario where the hub VNet has a VPN gateway and the spoke VNet needs to access on-premises resources through the hub, but the spoke does not have its own gateway. Enabling gateway transit on the hub and configuring the spoke to use remote gateways would be the correct first step.
Why candidates choose this
Candidates may confuse peering connectivity issues with gateway transit settings, thinking that enabling transit will force traffic through the hub and resolve routing conflicts, without realizing that overlapping address spaces are a fundamental design flaw that must be fixed first.
✗Add a route table to the spoke subnet so the networks can communicate.Wrong answer — click to see why▾
Why this is wrong here
Adding a route table to the spoke subnet does not resolve the address overlap issue. VNet peering requires non-overlapping address spaces; routing cannot fix overlapping IP ranges.
★ When this WOULD be the correct answer
In a scenario where VNet peering is already established but traffic is not flowing between subnets, adding a route table with a user-defined route (UDR) to direct traffic to the peered VNet's gateway or appliance would be the correct first step.
Why candidates choose this
Candidates may think routing can solve connectivity issues between peered VNets, overlooking that peering itself fails due to overlapping address spaces, which is a prerequisite for peering.
✗Configure a custom DNS server in the spoke to translate the overlapping range.Wrong answer — click to see why▾
Why this is wrong here
The peering failure is due to overlapping address spaces (10.20.0.0/16 hub vs 10.20.1.0/24 spoke), not DNS resolution. Configuring a custom DNS server does not resolve the IP address overlap, which prevents peering from being established.
★ When this WOULD be the correct answer
This option would be correct in a scenario where VNet peering is successful but resources in the spoke cannot resolve names from the hub (or vice versa) due to default Azure DNS not handling custom domains, requiring a custom DNS server to enable name resolution across peered VNets.
Why candidates choose this
Candidates may confuse overlapping address space issues with DNS resolution problems, thinking that a custom DNS server can translate overlapping IPs or resolve connectivity issues, when in fact overlapping ranges must be fixed at the network layer.
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?”
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
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.