What is hub-spoke topology and why does AZ-700 test it heavily?
Hub-spoke topology is a network design where a central virtual network (the hub) hosts shared services like firewalls, VPN gateways, and DNS, and multiple peripheral virtual networks (spokes) connect to the hub for centralized policy enforcement and cross-segment routing. The AZ-700 exam tests hub-spoke because it is the Microsoft-recommended landing zone topology, used in the Cloud Adoption Framework and the Azure Architecture Center. Candidates who do not understand non-transitive peering, user-defined routes, gateway transit, and route propagation lose roughly twenty-five percent of the exam.
AZ-700 is the Microsoft Azure Network Engineer Associate exam. It is one of the deepest networking certifications in the Microsoft track and tests exactly the design patterns that production architectures use. Hub-spoke is the topology that ties together VNet peering, ExpressRoute, VPN, Azure Firewall, route tables, and DNS. Understanding it deeply unlocks roughly half the exam.
Why Microsoft Recommends Hub-Spoke
Microsoft's Cloud Adoption Framework explicitly recommends hub-spoke as the default landing zone topology for organizations with more than a single workload. Three reasons drive this guidance.
Centralized security: a single Azure Firewall, network virtual appliance, or DDoS protection plan in the hub protects every spoke without per-spoke duplication.
Cost control: shared services -- VPN gateway, ExpressRoute gateway, Bastion -- run once in the hub instead of N times across spokes.
Operational segmentation: each spoke can be owned by a different team or business unit while the hub remains under central network operations.
The exam's most common scenario describes an organization migrating from a flat single-VNet design to multiple workloads requiring separation. The correct answer is hub-spoke. Candidates who select mesh peering or per-workload independent VNets lose the question.
"Hub-spoke is not a topology -- it is a contract between the network team and the workload teams. Each side owns its half of the boundary." -- John Savill, Microsoft Technical Trainer and Azure architect
VNet Peering Mechanics That AZ-700 Tests
Virtual network peering -- a low-latency, high-bandwidth connection between two Azure virtual networks. Traffic uses the Microsoft backbone and stays inside Azure.
Peering has properties that the exam tests by name and by behavior.
| Property | Effect |
|---|---|
AllowVirtualNetworkAccess |
Allows traffic between the two VNets |
AllowForwardedTraffic |
Allows traffic that originated outside the peered VNet (e.g. routed through a firewall) |
AllowGatewayTransit |
Lets one VNet share its VPN/ExpressRoute gateway with the peer |
UseRemoteGateways |
Lets the peered VNet use the other VNet's gateway |
Two peering relationships exist between every pair of peered VNets -- one in each direction. Both must be in the Connected state, and the properties on each side independently control behavior.
Non-Transitive Peering -- The Single Most Tested Concept
Peering is non-transitive. If VNet A peers with VNet B, and VNet B peers with VNet C, traffic from A does not reach C through B by default.
This single fact drives a quarter of AZ-700 networking questions. The exam scenarios test:
Two spokes both peered with a hub but unable to communicate with each other directly
The fix: route traffic between spokes through a network virtual appliance (NVA) or Azure Firewall in the hub
The implementation: user-defined routes (UDRs) on each spoke pointing the other spoke's address space at the firewall's private IP
Candidates who assume B2B peering transitivity miss the entire spoke-to-spoke routing scenario.
Gateway Transit -- The Second Most Tested Concept
When a hub VNet has a VPN gateway or ExpressRoute gateway, the spokes typically need to reach on-premises networks through that same gateway. This is gateway transit.
Configuration:
On the hub-to-spoke peering: enable
AllowGatewayTransitOn the spoke-to-hub peering: enable
UseRemoteGatewaysThe spoke's VNet must not have its own gateway (mutually exclusive)
The exam tests scenarios where gateway transit is misconfigured. Common error patterns include enabling both flags on the same side, deploying a gateway in the spoke after enabling UseRemoteGateways, and forgetting to refresh the BGP session after a gateway swap.
The Heineken global infrastructure team's publicly described Azure landing zone uses gateway transit from a single hub to over forty spokes across regions, with Azure Route Server dynamically propagating routes from on-premises to spokes. This pattern appears nearly verbatim in MeasureUp AZ-700 practice questions.
User-Defined Routes and the Forced Tunnel
Azure VNets have built-in system routes covering the local VNet, peering relationships, the internet, and Azure platform services. User-defined routes override system routes.
The pattern that dominates hub-spoke deployments:
Each spoke has a route table
The route table has a
0.0.0.0/0route pointing at the hub firewall's private IPThe route table is associated with the spoke's subnet
This forces all egress traffic from the spoke through the firewall, where logging, threat detection, and policy enforcement happen.
The Most-Missed UDR Detail
A UDR with 0.0.0.0/0 to the firewall does not automatically route inter-spoke traffic correctly. Each spoke also needs UDRs for the other spokes' address spaces pointing at the same firewall, because peering routes are more specific than 0.0.0.0/0 and win the longest-prefix match. Forgetting these per-spoke routes is the single most common AZ-700 trap.
Bram Stoker-era candidates joke that spoke-to-spoke routing is "the question Microsoft writes three different ways and you must get all three right." That joke is approximately accurate.
Azure Route Server -- The Modern Path
Azure Route Server is a managed BGP endpoint inside a VNet that lets NVAs and gateways exchange routes dynamically. It eliminates much of the manual UDR maintenance that traditional hub-spoke required.
When deployed in the hub, Route Server:
Receives BGP routes from on-premises via the VPN/ExpressRoute gateway
Receives BGP routes from NVAs (firewalls supporting BGP)
Advertises learned routes to peered spoke VNets via gateway transit
The exam scenario for Route Server typically involves a scaling problem -- the customer has fifty spokes and manual UDR management has become unsustainable. The correct answer adds Route Server with BGP-capable NVAs. Candidates who default to Azure Firewall + manual UDRs lose the modernization scenario.
Microsoft's principal program manager Anavi Nahar has published guidance comparing Route Server with traditional UDR-based hub-spoke. The Microsoft-recommended pattern in 2026 is Route Server for any deployment beyond a handful of spokes.
Azure Firewall in the Hub
Azure Firewall -- a managed, cloud-native, stateful firewall service. It is the default hub appliance for Microsoft-recommended hub-spoke designs.
Three SKUs exist.
Standard -- L3-L7 filtering, threat intelligence, basic IDPS-like features
Premium -- TLS inspection, advanced IDPS, URL filtering, web categories
Basic -- low-cost option for small deployments, limited throughput
AZ-700 tests SKU selection by scenario. A scenario describing TLS inspection requirements answers Premium; a scenario describing low-throughput dev/test answers Basic; a baseline production scenario answers Standard.
Firewall Policy Hierarchy
Azure Firewall Policy supports inheritance. A parent policy in a central management subscription can be inherited by child policies in workload subscriptions. The exam tests:
Application rules (FQDN-based) versus network rules (IP/port-based)
Rule collection priorities and processing order
The DNAT rules' priority over network rules
Microsoft Press's AZ-700 Exam Ref by Daniel Mauser and Anavi Nahar covers each rule type explicitly.
Hub-Spoke Variants the Exam Asks About
| Variant | When Used | Exam Signal |
|---|---|---|
| Single-region hub-spoke | One Azure region, multiple workloads | Standard CAF deployment |
| Multi-region hub-spoke | Two or more regions, regional hubs peered globally | Global enterprise scenario |
| Virtual WAN hub-spoke | Many regions, transitive routing required out of the box | Carrier-scale scenario |
| Hub-spoke with NVA | Third-party firewalls (Palo Alto, Check Point, Fortinet) | Compliance/standardization scenario |
Virtual WAN deserves special attention. It provides transit by default -- spokes connected to the same Virtual WAN hub can communicate without manual UDRs. The exam tests Virtual WAN as the answer when "transit must work without UDR maintenance."
Real-World Patterns the Exam Borrows From
ASOS multi-region: ASOS, the UK fashion retailer, runs Azure across multiple European regions with a regional hub in each, peered globally. AZ-700 multi-region scenarios mirror this pattern, including the requirement to keep traffic regional whenever possible.
Microsoft's own enterprise pattern: Microsoft IT publicly documented its move from a flat VNet topology to hub-spoke with Azure Firewall Premium, Route Server, and inherited firewall policies. The documentation reads like an AZ-700 question bank.
Practical Study Path
The Azure free tier is sufficient to build and break a hub-spoke topology. The following sequence covers the high-density topics.
Build a hub VNet, two spoke VNets, and peer each spoke with the hub
Confirm spoke A cannot reach spoke B (non-transitive peering)
Deploy Azure Firewall in the hub, configure UDRs on each spoke, and confirm spoke-to-spoke now works through the firewall
Enable a VPN gateway in the hub, configure gateway transit, and confirm spokes can reach a simulated on-premises network
Replace UDRs with Azure Route Server and observe BGP propagation
Convert to Virtual WAN and observe automatic transit
Each step maps directly to one or more exam objectives. The Microsoft Learn "Configure and manage virtual networks for Azure administrators" learning path covers the same ground for free.
See also: /certifications/azure/az-104-azure-administrator-domains-with-highest-question-density, /certifications/azure/microsoft-az-700-azure-network-engineer-associate-complete-2026-study-guide, /certifications/aws/aws-advanced-networking-vs-azure-network-engineer.
Common Pitfalls on the Exam
Several recurring traps catch candidates who study peering theory without configuring it hands-on.
Forgetting both directions of a peering: peering A-to-B and B-to-A are independent. Misconfiguring one side leaves the relationship in a broken state without an obvious error message.
Address space overlap: VNets with overlapping CIDR ranges cannot peer. The exam tests scenarios where a merger or acquisition introduces overlap, requiring a re-IP or NAT solution.
Subnet count limits: a VNet supports up to three thousand subnets, but practical limits hit much earlier when route tables and NSGs are involved. The exam tests scaling considerations indirectly.
NSG vs Firewall confusion: Network Security Groups filter at the subnet/NIC level; Azure Firewall filters at the network perimeter. The exam tests scenarios where both are deployed and asks which controls the specific traffic flow described.
DNS resolution across peering: peered VNets do not automatically share DNS. The fix is Azure DNS Private Resolver or a custom DNS server in the hub. AZ-700 dedicates several questions to DNS resolution patterns.
The Microsoft Learn article "Hub-spoke network topology in Azure" is the single most-cited reference for these scenarios and is mandatory reading before sitting AZ-700.
ExpressRoute and VPN Coexistence
A meaningful share of AZ-700 questions involve ExpressRoute and VPN running together in the same hub. ExpressRoute is a private connection from on-premises to Azure that bypasses the public internet, with circuits available in fifty megabits to one hundred gigabits. Site-to-site VPN uses IPsec tunnels over the internet.
The two coexist in production for several reasons.
Active-passive failover -- ExpressRoute as primary, VPN as backup if the circuit drops. The exam tests the BGP weight settings that prefer ExpressRoute routes.
Active-active dual-circuit -- ExpressRoute for steady-state, VPN for burst capacity or specific traffic classes.
Migration phase -- VPN during initial rollout, ExpressRoute added as a primary path once circuits are provisioned.
The exam expects candidates to know that both gateways can live in the same VNet (the GatewaySubnet) and that ExpressRoute Global Reach allows two ExpressRoute circuits in different geographies to exchange routes via the Microsoft backbone -- effectively turning Azure into a transit network for on-premises sites. This pattern appears in the Microsoft Cloud Adoption Framework enterprise reference architectures and is tested directly on AZ-700.
NSG and ASG Patterns
Network Security Groups attach to subnets or NICs and enforce stateful rules. AZ-700 tests three NSG patterns repeatedly. First, the default rules that allow VNet-to-VNet, allow Load Balancer probe traffic, and deny inbound internet are present unless overridden -- candidates must recognize that adding rules with priority 4096 does not change defaults. Second, Application Security Groups let rules reference logical groups of NICs rather than IP ranges -- a rule "allow web tier to app tier on port 8080" stays valid as instances scale. Third, NSG flow logs feed Network Watcher and Log Analytics; the exam tests the destination configuration and the difference between NSG flow logs version 1 and version 2 (which adds session counters and bytes).
A typical AZ-700 question describes a multi-tier application in a spoke and asks for the NSG design that enforces tier isolation while remaining maintainable across autoscale events. The correct answer combines ASGs per tier with rules referencing those ASGs, not static IP ranges. The Microsoft Press AZ-700 Exam Ref covers this pattern with full configuration examples.
Private Endpoints and DNS Across the Hub
Private endpoints attach a private IP from a VNet to an Azure PaaS service like Storage, SQL, or Key Vault. Hub-spoke deployments centralize private DNS zones in the hub so all spokes resolve private endpoints to the correct private IP regardless of where the endpoint lives.
The exam scenario: an organization deploys a Storage account with a private endpoint in spoke A, but workloads in spoke B resolve the storage FQDN to the public IP and the connection fails. The fix is linking the privatelink.blob.core.windows.net private DNS zone to spoke B as well as spoke A, or centralizing all private DNS zones in the hub and linking the hub zone to every spoke. The Microsoft Private Link and DNS documentation is the canonical reference.
Bastion and Privileged Access
Azure Bastion in the hub is the recommended pattern for administrative access into spoke virtual machines. Bastion eliminates public IPs on individual VMs and exposes RDP/SSH only through the Azure portal over TLS. AZ-700 tests Bastion sizing -- the Standard SKU supports IP-based connection to non-Azure targets, native client support via the az network bastion ssh command, and shareable links for short-term external access. Candidates often confuse Bastion in the hub with one Bastion per spoke; the hub-shared deployment is the exam-correct design.
References
- Microsoft Learn. "Hub-spoke network topology in Azure." Microsoft Corporation, 2025.
- Microsoft Cloud Adoption Framework. "Azure landing zone network topology." Microsoft Corporation, 2025.
- Microsoft Docs. "Azure Virtual Network peering documentation." Microsoft Corporation, 2025.
- Mauser, Daniel; Nahar, Anavi. AZ-700 Designing and Implementing Microsoft Azure Networking Solutions Exam Ref. Microsoft Press, 2024.
- Microsoft Docs. "What is Azure Route Server?" Microsoft Corporation, 2025.
- Savill, John. "AZ-700 Study Cram." YouTube, John Savill's Technical Training, 2024.
- Microsoft Docs. "Azure Firewall documentation." Microsoft Corporation, 2025.