The trickiest AZ-104 networking questions read like this: "VM1 can't connect to VM2. What is the cause, and what should you use to confirm it?" The official skills outline lists "troubleshoot network connectivity" and "evaluate effective security rules in NSGs" as separate items, and the monitoring domain adds "use Azure Network Watcher and Connection Monitor." A mistake in any one place, whether an NSG, a route, peering, or DNS, produces the same symptom ("can't connect"), so without a fixed order of checks you end up wandering between the options.
This article lays out a five-step order that narrows a connectivity problem from the outside in, along with the Network Watcher tool for each step. It covers the order in which NSGs are evaluated at the subnet and the NIC, route selection rules and next hops, why peering isn't transitive and how gateway transit works, and private DNS zone links and auto-registration. The basics of NSGs, UDRs, and peering are covered first in VNet, NSG, DNS, and Load Balancer Explained for Beginners.
---
Narrow a Connectivity Problem in Five Steps
When a parcel doesn't arrive, you check in order: is the address right, is the delivery route right, did building security stop it, are the regional delivery networks connected, and is the recipient home? Checking a VM-to-VM connectivity problem in the same order finds the cause quickly.
!Five steps that narrow a VM connectivity problem from the outside in
| Step | Question | Tools to check | |------|------|------| | 1. Name resolution | Does the name resolve to the right IP? | nslookup, the private DNS zone's virtual network link | | 2. Routing | Does the packet go to the right next hop? | Next hop, the NIC's effective routes | | 3. Security rules | Does an NSG allow it? | IP flow verify, NSG diagnostics, effective security rules | | 4. Topology | Are the VNets, and on-premises, connected? | Peering status, VPN troubleshoot, connection troubleshoot | | 5. Inside the VM | Is the app listening, and does the OS firewall allow it? | Connection troubleshoot, packet capture, in-VM diagnostics |
Exam tip: If a question says "find which rule blocks the traffic," the answer is IP flow verify; "find where the traffic is routed" is Next hop; "test a connection once between a VM and a destination and see latency and hops" is connection troubleshoot; "monitor continuously over time" is Connection Monitor.
---
Network Watcher Tools at a Glance
Network Watcher is a suite of tools for diagnosing IaaS network resources such as VMs, VNets, load balancers, and application gateways. Remember also that it isn't meant for monitoring PaaS services.
| Tool | What it does | What the result tells you | |------|------|------| | IP flow verify | Checks whether a specific 5-tuple packet is allowed, from a VM's point of view | Allowed/denied + the name of the deciding security rule | | NSG diagnostics | Checks traffic for an IP, prefix, or service tag at a VM, scale set, or application gateway | Allowed/denied + the rule; can add a higher-priority rule | | Next hop | Checks the route to a specific destination IP | Next hop type, IP address, route table ID | | Effective security rules | Shows the rules actually applied to a NIC | The NIC's NSG, the subnet's NSG, and the aggregate of both | | Connection troubleshoot | Tests a connection once from a VM (and more) to a VM, FQDN, URI, or IP | Reachability, latency, hops, detected issues | | Connection monitor | Continuously monitors connections between Azure and hybrid endpoints | Latency and loss over time, alerts | | Packet capture | Captures traffic for a VM or scale set remotely | Packet-level analysis | | VPN troubleshoot | Diagnoses virtual network gateways and their connections | Gateway and connection health and logs | | Flow logs | Logs IP traffic information to storage, visualized with traffic analytics | Records of allowed and denied flows | | Topology | Visualizes relationships of network resources across subscriptions and regions | Understanding the configuration |
For flow logs, use virtual network flow logs from now on. New NSG flow logs can no longer be created, and NSG flow logs retire on September 30, 2027.
---
NSG Rules Are Evaluated Twice, in a Fixed Order
If a building has both a guard at the entrance (the subnet NSG) and a lock on the office door (the NIC NSG), you must get past both. Azure evaluates them in a different order depending on direction.
| Direction | Evaluation order | Result | |------|------|------| | Inbound | Subnet NSG → NIC NSG | If the subnet denies it, the NIC NSG isn't evaluated | | Outbound | NIC NSG → subnet NSG | If the NIC denies it, the subnet NSG isn't evaluated | | Between VMs in the same subnet | Same order as above | The subnet NSG still applies within the same subnet |
Within each NSG, rules are evaluated from the lowest priority number (100–4096) upward, and evaluation stops at the first matching rule. NSGs are stateful, so return traffic for an allowed connection comes back without a separate rule. When you haven't created any rules, these default rules apply.
| Direction | Default rule (priority) | Meaning | |------|------|------| | Inbound | AllowVNetInBound (65000) | Allows traffic from inside the VNet and peered VNets | | Inbound | AllowAzureLoadBalancerInBound (65001) | Allows load balancer health probes | | Inbound | DenyAllInBound (65500) | Denies everything else | | Outbound | AllowVnetOutBound (65000) | Allows traffic going into the VNet | | Outbound | AllowInternetOutBound (65001) | Allows traffic going to the internet | | Outbound | DenyAllOutBound (65500) | Denies everything else |
Checking It With a Table Question
The subnet NSG has a rule "priority 200, allow TCP 3389," and VM1's NIC NSG has a rule "priority 100, deny all traffic from the internet." An RDP attempt from the internet to VM1 passes the subnet NSG but is denied by the NIC NSG. Effective security rules shows the rules of both NSGs together, and running IP flow verify returns the name of the NIC NSG's deny rule.
Exam tip: When picking a fix, check which NSG the rule goes into and with what priority. To beat the priority 100 deny rule in the NIC NSG, you must add an allow rule with a number lower than 100 to that same NIC NSG. No matter how low a number you use in the subnet NSG, the NIC NSG's deny doesn't change.
---
Routing: Where Does the Packet Go?
Even when an NSG allows traffic, a packet sent to the wrong place never connects. Azure automatically creates system routes for every subnet, and user-defined routes (UDRs) and BGP routes can override them.
There are two route selection rules. First, Azure picks the route whose prefix matches the destination IP most specifically (longest prefix match). If both 10.0.0.0/16 and 10.0.0.0/24 exist, traffic to 10.0.0.5 follows the /24 route. If the prefixes are identical, the priority is user-defined route → BGP route → system route.
| Next hop type | Meaning | What to remember | |------|------|------| | Virtual network | Delivered directly within the VNet address space | System route | | Internet | Sent to the internet | The default for the 0.0.0.0/0 system route | | Virtual appliance | Sent to the private IP of an NVA such as a firewall | IP forwarding must be enabled on that NVA's NIC | | Virtual network gateway | Sent to a VPN or ExpressRoute gateway | Traffic headed to on-premises | | None | Traffic is dropped | Used to block a range on purpose |
Exam tip: If "a UDR sends 0.0.0.0/0 to an NVA and all internet traffic stops," suspect the IP forwarding setting on the NVA's NIC or routing inside the NVA. The Next hop tool shows the next hop type as "Virtual appliance" along with the ID of the route table that applied.
---
Peering and Gateways: Topology Problems
Even with correct NSGs and routes, VNets can't talk without a connection between them. The most frequent trap is that peering isn't transitive. If VNet A is peered with B and B with C, A and C still can't communicate directly.
| Fix | How it works | |------|------| | Peer A and C directly | Simplest, but the number of peerings grows fast as VNets are added | | Go through an NVA or Azure Firewall in the hub | A UDR on spoke subnets sets the hub firewall as the next hop; allow forwarded traffic on the peering | | Share the hub's gateway | With gateway transit, spokes use the hub's VPN or ExpressRoute gateway |
Gateway transit means enabling "Allow gateway transit" on the hub side of the peering and "Use remote gateways" on the spoke side. In the current portal these appear as "Allow gateway or route server in this virtual network to forward traffic" and "Use the remote virtual network's gateway or route server." A VNet that uses a remote gateway can't have a gateway of its own.
The address spaces of two peered VNets must not overlap A peering status of "Initiated" means the other side's peering doesn't exist yet If one side's peering is deleted, the other side becomes "Disconnected" and must be deleted and recreated A VPN gateway is deployed to a subnet named exactly GatewaySubnet, and no other resources go in that subnet
Exam tip: "VMs in a spoke VNet must reach on-premises through the hub's VPN gateway" means allowing gateway transit on the hub peering and using remote gateways on the spoke peering. An option that creates a new gateway in the spoke is wrong.
---
DNS: When a Name Won't Resolve
If you can connect by IP but not by name, it's a DNS problem. An Azure private DNS zone is an internal phone book used only inside VNets, but just creating the zone doesn't let any VNet read it.
| Setting | Behavior | What to remember | |------|------|------| | Virtual network link | The linked VNet can query the zone's records | Many VNets can link to one zone | | Auto-registration | Automatically creates and deletes A records for VMs in the linked VNet | A VNet can be linked to only one zone with auto-registration; VMs