Implement and Manage Virtual Networking →mediumMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Virtual Networking Practice Question

A backend VM must accept TCP 8443 only from the web tier. The subnet NSG already has a deny-all inbound rule at priority 200. The administrator adds an allow rule for the web tier at priority 300, but the connection still fails. What should be changed?

⚠ Common exam trap

Watch out — candidates often assume higher priority numbers (like 300) override lower numbers (like 200), but in Azure NSGs, lower priority numbers are evaluated first, so a deny rule with a lower number will block traffic before a higher-numbered allow rule is ever checked.

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

✓

Change the allow rule to a lower priority number than 200.

Azure Network Security Groups (NSGs) process rules in priority order, with lower numbers evaluated first. The existing deny-all inbound rule at priority 200 is evaluated before the new allow rule at priority 300, so the deny rule blocks the traffic before the allow rule can be considered. To permit TCP 8443 from the web tier, the allow rule must have a priority number lower than 200 (e.g., 100) so it is evaluated first and allows the traffic.

Answer analysis

Option-by-option breakdown

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

✓
Change the allow rule to a lower priority number than 200.
Why this is correct
NSG rules are evaluated in ascending priority order, and the rule with the lowest priority number (highest precedence) is processed first. If the deny-all rule has priority 200 and the allow rule for TCP 8443 has a higher number like 300, the deny rule matches first and blocks the traffic. To permit the web tier, the allow rule must be assigned a priority lower than 200, such as 100, so it is evaluated before the deny-all rule.
✗
Change the allow rule protocol from TCP to Any.
Why it's wrong here
The issue is not the protocol match but the order of rule evaluation. A deny-all rule with priority 200 will match any protocol, including TCP, before a later allow rule is ever examined. Changing the allow rule's protocol from TCP to Any still leaves it at a lower priority than the deny rule, so the traffic remains blocked. Understanding that priority, not protocol specificity, determines which rule applies is essential to troubleshooting NSG behavior.
✗
Move the VM to a different subnet so the rule can apply.
Why it's wrong here
Simply relocating the VM to another subnet does not alter how NSG rules are prioritized or evaluated. The same NSG, if still attached, will apply the same deny-all rule before the allow rule regardless of the subnet's address space. Unless the new subnet has a different NSG without the conflicting deny-all rule, moving the VM has no effect on the TCP 8443 rejection.
✗
Add a route table entry for TCP 8443 to bypass the NSG.
Why it's wrong here
Route tables govern the path that packets take to reach their destination (next-hop selection), not whether the Azure firewall (NSG) permits them. An NSG deny rule is evaluated independently of routing and will drop the packet even if a route exists for TCP 8443. You cannot bypass an NSG deny decision with a user-defined route, as filtering occurs before or during packet delivery to the VM.

Visual reference

Go deeper

AZ-104 Implement and Manage Virtual Networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question