AZ-500 Secure networking Practice Question

A company has an Azure virtual network with a subnet that hosts a public web application. They want to allow inbound HTTPS traffic (port 443) only from the source IP range 203.0.113.0/24, and block all other inbound traffic. They associate a network security group (NSG) with the subnet. What is the minimum number of inbound security rules required in the NSG to achieve this?

⚠ Common exam trap

Many exam-takers think they need an explicit deny rule to block all other traffic, forgetting that NSGs have a built-in default deny-all rule that automatically handles this.

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

✓

NSGs include default inbound rules that already block all inbound traffic not explicitly allowed. By adding a single inbound rule to allow HTTPS (port 443) from the source IP range 203.0.113.0/24, all other inbound traffic is implicitly denied by the default deny-all rule (rule 65000). No explicit deny rule is needed, and no additional rules for Azure Load Balancer health probes are required unless the application is behind a load balancer, which is not specified in the scenario.

Answer analysis

Option-by-option breakdown

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

✗
0 (no additional rules needed because the default rules block all inbound traffic)
Why it's wrong here
The default rules in an NSG include AllowVNetInBound (priority 65000), AllowAzureLoadBalancerInBound (65001), and DenyAllInBound (65500). Because DenyAllInBound blocks all traffic from the internet that doesn't match an earlier allow rule, no HTTPS traffic from the specific IP range would ever reach the web server. You must create an explicit inbound allow rule for TCP 443 with a source IP range and a priority lower than 65500 (e.g., 100).
✓
1
Why this is correct
One carefully scoped inbound rule is sufficient: allow TCP 443 from the specific IP range to the subnet's destination port 443 at a priority like 100. Because NSG rules are evaluated in numeric priority order and DenyAllInBound (65500) is the final default rule, all other inbound traffic from the internet is automatically blocked without additional deny rules. This also avoids redundant rule overhead while preserving the default deny posture.
✗
2 (one allow rule for HTTPS and one deny rule for all other traffic)
Why it's wrong here
Adding an explicit deny-all-inbound rule is redundant because the built-in DenyAllInBound rule already matches and blocks every packet that no higher-priority allow rule accepts. If you put that explicit deny at a lower numeric priority (e.g., 200), it is evaluated early and simply repeats the action of the default rule; if you put it above your HTTPS allow, it would incorrectly block the very traffic you want to permit. The only truly necessary addition is the HTTPS allow rule.
✗
3 (one allow HTTPS, one allow for Azure Load Balancer health probes, and one deny all)
Why it's wrong here
The default AllowAzureLoadBalancerInBound rule (priority 65001) already permits Azure Load Balancer health probe traffic to reach VMs in the subnet, so an extra allow rule for health probes is unnecessary. Adding it, plus an explicit deny-all rule, compounds the error: health-probe allow is redundant, and the explicit deny duplicates DenyAllInBound. The effective result would be identical to option 1 (just the HTTPS allow rule), but with three rules instead of one, adding management complexity and clutter.

Visual reference

Go deeper

AZ-500 Secure networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question