AZ-104 Implement and Manage Virtual Networking Practice Question
Two virtual networks were created in different subscriptions. VNet-A uses 10.4.0.0/16 and VNet-B uses 10.4.128.0/17. You try to create peering between them, but Azure rejects the request. What is the best fix?
⚠ Common exam trap
A common mix-up: candidates think adding a route table or enabling gateway transit can fix the overlap, but Azure enforces a strict non-overlapping address space requirement for VNet peering at the time of creation, and no routing configuration can bypass this fundamental constraint.
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 one VNet to a non-overlapping address range, then create the peering again.
VNet peering requires that the address spaces of the two virtual networks do not overlap. VNet-A uses 10.4.0.0/16, which covers 10.4.0.0 to 10.4.255.255, and VNet-B uses 10.4.128.0/17, which falls entirely within that range (10.4.128.0 to 10.4.255.255). Azure rejects the peering because overlapping address spaces would cause routing conflicts. The only correct fix is to change one VNet's address space to a non-overlapping range, then recreate 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 both VNets before creating the peering.
Why it's wrong here
Gateway transit is a peering feature that allows a peered VNet to use the VPN gateway in another VNet for connectivity to on-premises or other networks. It cannot be enabled before a peering exists, and it has no effect on the address space overlap validation that is performed when you create the peering. Even if you enabled gateway transit on both VNets, the overlapping address spaces would still cause the peering to fail, so this option provides no solution.
When this WOULD be correct
In a scenario where two VNets have non-overlapping address spaces and you need to allow a VPN-connected on-premises network to access resources in both VNets via a single VPN gateway, enabling gateway transit on one VNet and using the other as a spoke would be correct.
- ✗
Add a route table to one VNet so the address spaces no longer overlap.
Why it's wrong here
A route table (UDR) only influences the next hop for traffic leaving a subnet; it does not modify the VNet's assigned address space. Azure Peering validation checks for overlapping address ranges between the two VNets, and a route table cannot change the ranges that were declared when the VNets were created. Therefore, even if you add a route table to one VNet, the overlap remains and peering creation will continue to fail.
- ✓
Change one VNet to a non-overlapping address range, then create the peering again.
Why this is correct
VNet peering requires that the address spaces of the two VNets do not overlap, because overlapping ranges create routing ambiguity that Azure cannot resolve. To fix this, you must modify one VNet so its address space no longer overlaps the other—this can be done by removing the conflicting range if no subnets use it and adding a new non-overlapping range. After the address space is updated, you can then create the peering between the two VNets, even if they are in different subscriptions.
- ✗
Create a private endpoint between the two VNets instead of peering.
Why it's wrong here
A private endpoint is a network interface with a private IP in your VNet that connects to a specific supported Azure PaaS service, such as SQL Database or Storage. It is not a general-purpose connectivity solution between two VNets and cannot route traffic between arbitrary virtual machines or other resources in those VNets. Even if you deployed private endpoints, you would still have no VNet-to-VNet connectivity, so this option does not address the underlying peering requirement or the address overlap issue.
When this WOULD be correct
A question where you need to connect an on-premises network to an Azure PaaS service (e.g., Azure Storage, SQL Database) privately, without exposing it to the public internet, and the service is in a different VNet.
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 one VNet to a non-overlapping address range, then create the peering again.Correct answer▾
Why this is correct
VNet peering requires that the address spaces of the two VNets do not overlap, because overlapping ranges create routing ambiguity that Azure cannot resolve. To fix this, you must modify one VNet so its address space no longer overlaps the other—this can be done by removing the conflicting range if no subnets use it and adding a new non-overlapping range. After the address space is updated, you can then create the peering between the two VNets, even if they are in different subscriptions.
✗Enable gateway transit on both VNets before creating the peering.Wrong answer — click to see why▾
Why this is wrong here
Azure VNet peering requires non-overlapping address spaces; enabling gateway transit does not resolve address overlap, and peering will still fail.
★ When this WOULD be the correct answer
In a scenario where two VNets have non-overlapping address spaces and you need to allow a VPN-connected on-premises network to access resources in both VNets via a single VPN gateway, enabling gateway transit on one VNet and using the other as a spoke would be correct.
Why candidates choose this
Candidates may confuse gateway transit as a solution for overlapping address spaces, or think that enabling it somehow bypasses the address space requirement.
✗Create a private endpoint between the two VNets instead of peering.Wrong answer — click to see why▾
Why this is wrong here
Private endpoints are used for secure access to PaaS services over a private IP, not for connecting two VNets; they cannot replace VNet peering for inter-VNet connectivity.
★ When this WOULD be the correct answer
A question where you need to connect an on-premises network to an Azure PaaS service (e.g., Azure Storage, SQL Database) privately, without exposing it to the public internet, and the service is in a different VNet.
Why candidates choose this
Candidates may confuse private endpoints with VNet peering, thinking both provide private connectivity between VNets, but private endpoints are for service-specific access, not general VNet-to-VNet routing.
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
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.