A lock-chamber VM sits on a subnet that already has an NSG, and operators also pinned a second NSG to the NIC. Inbound SSH from the harbor-pilot jump host still fails. What should the security engineer understand about effective rules?
Select an answer to reveal the explanation.
Short Explanation
Two NSGs on the path aren’t a relay race—they’re a double filter. Subnet and NIC both apply, and the stingiest allow/deny wins. Check effective security rules.
Full Explanation
When an NSG is associated with both the subnet and the NIC, inbound and outbound traffic is evaluated against both NSGs, and the most restrictive effective result applies. For a lock-chamber VM whose subnet already has an NSG and whose NIC has a second NSG, inbound SSH from the harbor-pilot jump host can fail if either NSG denies the flow—even when the other would allow it. Effective security rules in Network Watcher reflect that combined evaluation.
Claiming the NIC NSG completely replaces the subnet NSG fails by concept: both apply. Claiming Azure Firewall always overrides NSG associations so effective NSG rules can be ignored misstates the relationship—Firewall and NSGs are different controls. Claiming only the alphabetically first NSG name applies is false.
Exam caveat: troubleshoot with Network Watcher effective security rules and IP flow verify rather than staring at one NSG blade. Operational check: run IP flow verify for the jump host to the VM on TCP 22, inspect effective security rules for both associations, adjust the denying rule, and retest SSH. 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.