AZ 104 Networking Vnet Subnet Nsg Mental Model

You’re staring at your AZ-104 score report. 698. You needed 700.

You’re two points away from passing. Not two percentage points—two actual points on a scale where every question matters. You studied. You took practice tests. You know Azure. But when those networking questions hit, something broke. You picked the wrong answer because you couldn’t visualize how VNets, subnets, and NSGs actually fit together in the real world.

This is fixable. The problem isn’t that you don’t know these concepts. The problem is you’re thinking about them in isolation instead of as a connected system.

What Most Candidates Get Wrong About This

You’re memorizing definitions instead of building a mental model.

A subnet is a range of IP addresses. An NSG is a set of rules. A VNet is a network boundary. That’s all technically true. That’s also useless when you’re under exam pressure and the question asks: “You have a VNet called corp-prod-eastus with address space 10.0.0.0/16. You’ve created two subnets: web-tier (10.0.1.0/24) and db-tier (10.0.2.0/24). An NSG attached to the web-tier subnet blocks all outbound traffic on port 3306. A VM in the web tier needs to query a database in the db tier. What happens?”

Most candidates answer “blocked” or “allowed” without thinking through the actual traffic flow. They don’t see that the NSG is the gatekeeper—it filters traffic entering and leaving that subnet. They don’t realize that the db-tier subnet might have its own NSG. They don’t understand that outbound rules on one subnet don’t automatically block inbound traffic on the destination.

This mental model gap costs you points. Plural.

The Specific Problem You’re Facing

You can describe what an NSG does. You probably can’t quickly answer this under 90 seconds:

“Your company runs a three-tier application on Azure. The web servers are in subnet front-end (10.1.0.0/24). The app servers are in middle-tier (10.1.1.0/24). The databases are in backend (10.1.2.0/24). All three subnets are in the same VNet with address space 10.1.0.0/16.

The NSG on front-end allows inbound HTTPS (port 443) from the internet and allows outbound traffic to any destination on port 8080. The NSG on middle-tier allows inbound traffic on port 8080 from the front-end subnet and allows outbound to port 5432. The NSG on backend allows inbound on port 5432 from the middle-tier subnet only.

A user in London connects to the web server via HTTPS and tries to retrieve data. Trace the path. Where might the traffic fail?”

This is a real scenario type. It appears on the exam. Not exactly like this, but this pattern repeats: layered subnets, multiple NSGs, directional rules, traffic flowing between tiers.

If you’re not instantly seeing the answer (traffic succeeds because each hop is explicitly allowed), you’re missing the mental model.

A Step-By-Step Approach That Works

Build this in your head as three separate layers. Not abstract. Physical.

Layer 1: The VNet is your building.

The VNet corp-vnet with address space 10.0.0.0/16 is a single building. Nothing inside it can talk to anything outside without explicitly crossing a threshold (an application gateway, a firewall, a VPN gateway). Inside the building, traffic can move freely at Layer 3 unless something stops it.

Layer 2: Subnets are floors in the building.

Floor 1 is 10.0.1.0/24 (256 addresses). Floor 2 is 10.0.2.0/24. A VM on floor 1 can see and communicate with every other VM on every floor by default. Subnets are how you organize and manage the space. They don’t block traffic by themselves.

Layer 3: NSGs are security guards at each floor’s entrance and exit.

An NSG attached to a subnet is a checkpoint. It has inbound rules (who can enter) and outbound rules (who can leave). Rules are evaluated top-to-bottom. The first match wins. If no rule matches, the default is “deny.”

Here’s what breaks most candidates:

They think an NSG rule blocks traffic forever. Wrong. It blocks traffic in one direction.
They attach an NSG to a subnet and think it applies to everything there. Correct—but they forget NSGs can also attach to individual NICs.
They ignore the rule evaluation order. Default-deny at the end means every single traffic flow needs an explicit allow rule.

Apply this immediately:

Take a subnet. Draw it as a box. Draw VMs inside it as smaller boxes. Draw the NSG outside the box as a checkpoint.

Now trace a packet:

Source VM → (outbound NSG rule check) → leaves the subnet
Travels through the VNet
Enters destination subnet → (inbound NSG rule check) → destination VM

If the source NSG says “allow outbound to 10.0.2.0/24 on port 5432” and the destination NSG says “allow inbound from 10.0.1.0/24 on port 5432,” the traffic succeeds. If the destination NSG says nothing about port 5432, the traffic is dropped. Both rules must exist and both must allow.

What To Focus On (And What To Skip)

Focus on these:

Default rules. Every NSG has default inbound rules and default outbound rules. Inbound defaults to deny. Outbound defaults to allow. This is critical. An NSG you just created will block all inbound traffic by default.
Rule priority numbers. Lower numbers are evaluated first. A priority 100 rule runs before a priority 200 rule. If 100 says deny and 200 says allow, the deny wins.
Deny rules. You can explicitly deny traffic even if an allow rule exists. Denial rules override allows if they’re higher priority. This is how you block a specific subnet while allowing everything else.
Subnet vs. NIC NSGs. A subnet NSG filters all traffic through that subnet. A NIC NSG filters only traffic for that specific network interface. Both can exist. Both are evaluated. Both must allow.
Stateless evaluation. NSGs don’t maintain session state. Inbound and outbound are completely independent. A VM can receive traffic (inbound NSG allows it) but be unable to respond (outbound NSG denies it). Real scenario.

Skip:

Application Security Groups (ASGs) for now. Yes, they’re on the exam. No, they’re not your bottleneck. Master NSG fundamentals first.
Deep diving into service tags beyond “they’re shortcuts to IP ranges.” Understand they exist. Know VirtualNetwork, Internet, AzureLoadBalancer. Don’t memorize all 50.

Your Next Move

Open Azure Portal right now. Create a test VNet with three subnets. Create three NSGs. Attach one to each subnet.

Set these specific rules:

Subnet 1 NSG: Allow inbound HTTP from internet (0.0.0.0/0:80), allow outbound to Subnet 2 on port 8080 only.
Subnet 2 NSG: Allow inbound from Subnet 1 on port 8080, allow outbound to Subnet 3 on port 5432 only.
Subnet 3 NSG: Allow inbound from Subnet 2 on port 5432, deny everything else.

Now write out the exact path a packet takes from the internet to the database and back. Where is it allowed? Where is it blocked? Why?

Do this before your retake. Do this before you take another practice test. This mental model fix will unlock 3-5 more points on the networking section alone.