A tugboat VM cannot reach an API VM on TCP 8443, and the night shift needs to know which NSG rule is to blame. Which Network Watcher check should they run first?
Select an answer to reveal the explanation.
Short Explanation
Want the guilty NSG rule’s name? IP flow verify is your flashlight—source, dest, port, protocol, direction—Allow or Deny with the rule called out. Don’t start with packet capture theater.
Full Explanation
Network Watcher IP flow verify evaluates whether traffic would be allowed or denied by NSGs for a five-tuple and returns the responsible rule name—ideal when a tugboat VM cannot reach an API VM on TCP 8443 and night shift needs the blaming rule quickly.
Creating a Sentinel analytics rule that alerts on every denied packet fails as the first troubleshooting step for a single flow. Starting a full packet capture on both NICs before checking security rules is heavier than needed first. Disabling both NSGs temporarily in production fails safe operations.
Exam caveat: IP flow verify is the go-to NSG decision diagnostic on AZ-500. Operational check: run IP flow verify with correct source, destination, port, protocol, and direction, read Allow/Deny and rule name, fix the rule, and retest application connectivity. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.