AZ-104 Implement and Manage Virtual Networking Practice Question
Exhibit
Hub VNet address space: 10.20.0.0/16 Spoke VNet address space: 10.20.1.0/24 Planned action: Create VNet peering between Hub and Spoke Portal message: The address spaces overlap and cannot be peered.
Based on the exhibit, what should the administrator do so the hub and spoke can be peered successfully?
⚠ Common exam trap
Watch out — candidates often think overlapping subnets can be worked around by using NSGs or gateway transit, but Azure VNet peering strictly requires non-overlapping VNet address spaces at the time of peering creation.
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 to a non-overlapping address space.
VNet peering requires that the address spaces of the peered VNets do not overlap. Overlapping IP ranges cause routing conflicts and prevent successful peering. Changing the spoke VNet to a non-overlapping address space resolves this issue and allows the peering to be established.
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 the current ranges and enable gateway transit on the peering.
Why it's wrong here
Enabling gateway transit on the peering only tells the spoke to use the hub's VPN/ExpressRoute gateway for outbound connectivity; it does not change either VNet's IP address space. Because Azure refuses to create a peering connection when the ranges overlap, the peering does not exist, so this setting can never be applied or take effect. The overlapping address space must be resolved first.
When this WOULD be correct
If the VNets had non-overlapping address spaces and the hub had a VPN gateway, enabling gateway transit on the peering would allow the spoke to use the hub's gateway for connectivity to on-premises networks.
- ✓
Change the spoke VNet to a non-overlapping address space.
Why this is correct
Azure VNet peering requires that the address spaces of the two virtual networks do not overlap, so the spoke's current CIDR range is blocking the connection. You must change the spoke to a non-overlapping address space—usually by recreating the VNet with a unique range or by adding a new non-conflicting prefix and migrating resources—before peering can be established. This is the only remediation that removes the underlying route conflict with the hub.
- ✗
Add another subnet inside the spoke VNet and reuse the current address space.
Why it's wrong here
Adding another subnet inside the spoke VNet does not remove or change the existing overlapping address space; Azure evaluates the entire VNet's CIDR blocks, not just individual subnets, when establishing peering. The original spoke range still collides with the hub's range, so peering creation fails regardless of any new subnet's availability. In fact, a subnet's range must always be a subset of its VNet's address space, so this approach cannot eliminate the conflict.
When this WOULD be correct
This option would be correct if the question asked how to isolate workloads within a spoke VNet that has non-overlapping address space, and the goal was to segment traffic using additional subnets without changing the overall VNet address range.
- ✗
Create a network security group on the spoke subnet before peering.
Why it's wrong here
Creating a network security group (NSG) and attaching it to the spoke subnet only filters inbound and outbound traffic flows; it has no bearing on whether Azure can establish VNet peering. Peering operates at the control plane and routing layer, while NSGs are a separate security layer applied to interfaces or subnets. Thus an NSG cannot fix the overlapping address space or enable the peering to be created.
When this WOULD be correct
This option would be correct in a scenario where the administrator needs to restrict inbound or outbound traffic to/from the spoke subnet after peering is established. For example, if the question asked: 'What should the administrator do to secure traffic between the hub and spoke 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 to a non-overlapping address space.Correct answer▾
Why this is correct
Azure VNet peering requires that the address spaces of the two virtual networks do not overlap, so the spoke's current CIDR range is blocking the connection. You must change the spoke to a non-overlapping address space—usually by recreating the VNet with a unique range or by adding a new non-conflicting prefix and migrating resources—before peering can be established. This is the only remediation that removes the underlying route conflict with the hub.
✗Keep the current ranges and enable gateway transit on the peering.Wrong answer — click to see why▾
Why this is wrong here
The hub and spoke VNets have overlapping address ranges (10.1.0.0/16), which prevents peering. Enabling gateway transit does not resolve address overlap; peering requires non-overlapping address spaces.
★ When this WOULD be the correct answer
If the VNets had non-overlapping address spaces and the hub had a VPN gateway, enabling gateway transit on the peering would allow the spoke to use the hub's gateway for connectivity to on-premises networks.
Why candidates choose this
Candidates may confuse gateway transit as a solution for all peering issues, not realizing it only applies to gateway connectivity, not address overlap.
✗Add another subnet inside the spoke VNet and reuse the current address space.Wrong answer — click to see why▾
Why this is wrong here
Adding another subnet inside the spoke VNet does not resolve the overlapping address space issue; the hub and spoke VNets still have conflicting IP ranges, which prevents successful peering.
★ When this WOULD be the correct answer
This option would be correct if the question asked how to isolate workloads within a spoke VNet that has non-overlapping address space, and the goal was to segment traffic using additional subnets without changing the overall VNet address range.
Why candidates choose this
Candidates may think that adding a subnet can somehow fix the overlap, or they confuse subnet-level isolation with VNet-level address space conflicts, not realizing that peering requires non-overlapping VNet ranges.
✗Create a network security group on the spoke subnet before peering.Wrong answer — click to see why▾
Why this is wrong here
The question is about resolving overlapping address spaces between hub and spoke VNets for successful peering. Creating a network security group (NSG) on the spoke subnet does not address the address overlap issue; NSGs control traffic filtering, not IP address conflicts.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the administrator needs to restrict inbound or outbound traffic to/from the spoke subnet after peering is established. For example, if the question asked: 'What should the administrator do to secure traffic between the hub and spoke VNets?'
Why candidates choose this
Candidates may think that applying an NSG is a necessary step before peering to ensure security, or they might confuse subnet-level security requirements with the prerequisite of non-overlapping address spaces.
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
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
Key term
VNet peering
VNet peering is a networking connection that links two virtual networks so they can communicate with each other as if they were a single network.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.