Courseiva

Understanding NSG Rule Priority Order in Azure

An NSG is associated with a subnet. It contains these inbound rules: - Priority 100: Deny TCP 443 from Internet to Any - Priority 200: Allow TCP 443 from 203.0.113.0/24 to Any A tester at 203.0.113.10 browses to the VM's HTTPS endpoint in that subnet. What happens?

⚠ Common exam trap

The trap here is that candidates mistakenly believe NSG rules are evaluated based on the specificity of the source or destination (like a firewall with longest-prefix matching), but Azure NSGs strictly use priority-based evaluation where lower numeric priority wins.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The request is denied because the priority 100 deny rule matches before the allow rule.

Network Security Group (NSG) rules are evaluated in priority order, from lowest to highest numeric value. The priority 100 rule explicitly denies TCP 443 from the Internet (which includes the 203.0.113.0/24 range), and it is evaluated before the priority 200 allow rule. Since the deny rule matches first, the traffic is blocked regardless of the more specific source IP in the allow rule.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    The request is allowed because the more specific source range matches first.

    Why it's wrong here

    Azure Network Security Groups do not prioritize rules by how specific the source IP range is; they use numeric priority values, with the lowest number evaluated first. Because the inbound deny rule at priority 100 is evaluated before the allow rule at priority 200, the HTTPS packet is rejected regardless of the source address specificity.

    When this WOULD be correct

    This option would be correct if the NSG rules were processed using a 'most specific match' model, similar to route tables. For example, if the question stated that NSG rules are evaluated based on the most specific source IP range, then the allow rule with a more specific range would override the broader deny.

  • ✓

    The request is denied because the priority 100 deny rule matches before the allow rule.

    Why this is correct

    Azure NSGs evaluate rules by priority, and the lowest number is processed first. Both rules match this HTTPS traffic, but the deny rule at priority 100 is considered before the allow rule at priority 200. Because the first match wins, the packet is blocked even though the source is in the allowed range.

  • ✗

    The request is denied only if the VM has no public IP address.

    Why it's wrong here

    The presence or absence of a public IP address on the VM does not influence NSG rule evaluation. NSGs inspect packet attributes such as source/destination IP, port, and protocol against the rule set, so traffic that matches the priority 100 deny rule is blocked even when the VM has a public IP that would normally allow inbound internet traffic.

    When this WOULD be correct

    If the question involved Azure Firewall or a load balancer with SNAT, where traffic from the internet to a VM without a public IP might be handled differently. For example, if the VM is behind a load balancer and the NSG is on the VM subnet, but the load balancer's source NAT changes the source IP, then the VM's public IP presence could affect routing.

  • ✗

    The request is allowed because default NSG rules always override custom rules.

    Why it's wrong here

    Default NSG rules have very high priority numbers (e.g., 65000, 65500), so they are evaluated only after any custom rules with lower numbers. A custom deny rule at priority 100 always takes precedence over the default allow rules, and custom rules are never overridden by default rules once a match occurs.

    When this WOULD be correct

    If the question stated that no custom rules exist and only default rules are present, then default rules would allow or deny traffic based on their predefined behavior (e.g., default inbound deny all internet traffic).

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

✓The request is denied because the priority 100 deny rule matches before the allow rule.Correct answer▾

Why this is correct

Azure NSGs evaluate rules by priority, and the lowest number is processed first. Both rules match this HTTPS traffic, but the deny rule at priority 100 is considered before the allow rule at priority 200. Because the first match wins, the packet is blocked even though the source is in the allowed range.

✗The request is allowed because the more specific source range matches first.Wrong answer — click to see why▾

Why this is wrong here

NSG rules are evaluated by priority order, not by specificity. The priority 100 deny rule matches all traffic from Internet, including 203.0.113.0/24, so it is applied before the priority 200 allow rule, resulting in denial.

★ When this WOULD be the correct answer

This option would be correct if the NSG rules were processed using a 'most specific match' model, similar to route tables. For example, if the question stated that NSG rules are evaluated based on the most specific source IP range, then the allow rule with a more specific range would override the broader deny.

Why candidates choose this

Candidates often confuse NSG rule evaluation with route table evaluation, where more specific prefixes take precedence. They incorrectly assume that a more specific source IP range in an allow rule overrides a broader deny rule, regardless of priority.

✗The request is denied only if the VM has no public IP address.Wrong answer — click to see why▾

Why this is wrong here

NSG rules are stateless and apply to all traffic entering the subnet, regardless of whether the VM has a public IP. The deny rule at priority 100 blocks TCP 443 from Internet (any source), so the tester's request is denied irrespective of the VM's public IP.

★ When this WOULD be the correct answer

If the question involved Azure Firewall or a load balancer with SNAT, where traffic from the internet to a VM without a public IP might be handled differently. For example, if the VM is behind a load balancer and the NSG is on the VM subnet, but the load balancer's source NAT changes the source IP, then the VM's public IP presence could affect routing.

Why candidates choose this

Candidates may confuse NSG behavior with public IP requirements for internet connectivity, thinking that without a public IP, the VM cannot receive internet traffic, so the NSG rule is irrelevant. They overlook that NSGs filter traffic at the subnet level regardless of public IP assignment.

✗The request is allowed because default NSG rules always override custom rules.Wrong answer — click to see why▾

Why this is wrong here

Default NSG rules have lower priority than custom rules and do not override them; the priority 100 deny rule explicitly blocks the traffic before any default rule could apply.

★ When this WOULD be the correct answer

If the question stated that no custom rules exist and only default rules are present, then default rules would allow or deny traffic based on their predefined behavior (e.g., default inbound deny all internet traffic).

Why candidates choose this

Candidates may mistakenly believe that default rules take precedence over custom rules, or they may confuse NSG rule evaluation order with Azure policy or role-based access control hierarchies.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Visual reference

192.168.1.0 /24 256 addresses (254 usable) 192.168.1.0 /25 Subnet A 128 addr (126 usable) 192.168.1.128 /25 Subnet B 128 addr (126 usable) Borrowing 1 bit from host portion creates 2 subnets (/25)

About these practice questions

Courseiva writes every AZ-104 question from scratch — 1,053 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

4 more ways this is tested on AZ-104

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. A web tier and an app tier run in separate subnets. Each VM NIC is placed in an application security group named WebASG or AppASG. The administrator must allow only the web tier to reach the app tier on TCP port 8443 and block all other inbound traffic to the app tier. Which NSG rule should be created on the app subnet?

medium
  • ✓ A.Allow TCP 8443 from WebASG to AppASG with a priority lower number than the deny rule.
  • B.Allow TCP 8443 from the entire virtual network to the app subnet with a lower priority than the deny rule.
  • C.Allow UDP 8443 from WebASG to AppASG with any priority below 65000.
  • D.Allow TCP 8443 from WebASG to AppASG with a priority higher number than the deny rule.

Why A: NSG rules are evaluated in priority order, with lower numbers having higher priority. By placing an Allow rule for TCP 8443 from WebASG to AppASG with a lower priority number than a subsequent Deny-All rule, only traffic from the web tier is permitted, and all other inbound traffic to the app subnet is blocked. This leverages application security groups (ASGs) to define fine-grained, role-based network security policies without relying on IP addresses.

Variation 2. An application subnet has a network security group with these inbound rules: Allow-Web-From-Internet at priority 200, Allow-App-From-Web at priority 300, and Deny-All-Inbound at priority 250. The web tier must reach the app tier on TCP 8080, but traffic is being denied. The administrator confirms the source and destination IPs are correct. What is the best fix?

medium
  • A.Delete the Deny-All-Inbound rule because default NSG rules will allow the traffic.
  • ✓ B.Change the Allow-App-From-Web rule to a lower priority number than 250.
  • C.Add a route table entry for TCP 8080 traffic to bypass the NSG.
  • D.Move the Allow-Web-From-Internet rule to priority 400.

Why B: The Deny-All-Inbound rule at priority 250 is evaluated before the Allow-App-From-Web rule at priority 300 because lower priority numbers are processed first. To allow web-to-app traffic on TCP 8080, the Allow-App-From-Web rule must have a lower priority number (e.g., 240) than the Deny-All-Inbound rule so it is evaluated and applied first, permitting the traffic before the deny rule blocks it.

Variation 3. An NSG attached to a subnet contains these inbound rules: Deny-All-Inbound at priority 200, Allow-HTTPS-Admin at priority 250 from 203.0.113.20/32, and Allow-HTTPS-Internet at priority 300. A VM in the subnet cannot receive HTTPS from the admin workstation even though the source IP is correct. What should the administrator change?

medium
  • A.Change the protocol from TCP to Any on the allow rule.
  • ✓ B.Move the Allow-HTTPS-Admin rule to a priority number lower than 200.
  • C.Associate a NAT gateway with the subnet.
  • D.Enable service endpoint policies on the subnet.

Why B: The Deny-All-Inbound rule at priority 200 blocks all traffic, including HTTPS from the admin workstation, because NSG rules are evaluated in priority order (lowest number first). The Allow-HTTPS-Admin rule at priority 250 is never reached since the deny rule with a higher priority (lower number) matches first. To allow the admin traffic, the allow rule must have a priority lower than 200 (e.g., 150) so it is evaluated before the deny rule.

Variation 4. Based on the exhibit, a help desk engineer cannot RDP from an approved admin subnet to a VM in Azure. What change should the administrator make so the connection is allowed?

medium
  • A.Change the deny rule to use UDP instead of TCP.
  • ✓ B.Move Allow-RDP-Admin to a priority lower than 100.
  • C.Add the VM NIC to an application security group and leave the rules unchanged.
  • D.Delete the default AllowVNetInBound rule.

Why B: The exhibit shows a deny rule with priority 100 that blocks all inbound traffic from the approved admin subnet, and an allow rule for RDP with a priority lower than 100 (e.g., 200). Since Azure Network Security Group (NSG) rules are evaluated in priority order (lowest number first), the deny rule at priority 100 is evaluated before the allow rule at a lower priority, thus blocking the RDP connection. To allow the RDP traffic, the administrator must move the Allow-RDP-Admin rule to a priority lower than 100 (e.g., 90) so it is evaluated before the deny rule.

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.