8.4 Network Watcher Diagnostics and Effective Rules

Network Watcher and the SC-500 Skill

The blueprint skill Evaluate effective security rules by using Azure Network Watcher diagnostics is highly scenario-driven. Microsoft expects you to know which tool answers which question when connectivity fails or when you must prove what NSG/admin rules actually allow.

Azure Network Watcher is the IaaS network monitoring and diagnostics suite for VMs, VNets, load balancers, application gateways, and related constructs. It is not a PaaS application APM tool. Capabilities group into monitoring, network diagnostic tools, and traffic logging/analytics.

You need a Network Watcher instance in the region of the resources under test (auto-enabled in many subscriptions/regions, but know it must be available).

---

Diagnostic Tools Map (Memorize This Table)

SC-500 “effective security rules” language maps especially to IP flow verify, NSG diagnostics, and the Effective security rules viewer—use them when the exam describes “blocked by NSG” uncertainty.

---

IP Flow Verify

IP flow verify tests whether a packet to or from a VM is allowed by configured NSG rules and Azure Virtual Network Manager security admin rules.

Inputs

• Direction (inbound/outbound)
• Protocol (TCP or UDP—not ICMP; use NSG diagnostics for ICMP scenarios)
• Local IP (VM NIC) and local port
• Remote IP and remote port

Outputs

• Allow or Deny
• The specific rule that matched (name/priority source)

Considerations

• Requires Network Watcher in the VM’s region and proper RBAC.
• Evaluates rules on the VM’s NIC association path (NIC NSG + subnet NSG + AVNM admin rules).
• For VM scale sets, prefer NSG diagnostics.
• Does not test guest OS firewalls, application bind failures, or asymmetric return paths beyond security rules.

Exam use: “Traffic to port 443 is failing; is an NSG denying it?” → IP flow verify first for a single VM 5-tuple.

---

Next Hop

Next hop diagnoses routing, not filtering.

Provide a source VM and destination IP; Azure returns:

Classic findings

Exam trap: IP flow verify says Allow, but traffic still fails → check Next hop (routing) and then OS/app layers. Filtering and routing are different planes.

---

NSG Diagnostics and Effective Security Rules

Effective security rules

Effective security rules shows the applied security configuration for a NIC:

• Rules from NSG associated to the NIC
• Rules from NSG associated to the subnet
• The aggregate effective set the platform enforces

Use this when multiple NSGs exist and humans cannot mentally merge priorities, defaults, and denies. Remember Azure NSG evaluation: rules processed by priority (lower number = higher priority); default rules exist; deny can override broader allows depending on priority.

NSG diagnostics

NSG diagnostics expands filtering troubleshooting:

• Targets VM, VMSS, or Application Gateway
• Tests whether traffic is allowed/denied for IP/prefix/service tag sources
• Identifies which rule matched
• Can help you craft a higher-priority rule to fix the issue

Compared with IP flow verify: NSG diagnostics is the broader multi-resource filtering tool; IP flow verify is the quick VM 5-tuple check (TCP/UDP).

---

Connection Troubleshoot and Packet Capture

Connection troubleshoot

Runs a one-time connectivity check from a source (often a VM) to a destination (VM, App Gateway, Bastion, IP/FQDN depending on capability). Results highlight:

• Whether connectivity succeeded
• Latency measurements
• Hints about network path problems (security rules, routing, user configuration)

Use when the exam scenario needs an end-to-end probe rather than isolated “only NSG” or “only route” checks. For continuous monitoring, Connection Monitor is the longer-running relative (monitoring set)—know the difference: troubleshoot = on-demand diagnostic; monitor = ongoing.

Packet capture

Packet capture installs/uses an extension capability to capture traffic on a VM for analysis (Wireshark, etc.). Use for:

• Proving whether SYN packets arrive
• Investigating unexpected protocols
• Validating that NSG/firewall allow still fails inside the guest

Packet capture is heavier and more forensic; exams usually prefer IP flow verify/next hop first, then capture if needed.

---

Evaluating Effective Security Rules in Exam Scenarios

Use a consistent decision tree:

Connectivity failure reported
        │
        ├─► IP flow verify / NSG diagnostics
        │      Deny? → Fix NSG or AVNM admin rule (priority/source/port)
        │      Allow? → continue
        │
        ├─► Next hop
        │      Wrong hop / None? → Fix UDR, peering, gateway transit
        │      Correct hop? → continue
        │
        ├─► Connection troubleshoot
        │      Path-level confirmation of remaining Azure issues
        │
        └─► Packet capture + guest OS firewall + application bind
               Issues outside Azure control plane

Scenario pack (exam style)

Scenario 1 — “Port 22 closed.”
IP flow verify inbound TCP 22 from admin IP → Deny by subnet NSG default-like custom deny. Fix: higher-priority allow for jump host subnet only.

Scenario 2 — “Allow rule exists but still blocked.”
Effective security rules show a lower-number deny on NIC NSG. Priority beats broader allow. Fix priority order—not “add another allow at 4000.”

Scenario 3 — “NSG allows internet, still no egress.”
Next hop shows Virtual appliance firewall IP, but firewall network rules deny. Not an NSG problem—fix Azure Firewall rules / UDRs.

Scenario 4 — “AVNM security admin rules.”
IP flow verify attributes deny to a security admin rule with precedence over NSG. Fix admin rule assignment/configuration in Virtual Network Manager—not only the local NSG.

Scenario 5 — “VMSS instances cannot reach SQL private endpoint.”
NSG diagnostics on scale set; also verify private DNS and next hop toward private endpoint subnet; NSG on PE subnet may deny.

---

Related Traffic Tools (Awareness)

Exam trap: Flow logs record traffic; NSG diagnostics / IP flow verify simulate/evaluate whether rules would allow a hypothetical or current configuration. Do not interchange them.

---

Permissions and Prerequisites

• Network Watcher enabled in region
• RBAC to read NICs, NSGs, route tables, and run Network Watcher actions
• VM running/accessible for some probes (connection troubleshoot, packet capture)
• Correct source NIC selection on multi-NIC VMs

SC-500 Exam Traps (Network Watcher)

• IP flow verify = filtering; Next hop = routing.
• IP flow verify: TCP/UDP only; not ICMP.
• Effective security rules = merged NIC + subnet reality.
• AVNM admin rules appear in flow verify—don’t only stare at NSG JSON.
• Allow in Azure still fails if guest firewall or app is down—capture/OS tools next.
• Blueprint phrase “evaluate effective security rules” → Network Watcher diagnostics, not guessing from a single portal blade.

Practical Checklist for Candidates

1. Reproduce 5-tuple precisely (direction, protocol, IPs, ports).
2. Run IP flow verify or NSG diagnostics.
3. Open effective security rules if multiple NSGs confuse the result.
4. Run next hop for the destination IP.
5. Use connection troubleshoot for path confirmation.
6. Escalate to packet capture only when Azure path is proven clean.
7. If firewall is in path, remember Azure Firewall rules are outside NSG effective rules—diagnose firewall separately.

Mastering this toolkit is how you pass scenario questions that stack NSG, UDR, Firewall, and private endpoints—exactly the multi-layer failures real Cloud and AI Security Engineers debug.