"An Azure VM is not reachable" is one of the most common troubleshooting scenarios on the AZ-104 exam. The exam expects you to know the correct order to check and what each component controls. Working through them systematically will identify the problem every time.
The Four Things to Check
- NSG (Network Security Group) — Is inbound traffic allowed on the correct port?
- Route table — Is traffic being routed correctly, or is a custom route sending it somewhere unexpected?
- Public IP address — Does the VM have one assigned?
- VM's network interface — Is it in the correct subnet?
Step 1: Check the NSG
An NSG contains allow/deny rules evaluated in priority order (lower number = evaluated first). For connectivity problems, check the inbound rules on both:
- The NSG associated with the subnet (if any)
- The NSG associated with the VM's network interface (if any)
Both are evaluated. If either denies the traffic, the connection fails.
Default inbound deny rule: every NSG has a rule with priority 65500 that denies all inbound traffic not explicitly allowed. This rule cannot be removed.
Common exam scenario: "A VM was deployed and RDP is not working. An NSG is associated with the subnet. What is the most likely cause?"
The NSG does not have a rule allowing TCP port 3389 (RDP) inbound. The fix is to add an inbound rule permitting port 3389 from the appropriate source.
To add an inbound rule in the Azure portal: NSG → Inbound security rules → Add → set destination port to 3389, protocol TCP, action Allow.
Step 2: Check the Route Table
A route table associated with the subnet determines where traffic is sent. If a custom route table has a 0.0.0.0/0 route pointing to a network virtual appliance (NVA) or VPN gateway instead of the internet, outbound internet traffic will not reach its destination — and inbound traffic may not route back correctly.
Exam scenario: "A VM can reach other VMs on the same VNet but cannot reach the internet. An NSG allows outbound traffic. What else should be checked?"
Check the route table — a custom route may be redirecting internet-bound traffic to an NVA that is not functioning, or there may be no route for the internet at all.
Step 3: Check the Public IP
If you need to connect to a VM from the internet, the VM must have a public IP address associated with its network interface. A VM on a private subnet without a public IP is not directly reachable from outside Azure.
Options for connecting without a direct public IP:
- Azure Bastion (managed RDP/SSH through the browser, no public IP required)
- VPN gateway (connects your on-premises network to the VNet)
- ExpressRoute (dedicated private connection)
Exam trap: "A VM has no public IP and is in a private subnet. How can an administrator connect securely without adding a public IP?" — Azure Bastion is the preferred answer.
Step 4: Check the Network Interface and Subnet
The VM's NIC must be in the correct subnet. If it was accidentally placed in the wrong subnet, it will not have connectivity to the expected resources.
Also verify that the NIC is in the enabled state and associated with the VM.
Azure Network Watcher
For troubleshooting connectivity, Azure Network Watcher provides:
- IP flow verify — Tests whether a specific packet (source/destination IP and port) is allowed or denied by NSG rules on a given NIC
- Next hop — Shows what route table entry applies for a given source/destination, helping diagnose routing issues
- Connection troubleshoot — Tests TCP/UDP connectivity from a VM to an endpoint
Exam trap: which tool checks whether an NSG is blocking a specific port? The answer is "IP flow verify" in Network Watcher, not "Connection troubleshoot."
The Diagnostic Order for the Exam
- NSG inbound rules on the subnet and NIC
- Custom route table on the subnet
- Public IP assigned to the NIC
- VM and NIC are in the correct subnet and are enabled
Practice AZ-104 networking questions with topology scenarios to build speed on this diagnostic sequence.
NSG Effective Security Rules — The Tool That Saves Time
When you can't connect to a VM and you suspect NSG rules are the culprit, the instinct is to open each NSG and scan the rules manually. Don't. Azure has a better path.
Go to the VM in the portal → Networking → Effective security rules. This view combines every NSG that applies to the VM — the NSG on the NIC, the NSG on the subnet — and shows you the merged result in priority order. You can see at a glance exactly what traffic is allowed and denied without cross-referencing two separate resources.
The exam tests this tool directly. The question pattern is: "A VM has an NSG on its NIC and an NSG on its subnet. A network engineer wants to quickly determine what traffic is allowed to reach the VM. What should they use?" The answer is Effective security rules, not manually reading both NSGs separately.
You can also reach this from Network Watcher → Effective security rules if you want to check multiple VMs in one place.
Network Watcher IP Flow Verify — The Exam's Favourite Tool
IP Flow Verify is a diagnostic tool under Network Watcher that answers a simple question: given a specific source IP, destination IP, port, and protocol — will the current NSG rules allow or deny that traffic, and which rule is responsible?
In the portal: Network Watcher → IP flow verify → select subscription, resource group, VM, NIC → enter direction, protocol, local port, remote IP, remote port → Check.
The result tells you "Access allowed" or "Access denied" and names the specific NSG rule that made the decision. This is invaluable when you have dozens of rules across multiple NSGs and need to pinpoint the blocking rule without guessing.
For the exam, IP Flow Verify is the correct answer whenever a question asks how to "test whether a specific type of traffic is allowed by NSG rules" or "determine which rule is blocking inbound RDP to a VM." It does not test actual connectivity end-to-end — it only evaluates NSG logic. If the traffic is NSG-allowed but still failing, you'd look elsewhere (routing, firewall appliance, OS firewall).
JIT (Just-in-Time) VM Access — The Security Best Practice
Just-in-Time VM Access is a Microsoft Defender for Cloud feature that closes RDP (3389) and SSH (22) by default and only opens them on demand for a limited time window.
How it works: an administrator or developer requests access through the portal, specifying which port and for how long (maximum 3 hours by default). Defender for Cloud temporarily adds an NSG allow rule for that specific source IP for the requested duration. When the window expires, the rule is removed automatically.
The exam tests JIT as the answer for: "The security team requires that RDP access to production VMs is only available when explicitly requested and automatically revoked after use. What should be configured?" The answer is JIT VM Access, not a permanent NSG rule.
Enabling it: Microsoft Defender for Cloud → Workload protections → Just-in-time VM access → select VMs → Enable JIT.
Azure Bastion — The Agentless Secure Access Option
Azure Bastion provides browser-based RDP and SSH to VMs without exposing port 3389 or 22 to the internet. There is no public IP required on the VM, no VPN client to install, and no agent running inside the VM. You connect through the Azure portal using your browser.
The architecture requirement the exam loves testing: Bastion requires a dedicated subnet in the same VNet named exactly AzureBastionSubnet (case-sensitive). The subnet must be /27 or larger. A /28 will fail deployment. The Bastion resource itself gets a public IP, but the VMs it connects to do not need one.
When a question says "the most secure way to allow administrators to RDP to Azure VMs without exposing any ports to the internet," the answer is Azure Bastion. Not JIT (which still uses port 3389 temporarily), not a VPN (which is valid but requires client setup), not a jump box (which requires maintaining another VM). Bastion is the cleanest answer for that specific question pattern.
Run Command and Serial Console — The Break-Glass Options
These two tools are for when networking is completely broken and you still need to execute something on the VM.
Run Command executes a PowerShell or shell script on the VM through the Azure VM agent, without any network connection from the client. You paste the script in the portal, it runs inside the VM, and the output returns to you. It requires the Azure VM agent to be running and the VM to have internet egress (or a private endpoint to the service). Use it when: you need to fix a firewall rule or misconfigured network setting on the VM itself, but you can't get in because networking is broken.
Portal path: VM → Run command → RunPowerShellScript or RunShellScript.
Serial Console gives you a terminal connection through the VM's serial port, completely independent of the network stack. Even if the NIC is misconfigured, the OS is refusing connections, or there's a routing loop — Serial Console still works as long as the VM is powered on and the OS is bootable. It requires boot diagnostics to be enabled on the VM.
Portal path: VM → Help → Serial console.
The exam distinguishes these two: "A VM's networking is misconfigured and the administrator cannot connect. What provides access to the VM's command line without network connectivity?" — Serial Console. "An administrator needs to run a remediation script on a VM but RDP is blocked. The network is functional but the RDP port is closed." — Run Command.
Exam Scenario: VM Deployed, RDP Not Working, No NSG Changes Since Deployment
This is the most common RDP troubleshooting scenario on the exam and the answer is consistently the same: no inbound RDP rule exists in the NSG.
When you create a VM in Azure and associate it with an NSG (or let Azure create one), the default NSG has these inbound rules: allow VNet traffic, allow Azure Load Balancer probes, deny everything else. There is no default rule permitting port 3389 from the internet. You must add it explicitly.
The wrong answers candidates choose: "The VM has no public IP" — wrong, because even with a public IP, the NSG still blocks RDP by default. "The route table is missing a route to the internet" — wrong, the default route 0.0.0.0/0 to Internet is always present unless you've overridden it. "The VM agent is not running" — wrong, the VM agent has nothing to do with RDP connectivity.
The correct fix: NSG → Inbound security rules → Add → Destination port: 3389, Protocol: TCP, Priority: 100 (or any number below the deny-all rule), Action: Allow.