Skip to main content

Technical Lab: Evaluate Effective Security Rules in NSGs

Questions​

Question 1 — Multiple Choice​

A VM has two NICs: nic-frontend and nic-backend. The nic-frontend is associated with an NSG that allows inbound traffic on port 443. The subnet to which both NICs belong is associated with an NSG that denies inbound traffic on port 443 with priority 100.

What is the effective behavior for inbound HTTPS traffic destined to nic-frontend?

A) Traffic is allowed, as NIC NSG rules take precedence over subnet NSG rules.

B) Traffic is denied, as the subnet NSG is evaluated first and denial terminates processing.

C) Traffic is allowed, as allow rules always override deny rules when there's conflict between NSGs.

D) The behavior is undefined; associating two NSGs to the same flow is not supported by Azure.

Question 2 — Technical Scenario​

An administrator needs to diagnose why a VM cannot communicate with an external service on port 8080. He runs the following command:

az network watcher test-ip-flow \
  --direction Outbound \
  --protocol TCP \
  --local 10.0.1.4:5000 \
  --remote 203.0.113.50:8080 \
  --vm myVM \
  --resource-group myRG

The result returns Access: Deny and indicates the name of a rule. The administrator locates this rule in the subnet NSG and notices it has priority 200 and denies destination 203.0.113.50. However, in the VM's NIC NSG there's a rule with priority 150 that allows outbound traffic to any destination on port 8080.

Why is traffic still denied?

A) IP Flow Verify only returns the subnet NSG result, ignoring the NIC NSG.

B) For outbound traffic, the NIC NSG is evaluated before the subnet NSG; since the allow rule on the NIC has priority 150, it should allow. The scenario describes impossible behavior.

C) For outbound traffic, the NIC NSG is evaluated first; the allow rule on the NIC (priority 150) permits traffic before the subnet NSG is evaluated. The Deny result indicates there's a deny rule with higher priority (lower number) in the NIC NSG that the administrator hasn't located yet.

D) Outbound rules in subnet NSGs always take precedence over outbound rules in NIC NSGs, regardless of numerical priority.

Question 3 — True or False​

The VirtualNetwork service tag in an NSG rule represents exclusively the address space of the local VNet where the NSG is applied, without including peered VNets or networks connected via VPN Gateway.

True or False?

Question 4 — Technical Scenario​

An engineer reviews the inbound rules of an NSG associated with a subnet and finds the following configuration:

PriorityNamePortProtocolSourceDestinationAction
100Allow-SSH22TCP10.10.0.0/24AnyAllow
200Deny-Management22TCPAnyAnyDeny
300Allow-All-InboundAnyAnyAnyAnyAllow
65000AllowVnetInBoundAnyAnyVirtualNetworkAnyAllow

A VM in this subnet receives an SSH connection attempt originating from IP 10.10.0.55. The engineer claims that the priority 300 rule would be triggered for this traffic. What is the error in the engineer's reasoning?

A) The VirtualNetwork tag in rule 65000 would prevent any evaluation of previous rules.

B) Rules are evaluated in ascending priority order and processing stops at the first matching rule; traffic from 10.10.0.55 matches rule 100 and is allowed without rules 200 or 300 being evaluated.

C) The error is assuming priority 300 is evaluated; actually, rules are evaluated in descending priority order, so rule 65000 would be the first to be checked.

D) Priority 200 rule would deny traffic before any other rule, as deny rules always take precedence in Azure NSGs.

Question 5 — Multiple Choice​

When analyzing the effective rules of a NIC via Azure portal or CLI, what exactly is displayed?

A) Only the rules from the NSG directly associated with the NIC, excluding rules inherited from the subnet.

B) The union of rules from all NSGs in the subscription that reference the subnet or NIC, ordered by global priority.

C) The combination of rules from NSGs associated with the NIC and subnet, presented as a consolidated list that allows identifying which rule would be applied to a specific flow.

D) Only Azure default rules, as custom rules are only visible directly in each NSG.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

For inbound traffic, Azure evaluates the subnet NSG before the NIC NSG. If the subnet NSG contains a rule that denies traffic, the packet is immediately dropped and the NIC NSG is never consulted. The claim that the NIC NSG takes precedence (alternative A) reverses the evaluation order for inbound traffic. Alternative C introduces a non-existent principle in Azure: there's no hierarchy between allow and deny beyond numerical priority order within the same NSG. Alternative D is false; associating NSGs to both subnet and NIC is a fully supported and common scenario.

Answer Key — Question 2​

Answer: C

For outbound traffic, the order is reversed compared to inbound: the NIC NSG is evaluated first. If the allow rule on the NIC (priority 150) were really the most restrictive in that NSG, traffic would be allowed without reaching the subnet NSG. The Deny result returned by IP Flow Verify, pointing to the subnet, indicates there's a deny rule with numerically lower priority than 150 in the NIC NSG that the administrator hasn't identified yet. Alternative A is incorrect because IP Flow Verify evaluates both NSGs and accurately points to which rule in which NSG caused the block. Alternative D reverses the correct precedence for outbound traffic.

Answer Key — Question 3​

Answer: False

The VirtualNetwork tag encompasses the local VNet address space and also all address spaces of peered VNets, on-premises networks connected via VPN Gateway or ExpressRoute, and other connected spaces that Azure considers part of the virtual environment. This behavior is often underestimated and can result in NSG rules being more permissive than the administrator intended, especially in hub-and-spoke architectures where multiple VNets are peered.

Answer Key — Question 4​

Answer: B

The NSG evaluates rules in ascending priority order (lower number = higher precedence) and stops evaluation at the first matching rule. IP 10.10.0.55 belongs to block 10.10.0.0/24, so rule 100 matches and traffic is allowed. Rules 200, 300, and 65000 are never evaluated for this packet. The engineer made the classic mistake of ignoring that processing stops at the first match. Alternative C reverses the evaluation direction, and alternative D describes non-existent behavior: there's no automatic priority for deny rules in Azure NSGs.

Answer Key — Question 5​

Answer: C

The Effective Security Rules functionality consolidates in a single view the rules from NSGs associated with both the NIC and its subnet. This allows the administrator to identify, without switching between two separate NSGs, which rule would be applied to a specific type of traffic. Alternative A describes only the NIC NSG view in isolation, which can be obtained directly in the NSG resource, but doesn't represent effective rules. Alternative B is incorrect because the scope is restricted to NSGs in that specific NIC's network path, not the entire subscription. Alternative D contradicts the basic functionality of the feature.