AZ-500 Secure networking Practice Question

You are designing a hub-spoke network topology in Azure. You need to ensure that all traffic between spokes is inspected by a network virtual appliance (NVA) deployed in the hub. What should you configure?

⚠ Common exam trap

Many exam-takers assume Azure Firewall is the only way to inspect traffic, but the question explicitly mentions an NVA, so the correct answer is configuring UDRs to force traffic through that NVA's IP address.

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

✓

Create user-defined routes (UDRs) in each spoke pointing to the NVA's IP address.

To force all inter-spoke traffic through a network virtual appliance (NVA) in the hub, you must create user-defined routes (UDRs) in each spoke's subnet that direct traffic destined for other spoke address spaces to the NVA's private IP address. This overrides the default system route that would otherwise allow direct communication over VNet peering, ensuring the NVA inspects every packet.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Create user-defined routes (UDRs) in each spoke pointing to the NVA's IP address.
Why this is correct
In a hub-spoke architecture with an NVA, you must explicitly insert the appliance into the data path. Create a route table on each spoke subnet that needs inspection, add routes for other spoke prefixes (or 0.0.0.0/0) with the NVA's private IP as the next hop, and associate that table to the subnet. Also enable IP forwarding on the NVA's NIC; otherwise the NVA will drop traffic not addressed to itself. Without these UDRs, VNet peering still allows direct spoke-to-spoke traffic and bypasses the NVA completely.
✗
Deploy Azure Firewall in the hub.
Why it's wrong here
Azure Firewall is a fully managed, platform-as-a-service firewall, not a network virtual appliance that you deploy and operate as a VM. The requirement is to use an NVA, and Azure Firewall cannot act as that NVA because it has no VM image, no custom routing software, and you don't control its underlying routing. Even if you placed Azure Firewall in the hub, you would still need UDRs pointing to its private IP for inspection, but that still doesn't satisfy the explicit 'NVA' requirement. It is wrong because it replaces the NVA with a different service, not because it can't inspect traffic.
✗
Configure VNet peering between all spokes.
Why it's wrong here
VNet peering is non-transitive and creates a direct, layer-3 connection between the peered VNets. If you peer all spokes together, traffic from one spoke to another flows directly across that peering, completely bypassing the hub and any NVA firewall deployed there. In a hub-spoke design you should only peer each spoke to the hub, then force inter-spoke traffic through the hub NVA using UDRs. Direct spoke-to-spoke peering defeats the security inspection requirement and therefore does not meet the design goal.
✗
Use a VPN gateway to route traffic through the hub.
Why it's wrong here
A VPN gateway in the hub is designed for encrypted IPsec tunnel termination between Azure and on-premises networks or between VNets; it forwards packets based on its routing table and does not perform stateful inspection or content filtering like an NVA. Placing a VPN gateway in the hub does not by itself route spoke-to-spoke traffic through it because peered spokes use the Azure backbone directly, not the gateway. To actually force traffic through an NVA you need UDRs with the NVA IP as the next hop; a VPN gateway cannot serve as that next hop for inspection traffic. It is wrong because it provides connectivity, not inspection.

Visual reference

Go deeper

AZ-500 Secure networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question