The AZ-700 exam's routing section asks you to determine which traffic path is chosen and what drives the priority decision. Rather than memorizing a feature list, you are expected to judge which tool belongs where in a given scenario. Controlling static routes with UDR, managing dynamic routes with BGP and Azure Route Server, and structuring large networks with VNet Peering and Hub-Spoke are the pillars of this section.
System Routes and Routing Priority
When a new highway opens in a city, navigation apps automatically recognize that road and start routing drivers through it. Azure works the same way: the moment you create a VNet, it automatically generates system routes. The VNet address space gets a next hop, goes to , and RFC 1918 private ranges are set to (drop).
Route priority follows two principles. First, the more specific prefix always wins — this is longest prefix match. Second, when two routes share the same prefix length, the order is .
A classic exam trap involves this priority. If a UDR sets with next hop , that UDR beats any BGP advertisement coming from a VPN Gateway. To implement force tunneling, the next hop must be , not .
UDR: Steering Traffic Where You Need It
Imagine a distribution center where certain items must pass through an inspection station before shipping. Instead of leaving it up to each worker to find the right path, you put up signs that force everyone through that checkpoint. User Defined Routes work exactly like those signs — they override Azure's system routes to direct traffic through a specific hop.
The most common use case is forcing all Spoke subnet traffic through a Hub NVA or firewall. You attach a route table to the Spoke subnet with a rule: .
UDR supports five next hop types:
: forwards to a specific IP (NVA, firewall) : routes to VPN or ExpressRoute gateway : keeps traffic within the VNet : sends traffic to Azure's public internet : drops the packet
BGP and Azure Route Server: The World of Dynamic Routing
Like an air traffic control tower, BGP (Border Gateway Protocol) lets routers continuously exchange and update routes dynamically, rather than relying on static tables.
In Azure, BGP is primarily used on VNet Gateways to exchange routes dynamically with on-premises routers over VPN or ExpressRoute connections. When you enable BGP on a VPN Gateway, it uses an ASN (Autonomous System Number) to identify itself. The default ASN is 65515, and it must not overlap with the on-premises ASN.
Azure Route Server takes this a step further. When an NVA peers with Azure Route Server over BGP, the routes the NVA advertises are automatically propagated throughout the VNet. This eliminates the need to manually manage UDR entries every time the NVA's routing table changes.
| Attribute | UDR | Azure Route Server | |--|--|--| | Route type | Static (manual) | Dynamic (BGP) | | Management | Manual update on change | NVA updates automatically | | Best fit | Small, fixed topologies | Large environments with NVA |
VNet Peering: Connected but Isolated
Think of two office buildings in the same business park. You could go out to the street and walk around, or use a dedicated internal corridor that links them directly. VNet Peering is that corridor — traffic flows over the Azure backbone without touching the public internet or passing through a gateway.
Peering is either Regional (same region) or Global (cross-region). The critical rule: peering is . VNet A peering with B, and B with C, does not let A reach C automatically.
To allow Spoke-to-Spoke communication, route traffic through the Hub's NVA via UDR, or use Azure Virtual WAN for automatic handling.
Gateway Transit lets Spoke VNets share the Hub's VPN or ExpressRoute Gateway for on-premises connectivity. Both sides must be configured: on the Hub peering, and on the Spoke peering.
Hub-Spoke Topology: Centralized Security by Design
Picture a company headquarters that receives all mail from branches, sorts it, and routes it correctly. The Hub-Spoke topology works the same way: the Hub VNet holds shared infrastructure — firewall, VPN/ExpressRoute Gateway, DNS, and Active Directory — while each Spoke VNet runs its own workloads.
The key advantage is that security policies live in one place. As Spoke VNets multiply, you never need to replicate firewall rules across each one independently.
Force tunneling uses a UDR with pointing to the Hub's NVA. This ensures that every outbound internet request from a Spoke VM must pass through the central firewall for inspection. Setting next hop to instead of would bypass the firewall entirely — a subtle but serious mistake.
VNet Peering vs VPN vs ExpressRoute: Choosing the Right Connection
Choosing how to connect locations is like picking a transportation method. A direct internal walkway, a public highway, or a private chartered road all serve different needs based on speed, cost, and security requirements.
| Attribute | VNet Peering | VPN Gateway | ExpressRoute | |--|--|--|--| | Path | Azure backbone | Public internet (encrypted) | Dedicated private circuit | | Latency | Lowest | Medium | Lowest (private line) | | Transit support | No | Yes (BGP) | Yes (BGP) | | Cost basis | Data transfer volume | Gateway SKU + data | Circuit + Gateway SKU | | Primary use | Azure-to-Azure internal | Small on-premises connection | High-volume, high-availability |
The non-transitive nature of VNet Peering is the most tested distinction in this area. For on-premises traffic to reach a Spoke VNet via the Hub, you need both a VPN Gateway in the Hub and Gateway Transit properly configured on both sides of the peering.
Exam Traps: Three Scenarios That Catch People Off Guard
Just like a quiz show question where two answers look almost identical, AZ-700 routing questions hinge on small but meaningful differences.
Scenario one: a UDR on can route on-premises traffic through an NVA, but any mistake silently breaks the VPN or ExpressRoute link.
Scenario two: is a Hub-side setting; is Spoke-side. Both must be on. Missing either means the Spoke has no gateway to use.
Scenario three: if the NVA supports BGP and routes change often, use Azure Route Server. For stable, simple topologies, UDR is sufficient.
Exam Key Takeaways
"Spoke-to-Spoke traffic fails" -- VNet Peering is non-transitive; route through Hub NVA using UDR "Spoke needs to use Hub gateway" -- Hub: Allow gateway transit on; Spoke: Use remote gateway on "UDR with 0.0.0.0/0 next hop Internet + VPN BGP" -- UDR wins; BGP advertisement is ignored "Force tunneling configuration" -- UDR 0.0.0.0/0, next hop: Virtual network gateway or Virtual appliance "NVA injects routes dynamically into VNet" -- Azure Route Server with BGP peering "Automatic Spoke-to-Spoke routing in Hub-Spoke" -- Azure Virtual WAN "A talks to C through B, all VNet Peering" -- Not possible; add explicit peering A-C or use Virtual WAN "Mistake in GatewaySubnet UDR" -- Can break VPN or ExpressRoute connectivity entirely "ASN overlap between on-premises and Azure VPN Gateway" -- Configuration error; ASNs must be unique "Route priority order" -- UDR beats BGP, BGP beats system route, for same-length prefix
UDR = static route control, Azure Route Server = dynamic NVA route injection, Hub-Spoke = centralized security gateway