AZ-305 Design infrastructure solutions Practice Question
Your company has an Azure subscription that contains a hub virtual network and multiple spoke virtual networks connected via VNet peering. You need to ensure that all traffic between spokes is routed through a network virtual appliance (NVA) in the hub. The NVA is configured with IP forwarding enabled. What should you configure in the spoke virtual networks?
⚠ Common exam trap
A common mix-up: candidates confuse NSG rules (which filter traffic) with route tables (which direct traffic), leading them to choose Option B, but NSGs cannot force traffic through an NVA—they only allow or deny traffic at the subnet or NIC level.
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
✓
Add route tables to the spoke subnets with a default route (0.0.0.0/0) pointing to the NVA's private IP.
Adding a route table to the spoke subnets with a default route (0.0.0.0/0) pointing to the NVA's private IP forces all outbound traffic from the spoke, including traffic destined for other spokes, to be forwarded to the NVA. The NVA, with IP forwarding enabled, can then inspect and route the traffic to the target spoke. This ensures the desired traffic flow through the hub without requiring any changes to the VNet peering configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Deploy a VPN gateway in each spoke and configure site-to-site VPNs.
Why it's wrong here
Deploying a VPN gateway in each spoke and configuring site-to-site VPNs is incorrect because it introduces unnecessary cost and complexity, and VPN gateways do not automatically redirect spoke-to-spoke traffic through a hub NVA. For traffic between peered VNets to traverse a central NVA, you need to override the direct peering route with a user-defined route (UDR), not an encrypted tunnel. Even with VPN gateways, you would still have to define UDRs to force traffic through the gateways, and the NVA in the hub would not be in the path unless explicitly routed. Thus, this approach fails to meet the requirement while adding significant overhead.
- ✗
Configure NSG rules to block direct spoke-to-spoke traffic.
Why it's wrong here
Configuring NSG rules to block direct spoke-to-spoke traffic is wrong because NSGs are stateful packet filters, not routing devices. An NSG can only allow or deny traffic based on source/destination IP and port, but it cannot change the next hop or force traffic to traverse an NVA. Blocking direct traffic would simply drop packets, which is not the same as routing them through the hub NVA. The correct solution must modify the routing table, not add filtering rules, because the issue is about path selection, not access control.
- ✓
Add route tables to the spoke subnets with a default route (0.0.0.0/0) pointing to the NVA's private IP.
Why this is correct
Adding route tables to the spoke subnets with a default route (0.0.0.0/0) pointing to the NVA's private IP is correct because it creates a user-defined route (UDR) that overrides the system route for peered VNets. When the next hop type is set to 'Virtual appliance' and the NVA's private IP is specified, all outbound traffic from that subnet—including traffic destined for other spoke VNets—is forced through the NVA in the hub. This works because UDRs take precedence over the automatically propagated routes from VNet peering. To ensure spoke-to-spoke traffic flows correctly, the NVA must have IP forwarding enabled, and the hub subnet containing the NVA must allow the traffic.
- ✗
Enable BGP on the VNet peerings.
Why it's wrong here
Enabling BGP on VNet peerings is incorrect because BGP is a dynamic routing protocol used with VPN gateways and ExpressRoute, not with VNet peering. VNet peering automatically exchanges routes between peered networks without any BGP configuration; there is no BGP setting to enable on a peering connection. Even if BGP were somehow enabled, it does not provide a mechanism to redirect traffic through an NVA—it only exchanges routing information. Therefore, this option has no effect on forcing spoke-to-spoke traffic through the hub NVA and is technically invalid in the Azure VNet peering context.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 795 original AZ-305 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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-305 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-305 exam.