AZ-104 Implement and Manage Virtual Networking Practice Question
An NSG rule allows TCP 8443 from ASG-Web to ASG-Api on the API subnet. The web VM NIC is already in ASG-Web, but the API VM was only placed in the subnet and not added to ASG-Api. Traffic still fails. What is the best fix?
⚠ Common exam trap
It's easy for candidates to assume subnet membership automatically applies ASG rules, but ASGs require explicit NIC association, and NSG rules with ASG destinations will not match VMs that are only in the subnet.
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 the API VM's NIC to ASG-Api so the NSG rule can match the destination NIC.
The NSG rule specifies ASG-Api as the destination, but NSGs evaluate traffic based on the NIC membership in an ASG, not the subnet. Since the API VM's NIC is not added to ASG-Api, the rule cannot match the destination, so traffic is dropped by default (implicit deny). Adding the NIC to ASG-Api allows the NSG rule to correctly identify the destination and permit TCP 8443 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.
- ✓
Add the API VM's NIC to ASG-Api so the NSG rule can match the destination NIC.
Why this is correct
Application security groups are assigned to NICs, not to subnets. If the destination NIC is not in ASG-Api, the rule that references ASG-Api never matches, even if the VM sits in the right subnet. Adding the API NIC to the correct ASG allows the NSG rule to evaluate as intended and is the cleanest fix for the blocked 8443 traffic.
- ✗
Add ASG-Api to the API subnet because ASGs are inherited from subnet membership.
Why it's wrong here
Application security groups are explicit NIC-level attributes, not subnet properties. You cannot associate an ASG to a subnet, and VMs do not inherit ASG membership from their subnet placement. Without the API NIC being added to ASG-Api, the destination address of the 8443 traffic will never match the rule, regardless of which subnet the API VM occupies.
When this WOULD be correct
If the question stated that ASGs are automatically applied to all resources in a subnet (e.g., a hypothetical scenario where ASG membership is inherited from subnet configuration), then adding ASG-Api to the subnet would be the correct fix.
- ✗
Lower the rule priority number on the web subnet to make source traffic more specific.
Why it's wrong here
NSG priority numbers determine the order of rule evaluation, not whether a rule's matching conditions are fulfilled. Lowering the priority (making the number smaller) on a rule cannot make the destination NIC magically belong to ASG-Api; if the destination membership check fails, the rule is skipped. The source condition is already matched correctly; the mismatched destination is why traffic is blocked.
When this WOULD be correct
In a scenario where multiple NSG rules apply to the same traffic and a lower-priority rule (higher number) is incorrectly blocking traffic, lowering the priority number (making it higher priority) of the correct rule would allow it to override the blocking rule.
- ✗
Create a user-defined route from AppSubnet to API subnet to bypass the NSG.
Why it's wrong here
A user-defined route only changes the next hop IP path by altering the effective route table; it does not alter or bypass NSG evaluation. NSGs are stateful filters applied at the NIC or subnet after routing, so the rule still requires the destination NIC to be in ASG-Api. Directing traffic through a UDR may also cause asymmetric routing without resolving the membership mismatch.
When this WOULD be correct
A question where traffic between subnets is failing due to incorrect routing (e.g., traffic is being sent to a network virtual appliance instead of directly to the destination subnet), and you need to override the default system route with a UDR to force traffic to the correct next hop.
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 the API VM's NIC to ASG-Api so the NSG rule can match the destination NIC.Correct answer▾
Why this is correct
Application security groups are assigned to NICs, not to subnets. If the destination NIC is not in ASG-Api, the rule that references ASG-Api never matches, even if the VM sits in the right subnet. Adding the API NIC to the correct ASG allows the NSG rule to evaluate as intended and is the cleanest fix for the blocked 8443 traffic.
✗Add ASG-Api to the API subnet because ASGs are inherited from subnet membership.Wrong answer — click to see why▾
Why this is wrong here
ASGs are not inherited from subnet membership; they must be explicitly assigned to NICs. Adding ASG-Api to the subnet does not associate the API VM's NIC with the ASG, so the NSG rule still cannot match the destination.
★ When this WOULD be the correct answer
If the question stated that ASGs are automatically applied to all resources in a subnet (e.g., a hypothetical scenario where ASG membership is inherited from subnet configuration), then adding ASG-Api to the subnet would be the correct fix.
Why candidates choose this
Candidates may confuse ASGs with NSGs, which are applied at the subnet level, and incorrectly assume that ASGs also propagate from subnet membership.
✗Lower the rule priority number on the web subnet to make source traffic more specific.Wrong answer — click to see why▾
Why this is wrong here
Lowering the rule priority number makes the rule more specific (higher priority), but the issue is that the destination ASG-Api has no members, so the rule cannot match any traffic. Priority does not fix the missing membership.
★ When this WOULD be the correct answer
In a scenario where multiple NSG rules apply to the same traffic and a lower-priority rule (higher number) is incorrectly blocking traffic, lowering the priority number (making it higher priority) of the correct rule would allow it to override the blocking rule.
Why candidates choose this
Candidates may confuse rule priority with rule effectiveness, thinking that making a rule more specific (higher priority) will fix connectivity issues, without realizing that the rule's conditions (like ASG membership) must be met first.
✗Create a user-defined route from AppSubnet to API subnet to bypass the NSG.Wrong answer — click to see why▾
Why this is wrong here
User-defined routes (UDRs) control traffic routing between subnets, not NSG rule evaluation. The issue is that the NSG rule cannot match the destination because the API VM's NIC is not in ASG-Api; a UDR does not fix NSG rule matching.
★ When this WOULD be the correct answer
A question where traffic between subnets is failing due to incorrect routing (e.g., traffic is being sent to a network virtual appliance instead of directly to the destination subnet), and you need to override the default system route with a UDR to force traffic to the correct next hop.
Why candidates choose this
Candidates may confuse NSG rule application with routing, thinking that a UDR can bypass NSG rules or that routing changes can fix application-level connectivity issues caused by NSG misconfigurations.
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
Related to this question
Learn chapter
Dynamic Membership Groups
Key term
NSG rule
An NSG rule is a set of security rules in Microsoft Azure that controls whether network traffic is allowed or denied to and from Azure resources.
Key term
TCP
TCP (Transmission Control Protocol) is a core internet protocol that ensures data is sent reliably and in order between devices over a network.
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 →
Same concept, more angles
1 more way this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An NSG outbound rule allows TCP 8443 traffic from ASG-Web to ASG-Api. The web VM NIC is in ASG-Web, but the API VM NICs were deployed into the correct subnet and never added to ASG-Api. The traffic still fails. What should the administrator do?
medium- A.Move the NSG to the web subnet so source membership is automatically detected.
- ✓ B.Add the API VM NICs to ASG-Api.
- C.Change the destination port to 443 because ASGs only work with common HTTPS traffic.
- D.Create a service endpoint for the spoke subnet so the NSG rule becomes effective.
Why B: The NSG rule references ASG-Api as the destination, but the API VM NICs were never added to that application security group. ASGs are logical groupings of VM NICs; a rule targeting an ASG only applies to NICs that are members of that ASG. Since the API NICs are not in ASG-Api, the rule does not match them, and traffic fails. Adding the API VM NICs to ASG-Api resolves the issue by making them valid destinations for the rule.
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.