NSG and route table questions on the AZ-104 exam hinge on a single distinction: NSGs decide whether traffic is allowed, route tables decide where traffic goes. Confusing these two is one of the most common reasons candidates choose wrong answers in Azure networking scenarios.
Network Security Groups (NSGs)
An NSG is a stateful firewall that filters traffic based on rules. Each rule specifies:
- Source IP/range or service tag
- Destination IP/range or service tag
- Protocol (TCP, UDP, Any)
- Port (or range)
- Action: Allow or Deny
- Priority: 100–4096, lower number evaluated first
NSGs can be associated with:
- A subnet — applies to all traffic entering/leaving every NIC in that subnet
- A network interface (NIC) — applies to traffic to/from that specific VM
When both subnet-level and NIC-level NSGs exist, traffic must pass both. Azure evaluates subnet NSG first for inbound traffic, then NIC NSG. For outbound, NIC NSG first, then subnet NSG.
Default rules (cannot be deleted, only overridden by lower-priority rules):
- Allow all inbound traffic from the same VNet
- Allow Azure Load Balancer inbound health probes
- Deny all other inbound traffic (priority 65500)
- Allow all outbound to the internet and VNet
- Deny all other outbound (priority 65500)
Route Tables
A route table controls where traffic is sent next. Every subnet in Azure has a system route table that handles traffic by default:
- Traffic within the VNet: delivered directly
- Traffic to the internet: sent to the internet gateway
- Traffic to Azure services: via the Microsoft backbone
A custom (user-defined) route table overrides system routes. Common uses:
- Force all internet-bound traffic through a firewall or NVA (next hop: virtual appliance)
- Route traffic between VNets through a security device
- Block a specific route entirely (next hop: None)
Which One to Change for Each Problem
| Symptom | Cause | Fix |
|---|---|---|
| VM cannot be reached on port 3389 | NSG blocking inbound TCP 3389 | Add NSG inbound allow rule for port 3389 |
| VM can ping locally but not reach internet | Route table next hop is NVA that is down | Fix the NVA, or update the route |
| Traffic between two VMs is being dropped | NSG deny rule between their IPs | Add or modify NSG allow rule |
| All subnet traffic going through firewall instead of direct | Custom route with next hop = NVA | Expected if intentional; remove route if not |
Service Tags
NSG rules support service tags — named groups of IP ranges maintained by Microsoft:
- Internet — All public IP addresses
- VirtualNetwork — All addresses in the VNet
- AzureLoadBalancer — Azure load balancer health probe IPs
- Storage — Azure Storage service IPs
Using service tags instead of IP ranges means your rules stay accurate as Microsoft updates its infrastructure — you do not need to manually update IP lists.
Exam Scenarios
"A VM can connect to other VMs in the same subnet but cannot reach the internet."
Check the route table first — a custom route may be sending internet traffic to a next hop that is not working. If no custom route exists, check if an NSG deny rule is blocking outbound internet traffic.
"An on-premises computer cannot connect to an Azure VM on port 443."
Check the NSG — is there an inbound allow rule for TCP 443 from the on-premises IP range? Also check that the VM is listening on 443 (application-level, not NSG-level).
"Traffic from a VM is not reaching the intended destination — it is going to a different endpoint."
This is a route table problem. Traffic being misdirected = wrong route. Traffic being blocked = NSG.
Practice AZ-104 networking questions to build fast recognition of these NSG vs route table scenarios.
NSG Rule Priority and Evaluation — The Exact Order
Within a single NSG, rules are evaluated in priority order from lowest number to highest. The first matching rule wins. Evaluation stops at the first match — lower-numbered rules are not overridden by higher-numbered rules that match the same traffic.
Built-in rules that cannot be deleted, always present at the bottom of every NSG:
- 65000 — AllowVnetInBound: Allows all traffic between resources in the same VNet.
- 65001 — AllowAzureLoadBalancerInBound: Allows health probe traffic from Azure Load Balancer.
- 65500 — DenyAllInBound: Denies everything that didn't match a higher-priority rule.
(Outbound has corresponding built-in rules.)
The exam trap: "Can you delete the DenyAllInBound rule?" → No. Built-in rules cannot be deleted or modified. You can only add custom rules with priority numbers 100–4096 to override them.
Another trap: "An NSG has a rule at priority 200 that allows port 443 inbound, and a rule at priority 100 that denies all inbound traffic. What happens to HTTPS traffic?" → It's denied. Priority 100 (deny all) is evaluated first and matches before priority 200 is reached. Candidates who think "allow overrides deny" get this wrong — order of evaluation determines the winner, not the action type.
Route Table Association Rules — The Specifics
Route tables are associated at the subnet level, not the VNet level or resource level. One subnet can have at most one route table. One route table can be associated with multiple subnets.
If a subnet has no route table, it uses the VNet's system routes (local VNet prefix, peering routes, VPN gateway routes, internet default route). Custom route tables add to and override system routes — they don't replace the entire routing table.
Specificity wins: if a custom route for 10.10.0.0/16 exists alongside the system route for the local VNet (10.10.0.0/16), the routes are evaluated by longest prefix match. More specific routes (longer prefix) win regardless of whether they're system or custom. The exam tests this: "A subnet has a custom route for 0.0.0.0/0 pointing to an NVA. A VM in the subnet sends traffic to another VM in the same VNet. Which route is used?" → The VNet system route (more specific), not the 0.0.0.0/0 custom route.
The Hub-Spoke Network Topology — How Route Tables Enable It
Hub-spoke is the most common enterprise Azure network topology and appears regularly in AZ-104 exam scenarios.
Architecture:
- Hub VNet: contains shared services — NVA (firewall appliance, usually Azure Firewall or a third-party NVA), VPN/ExpressRoute gateway, DNS servers.
- Spoke VNets: contain workloads, each peered to the hub. Spokes are not peered to each other directly.
- Route tables on spoke subnets: custom route 0.0.0.0/0 → Hub NVA private IP. This forces all internet-bound and cross-spoke traffic through the firewall.
- Route table on hub GatewaySubnet (for on-premises connectivity): routes for spoke address spaces → NVA, so on-premises-to-spoke traffic is also inspected.
Without custom route tables, peering traffic goes directly between VNets and bypasses the NVA entirely. Route tables are what force the traffic through the firewall — peering alone doesn't do it.
Exam pattern: "A company uses a hub-spoke topology with Azure Firewall in the hub VNet. Spoke VMs can communicate with each other without going through the firewall. What needs to be configured?" → Add a User Defined Route (UDR) in the spoke subnets routing all traffic to the Azure Firewall private IP.
System Routes vs Custom Routes — What You Can and Cannot Override
System routes Azure creates automatically:
- Local VNet address space → local (cannot be overridden)
- VNet peering → peering routes (can be overridden with a more specific or equal custom route — but this would break peering traffic)
- 0.0.0.0/0 → Internet (can be overridden)
- Service endpoints create system routes automatically
Custom routes (User Defined Routes) — You create these. Types of next hops:
- Virtual appliance — NVA or Azure Firewall (specify private IP)
- Virtual network gateway — For routing to on-premises via VPN/ExpressRoute
- Virtual network — Keep traffic within VNet (used to override a more general route)
- Internet — Route to Azure's internet edge
- None — Drop the traffic (black hole)
The one route you cannot override: the local VNet route. If you have a VNet with 10.10.0.0/16, you cannot create a custom route for 10.10.0.0/16 that sends traffic somewhere else — Azure ignores custom routes that would override local VNet routing. This is by design; it prevents breaking intra-VNet communication.
Force Tunneling — The Compliance Use Case
Force tunneling is a configuration where all internet-bound traffic from Azure VMs is redirected to on-premises (via VPN gateway) rather than going directly to the internet. This is required when corporate policy mandates that all traffic — including from cloud workloads — passes through on-premises security appliances for inspection and logging.
Implementation: add a custom route in the subnet's route table for 0.0.0.0/0 with next hop Virtual Network Gateway. This overrides the default system route that sends 0.0.0.0/0 directly to the internet.
Requirement: the VPN gateway must be configured for BGP or have the appropriate routes to accept this traffic. If the VPN tunnel goes down, VMs lose internet access entirely (no fallback to direct internet routing, which is intentional for compliance scenarios).
The exam distinguishes force tunneling from NVA routing: both redirect internet traffic, but force tunneling sends it to on-premises via VPN, while NVA routing keeps it in Azure and sends it through a firewall appliance. The exam clue is "on-premises firewall" or "on-premises security appliance" → force tunneling.
NSG + Route Table Together — The Architecture Pattern
These two components work independently on different layers, and the exam tests scenarios that require both to be configured correctly.
NSG answers: is this traffic permitted? Route table answers: where does this traffic go?
A common exam scenario that requires understanding both:
"A spoke VM sends traffic to the internet. The route table has 0.0.0.0/0 → Azure Firewall. The Azure Firewall has a rule permitting the traffic. An NSG on the spoke subnet allows outbound traffic to any destination. The VM cannot reach the internet. What is the cause?"
The answer depends on the NSG on the Azure Firewall's subnet or the NIC — if there's an NSG that blocks return traffic to the VM, the connection fails even though the outbound rules look correct. NSG evaluation happens at both the source and destination.
Another pattern: "A route table correctly directs traffic to an NVA. The NVA is configured to pass the traffic. But connectivity still fails." → Check the NSG on the NVA's NIC — it may be blocking traffic that the route table is correctly forwarding.