A grain-elevator NSG has an Allow on TCP 443 at priority 400 and a Deny on TCP 443 at priority 200. Operators argue the Allow should win because it was added last. Which rule takes effect?
Select an answer to reveal the explanation.
Short Explanation
NSG priority is a race number, not a calendar. Two hundred beats four hundred—so that Deny on 443 lands first and the late Allow never gets a turn.
Full Explanation
NSG rules are processed by priority number: the lowest number has the highest priority and is evaluated first. When a grain-elevator NSG has Deny TCP 443 at priority 200 and Allow TCP 443 at priority 400, the Deny at 200 takes effect for matching traffic. “Added last” does not override priority numbering.
Claiming the Allow at 400 wins because it is newest fails—recency is not the NSG evaluation rule. Claiming neither rule applies because unmatched traffic uses VirtualNetwork service tag allow confuses default rules with these explicit matches. Claiming both merge into a soft allow based on display name is false.
Exam caveat: remember lower priority number wins; default rules sit at high numbers such as 65000 and above. Operational check: document rule priorities, use Effective security rules, test HTTPS from a source matching both rules, and renumber carefully when inserting exceptions above a Deny. 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.