Configure VNets, Subnets, Peering, Public IPs, and Routing for AZ-104

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.

Topology chooser

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.

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.

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:

1. Confirm the source and destination address spaces make sense.
2. Check whether peering or the expected route path actually exists.
3. Inspect effective routes after any user-defined routes are attached.
4. 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.

Quiz

Continue with Secure Private Access Patterns so the basic path model connects to real access control.