AZ-500 Secure networking Practice Question
Which THREE of the following are required to enable network traffic flow between two peered Azure virtual networks in different Azure regions?
⚠ Common exam trap
Test-takers frequently confuse optional features like gateway transit or NSG rules as mandatory requirements for VNet peering, when in fact only the peering settings and non-overlapping address spaces are required for basic traffic flow.
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
✓
Both VNets must have the Allow virtual network access setting enabled for the peering.
Option A is correct because each side of a VNet peering link has an 'Allow virtual network access' setting that must be enabled so the peered VNet's address space is reachable; if it is disabled, traffic to that VNet is blocked even though the peering exists. Option B is correct because when traffic is routed through a network virtual appliance in the peered VNet, the receiving peering must have 'Allow forwarded traffic' enabled, otherwise traffic not originating from the peered VNet's own address space is dropped. Option E is correct because VNet peering requires the address spaces of the two VNets to be non-overlapping; overlapping prefixes make routing ambiguous and the peering cannot be created. Option C is not required: gateway transit only matters when sharing a VPN/ExpressRoute gateway, not for basic VNet-to-VNet traffic flow. Option D is not required: NSGs are optional security filters, and peering itself does not depend on an NSG rule allowing traffic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Both VNets must have the Allow virtual network access setting enabled for the peering.
Why this is correct
The 'Allow virtual network access' setting is the master switch that permits the two virtual networks to communicate directly through peering. Both peering links must have it enabled; if one side disables it, traffic from that VNet will not be allowed to pass to the other. Without this setting, no other peering features (forwarded traffic or gateway transit) matter.
- ✓
If using a network virtual appliance, the Allow forwarded traffic setting must be enabled.
Why this is correct
When a network virtual appliance (NVA) is placed in the path, it receives packets whose destination IP is not the NVA itself and then forwards them toward their final destination. To allow peering to accept these forwarded packets, the 'Allow forwarded traffic' setting must be enabled on the peering connection; otherwise, the NVA's outbound traffic will be dropped at the peering boundary. This is separate from the basic peering traffic flow, which only handles packets originated in the source VNet.
- ✗
Gateway transit must be enabled in at least one VNet.
Why it's wrong here
Gateway transit is a peering feature that lets a spoke VNet use a virtual network gateway (VPN or ExpressRoute) placed in a hub VNet to reach on-premises or other networks. It is not a prerequisite for VNet peering itself; direct VNet-to-VNet traffic works without any gateway. Therefore, enabling gateway transit in at least one VNet is unnecessary for basic peering connectivity and only matters when you specifically need to share the hub's gateway.
- ✗
An NSG rule must allow traffic between the VNets.
Why it's wrong here
Network security groups (NSGs) are an optional layer of filtering, not an enabler of connectivity. When two VNets are peered, their address spaces become routable to each other by default, and the default NSG rules permit all traffic inside a VNet; given that peering treats the paired VNets as a single network, no explicit NSG allow rule is needed for traffic to flow. In fact, if you create an NSG with restrictive rules, it could block peering traffic, but simply not having an NSG does not prevent connectivity.
- ✓
The address spaces of the VNets must not overlap.
Why this is correct
Virtual network peering requires that the address spaces of the two VNets be distinct and non-overlapping. Azure uses the address ranges to create system routes for the peering; if ranges overlap, routing becomes ambiguous and Azure will not establish the peering. This constraint also forces careful IP address planning before deploying peered VNets.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-500 question from scratch — 617 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-500 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-500 exam.