Microsoft AZ-700: Azure Virtual WAN & Hub-Spoke — Study Guide
Part of the Microsoft Azure Network Engineer AZ-700 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.
Virtual WAN versus classic hub-and-spoke: pick the right transit model
Designing global transit requires choosing between Azure Virtual WAN (vWAN) and a traditional hub-and-spoke built from VNets, NVAs, and peering. Virtual WAN provides a Microsoft-managed global backbone with vHubs that natively host VPN, ExpressRoute and P2S connectivity and support automated route propagation, site-to-site scaling, and SD‑WAN partner integrations. For organizations needing many branch connections, global routing, and simple operational model, vWAN reduces orchestration work and improves resilience. In contrast, a manual hub-and-spoke (a VNet with an Azure Firewall or third‑party NVA in a central hub and spokes peered) gives maximum control over packet flow, custom NVA features, and often lower steady-state cost for small deployments. Key trade-offs are throughput and predictability versus granular control: vWAN hubs abstract many details and offer near‑global scale but add managed service costs and less flexible packet path customization. Common traps include assuming vWAN automatically provides transitive peering into VNets not explicitly connected; every spoke or VNet must be connected and associated with hub route tables. Another frequent mistake is neglecting the governance and subnet naming constraints (for example, required AzureFirewallSubnet for Azure Firewall) that break automated deployments if not followed.
Secured virtual hub, Azure Firewall, and NVA integration
The secured virtual hub model layers inspection and policy onto vWAN by integrating Azure Firewall (or a third‑party NVA) and Firewall Manager to centralize security, NAT, and routing for spokes and on‑prem sites. Azure Firewall should be deployed in the dedicated AzureFirewallSubnet and you should decide between Azure Firewall SKUs based on features. Carefully plan route tables: hub route tables control flows to spokes, VPN sites, P2S, and the internet. To force‑tunnel traffic to an NVA you associate the spoke connection with a hub route table that directs 0.0.0.0/0 to the NVA/Firewall. Consider high availability and throughput: Azure Firewall is zonal and supports autoscaling with the Standard and Premium SKUs, but Premium is required for TLS inspection and IDPS. Avoid placing Application Gateway or Private Link endpoints in subnets shared with firewall infrastructure; they need their own subnets. Watch NAT and SNAT port exhaustion for large-scale outbound flows; implement SNAT pooling, Azure Firewall with DNAT rules, or use NAT Gateway where applicable.
- Azure Firewall Standard vs Premium: Standard supports stateful F/W, FQDN filtering, basic SNAT/DNAT; Premium adds TLS inspection, IDPS, URL filtering, and fully qualified domain name (FQDN) tag exclusions.
- Load Balancer Basic vs Standard: Standard supports zone‑redundant, backend health probes, and required for Private Link service ILB; Basic lacks zone resilience and stricter security rules.
- VPN Gateway SKUs: VpnGw1/2/3 (increasing throughput and concurrent tunnels); use higher tiers for more S2S tunnels or higher aggregate throughput.
Private connectivity patterns: Private Link, Private Endpoints, and service endpoints
Private Link and private endpoints provide first‑class PaaS access without routing traffic over the internet; service endpoints secure service access but keep egress via the public service backbone. Use a private endpoint when you need per-resource private IPs and DNS integration; use service endpoints when you need simpler subnet-level access control and are comfortable exposing service egress to the service backbone. Important operational details include DNS resolution: private endpoints require updating on‑prem DNS or Azure DNS Private Zones so clients resolve the private IP; conditional forwarders to on‑prem DNS servers are common for S2S-connected networks. Cross‑subscription Private Link service scenarios are supported if resources are in the same Azure AD tenant; deploy the Private Link service behind a Standard internal Load Balancer (ILB) to scale and zone‑redundancy. A frequent trap is using Basic ILB or incorrect SKU, which limits backend health and scale. For Private Link service supporting high connection volume, use Standard ILB, scale‑set backends, and consider multiple endpoint NICs per backend instance. Also consider DDoS protection: enable DDoS Protection Standard for public-facing NICs and plan for SNAT port scaling and NAT Gateway where many outbound connections originate.
vWAN hub route tables and practical route design
vWAN uses hub route tables to steer traffic between connected spokes, on‑prem sites, and the internet. Each connection (site, VNet, P2S) can be associated with a hub route table; route priorities and propagation rules determine final forwarding. Good design starts with a default hub route table that forwards internet-bound traffic to Azure Firewall or an NVA, and specialized route tables for branches that require on‑prem breakout. BGP from on‑prem VPN devices propagates prefixes into the hub, and you can redistribute those to spokes or filter with route‑tables. A common pitfall is conflicting user-defined routes (UDRs) in spoke VNets that attempt to override hub propagation; in vWAN, hub route tables take precedence for interconnects but UDRs on spokes still affect local egress. For forced tunneling, associate spoke connections to a hub route table directing 0.0.0.0/0 to your chosen inspection device. Monitor and plan for route limits: vWAN hubs have maximum numbers of learned and advertised prefixes—design prefix summarization and BGP communities or filters to stay within limits. Always test DNS resolution and split‑DNS for private endpoints, and document failover behavior for multi‑hub active/active designs to meet resilience SLAs.
Practical Problem: Use-Case Scenario
Scenario: Contoso Manufacturing operates a global Azure footprint with an existing hub-and-spoke VNet architecture in two regions, multiple on‑premises sites connected via SD‑WAN, and a requirement to centralize security and provide private PaaS connectivity across subscriptions.
Challenge: They need a scalable, managed global transit that centralizes inspection (TLS inspection, IDPS), supports many branch connections via SD‑WAN, and exposes several storage and database PaaS resources privately to spokes and on‑prem without exposing them publicly.
Recommended Approach:
- Deploy Azure Virtual WAN (vWAN) and create secured virtual hubs in each region. In each hub, enable Azure Firewall Premium (for TLS inspection and IDPS) and integrate with Firewall Manager. Associate the hub with the vWAN partner SD‑WAN connections for direct branch on‑ramp.
- Configure hub route tables to direct internet‑bound and cross‑region traffic to Azure Firewall Premium; create specialized route tables for branches that must egress on‑prem. Use BGP from SD‑WAN to advertise on‑prem prefixes into vWAN and apply prefix filters to avoid route bloat.
- For PaaS services, provision Private Link services in a dedicated VNet per region behind a Standard Internal Load Balancer, and expose Private Endpoints in spoke VNets and on‑prem via vWAN connectivity. Use Azure DNS Private Zones and conditional forwarders to ensure on‑prem resolution.
- Enable DDoS Protection Standard on public endpoints, deploy NAT Gateway for large outbound SNAT needs on spokes, and monitor SNAT/DNAT metrics. Use Firewall Manager policies for centralized rule distribution and configure logging to a central Log Analytics workspace.
Rationale: This approach leverages vWAN for scalable branch connectivity and global transit, uses Azure Firewall Premium for centralized, advanced inspection required by security policy, and Private Link for secure PaaS access without public exposure—balancing manageability, security, and operational scale.
← Network Monitoring · All domains
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →