Azure virtual networking questions become much easier when traffic is treated as a path rather than a collection of objects. A packet leaves a network interface, Azure evaluates routes, security controls may filter the flow, and the packet reaches a local subnet, a peered virtual network, a virtual appliance, an on-premises network or the internet. The AZ-104 exam expects administrators to understand that path well enough to build it and troubleshoot it.
Virtual networks provide address space and isolation. Subnets divide that space into practical security and routing boundaries. Peering connects virtual networks privately over the Azure backbone. Route tables can override parts of Azure’s default routing behavior. Those services work together, and a configuration that looks correct in one layer can still fail because another layer changes the effective path.
Address planning comes before peering
Virtual networks use private IP address spaces expressed as CIDR ranges. Administrators should allocate ranges that leave room for growth and avoid overlap with networks that may need to connect later. Overlapping address space is one of the fastest ways to make peering, VPN or hybrid connectivity difficult.
Subnets should reflect routing, security and service-placement requirements rather than simply divide the address range into equal pieces. Some Azure services need dedicated subnets or impose subnet-size expectations. Workloads with different trust or routing needs also benefit from separate subnet boundaries.
The broader Microsoft Azure infrastructure certifications path treats address design as a foundation because later choices such as firewall insertion, private endpoints and hub-and-spoke topology depend on an address plan that can actually be routed.
VNet peering provides private network connectivity
Virtual-network peering connects two Azure virtual networks so resources can communicate using private IP addresses. Traffic remains on the Microsoft backbone rather than traversing the public internet. Peering can be used within a region or across regions where supported.
Peering is not transitive by default. If VNet A peers with B and B peers with C, A does not automatically gain a path to C through B. Hub-and-spoke architectures solve that deliberately with routing, gateways or network virtual appliances rather than assuming the hub acts like an ordinary router.
Peering settings also determine whether forwarded traffic and gateway transit are allowed. The exam often describes a hub containing shared connectivity and spokes containing workloads. Read those settings carefully because a peering that exists can still lack the behavior required by the topology.
Azure creates system routes automatically
Every subnet receives system routes that allow basic VNet, peering and platform connectivity. Administrators usually do not create routes for ordinary communication inside the same virtual network. Peering also introduces system routes for the peered address space.
The presence of system routes explains why a newly created VNet can communicate internally without a custom route table. It also provides the baseline against which user-defined routes should be understood. A UDR is used when the administrator needs Azure to send traffic somewhere different from the default path.
Examples include sending internet-bound traffic through a firewall, steering spoke traffic through a hub appliance or creating a controlled path toward a virtual appliance that inspects traffic.
User-defined routes can override the expected path
A route table contains user-defined routes and can be associated with subnets. Route selection considers prefix specificity and route source. A sufficiently specific UDR can override a system route and redirect traffic to a virtual appliance, virtual-network gateway or other supported next hop.
This is powerful but easy to misconfigure. A UDR can cause asymmetric routing, bypass the expected firewall, blackhole traffic or override the system route created by peering. In hub-and-spoke designs, the administrator should know exactly which subnets have route tables and which next hop is selected for each important destination.
When troubleshooting, do not read the route table in isolation. Azure exposes the effective routes on a VM network interface, combining system routes, UDRs and routes learned through a gateway. That effective view is what the VM actually uses.
Longest-prefix matching is a practical troubleshooting tool
When several routes could match a destination, the most specific address prefix usually wins before route-source preference is considered. This means a narrow route can intentionally or accidentally take precedence over a broader one.
For example, a default route may send general outbound traffic to a network virtual appliance while a more specific route keeps traffic to another Azure network on a direct path. If a troubleshooting scenario provides several prefixes, compare them rather than assuming the manually created route always wins simply because it is user-defined.
Thinking in prefixes also helps detect address-design errors. Overly broad private ranges can capture destinations the organization did not intend to steer through a particular network appliance.
Gateway transit enables shared hybrid connectivity
A hub VNet can host a VPN or ExpressRoute gateway and, with the appropriate peering configuration, allow spoke networks to use that gateway. This avoids deploying a separate gateway in every spoke and is a common hub-and-spoke pattern.
The peering settings on both sides must support the design: the hub advertises gateway transit, while the spoke is configured to use the remote gateway. A VNet generally cannot use its own gateway and a remote peered gateway for the same purpose at the same time.
These details sit near the boundary between AZ-104 and more specialized networking study such as AZ-700. AZ-104 focuses on implementing and managing the virtual-network behavior an administrator encounters in ordinary Azure environments.
Service chaining deliberately sends traffic through an appliance
In some designs, traffic from a spoke should pass through a firewall or network virtual appliance in a hub. User-defined routes can point at the appliance as the next hop, including appliances located in a peered network when the topology is designed correctly.
Forwarded-traffic settings, IP forwarding on the appliance and return-path symmetry all matter. If the forward path traverses an appliance but the return path goes directly between networks, stateful inspection may fail. Troubleshooting therefore requires both directions of the flow.
This is one reason a simple ping result is not enough to understand a complex network. The packet may be filtered, misrouted, returned asymmetrically or affected by application-layer behavior after routing succeeds.
Use Network Watcher and effective routes instead of guessing
Azure Network Watcher provides tools such as next hop and connection troubleshoot that expose how Azure sees the path. Effective routes on a network interface show the combined routing result. These tools are often faster and more reliable than inferring behavior from screenshots of separate route tables.
If a workload cannot reach a destination, identify the source NIC, inspect effective routes, determine the selected next hop and then examine security controls. If the wrong next hop is selected, focus on routes and peering. If the route is correct but the packet is denied, inspect NSGs, firewalls and the destination service.
The site’s Azure administrator role coverage emphasizes exactly this type of cross-resource troubleshooting. Administrators are expected to understand the deployed path, not simply know how to create each network object.
Keep routing and segmentation concepts separate
A subnet is a network boundary, a route controls where traffic goes and an NSG controls whether selected traffic is allowed. These concepts interact but are not interchangeable. Creating more subnets does not automatically enforce security, and adding an NSG does not determine the next hop.
Similarly, peering creates reachability between networks but does not mean every connection is permitted. Security rules and application configuration still apply. Strong AZ-104 answers identify the layer that addresses the stated requirement instead of selecting a network feature merely because it appears in the scenario.
Build a path in your head before choosing an answer
For each networking scenario, identify source, destination, address spaces, subnet, peering relationship, applicable route table and intended next hop. Then evaluate security controls. If hybrid connectivity is involved, add the gateway and propagated routes. This sequence makes even complicated hub-and-spoke questions manageable.
Networking is one of the clearest examples of why the cloud architecture certification layer matters to administrators: the design determines what the packet should do, while AZ-104 skills let you implement, inspect and fix that behavior.
DNS and security can make a correct route look broken
Routing determines where packets are sent, but a successful route does not guarantee a successful application connection. A client can resolve the wrong IP address, an NSG can deny the flow after the correct route is chosen, a guest firewall can block the destination port, or the application may not be listening. These failures often look identical from the user’s perspective.
That is why Azure network troubleshooting should preserve the order of operations. Confirm the name resolves to the intended address. Inspect the effective route and next hop. Check the applicable security rules. Then test the service itself. Changing route tables before confirming DNS or security can introduce a new path problem without fixing the original issue.
Peered networks make this especially important because private address reachability can be correct while private DNS zones or custom DNS servers are not linked or forwarding as expected. AZ-104 does not require every advanced DNS architecture, but administrators should know that name resolution and packet routing are distinct systems that must agree for an application connection to work.