Skip to main content

Troubleshooting Lab: Associate an NSG to a Resource

Diagnostic Scenarios​

Scenario 1 — Root Cause​

The operations team reports that a VM named vm-web-prod stopped responding to HTTP requests on port 80, but remains accessible via SSH on port 22. The VM is running, the web service is active in the operating system, and application logs show no errors. The VM is in the snet-frontend subnet, which belongs to the vnet-prod VNet in the eastus2 region.

During investigation, an analyst observed that the VM's public IP address was updated yesterday due to a reallocation. Additionally, the VM has a single NIC named nic-web-prod.

The administrator runs the following command and gets this output:

az network nic show \
  --name nic-web-prod \
  --resource-group rg-prod \
  --query "networkSecurityGroup"
null

Then verifies the subnet NSG:

az network vnet subnet show \
  --name snet-frontend \
  --vnet-name vnet-prod \
  --resource-group rg-prod \
  --query "networkSecurityGroup"
{
  "id": "/subscriptions/.../networkSecurityGroups/nsg-frontend"
}

The nsg-frontend rules are:

Inbound Rules:
Priority 100 | TCP | Port 22 | Allow
Priority 200 | TCP | Port 443 | Allow
Priority 65500 | Any | Any | Deny (DenyAllInBound)

What is the root cause of the port 80 access failure?

A) The public IP address was reallocated and DNS has not yet propagated the update, preventing external requests from reaching the VM.

B) The NSG associated with the subnet does not have an inbound rule allowing traffic on port 80, and no NSG is associated with the NIC.

C) The nic-web-prod NIC is not associated with any NSG, so all inbound traffic is being blocked by default.

D) The priority 65500 rule in nsg-frontend is specifically blocking port 80, as it takes precedence over implicit rules.

Scenario 2 — Action Decision​

The cause of the following problem has already been identified by the team: an NSG named nsg-api was accidentally associated with the snet-shared subnet, which hosts both the API layer and a critical internal monitoring service. The nsg-api has an inbound rule that blocks all traffic on port 9090, used exclusively by the monitoring agent. The environment is in production with an active SLA, and any service interruption must be avoided. The team has Contributor permission on the resource group but does not have access to the tenant's Policy resource.

The manager requests that the problem be resolved without removing the nsg-api from the subnet, as it also protects the APIs with blocking rules that took weeks to be audited and approved.

What is the correct action to take at this time?

A) Remove the nsg-api from the subnet, apply a new NSG only to the API VMs' NICs, and recreate all audited rules in the new NSG.

B) Add a new inbound rule in the nsg-api allowing traffic on port 9090 with higher priority than any existing blocking rule.

C) Create a new NSG exclusive for the monitoring agent, disassociate the nsg-api from the subnet and associate both NSGs simultaneously to the subnet.

D) Associate a second NSG to the monitoring agent VM's NIC, with an Allow rule on port 9090 with higher priority than the nsg-api rules.

Scenario 3 — Root Cause​

A VM named vm-db-01 is in the snet-data subnet and has two NICs: nic-primary (connected to snet-data) and nic-mgmt (connected to the snet-mgmt subnet). The DBA team reports that database connections on port 1433 are failing from VMs in snet-app, but work normally when tested from snet-mgmt.

The administrator collects the following information:

NSG associated with snet-data: nsg-data
NSG associated with snet-app: nsg-app
NSG associated with nic-primary: none
NSG associated with nic-mgmt: nsg-mgmt

nsg-data inbound rules:

Priority 100 | TCP | Port 1433 | Source: VirtualNetwork | Allow
Priority 200 | TCP | Port 22   | Source: 10.2.0.0/24   | Allow
Priority 65500 | Any | Any | Deny

nsg-app outbound rules:

Priority 100 | TCP | Port 1433 | Destination: 10.3.0.0/24 | Allow
Priority 65500 | Any | Any | Deny

The VirtualNetwork tag encompasses addresses from all VNets connected by peering. The snet-app is in a different VNet from snet-data, and the two VNets are connected via properly configured peering. The team states that the failure began after a network configuration change made last week.

What is the most likely root cause?

A) The peering between VNets was not configured correctly, preventing traffic from snet-app from reaching snet-data.

B) The outbound rule in nsg-app uses an incorrect destination prefix, blocking traffic before it leaves the application VMs.

C) The VirtualNetwork tag in nsg-data does not encompass addresses from peered VNets when peering was configured after NSG creation, causing traffic to be blocked by the Deny rule.

D) The nsg-app has an outbound rule that allows traffic on port 1433, but there is no corresponding inbound rule in nsg-data for the snet-app IP range explicitly.

Scenario 4 — Diagnostic Sequence​

An analyst receives the following report: "VMs in the snet-backend subnet cannot communicate with an external service on port 443. Outbound traffic appears to be blocked."

The available investigation steps are:

  1. Check if there is an Allow outbound rule for port 443 in the NSG associated with the subnet.
  2. Confirm if there is an NSG associated with the snet-backend subnet using az network vnet subnet show.
  3. Check if there is an Allow outbound rule for port 443 in the NSGs associated with the NICs of affected VMs.
  4. Use the Network Watcher IP Flow Verify resource to confirm which NSG and which rule is blocking traffic.
  5. Check if the subnet's default route points to an NVA or firewall that might be dropping traffic before the NSG.

What is the correct progressive diagnostic sequence?

A) 2 → 1 → 3 → 4 → 5

B) 4 → 2 → 1 → 3 → 5

C) 1 → 2 → 4 → 3 → 5

D) 2 → 3 → 1 → 5 → 4

Answer Key and Explanations​

Answer Key — Scenario 1​

Answer: B

Explanation:

  • The command output confirms that the NIC has no associated NSG. Therefore, the only NSG evaluated for inbound traffic is the one on the snet-frontend subnet. The rules of this NSG explicitly allow only ports 22 and 443. Since there is no Allow rule for port 80, the default DenyAllInBound rule (priority 65500) blocks this traffic.
  • The determining clue is in the nsg-frontend rules: port 80 simply does not exist as an allowed inbound entry.
  • The irrelevant information is the public IP reallocation. It does not affect NSG rules and does not explain why port 22 continues working while port 80 does not.
  • Alternative C is the most dangerous distractor: it claims that the absence of an NSG on the NIC blocks everything by default. This is wrong. When there is no NSG on the NIC, traffic is not blocked by that layer; only the subnet NSG is applied. Acting on this premise would lead to associating an unnecessary NSG to the NIC without fixing the missing rule.

Answer Key — Scenario 2​

Answer: B

Explanation:

  • The central constraint of the scenario is clear: the nsg-api cannot be removed from the subnet, as it contains audited rules that took weeks to be approved. The solution must preserve the existing NSG and its association position.
  • Adding an Allow rule for port 9090 with higher priority than any existing blocking rule solves the problem without removing the NSG, without recreating rules, and without introducing a second NSG association to the subnet, which is not possible.
  • Alternative D seems plausible, but has a critical reasoning error: the NSG on the NIC and the NSG on the subnet are independent layers. In inbound traffic, the subnet NSG is evaluated first. If it blocks port 9090, traffic never reaches the NIC for its NSG to allow it. Therefore, alternative D would not solve the problem.
  • Alternative C is technically invalid: it is not possible to associate two NSGs to the same subnet simultaneously in Azure.

Answer Key — Scenario 3​

Answer: B

Explanation:

  • The inbound rule in nsg-data uses the VirtualNetwork tag as source. This tag, in Azure, includes the address space of the VNet itself and of VNets connected by peering. Therefore, traffic from snet-app should be covered by this rule, ruling out alternative C.
  • Peering is "configured correctly" according to the statement, ruling out alternative A.
  • The critical point is in the outbound layer of nsg-app: the outbound rule allows traffic to 10.3.0.0/24 on port 1433. If the snet-data prefix is not exactly 10.3.0.0/24, traffic does not match the Allow rule and is blocked by the outbound Deny rule before even leaving the application VMs.
  • The clue is in the statement that the failure began after a "network configuration change," which suggests alteration in rules or addressing, not in the peering mechanism itself.
  • The most dangerous distractor is alternative C, as it presents false but technically sophisticated behavior about the VirtualNetwork tag behavior and NSG creation.

Answer Key — Scenario 4​

Answer: A

Explanation:

  • The correct diagnostic reasoning flows from the simplest and structural to the most specific and tool-based.
  • Step 2 comes first: confirming if there is an NSG associated with the subnet is the prerequisite for any rule investigation. Without this confirmation, the following steps might be applied to the wrong object.
  • Step 1 comes next: checking the subnet NSG's outbound rules, as it is the first layer evaluated in outbound traffic.
  • Step 3 covers the second layer: NSGs on individual NICs of affected VMs.
  • Step 4 uses Network Watcher to instrumentally confirm which rule is blocking, after mapping hypotheses via manual inspection.
  • Step 5 evaluates the routing layer, which is independent of NSG and represents an alternative cause if NSGs are not the problem.
  • Alternative B starts with the diagnostic tool before understanding what exists in the configuration, which is an inefficient practice in complex environments.

Troubleshooting Tree: Associate an NSG to a Resource​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Color Legend:

ColorNode Type
Dark blueInitial symptom (entry point)
Medium blueDiagnostic question
RedIdentified cause
GreenRecommended action or resolution
OrangeIntermediate validation or verification

When facing a real problem, start with the root node describing the blocked traffic symptom. Follow the diagnostic questions answering yes or no based on what you observe in the environment: first check if there is an associated NSG, then identify the resource type and traffic direction. Each branch leads to a concrete cause or remediation action. When the path reaches an intermediate validation node (orange), use tools like Network Watcher to confirm the hypothesis before acting.