Azure NSG rules: priorities, direction and evaluation

Learn how Azure evaluates subnet and NIC network security groups, rule priorities and stateful traffic filtering.

Read, then practise

Compare the concepts, work through a scenario and check your answer.

AZ-104 guide · no account required

Evaluate rules inside each NSG

An NSG filters traffic using direction, protocol, source, destination and ports. A smaller priority number has higher precedence. Evaluation stops at the first matching rule in that NSG.

Custom rules use priorities 100–4096 and precede the default rules. Priorities belong to an individual NSG; a NIC allow at 100 cannot override a subnet deny at 300.

Check both subnet and NIC

If both scopes have an NSG, traffic must be permitted by both. Follow the processing order for the direction you are troubleshooting.

Check both subnet and NIC
Direction	First NSG	Second NSG
Inbound	Subnet	NIC
Outbound	NIC	Subnet

Troubleshoot the complete path

NSGs are stateful: response traffic for an allowed connection does not require a separate reverse rule. Rule changes affect new connections; existing flows may continue.

After checking matching rules in every applicable NSG, inspect routes, the guest firewall and the application listener. An NSG allow does not create connectivity by itself. Use effective security rules and Network Watcher IP flow verify to investigate the applicable filtering decision.

Check your understanding

Question 1NSGs and application security groups

In VNet-Fin, web servers run in Subnet-Front, and their network interfaces are members of the application security group ASG-WebTier. Database servers run in Subnet-Back, which is associated with NSG-Back. NSG-Back contains a custom inbound rule that denies traffic from any source at priority 4000. Each database server’s network interface is associated with NSG-DB, which contains only the default rules. The web servers must connect to the database servers on TCP port 1433, all other inbound traffic to the database servers must be blocked, and you must use the fewest security rules. What should you do?

In NSG-DB, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100
In NSG-Back, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 4096
In both NSG-Back and NSG-DB, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100
In NSG-Back, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100

Show answer and explanation

Correct answer: D · In NSG-Back, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100

Inbound traffic is evaluated by the subnet NSG first and then by the NIC NSG, and both must allow it. In NSG-Back, an allow at priority 100 matches before the deny at 4000, because lower numbers are processed first. NSG-DB already permits the web servers through its default AllowVnetInBound rule, because both tiers are in VNet-Fin. Everything else is still stopped by the deny at 4000 in NSG-Back. Using the ASG as the source is valid because the web and database interfaces are in the same virtual network.

Why the other choices do not fit

NSG-DB already allows this traffic through AllowVnetInBound. The block is the deny at 4000 in NSG-Back, which is evaluated first for inbound traffic and is not changed.
Priority 4096 is valid for a custom rule, but it is processed after the deny at 4000. The deny still matches the traffic first.
This works, but the NSG-DB rule is redundant because the default AllowVnetInBound rule already permits the traffic. Two rules fail the fewest-rules requirement.

How NSGs filter inbound traffic Default security rules and priorities Application security groups

Original practice scenarios adapted from the Pass104 question bank, not actual Microsoft exam questions. Consult Microsoft Learn for current service details. Pass104 is independent of Microsoft.