Microsoft AZ-700: ExpressRoute & WAN Connectivity — Study Guide

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #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.

ExpressRoute fundamentals, peering models, and SKUs

ExpressRoute provides a private, high-throughput connection between your on-premises networks and Microsoft’s global backbone. There are two deployment models: service-provider provided circuits (co-location at an exchange or via a partner) and ExpressRoute Direct where you order physical ports from Microsoft (suitable for 10/100/400 Gbps scenarios). Logical connectivity to Azure uses peering: private peering for VNet connectivity, Microsoft peering for Azure platform and PaaS endpoints, and (where supported) public peering legacy migrations. Design choices hinge on bandwidth, geographic scope, and advertised route scale. Choose the circuit SKU based on scope and route scale rather than pure bandwidth, and pair it with an appropriately sized virtual network gateway or Virtual WAN hub to terminate connectivity.

Local: peering limited to the metro/region of the peering location; lower cost and smaller routing table footprint.
Standard: connectivity to all Azure public regions in the same geography; mid-range cost and route scale.
Premium (add‑on): expands reach to all global regions and increases supported route counts and VNet attachments; required for global transit topologies and many peered VNets.

Common traps include assuming ExpressRoute equals unlimited routes or automatic transitive routing between VNets; you must explicitly evaluate route limits, peering types, and whether you need the Premium add-on for global reach or extra prefixes.

Provisioning lifecycle, required artifacts, and configuration details

Provisioning an ExpressRoute circuit is a coordination exercise between your networking team and a connectivity provider. After you create the circuit in Azure you receive a service key (the ServiceKey/Service Key ID) that the provider uses to provision the physical cross-connect. Choose the peering location (metro/colocation) when creating the circuit, select the bandwidth (50 Mbps up to multiple Gbps depending on provider and model), and configure peering (private and/or Microsoft) and VLAN/subnets for BGP. Terminate the ExpressRoute into either a VNet via a Virtual Network Gateway (or into a Virtual WAN hub) or use ExpressRoute Direct to connect to Microsoft’s edge for very high bandwidth.

Typical provisioning sequence:

Create ExpressRoute circuit in Azure and record the Service Key.
Share Service Key with provider and coordinate physical cross-connect and VLAN.
Configure peering (private/ Microsoft), BGP peer IPs and ASNs on both sides.
Link circuit to VNet(s) via an ExpressRoute connection to a virtual network gateway or Virtual WAN hub and validate BGP routes.

Be mindful to pre-plan BGP ASN choices, router peer IPs, overlapping IP spaces, and the gateway SKU capacity you will require.

FastPath, Global Reach, gateway SKUs and performance trade-offs

ExpressRoute FastPath reduces latency and increases throughput by bypassing the gateway host and forwarding packets directly between your on‑premises device and the VM/instance NICs on the VNet data path. It is ideal for latency-sensitive workloads, but it has requirements and constraints: FastPath requires private peering, an ExpressRoute circuit that supports it, and a virtual network gateway SKU that explicitly supports FastPath (Basic gateways are not supported). FastPath also affects inspection and traffic flow: because packets bypass the gateway host, any security appliances or centralized inspection that rely on gateway‑hosted hairpinning may not see the traffic unless you architect traffic through NVAs placed inline or via forced tunneling.

ExpressRoute Global Reach lets you interconnect two or more on‑premises sites by using the Microsoft backbone—useful when you want Microsoft to carry private traffic between sites rather than routing across ISP links. To use Global Reach you must have ExpressRoute circuits at both sites, enable Global Reach on the circuits, and ensure the provider supports it. Performance vs cost trade-offs are straightforward: use ExpressRoute Direct or multiple high‑bandwidth circuits for throughput and resilience; use Standard/Local circuits for lower cost metro-only connectivity; and use FastPath where microsecond gains matter but accept design changes to NVA placement and packet inspection.

WAN architecture patterns: Virtual WAN, VPN vs ExpressRoute, routing and common design traps

When designing a WAN to Azure, three dominant patterns emerge: hub-and-spoke using Virtual Network Gateway(s), Virtual WAN (managed hub) with integrated SD‑WAN/branch connectivity, and pure ExpressRoute fabric with VNet peering or Virtual WAN attachments. Virtual WAN simplifies branch connectivity and scales well for many S2S/VPN tunnels and SD‑WAN integrations, but incurs higher ongoing cost and uses the Virtual WAN hub routing model. Traditional Virtual Network Gateways (VpnGw1/2/3 families) are cheaper for limited tunnels but require per‑VNet gateways for transitive scenarios. ExpressRoute provides predictable latency and throughput and pairs well with Virtual WAN when you need both private backbone connectivity and managed branch aggregation.

Key routing and operational traps include overlapping IP spaces between on‑prem and VNets, incorrect BGP ASN or peer IP configuration (you must enable BGP on both the Virtual Network Gateway and on your customer edge), and inadvertent UDRs or NSG rules that block BGP-learned prefixes. Additionally, be clear on routing precedence: system routes (BGP/connected) generally take precedence over UDRs unless you explicitly configure next hops differently; ensure forced tunneling/Internet breakouts and NVA inspection points are tested when combining ExpressRoute and VPN, and verify supported route limits and VPN gateway tunnel counts for the SKU you choose.

Practical Problem: Use-Case Scenario

Scenario: Contoso Corp has a primary datacenter in Washington, D.C. and an existing Azure footprint with VNets in East US and East US 2. Contoso already has a provider-mediated ExpressRoute circuit peered at the Ashburn metro and needs to connect a second datacenter in Virginia and enable low-latency connectivity between both datacenters and their VNets.

Challenge: They need resilient, low-latency cross-datacenter connectivity into Azure, want to minimize public-internet exposure, and require Microsoft backbone transit between on-prem sites without rebuilding major on-prem routing.

Recommended Approach:

Provision a second ExpressRoute circuit at the second datacenter and request the provider peer at the same peering location (Ashburn). Use a Standard circuit initially and plan for Premium if global VNet reach or increased route capacity is required.
Provide each circuit’s Service Key to the provider to complete cross‑connects, then enable ExpressRoute Global Reach between the two circuits so on‑prem sites can exchange private traffic via Microsoft’s backbone.
Deploy or upgrade the Virtual Network Gateway in the hub VNet to an ExpressRoute‑capable SKU that supports FastPath (avoid Basic); enable private peering with BGP, set unique local ASNs and peer IPs, and advertise on‑prem prefixes.
If latency-sensitive workloads exist, enable ExpressRoute FastPath on the private peering connection after validating that NVAs and inspection paths are re-architected to account for the bypassed gateway host.

Rationale: Dual circuits with Global Reach provide resilient, private Microsoft-backbone transit between datacenters and Azure without exposing traffic to the public internet; enabling FastPath improves latency for sensitive flows but requires gateway SKU support and design adjustments for packet inspection and NVAs.

All domains · Azure Virtual Network Design →

Practice these questions → · Timed practice on ExamRoll.io →