Courseiva
Implement and Manage Virtual NetworkingmediumMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Virtual Networking Practice Question

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?

⚠ Common exam trap

Watch out — candidates often assume ASGs automatically include all VMs in the same subnet, but ASGs require explicit NIC membership and do not inherit subnet scope.

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 NICs to ASG-Api.

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.

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 NSG to the web subnet so source membership is automatically detected.

    Why it's wrong here

    Moving the NSG to the web subnet will not fix the rule because NSG association determines where the network security policy is applied (subnet or NIC), but it does not change which NICs are members of the destination ASG. The source ASG membership for the web VMs is already known, yet the destination VMs still must be added to ASG-Api to be matched. Even if the NSG is associated to the web subnet, the destination scope of the rule remains defined by ASG-Api, and an empty ASG still means no traffic is permitted.

    When this WOULD be correct

    This would be correct if the NSG was applied to the web subnet instead of the web VM NIC, and the source ASG-Web membership was not being detected because the NSG was at the NIC level. Moving the NSG to the subnet allows it to evaluate traffic from all VMs in the subnet, including those in ASG-Web, without requiring NIC-level application.

  • Add the API VM NICs to ASG-Api.

    Why this is correct

    Adding the API VM NICs to ASG-Api is the correct fix because the NSG rule's destination object is that ASG, and Azure matches traffic by checking which NICs are currently members of that ASG. The rule only takes effect for traffic whose destination IP is on a NIC that belongs to ASG-Api; without those memberships, the rule's condition cannot be satisfied. Note that ASG membership is assigned at the NIC layer, so the VM's NIC must be explicitly associated with the ASG, independent of the NSG's association to the subnet or VM.

  • Change the destination port to 443 because ASGs only work with common HTTPS traffic.

    Why it's wrong here

    Changing the destination port to 443 is incorrect because application security groups are port-agnostic; they are simply a logical grouping of NICs that NSG rules can use as source or destination. The rule can freely allow TCP 8443 or any other port; ASGs do not restrict which ports are valid. The real problem is that the API VMs' NICs are not in ASG-Api, so the destination set is empty, and altering the port does nothing to populate that set or change how the rule is evaluated.

    When this WOULD be correct

    This would be correct if the question stated that the NSG rule was configured for HTTPS (TCP 443) but the application uses a custom port like 8443, and the administrator mistakenly thought ASGs only support common ports. In that scenario, updating the rule to the correct port would fix the issue.

  • Create a service endpoint for the spoke subnet so the NSG rule becomes effective.

    Why it's wrong here

    Creating a service endpoint for the spoke subnet is unrelated because service endpoints secure outbound traffic to Azure PaaS services (such as Storage, SQL, or Key Vault) by forcing that traffic through the Azure backbone, not by altering NSG rule processing or ASG membership. The rule at issue is for VM-to-VM TCP traffic between two application security groups; service endpoints do not enable or activate ASG-based rules. The only way to make this rule effective is to ensure the destination NICs are explicitly associated with ASG-Api.

    When this WOULD be correct

    A question where traffic to an Azure service (e.g., Azure SQL or Storage) from a subnet is failing, and enabling a service endpoint on that subnet allows the NSG rule to match traffic to the service's public IPs.

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 NICs to ASG-Api.Correct answer

Why this is correct

Adding the API VM NICs to ASG-Api is the correct fix because the NSG rule's destination object is that ASG, and Azure matches traffic by checking which NICs are currently members of that ASG. The rule only takes effect for traffic whose destination IP is on a NIC that belongs to ASG-Api; without those memberships, the rule's condition cannot be satisfied. Note that ASG membership is assigned at the NIC layer, so the VM's NIC must be explicitly associated with the ASG, independent of the NSG's association to the subnet or VM.

Move the NSG to the web subnet so source membership is automatically detected.Wrong answer — click to see why

Why this is wrong here

Moving the NSG to the web subnet does not resolve the issue because the API VM NICs are not in ASG-Api, so the destination ASG membership is not recognized. The NSG rule requires the destination to be ASG-Api, but the API VMs are not members.

★ When this WOULD be the correct answer

This would be correct if the NSG was applied to the web subnet instead of the web VM NIC, and the source ASG-Web membership was not being detected because the NSG was at the NIC level. Moving the NSG to the subnet allows it to evaluate traffic from all VMs in the subnet, including those in ASG-Web, without requiring NIC-level application.

Why candidates choose this

Candidates may think that moving the NSG to the subnet will automatically include all VMs in the subnet in the ASG, but ASGs require explicit membership assignment; subnet-level NSG does not automatically add VMs to an ASG.

Change the destination port to 443 because ASGs only work with common HTTPS traffic.Wrong answer — click to see why

Why this is wrong here

ASGs (Application Security Groups) have no port restrictions; they work with any TCP/UDP port. Changing the port to 443 is unnecessary and does not address the root cause—the API VM NICs are not in ASG-Api.

★ When this WOULD be the correct answer

This would be correct if the question stated that the NSG rule was configured for HTTPS (TCP 443) but the application uses a custom port like 8443, and the administrator mistakenly thought ASGs only support common ports. In that scenario, updating the rule to the correct port would fix the issue.

Why candidates choose this

Candidates may confuse ASG behavior with common security practices where HTTPS (443) is often used, or they might think ASGs have built-in port limitations, leading them to assume the port must be changed.

Create a service endpoint for the spoke subnet so the NSG rule becomes effective.Wrong answer — click to see why

Why this is wrong here

Service endpoints extend VNet identity to Azure service resources, not to NSG rules. They do not affect NSG destination matching; the NSG rule still requires the destination ASG to contain the target NICs.

★ When this WOULD be the correct answer

A question where traffic to an Azure service (e.g., Azure SQL or Storage) from a subnet is failing, and enabling a service endpoint on that subnet allows the NSG rule to match traffic to the service's public IPs.

Why candidates choose this

Candidates confuse service endpoints with a general network connectivity feature, thinking they can magically make NSG rules work across subnets without proper ASG membership.

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

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

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.