Implement and Manage Virtual Networking →hardMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Virtual Networking Practice Question

A VM in AppSubnet must reach a database VM in DbSubnet on TCP 1433. AppSubnet's NSG has an outbound deny rule for TCP 1433 to Any at priority 200. DbSubnet's NSG has an inbound allow rule for TCP 1433 from ASG-App to ASG-Db at priority 300. Both NICs are in the correct application security groups. Connectivity tests fail. What should the administrator change?

⚠ Common exam trap

The trap here is that candidates often focus on the inbound rule on the destination subnet, overlooking the outbound deny rule on the source subnet that blocks traffic before it can even reach the destination NSG.

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

✓

Create an outbound allow rule on AppSubnet with a lower priority number than 200 for TCP 1433 to ASG-Db.

The AppSubnet's NSG has an outbound deny rule for TCP 1433 to Any at priority 200, which blocks all outbound traffic on that port regardless of destination. To allow the VM in AppSubnet to reach the database VM in DbSubnet, an outbound allow rule must be created with a lower priority number (e.g., 100) so it is evaluated before the deny rule. This rule should specify the destination as ASG-Db (the application security group of the database VM) to precisely permit the required 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.

✗
Remove the inbound allow rule from DbSubnet so the default rules can take over.
Why it's wrong here
Removing the inbound allow rule on DbSubnet does not influence the outbound filtering performed on AppSubnet. Even though the default AllowVNetInBound rule would broadly permit traffic from the virtual network, that default rule is evaluated only on the destination side, after the packet has already been blocked at the source. You would lose the explicit TCP 1433 authorization and undermine the least-privilege model without resolving the actual failure point—the outbound deny at priority 200.
When this WOULD be correct
This option would be correct in a scenario where the DbSubnet NSG has a high-priority inbound deny rule for TCP 1433 that is blocking traffic, and the default rules would allow the traffic if the explicit deny is removed. For example, if DbSubnet had an inbound deny rule at priority 200 for TCP 1433 from Any, removing it would let the default allow rule (if any) take effect.
✗
Move the inbound allow rule on DbSubnet to priority 100 so it is evaluated sooner.
Why it's wrong here
Lowering the priority number of the DbSubnet inbound rule from 200 to 100 increases precedence only within the destination NSG's inbound rule list. The TCP packet still must first traverse the AppSubnet's outbound NSG, where the deny rule at priority 200 wins over any lower-priority allows; as a result, the packet never reaches the DbSubnet. Priority adjustments are only meaningful within the same NSG and direction, so changing the destination rule cannot override a block on the source side.
When this WOULD be correct
This option would be correct if the outbound deny rule on AppSubnet did not exist or was not blocking traffic, and the inbound allow rule on DbSubnet was being overridden by a higher-priority inbound deny rule (e.g., priority 200). In that case, moving the allow rule to a lower priority number (e.g., 100) would ensure it is evaluated before the deny rule.
✓
Create an outbound allow rule on AppSubnet with a lower priority number than 200 for TCP 1433 to ASG-Db.
Why this is correct
NSG evaluation is priority-based and stateful, but an outbound deny still blocks the initial connection. A higher-priority outbound allow on the source subnet must match before the deny rule. Because the destination rule already allows the traffic, adding or moving the source-side allow above priority 200 resolves the failure without changing the application subnets or ASG design.
✗
Assign the database VM NIC to ASG-App so the destination rule matches a broader group.
Why it's wrong here
Assigning the database VM NIC to ASG-App would place it in the same logical source group as the app VMs, but that does not affect the outbound path from AppSubnet. The connection is dropped by the outbound deny rule on the AppSubnet NSG before the DbSubnet NSG inbound rule can match the now-broader ASG membership. Altering ASG assignments also muddles the design intent and can make the database VM match its own inbound rule as both source and destination, but it still cannot circumvent the source-side deny.
When this WOULD be correct
This option would be correct if the inbound rule on DbSubnet's NSG specified ASG-App as the destination instead of ASG-Db, and the database VM was not in ASG-Db. Assigning the database VM NIC to ASG-App would then make the rule apply, allowing 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.

✓Create an outbound allow rule on AppSubnet with a lower priority number than 200 for TCP 1433 to ASG-Db.Correct answer▾

Why this is correct

NSG evaluation is priority-based and stateful, but an outbound deny still blocks the initial connection. A higher-priority outbound allow on the source subnet must match before the deny rule. Because the destination rule already allows the traffic, adding or moving the source-side allow above priority 200 resolves the failure without changing the application subnets or ASG design.

✗Remove the inbound allow rule from DbSubnet so the default rules can take over.Wrong answer — click to see why▾

Why this is wrong here

Removing the inbound allow rule would not fix the connectivity issue because the outbound deny rule on AppSubnet is blocking the traffic. Without an explicit outbound allow, the default outbound deny would still block traffic even if the inbound rule is removed.

★ When this WOULD be the correct answer

This option would be correct in a scenario where the DbSubnet NSG has a high-priority inbound deny rule for TCP 1433 that is blocking traffic, and the default rules would allow the traffic if the explicit deny is removed. For example, if DbSubnet had an inbound deny rule at priority 200 for TCP 1433 from Any, removing it would let the default allow rule (if any) take effect.

Why candidates choose this

Candidates may think that removing the inbound rule allows default rules to permit traffic, but they overlook that the outbound deny on AppSubnet is the actual blocker. They might also assume that default rules are permissive, but in this case, the outbound default is deny.

✗Move the inbound allow rule on DbSubnet to priority 100 so it is evaluated sooner.Wrong answer — click to see why▾

Why this is wrong here

The inbound allow rule on DbSubnet is already at priority 300, which is evaluated before the default deny rule (priority 65000). The issue is the outbound deny rule on AppSubnet at priority 200, which blocks traffic before it reaches DbSubnet. Changing the priority of the inbound rule does not address the outbound block.

★ When this WOULD be the correct answer

This option would be correct if the outbound deny rule on AppSubnet did not exist or was not blocking traffic, and the inbound allow rule on DbSubnet was being overridden by a higher-priority inbound deny rule (e.g., priority 200). In that case, moving the allow rule to a lower priority number (e.g., 100) would ensure it is evaluated before the deny rule.

Why candidates choose this

Candidates may think that increasing the priority of the inbound allow rule (lower number) will make it more effective, but they overlook that the traffic is blocked by the outbound NSG on the source subnet before it even reaches the destination subnet's NSG.

✗Assign the database VM NIC to ASG-App so the destination rule matches a broader group.Wrong answer — click to see why▾

Why this is wrong here

Assigning the database VM NIC to ASG-App would not help because the inbound rule on DbSubnet's NSG already allows traffic from ASG-App to ASG-Db. The issue is the outbound deny rule on AppSubnet blocking traffic; changing the destination ASG does not address the outbound block.

★ When this WOULD be the correct answer

This option would be correct if the inbound rule on DbSubnet's NSG specified ASG-App as the destination instead of ASG-Db, and the database VM was not in ASG-Db. Assigning the database VM NIC to ASG-App would then make the rule apply, allowing traffic.

Why candidates choose this

Candidates may think that matching the destination ASG to the VM's group will make the rule apply, but they overlook that the rule already correctly targets ASG-Db and the VM is already in that group. The real problem is the outbound deny rule.

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

Go deeper

AZ-104 Implement and Manage Virtual Networking Practice Question

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question