Azure AZ-104 VNets and Routing Guide
Study Azure AZ-104 VNets and Routing: key concepts, common traps, and exam decision cues.
AZ-104 expects you to build and troubleshoot basic Azure network topology with confidence. That starts with knowing how virtual networks, subnets, peering, public IP resources, and user-defined routes combine into one path.
What Microsoft is testing
The official outline includes creating and configuring VNets and subnets, creating and configuring VNet peering, configuring public IP addresses, configuring user-defined routes, and troubleshooting network connectivity.
The path logic that matters
A virtual network provides the address space boundary. Subnets create smaller administrative and security boundaries within it. Peering connects VNets directly, but it does not create magical transit routing. Public IP resources expose Azure-managed entry or exit points where needed. User-defined routes override default route behavior when traffic must go somewhere specific, such as an NVA or inspection path.
The exam is usually testing whether you can separate addressing, reachability, exposure, and forced path control. If those lanes blur together, the question becomes harder than it really is.
Topology chooser
| Need | Strongest first fit | Why |
|---|---|---|
| Isolate workloads inside one Azure address space | Separate subnets | Lets you apply different NSGs, UDRs, and service placement |
| Connect two VNets directly with low administrative overhead | VNet peering | Keeps traffic on Azure’s backbone without a transit appliance by default |
| Expose a supported frontend publicly | Public IP resource | Gives Azure-managed inbound or outbound public addressing |
| Force traffic through inspection or a specific next hop | User-defined route | Overrides the default route behavior intentionally |
Control boundary chooser
| If the question is really about… | Inspect first | Why |
|---|---|---|
| splitting workloads inside one VNet | subnet design | The subnet is the first administrative and routing boundary |
| who can talk to what | NSG rules | NSGs decide allowed traffic flows |
| where packets should go next | route table and effective routes | UDRs can override your expected default path |
| direct VNet-to-VNet reachability | peering settings | Peering creates the backbone path, but not transit everywhere |
| internet exposure for a frontend | public IP plus the attached service | Public addressing belongs to the exposed Azure resource, not the whole VNet |
What subnets are really doing
AZ-104 questions often make subnets sound like a simple address-splitting exercise. They matter more than that. A subnet is frequently the place where security rules, route tables, service requirements, and workload boundaries start to diverge. If one application tier needs a different path or a different control boundary, splitting it into a separate subnet is often the right first move.
Peering and route mental model
VNet peering gives direct connectivity between the peered networks, but it does not automatically make one network a transit hub for every other network it can see. That matters when a scenario introduces a hub-and-spoke design, inspection appliances, or overlapping expectations about where packets should travel next. When routing becomes surprising, inspect the effective routes rather than assuming peering alone explains the path.
Common topology traps
| Trap | Cleaner reading |
|---|---|
| “The VNets are peered, so every downstream network is reachable.” | Peering gives direct connectivity, not default transitive routing. |
| “The workload has a public IP, so the subnet path is probably fine.” | Public reachability can still fail behind the frontend because of NSGs, UDRs, or backend path issues. |
| “The route table is attached, so peering no longer matters.” | Both still matter: peering establishes reachability, while routes influence the chosen path. |
| “A subnet problem and an NSG problem are the same class of issue.” | Subnets define placement and route boundaries; NSGs define traffic allow/deny rules. |
Azure CLI example: peering plus a forced route
This is the kind of pattern AZ-104 expects you to reason about even when the question is presented in portal language rather than CLI syntax.
1# Peer a spoke VNet to a hub VNet
2az network vnet peering create -g RG --vnet-name spoke-vnet -n spoke-to-hub \
3 --remote-vnet "/subscriptions/<sub>/resourceGroups/RG/providers/Microsoft.Network/virtualNetworks/hub-vnet" \
4 --allow-vnet-access
5
6# Create a route table and send default traffic to a firewall or NVA
7az network route-table create -g RG -n app-rt
8az network route-table route create -g RG --route-table-name app-rt -n default-to-fw \
9 --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.2.4
10
11# Attach the route table to the application subnet
12az network vnet subnet update -g RG --vnet-name spoke-vnet -n app-subnet --route-table app-rt
What matters here is the control story:
- peering establishes direct VNet-to-VNet reachability
- the route table can still override the default path for selected traffic
- once a UDR exists, effective routes matter more than your intuition about where packets “should” go
Common traps
The biggest misses are assuming peering is transitive, forgetting that route decisions can override expected connectivity, and troubleshooting a public-IP problem when the real issue sits in the subnet, route, or security layer.
If Microsoft asks for the best next check
| Symptom | Strongest first check |
|---|---|
| peered VNets cannot talk | peering status and address-space logic |
| a subnet starts taking an unexpected path | effective routes after the route table attachment |
| a public endpoint exists but the app still fails | backend subnet path, NSGs, and destination health |
| only one application tier is affected | the specific subnet’s NSG and UDR combination |
Lab moves worth practicing
- create a VNet with multiple subnets
- peer two VNets and verify which traffic patterns work
- inspect effective routes after adding a custom route table
Fast troubleshooting sequence
When a connectivity question appears, work in this order:
- Confirm the source and destination address spaces make sense.
- Check whether peering or the expected route path actually exists.
- Inspect effective routes after any user-defined routes are attached.
- Only then decide whether the problem is more likely in NSGs, DNS, or the destination service itself.
If the scenario includes a public IP, also ask one extra question: is the public endpoint actually the component being tested, or is the real failure deeper in the private path behind it? AZ-104 often includes a public-facing symptom when the underlying issue is a subnet, route, or security boundary.
Decision order that usually wins
- First classify the issue as basic reachability, transit assumption, or intentional traffic steering.
- If a network behind a peered network is unexpectedly unreachable, remember peering is not transitive.
- If traffic should be forced through a firewall or NVA, think UDR.
- If the question is simply about assigning public reachability, think public IP resource.
- AZ-104 usually rewards understanding the path model before changing security or compute settings.
Quiz
Continue with Secure Private Access Patterns so the basic path model connects to real access control.