AZ-500 Secure networking Practice Question
You are designing a hub-and-spoke network topology with Azure Firewall in the hub VNet. Which TWO components are essential for routing traffic from spoke VNets through the firewall? (Choose two.)
⚠ Common exam trap
Test-takers frequently assume a VPN gateway or other gateway is required for routing traffic through a firewall in a hub-and-spoke topology, but Azure Firewall works with VNet peering and UDRs alone, without any gateway in the spoke.
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
✓
VNet peering between spoke and hub VNets
Option D is correct because VNet peering between each spoke and the hub VNet is the foundational connectivity that allows traffic to flow from spokes to the hub where Azure Firewall resides; without peering (or another connectivity method), spoke traffic cannot reach the firewall at all. Option E is correct because even with peering, Azure's default system routes would send internet-bound traffic directly out of the spoke, so user-defined routes (UDRs) in a route table must set 0.0.0.0/0 (and typically spoke-to-spoke prefixes) with a next hop of the Azure Firewall's private IP to force traffic through the firewall for inspection. Option A is incorrect because Azure Private DNS zones provide name resolution for private endpoints and are unrelated to traffic routing through a firewall. Option B is incorrect because Azure Bastion provides secure RDP/SSH access to VMs and does not influence packet routing between VNets. Option C is incorrect because a VPN gateway in each spoke is not required for hub-and-spoke firewall routing; VNet peering is the standard mechanism, and gateways are only needed for hybrid/on-premises connectivity, typically deployed in the hub.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Azure Private DNS zones
Why it's wrong here
Azure Private DNS zones provide name resolution within a virtual network by maintaining DNS records, but they do not participate in packet forwarding. In a hub-spoke design, spokes can link to a shared private DNS zone hosted in the hub to resolve private endpoints or VMs, but this has zero effect on the data-plane path. Routing decisions in Azure are driven by the system routes, VNet peering, and user-defined routes, not by DNS records.
- ✗
Azure Bastion host in the hub VNet
Why it's wrong here
An Azure Bastion host deployed in the hub is a managed PaaS service that enables secure RDP and SSH access to virtual machines over TLS, without exposing public IPs. It integrates with the network for management connectivity only and never forwards traffic between spoke VNets or enforces security policies on east-west traffic. Bastion's presence in the hub does not create any routing adjacency; it uses the hub's IP space but does not route data plane traffic.
- ✗
VPN gateway in each spoke VNet
Why it's wrong here
Placing a VPN gateway in each spoke VNet is unnecessary and architecturally incorrect for hub-spoke because VNet peering already establishes private, low-latency connectivity directly to the hub. VPN gateways are intended for site-to-site or point-to-site tunnels over the public internet, and they introduce additional cost, IPsec overhead, and configuration complexity without enabling inspection by the central firewall. Moreover, spoke-to-spoke traffic through individual VPN gateways would bypass the hub firewall entirely, defeating the security purpose of a hub-spoke topology.
- ✓
VNet peering between spoke and hub VNets
Why this is correct
VNet peering is the foundational connectivity mechanism in a hub-spoke topology; each spoke's virtual network is peered to the hub's virtual network to create a low-latency, high-bandwidth link over the Microsoft backbone. Peering is non-transitive, so spokes cannot communicate directly with each other unless they are both peered to the hub and the hub's route tables forward traffic between them. When combined with user-defined routes and a network virtual appliance like Azure Firewall, peering enables controlled east-west and hub-originated traffic without a VPN gateway.
- ✓
Route tables with default route to Azure Firewall private IP
Why this is correct
A route table (UDR) associated with spoke subnets is required to override Azure's default system routes and force all outbound traffic to the Azure Firewall's private IP address as the next hop. The route entries specify the virtual appliance as the next hop type, and the next hop IP is the firewall's private IP, which ensures that traffic from workloads is inspected and filtered centrally. Without these routes, peered spokes would use the default system route that allows direct connectivity, causing traffic to bypass the firewall and breaking the security architecture.
Visual reference
Go deeper
Related to this question
About these practice questions
This AZ-500 question is part of Courseiva's 617-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.