Troubleshooting Lab: Associate an ASG to a network interface
Diagnostic Scenarios
Scenario 1 — Root Cause
A network administrator reports that a virtual machine named vm-app-prod-01 stopped receiving traffic on port 8080 after an environment reorganization performed the previous week. The VM is running, the agent is responding to internal pings, and the Network Security Group associated with the subnet contains an explicit inbound rule allowing TCP 8080 from any source with priority 300.
During investigation, the administrator confirms that the VM's NIC was removed from the asg-app-tier ASG and added to the asg-web-tier ASG during the reorganization. The asg-web-tier ASG only has rules that allow traffic on ports 80 and 443. There is no NSG directly associated with the VM's NIC.
Additional information: the VM was resized from Standard_B2s to Standard_D2s_v3 during the same period and the diagnostic storage account was temporarily detached.
What is the root cause of the traffic blocking on port 8080?
A) The VM resizing caused automatic dissociation of the subnet NSG, removing the permission rules.
B) The NIC is associated with the asg-web-tier ASG, whose NSG rules don't cover port 8080, and the subnet rule doesn't reference the correct ASG for this traffic.
C) The diagnostic storage account detachment interrupted NSG log flow, making traffic appear blocked without actually being blocked.
D) The inbound rule on the subnet with priority 300 is being overridden by an implicit denial rule in the asg-web-tier ASG with lower priority.
Scenario 2 — Action Decision
The security team identified that lateral traffic between database tier VMs and application tier VMs is occurring on unauthorized ports. The cause was confirmed: the database VMs' NICs were associated with both the asg-db-tier ASG and the asg-app-tier ASG by mistake during an automated provisioning script.
The environment is in active production. The maintenance window starts in 4 hours. NSG rules that use asg-app-tier as source or destination are being audited, but the audit has not yet been completed. Modifying NSG rules outside the window requires change committee approval.
What is the correct action to take now, before the maintenance window?
A) Immediately remove the database VMs' NICs from the asg-app-tier ASG via Azure Portal, without waiting for the window.
B) Wait for the NSG rules audit completion and, within the maintenance window, remove the NICs from the incorrect ASG after validating the impact.
C) Create a temporary NSG with explicit denial rules and associate it directly to the database VMs' NICs until the maintenance window.
D) Immediately delete the asg-app-tier ASG to eliminate the risk vector, recreating it during the window with the correct associations.
Scenario 3 — Root Cause
A VM named vm-worker-03 is part of a worker set that processes internal queues. All VMs in the set were provisioned with the same template and should have identical network behavior. The other VMs in the set process normally, but vm-worker-03 cannot initiate outbound connections to the internal endpoint 10.10.5.20:5432.
The administrator checks the NSG associated with the subnet and finds the following outbound rule:
Name: Allow-DB-Outbound
Direction: Outbound
Priority: 200
Protocol: TCP
Destination port: 5432
Destination: asg-db-tier
Source: asg-worker-tier
Action: Allow
The administrator also confirms that 10.10.5.20 is the NIC of a database VM correctly associated with asg-db-tier. The NSG of the worker VMs subnet has no explicit denial rules for port 5432. The vm-worker-03 VM was manually provisioned after the others, using the same template, and is in the same Resource Group and subnet.
Additional information: the VM underwent an operating system update two days ago and its data disk was expanded yesterday.
What is the root cause of vm-worker-03's connectivity problem?
A) The operating system update reset local firewall settings, blocking outbound traffic on port 5432.
B) The data disk expansion caused a reboot that dissociated the NIC from the subnet NSG.
C) The vm-worker-03 NIC was not associated with the asg-worker-tier ASG, therefore the outbound rule that uses this ASG as source doesn't apply to it.
D) The Allow-DB-Outbound rule with priority 200 is being overridden by a default outbound denial rule with priority 100 that blocks traffic to private addresses.
Scenario 4 — Diagnostic Sequence
A production VM stopped receiving traffic on port 443 after a network configuration change. The administrator suspects the problem is related to ASG association on the VM's NIC, but is not certain.
The available investigation steps are:
- Verify if the VM's NIC is associated with the ASG referenced as destination in NSG rules that allow port 443
- Use the IP flow verify tool in Network Watcher to confirm if traffic on port 443 is being blocked and by which rule
- Review recent change history via Azure Activity Log to identify which operation was performed on the NIC or ASG
- Confirm that the VM is running and that the NIC is in connected (attached) state to the VM
- Verify if the correct NSG is associated with the subnet or NIC and if it contains rules that reference the ASG as destination for port 443
What is the correct investigation sequence?
A) 3 -> 1 -> 5 -> 2 -> 4
B) 4 -> 2 -> 5 -> 1 -> 3
C) 2 -> 3 -> 4 -> 5 -> 1
D) 4 -> 3 -> 5 -> 1 -> 2
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The root cause is the NIC's ASG change. When the NIC left asg-app-tier and joined asg-web-tier, it began being evaluated by NSG rules that reference this new ASG. The subnet NSG has a rule that allows port 8080, but this rule doesn't reference asg-web-tier as destination, but rather asg-app-tier (implicitly, given the reorganization context). Since there's no NSG on the NIC and the subnet rule is generic for any source, the flow depends on which ASG is associated with the NIC for ASG-based rules to apply correctly.
The irrelevant information is the diagnostic storage account detachment and VM resizing. Neither of these operations affects ASG association or NSG rules. Resizing may cause brief unavailability, but doesn't change network configurations.
The most dangerous distractor is alternative A, as it attributes the problem to VM resizing. This hypothesis would lead the administrator to unnecessarily recreate the VM without correcting the ASG association, keeping the problem intact.
Answer Key — Scenario 2
Answer: B
The scenario presents two critical constraints: the audit has not yet been completed and NSG changes outside the window require approval. Removing the incorrect ASG from NICs (alternative A) would be the correct technical action, but alternative B is the only one that simultaneously respects the environment constraints: waiting for the audit to understand the complete impact and executing the correction within the approved window.
Alternative A ignores the audit dependency. Removing the ASG without knowing which NSG rules reference it could break legitimate connectivity of other VMs that depend on the current association.
Alternative C creates a temporary NSG on the NIC, which would technically work to block unwanted traffic, but is also an NSG modification that requires committee approval, making it equally invalid outside the window.
Alternative D is the most dangerous distractor: deleting the ASG would immediately affect all NSG rules that reference it throughout the environment, potentially causing widespread disruption of legitimate traffic in production.
Answer Key — Scenario 3
Answer: C
The Allow-DB-Outbound rule explicitly uses asg-worker-tier as source. This means it applies only to NICs that are associated with this ASG. Since vm-worker-03 was manually provisioned after the others, it's highly likely that the association with asg-worker-tier was omitted during manual provisioning. Without this association, the VM's NIC is not recognized as a valid source by the rule, and outbound traffic to 5432 is not allowed.
The information about operating system update and disk expansion is irrelevant and was deliberately included to divert focus. Neither of these operations removes a NIC's association with an ASG.
Alternative A represents the classic error of confusing the OS layer with Azure's network layer. The local firewall wouldn't be consistent with the behavior of other VMs, which were updated by the same template.
Alternative D is technically incorrect: Azure's default outbound rules allow traffic to VNets and internet, and the default denial rule has priority 65500, not 100.
Answer Key — Scenario 4
Answer: B
The correct sequence is: 4 -> 2 -> 5 -> 1 -> 3
- Step 4 first: confirming that the VM is running and the NIC is connected is the basic prerequisite. Any network diagnosis assumes the resource is operational.
- Step 2 next: IP flow verify delivers the objective answer about blocking and identifies which rule is acting. This delimits the scope before investigating configurations.
- Step 5 after: with the problematic rule identified, it's possible to verify if the NSG is correctly associated and if the rule in question references an ASG.
- Step 1 then: knowing which rule and which ASG are involved, verify if the VM's NIC is actually associated with the expected ASG.
- Step 3 last: the Activity Log confirms what changed and when, being useful for documentation and preventing recurrence, not for initial diagnosis.
Alternative A starts with the Activity Log, which is a common error: the log describes what happened, but doesn't confirm if traffic is actually blocked or which rule is responsible. Starting with it delays diagnosis.
Alternative C starts with IP flow verify without first confirming the VM is active, which can generate inconclusive or misleading results if the VM is in a failed state.
Troubleshooting Tree: Associate an ASG to a network interface
Color legend:
- Dark blue: initial symptom, investigation entry point
- Blue: objective diagnostic question with yes or no answer
- Red: identified cause, confirmed problem origin
- Green: recommended action or resolution to execute
- Orange: validation or intermediate verification before proceeding
How to navigate the tree when facing a real problem: start with the root node, which represents the observed symptom. At each blue node, answer the question based on what is directly verifiable in the environment, whether via Azure Portal, CLI, or Network Watcher. Follow the branch corresponding to your answer. When reaching a red node, the cause is identified. When reaching an orange node, execute the validation before proceeding. When reaching a green node, execute the described action and return to the validation node to confirm resolution.