Cascade Regional Airlines applies a network security group to both the outstation-office subnet and the network interface of a specific VM within that subnet. For inbound traffic reaching that VM, in what order are the two NSGs evaluated?
Select an answer to reveal the explanation.
Short Explanation
Think of it as two checkpoints on the way in: traffic has to clear the subnet's checkpoint first, then the individual VM's checkpoint second. Both NSGs have to say yes for inbound traffic to actually reach the VM — one blocking rule anywhere in that chain stops it.
Full Explanation
When both a subnet and a NIC have an NSG associated with them, Azure evaluates them in a defined order rather than merging them: for inbound traffic, the subnet-level NSG is checked first, and only traffic it permits is then checked against the NIC-level NSG; for outbound traffic, the order is reversed, with the NIC-level NSG evaluated first. Traffic must be allowed by both NSGs to reach or leave the VM. The claim that only the NIC-level NSG matters ignores the subnet-level NSG entirely, which is incorrect since both are enforced independently. The claim that NIC-level is checked first for inbound traffic reverses the actual documented order. The claim that the two NSGs merge into one rule set misrepresents the architecture; they remain two separate, sequentially applied filters, and a deny in either one blocks the traffic regardless of what the other allows. This layered design lets Cascade apply a broad policy at the subnet level (for example, blocking all inbound traffic from the internet) while still applying a narrower, VM-specific policy at the NIC level. To troubleshoot unexpected blocks, an engineer should check ‘Effective security rules’ on the specific NIC, which shows the combined effect of both NSGs.