Azure Networking for AZ-104: VNets, NSGs, and Peering

Azure networking is the single topic that catches more candidates off guard on the Microsoft AZ-104 exam than any other. Other domains reward memorization, but networking rewards understanding: the exam loves to describe a topology, add a security rule or a peering link, and ask why traffic does or does not flow. If you can reason through how packets actually move between a virtual network, a subnet and the wider world, a whole cluster of questions on the Microsoft Azure Administrator exam becomes almost mechanical. This article teaches the three pieces that trip people up the most — virtual networks and subnets, network security groups, and the choice between peering and a VPN gateway.

VNets and subnets: the address space you carve up

A virtual network, or VNet, is your private slice of the Azure network. You give it an address space in CIDR notation — say 10.0.0.0/16 — and that space is yours alone within your subscription. Think of the VNet as a plot of land and the address space as its fence line. Nothing about the VNet itself does any work; it is just the boundary that defines which private IP addresses are available.

You then divide that space into subnets, each a smaller CIDR block that fits inside the VNet's range, such as 10.0.1.0/24 for a web tier and 10.0.2.0/24 for a database tier. Subnets are where resources actually live: a network interface on a VM draws its IP from a subnet, not directly from the VNet. Two facts here quietly cause a lot of wrong answers. First, Azure reserves five addresses in every subnet — the first four and the last — so a /24 gives you 251 usable addresses, not 256. Second, resources in different subnets of the same VNet can talk to each other by default, with no gateway and no extra configuration. That default openness is exactly why network security groups exist.

Understanding this hierarchy — subscription contains VNet, VNet contains subnets, subnets contain interfaces — is the mental model everything else hangs on. If you want to drill it until it is automatic, the scenario-based practice questions for the AZ-104 walk you through topologies you have to reason about rather than facts you simply recall.

Network security groups and the priority puzzle

A network security group, or NSG, is a stateful firewall made of rules that allow or deny traffic. Each rule has a priority number from 100 to 4096, a direction (inbound or outbound), a source, a destination, a port range, a protocol, and an action. The behavior that catches people out is how Azure evaluates those rules: lower priority numbers are processed first, and the first matching rule wins. Once a rule matches, evaluation stops — no later rule, however specific, gets a say.

Picture a bouncer working down a numbered list of instructions. Instruction 100 says "allow anyone on the guest list." Instruction 200 says "deny everyone from that company." If a guest is both on the list and from that company, the bouncer acts on instruction 100 and never reaches 200. The person gets in. Candidates lose points by assuming the more specific or more restrictive rule prevails; it does not. Only the number matters.

Two more details complete the picture. Every NSG ships with default rules — hidden at priorities in the 65000 range — that allow all traffic within the VNet and from the Azure load balancer, allow outbound to the internet, and then deny everything else. Your custom rules sit at lower numbers and therefore override these defaults. And because NSGs are stateful, if you allow an inbound request, the response is allowed back out automatically; you do not need a matching outbound rule for return traffic. That statefulness is a favorite exam twist.

NSGs can be attached to a subnet, to a network interface, or to both at once — which leads directly to the concept the exam tests hardest.

Effective security rules: when two NSGs stack

When an NSG is applied to a subnet and another NSG is applied to a NIC inside that subnet, both are evaluated, and traffic must be allowed by both to reach the resource. For inbound traffic Azure processes the subnet NSG first, then the NIC NSG; for outbound it reverses the order, NIC first, then subnet. If either layer denies the packet, it is dropped — there is no "allow on one wins." This is why a VM can be unreachable even though its NIC-level NSG clearly permits port 3389: a subnet NSG upstream is quietly blocking it. Azure exposes an effective security rules view that flattens both layers into the actual rule set applied, and knowing that this tool exists — and that it is the right way to diagnose a "why can't I reach this VM" scenario — is itself a testable point. If you want to see how these layered-NSG scenarios are framed on the real test, the timed AZ-104 exam simulations put you in front of them under the same clock and pass bar you will face on exam day.

Peering versus VPN gateway: connecting networks

The last common confusion is how to connect two virtual networks, because Azure gives you two very different tools and the exam expects you to pick correctly. VNet peering links two VNets directly over Microsoft's backbone network. Traffic stays on Azure's private infrastructure, latency is low, throughput is high, and there is no gateway to deploy or manage. Peering works both within a region and globally across regions. The catch that shows up in questions: peering is non-transitive. If VNet A is peered with B, and B is peered with C, A cannot reach C through B automatically. You either peer A and C directly or route through a network virtual appliance in B.

A VPN gateway, by contrast, is a deployed resource that creates encrypted IPsec tunnels — typically to connect Azure to an on-premises datacenter over the public internet, or in some designs to link VNets across regions. It costs more, adds latency, and is throughput-limited by the gateway SKU you choose. The decision rule the exam wants is straightforward: to connect two Azure VNets, reach for peering first because it is faster, cheaper and simpler; reach for a VPN gateway when one side is on-premises or you specifically need an encrypted tunnel over the public internet. Confusing the two — proposing a VPN gateway to join two VNets in the same region — is a classic distractor.

Tying it together for exam day

Azure networking rewards a small number of durable mental models over rote memorization: a VNet is a fenced address space, subnets carve it up and talk freely by default, NSGs filter that traffic strictly by lowest-priority-first with the first match winning, layered NSGs must both allow, and peering beats a VPN gateway for VNet-to-VNet links unless on-premises is involved. Get those straight and the networking domain of the Microsoft AZ-104 exam shifts from guesswork to reasoning. When you are ready to pressure-test that understanding, the adaptive practice on ExamStudyApp keeps serving you networking scenarios from the areas where you are still missing points and tracks your readiness across every objective, so you can book the Microsoft Azure Administrator exam with evidence you are prepared rather than a hopeful guess.