Troubleshooting Lab: Create an application security group (ASG)
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator created an ASG named asg-frontend to segment inbound traffic from presentation VMs of a web application. After creating the ASG via the Azure Portal, they attempt to associate it with an existing NSG rule in the NSG nsg-app-eastus2 to allow HTTP traffic on port 80. When trying to save the rule with the ASG as destination, the Portal returns the following error:
The application security group
'/subscriptions/a1b2c3d4/resourceGroups/rg-network-westus/providers/
Microsoft.Network/applicationSecurityGroups/asg-frontend'
cannot be used in region 'eastus2' because it is in region 'westus'.
The administrator confirms that all application VMs are in the eastus2 region, that the NSG nsg-app-eastus2 is associated with a subnet in eastus2, and that the Resource Group rg-network-westus was intentionally created in the westus region to centralize network metadata. The administrator mentions that other resources within rg-network-westus, such as route tables, work normally when referenced by subnets in eastus2.
What is the root cause of the observed error?
A) The Resource Group rg-network-westus is in a different region from eastus2, and network resources cannot be referenced between Resource Groups from different regions.
B) The ASG was created in the westus region by inheriting the Resource Group's region, and ASGs can only be used in NSGs and NICs that are in the same region as the ASG.
C) The NSG nsg-app-eastus2 does not support ASGs as destination in inbound rules when the ASG was created in a different Resource Group from the NSG.
D) The error occurs because the ASG asg-frontend does not have associated NICs yet, and Azure requires at least one associated NIC before allowing the use of ASG in NSG rules.
Scenario 2 — Diagnostic Sequence
An infrastructure team receives a ticket reporting that VMs in a new environment are not communicating as expected after creating ASGs and NSG rules. The responsible administrator suspects that the ASGs were created correctly, but something in the association or rules is incorrect.
The available investigation steps are:
- Verify if the VMs' NICs are associated with the correct ASGs using the Portal or the
az network nic showcommand - Confirm that the ASGs referenced in NSG rules exist and are in the same region as the NSG
- Review NSG rules to verify if ASGs are being used correctly as source or destination in relevant rules
- Use IP flow verify in Network Watcher to confirm if specific traffic is being allowed or blocked
- Confirm that the NSG is associated with the subnet or NICs of the affected VMs
What is the correct investigation sequence?
A) 2 -> 5 -> 3 -> 1 -> 4
B) 4 -> 2 -> 1 -> 3 -> 5
C) 1 -> 3 -> 2 -> 5 -> 4
D) 5 -> 2 -> 3 -> 1 -> 4
Scenario 3 — Action Decision
During a security review, the team identified that the ASG asg-db-tier was created in the brazilsouth region, but all database VMs that should be associated with it are in the eastus region. The cause is confirmed: the provisioning script used the Resource Group location parameter instead of the explicit VM location.
The environment has the following constraints:
- Database VMs are in production and processing active transactions
- No maintenance window is available for the next 6 hours
- The ASG asg-db-tier does not have associated NICs yet and is not referenced in any active NSG rules
- The security team requires ASG segmentation to be operational before the next maintenance window, which occurs in 8 hours
- Creating a new ASG in the correct region does not require additional approval
What is the correct action to take now?
A) Move the ASG asg-db-tier from brazilsouth to eastus using the Azure Resource Mover relocation feature to preserve the name and avoid rework.
B) Create a new ASG in the eastus region named asg-db-tier-eastus, associate the database VMs' NICs to it, and configure the necessary NSG rules before the maintenance window.
C) Associate the database VMs' NICs to the existing ASG asg-db-tier in brazilsouth and update the NSG to reference this ASG, since NSGs accept ASGs from different regions when VMs are in the same VNet.
D) Wait for the maintenance window in 8 hours to delete the incorrect ASG and recreate everything in the production environment with controlled impact.
Scenario 4 — Root Cause
An administrator creates an ASG named asg-api-layer via Azure CLI with the following command:
az network asg create \
--resource-group rg-networking \
--name asg-api-layer \
--location eastus
The output returns success. Next, they attempt to create a rule in the NSG nsg-backend that uses asg-api-layer as source and a specific IP address as destination:
az network nsg rule create \
--resource-group rg-networking \
--nsg-name nsg-backend \
--name Allow-API-to-DB \
--priority 300 \
--direction Inbound \
--source-asgs asg-api-layer \
--source-port-ranges '*' \
--destination-address-prefixes 10.2.1.5 \
--destination-port-ranges 1433 \
--access Allow \
--protocol Tcp
The command returns an error. The administrator verifies that the NSG nsg-backend exists in Resource Group rg-networking and is associated with a subnet in eastus. The ASG asg-api-layer is also in eastus. The administrator mentions they created the NSG three weeks ago and it already contains 12 active rules without issues. The subscription is at 95% of the ASG limit per region.
When running az network nsg rule list --resource-group rg-networking --nsg-name nsg-backend, all 12 existing rules appear correctly.
The error returned by the CLI is:
(InvalidRequestFormat) Cannot mix ASG and non-ASG in source or destination.
What is the root cause of the error?
A) The ASG limit per region is near exhaustion, preventing the creation of new rules that reference ASGs.
B) An NSG rule cannot mix ASG as source with an IP address as destination; when ASGs are used, both source and destination must be ASGs or both must be IP addresses or prefixes.
C) The --source-asgs parameter requires the ASG to be associated with at least one NIC before being used in an NSG rule, and asg-api-layer does not have NICs yet.
D) The NSG nsg-backend has already reached the limit of rules that can reference ASGs, and the 12 existing rules have exhausted the quota of ASG references per NSG.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The key point is that the region of an ASG is determined at creation time and not by the Resource Group's region. However, in practice, when an administrator creates a resource through the Portal without explicitly specifying the location, the Portal may use the Resource Group's region as default. The CLI error confirms that the ASG is in westus and the NSG is in eastus2: ASGs can only be referenced in NSGs and NICs that are in the same region as the ASG. This restriction is absolute and cannot be bypassed.
The irrelevant information is the mention that route tables in rg-network-westus work when referenced by subnets in eastus2. Route tables have a different association relationship with subnets and do not follow the same regional co-location restriction that ASGs have with NSGs.
The main reasoning error of the distractors is confusing regional restriction with Resource Group restriction. Alternative A suggests the problem is the Resource Group difference between regions, which is not the correct model. Alternative D introduces a NIC prerequisite that doesn't exist on the platform: ASGs can be referenced in NSG rules before having any associated NICs.
The most dangerous distractor is alternative A. Acting based on it would lead the administrator to unnecessarily move resources between Resource Groups without solving the actual ASG region problem.
Answer Key — Scenario 2
Answer: A
The correct sequence is: 2 -> 5 -> 3 -> 1 -> 4
- Step 2 first: confirming that ASGs exist and are in the correct region is the prerequisite for any valid use of them. An ASG in the wrong region invalidates the entire following chain.
- Step 5 next: verifying if the NSG is associated with the subnet or NICs is the second prerequisite. An unassociated NSG produces no effect, regardless of the rules it contains.
- Step 3 after: with NSG associated and valid ASGs confirmed, reviewing rules to ensure ASGs are being used as correct source or destination is the next logical step.
- Step 1 following: verifying if VMs' NICs are effectively associated with the ASGs referenced in rules is what closes the configuration cycle.
- Step 4 last: IP flow verify is the final validation tool, used to empirically confirm behavior after all configuration items have been verified.
Alternative B starts with IP flow verify, which inverts the logic: using a validation tool before checking configurations produces results that may be difficult to interpret without the established configuration context.
Alternative C starts with NIC association, which is an internal configuration detail, before checking structural prerequisites like region and NSG association.
Answer Key — Scenario 3
Answer: B
The statement establishes that the incorrect ASG has no associated NICs and is not referenced in any active rules, which means deleting it and creating a new one causes no operational impact. The critical constraint is the timeline: segmentation needs to be operational in less than 8 hours, and the maintenance window occurs exactly at that time. Creating a new ASG in the correct region and configuring rules within the window is the only alternative that simultaneously respects the timeline, active production constraint, and absence of risk.
Alternative A is the most dangerous distractor: ASGs are not relocatable resources by Azure Resource Mover. Attempting to use this approach would consume precious time to discover that the operation is not supported, compromising the maintenance window timeline.
Alternative C is technically incorrect: NSGs do not accept ASGs from different regions. This configuration would result in the same error seen in Scenario 1.
Alternative D postpones action to the maintenance window unnecessarily, since the incorrect ASG has no active dependencies and can be handled immediately without risk.
Answer Key — Scenario 4
Answer: B
The error Cannot mix ASG and non-ASG in source or destination is explicit and direct: in a single NSG rule, it is not allowed to combine an ASG with an IP address or prefix in the same source or destination field, nor use ASG in one field and IP address in the other. When a rule uses ASG as source, the destination must also be an ASG or the field must be configured as * (any). The combination of ASG as source with specific IP address as destination violates this platform restriction.
The irrelevant information is the percentage of ASG limit per region utilization (95%). This data was included to lead the reader to alternative A. The ASG limit per region controls how many ASGs can be created, not whether rules can reference existing ASGs.
The main reasoning error of the distractors is attributing the problem to capacity limits or configuration prerequisites like associated NICs. None of these factors are relevant to the returned error. Alternative C is especially misleading because it creates a non-existent requirement: ASGs can be used in NSG rules before having any associated NICs.
The most dangerous distractor is alternative A. Acting based on it would lead the team to investigate subscription limits and open tickets with Microsoft, without ever correcting the NSG rule.
Troubleshooting Tree: Create an application security group (ASG)
Color Legend:
- Dark blue: initial symptom, investigation entry point
- Blue: objective diagnostic question with verifiable answer
- Red: identified and confirmed cause
- Green: recommended action or resolution to execute
- Orange: intermediate validation or verification before proceeding
How to navigate the tree when facing a real problem: start from the root node and immediately identify whether the problem occurs during ASG creation or its later use in NSG rules or NIC association. This first bifurcation determines the investigation path. Answer each blue question based on what is directly verifiable in the Portal or via CLI. When reaching an orange node, execute the verification before advancing. When reaching a red node, the cause is confirmed; follow to the corresponding green node and execute the action. Use IP flow verify as final validation after any configuration correction.