A lock subnet was supposed to send 0.0.0.0/0 to Azure Firewall, but a VM still egresses directly to the Internet. How should the security engineer prove the routing miss?
Select an answer to reveal the explanation.
Short Explanation
Thought default route went to the firewall but the VM still sneaks out? Next hop (or connection troubleshoot) shows the real next hop and outs a missing or overridden UDR.
Full Explanation
Network Watcher next hop reports the effective next hop for traffic from a VM NIC, exposing missing or overridden UDRs when a lock subnet was supposed to send 0.0.0.0/0 to Azure Firewall but still egresses directly to the Internet. Use next hop and/or connection troubleshoot to prove the routing miss.
Assuming Azure Firewall always steals default routes so no diagnostic is required fails. Deleting the VM’s NIC to permanently rewrite all route tables in the subscription is destructive nonsense. Enabling Microsoft Defender for DNS only does not force all VM egress through Azure Firewall.
Exam caveat: effective routes and next hop beat guessing when forced tunneling fails. Operational check: run next hop for an Internet destination, compare to expected firewall private IP, fix the route table association or UDR, and retest egress SNAT/inspection. 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.