Courseiva
Implement and Manage Virtual NetworkinghardMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Virtual Networking Practice Question

A backend VM belongs to AppASG and listens on TCP 8443. The subnet NSG has a deny rule at priority 200 that blocks TCP 8443 from VirtualNetwork to any destination. The backend VM's NIC NSG has an allow rule at priority 100 for TCP 8443 from WebASG to AppASG. Web VMs in WebASG still cannot connect. What should you change to allow only the web tier while keeping other virtual network traffic blocked?

⚠ Common exam trap

It's easy for candidates to assume NIC NSG rules can override subnet NSG rules due to higher priority, but in Azure, subnet NSG rules are evaluated before NIC NSG rules for inbound traffic, so a subnet deny will always block traffic regardless of NIC allow rules.

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

Add an allow rule in the subnet NSG at priority 150 for TCP 8443 from WebASG to AppASG.

In Azure, network security group (NSG) rules are evaluated in priority order, and subnet NSG rules are evaluated before NIC NSG rules for inbound traffic. The subnet NSG has a deny rule at priority 200 that blocks TCP 8443 from VirtualNetwork to any destination, which overrides the NIC NSG allow rule because the subnet deny is evaluated first. To allow traffic from WebASG to AppASG while still blocking other virtual network traffic, you must add an allow rule in the subnet NSG at a higher priority (e.g., 150) than the deny rule, explicitly permitting TCP 8443 from WebASG to AppASG.

Answer analysis

Option-by-option breakdown

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

  • Move the NIC NSG allow rule to priority 50.

    Why it's wrong here

    Moving the NIC NSG allow rule to priority 50 does not resolve the conflict because, for inbound traffic, the subnet NSG is processed before the NIC NSG, regardless of the priority numbers. The subnet-level deny rule is still evaluated first and will block TCP 8443 before the NIC-level allow rule can even be considered. Priority numbers only order rules within the same NSG; they cannot reorder the evaluation sequence across different NSGs.

    When this WOULD be correct

    In a scenario where the subnet NSG has an allow rule for the traffic but the NIC NSG has a deny rule at a higher priority, moving the NIC allow rule to a lower priority number (higher priority) would allow the traffic. For example, if the subnet NSG allows TCP 8443 from WebASG to AppASG and the NIC NSG has a deny rule at priority 200, moving an allow rule to priority 100 would override the deny.

  • Add an allow rule in the subnet NSG at priority 150 for TCP 8443 from WebASG to AppASG.

    Why this is correct

    Adding an allow rule in the subnet NSG at priority 150 for TCP 8443 from WebASG to AppASG works because inbound traffic is first evaluated against the subnet NSG, and a lower priority number (150) is processed before the existing subnet deny rule. This places a more specific allow ahead of the deny, so the connection is permitted. Also, by scoping both source and destination to application security groups, the rule grants only the Web tier access to the backend AppASG on the required port, rather than opening the whole subnet.

  • Replace the subnet deny rule with a rule for the AzureLoadBalancer service tag.

    Why it's wrong here

    The AzureLoadBalancer service tag only matches the source addresses used by Azure Load Balancer health probes, not the Web tier VMs in WebASG. Replacing the subnet deny rule with an allow rule for this tag would still block TCP 8443 from WebASG to AppASG, and it would also remove the existing deny, leaving the subnet less secure by allowing probe traffic to reach all VMs. This does not address the actual application traffic or the rule priority conflict.

    When this WOULD be correct

    This option would be correct in a scenario where the backend VM is behind an Azure Load Balancer and the issue is that health probes from the load balancer are being blocked by a subnet NSG rule. In that case, adding an allow rule for the AzureLoadBalancer service tag at a higher priority would resolve the health probe failure while maintaining other restrictions.

  • Remove the backend VM from AppASG and allow traffic by subnet only.

    Why it's wrong here

    Removing the backend VM from AppASG and allowing traffic by subnet only fails to address the existing subnet deny rule, which still blocks TCP 8443 at its priority until a new allow rule with a lower priority number is added. Even if you then add a broad subnet-to-subnet allow rule, you lose the precise source and destination scoping that application security groups provide, forcing you to manage individual IP addresses or CIDR ranges. This reduces manageability and security, and the original priority conflict remains unsolved.

    When this WOULD be correct

    This option would be correct in a scenario where the backend VM must be accessible from any VM in the same subnet (e.g., for management or backup purposes), and the use of ASGs is not required or is causing complexity. The question would specify that subnet-level access is acceptable and that ASG-based filtering is unnecessary.

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.

Add an allow rule in the subnet NSG at priority 150 for TCP 8443 from WebASG to AppASG.Correct answer

Why this is correct

Adding an allow rule in the subnet NSG at priority 150 for TCP 8443 from WebASG to AppASG works because inbound traffic is first evaluated against the subnet NSG, and a lower priority number (150) is processed before the existing subnet deny rule. This places a more specific allow ahead of the deny, so the connection is permitted. Also, by scoping both source and destination to application security groups, the rule grants only the Web tier access to the backend AppASG on the required port, rather than opening the whole subnet.

Move the NIC NSG allow rule to priority 50.Wrong answer — click to see why

Why this is wrong here

The NIC NSG rule at priority 100 already allows traffic from WebASG to AppASG on TCP 8443, but the subnet NSG deny rule at priority 200 blocks it. Since subnet NSG rules are evaluated before NIC NSG rules, traffic is denied regardless of NIC rule priority. Moving the NIC rule to a higher priority does not override the subnet deny rule.

★ When this WOULD be the correct answer

In a scenario where the subnet NSG has an allow rule for the traffic but the NIC NSG has a deny rule at a higher priority, moving the NIC allow rule to a lower priority number (higher priority) would allow the traffic. For example, if the subnet NSG allows TCP 8443 from WebASG to AppASG and the NIC NSG has a deny rule at priority 200, moving an allow rule to priority 100 would override the deny.

Why candidates choose this

Candidates often believe that increasing the priority (lowering the number) of a rule makes it more effective, but they overlook that subnet NSG rules are evaluated before NIC NSG rules, so a subnet deny cannot be bypassed by a NIC allow regardless of priority.

Replace the subnet deny rule with a rule for the AzureLoadBalancer service tag.Wrong answer — click to see why

Why this is wrong here

The subnet NSG deny rule blocks TCP 8443 from VirtualNetwork to any destination. Replacing it with a rule for AzureLoadBalancer service tag would allow health probe traffic from the load balancer, but it would not allow traffic from WebASG to AppASG because the deny rule is removed, potentially allowing all virtual network traffic, which violates the requirement to keep other traffic blocked.

★ When this WOULD be the correct answer

This option would be correct in a scenario where the backend VM is behind an Azure Load Balancer and the issue is that health probes from the load balancer are being blocked by a subnet NSG rule. In that case, adding an allow rule for the AzureLoadBalancer service tag at a higher priority would resolve the health probe failure while maintaining other restrictions.

Why candidates choose this

Candidates may think that since the load balancer is involved (implied by the scenario), the AzureLoadBalancer service tag is the key to allowing traffic, but they overlook that the specific requirement is to allow only web tier traffic while blocking other virtual network traffic, which the service tag rule does not address.

Remove the backend VM from AppASG and allow traffic by subnet only.Wrong answer — click to see why

Why this is wrong here

Removing the backend VM from AppASG would break the application security group association, preventing the NIC NSG rule from matching traffic from WebASG. Additionally, allowing traffic by subnet only would permit all VMs in the subnet, violating the requirement to allow only the web tier.

★ When this WOULD be the correct answer

This option would be correct in a scenario where the backend VM must be accessible from any VM in the same subnet (e.g., for management or backup purposes), and the use of ASGs is not required or is causing complexity. The question would specify that subnet-level access is acceptable and that ASG-based filtering is unnecessary.

Why candidates choose this

Candidates may think that removing the ASG simplifies the configuration and that subnet-level rules are easier to manage, overlooking the need for granular, tier-specific access control.

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

This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.