A subnet has an NSG with these inbound rules: priority 200 DenyAllInbound and priority 300 AllowHTTPSFromInternet. A VM in the subnet is still unreachable on TCP 443 from the internet. What should you do to make HTTPS work while keeping the deny rule in place?

Create the same allow rule on the NIC-level NSG at priority 300 and leave the subnet NSG unchanged.

A higher-priority deny on the subnet NSG still blocks the traffic. Adding a NIC rule with a weaker priority does not override the subnet-level deny.

Change the deny rule to protocol Any and keep the same priority so Azure evaluates the allow rule first.

Changing the protocol does not affect evaluation order. The deny rule would still win because it has the lower priority number.

Add a route table entry for TCP 443 traffic so Azure sends it directly to the VM.

Route tables control next hop selection, not security filtering. A route does not bypass an NSG deny rule on the subnet.

What does this AZ-104 question test?

CIDR notation defines the prefix length.

What is the correct answer to this question?

The correct answer is: Move the allow HTTPS rule to a lower priority number such as 100 so it is evaluated before the deny rule. — NSG processing is based on priority, where the lowest numerical value is evaluated first. In this case, the deny-all rule at priority 200 matches before the allow-HTTPS rule at 300, so inbound 443 traffic is blocked. The correct fix is to give the allow rule a lower number than the deny rule, such as 100, so HTTPS is permitted while the broader deny remains in place. Why others are wrong: A NIC-level allow rule cannot override a subnet-level deny that is evaluated first. Changing protocol settings does not change rule precedence. A route table does not provide access control, so it cannot open port 443. The problem is rule order, not routing or protocol syntax.

What should I do if I get this AZ-104 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.