Troubleshooting Lab: Implement and manage virtual network security by using Azure Virtual Network Manager
Diagnostic Scenarios
Scenario 1 — Root Cause
A network team configured Azure Virtual Network Manager (AVNM) to manage security for 14 VNets distributed across three regions. A Security Admin Configuration was created with rules that block inbound traffic on port 23 (Telnet) for the entire managed scope. The configuration was successfully deployed, as confirmed in the Portal.
After deployment, the audit team verifies two specific VNets and finds that Security Admin rules are present and active. However, when checking a third VNet called vnet-legacy-centralus, the Security Admin rules don't appear and inbound Telnet traffic is still accepted on it.
The administrator runs the following command to inspect the VNet state:
az network manager list-effective-connectivity-config \
--resource-group rg-network-central \
--virtual-network-name vnet-legacy-centralus
The output returns an empty list for connectivity configurations, but the administrator confirms that the VNet exists, is active, and has running VMs. The creation history shows that vnet-legacy-centralus was provisioned 18 months ago, before the AVNM was created. The subscription where it resides is the same as the other VNets. The Network Group to which the other VNets belong uses membership type: Static.
What is the root cause of the problem?
A) VNets created before AVNM deployment need to be redeployed to receive Security Admin configurations, as propagation is not retroactive.
B) The VNet vnet-legacy-centralus was not added to the Network Group that is the scope of the Security Admin Configuration, therefore the rules don't apply to it.
C) The command used checks connectivity configurations, not security, and that's why the output is empty; Security Admin rules are present but the wrong command was used for validation.
D) The centralus region was not included in the Security Admin Configuration deployment scope, and regions added after initial creation require manual redeployment.
Scenario 2 — Root Cause
A company uses AVNM to apply a Security Admin Configuration with a rule that explicitly blocks outbound traffic to the range 0.0.0.0/0 on port 3389 (external RDP). The rule has priority 100 and action Deny. The deployment completed without errors.
A systems administrator reports that they can initiate RDP sessions from a VM in vnet-prod-eastus to an external public IP address. The NSG associated with the VM's subnet contains only default Azure rules, with no custom outbound rules.
The administrator verifies the Security Admin configuration via Portal and finds the following state:
| Field | Value |
|---|---|
| Rule name | Block-RDP-External |
| Direction | Outbound |
| Priority | 100 |
| Protocol | TCP |
| Destination port | 3389 |
| Destination | 0.0.0.0/0 |
| Action | Deny |
| Deployment state | Succeeded |
The administrator also confirms that the VNet vnet-prod-eastus is in the correct Network Group and that the Security Admin Configuration is deployed to this VNet. The VM was migrated from another subscription three days ago and its IP address was maintained per the applications team's request.
What is the root cause of the observed behavior?
A) Security Admin rules with Deny action don't block outbound traffic to public addresses when the VM has a public IP directly associated to the NIC.
B) The VM migration between subscriptions caused temporary dissociation of the VNet from the Network Group, and the Portal state hasn't been updated to reflect the dissociation.
C) A Security Admin rule with Deny action can be bypassed by an NSG rule with Allow action and higher priority, and the NSG default rules allow outbound traffic to internet.
D) The destination field 0.0.0.0/0 in Security Admin rules doesn't cover public IPv4 addresses; it's necessary to specify the Internet prefix to cover external traffic.
Scenario 3 — Action Decision
A company's security team identified that a Security Admin Configuration deployed in AVNM contains an incorrect rule: the Allow-Mgmt-Inbound rule with priority 150 is allowing inbound traffic on port 22 from any source (0.0.0.0/0) instead of only from the management block 10.0.0.0/8. The cause was confirmed: the source field was incorrectly filled during provisioning via template.
The environment has the following constraints:
- The Security Admin Configuration is deployed to 22 VNets in active production
- Modifying a rule within a Security Admin Configuration requires redeployment of the configuration to all VNets in scope after the change
- Redeployment doesn't interrupt existing traffic on the VNets, but has an estimated duration of 15 to 30 minutes per VNet
- The maintenance window starts in 45 minutes
- An explicit NSG denial rule on port 22 with source
0.0.0.0/0can be added immediately to all affected subnets as a temporary measure - The operations team has permission to modify NSGs without additional approval, but AVNM modifications require approval from the security committee, which only meets during the maintenance window
What is the correct action to take now, before the maintenance window?
A) Immediately start modifying the rule in the Security Admin Configuration and redeploy to all 22 VNets before the window begins.
B) Remove the complete Security Admin Configuration from all VNets now to eliminate the incorrect rule, and redeploy the corrected version during the maintenance window.
C) Add an explicit NSG denial rule on port 22 with source 0.0.0.0/0 to affected subnets as immediate mitigation, and correct the rule in the Security Admin Configuration during the maintenance window with committee approval.
D) Wait for the maintenance window without taking any action now, as AVNM modification requires committee approval and any isolated action may create rule conflicts.
Scenario 4 — Collateral Impact
A network team decides to reorganize AVNM Network Groups to simplify management. As part of the reorganization, they remove VNet vnet-spoke-02 from Network Group A and add it to Network Group B. The immediate result is as expected: the Security Admin Configuration rules associated with Network Group B now apply to vnet-spoke-02.
Network Group A had a Connectivity Configuration of type Hub-and-Spoke deployed, with vnet-hub-central as the hub. Network Group B has only a Security Admin Configuration deployed, with no associated Connectivity Configuration.
What secondary consequence can this action cause?
A) Security Admin rules from Network Group A will continue to be applied to vnet-spoke-02 for up to 24 hours after removal, as removal propagation has guaranteed SLA latency.
B) The peering between vnet-spoke-02 and vnet-hub-central, which was managed by Network Group A's Connectivity Configuration, will be removed, potentially interrupting traffic that depended on this peering.
C) Adding to Network Group B will cause configuration conflict because a VNet cannot be a member of two different Network Groups within the same AVNM simultaneously.
D) Network Group A's Connectivity Configuration will be automatically extended to cover Network Group B, maintaining hub peering for the newly added VNet.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The Static membership type of the Network Group means that VNets are added manually, one by one. No VNet automatically enters the group by existing in the subscription or by satisfying some dynamic criteria. The decisive clue in the scenario is the combination of two facts: the Network Group uses static membership and VNet vnet-legacy-centralus was created before AVNM. With static membership, the VNet's age is irrelevant; what matters is whether it was explicitly added to the group. Since the command output returns an empty list of applied configurations, the VNet is simply not in the scope of the Security Admin Configuration.
The irrelevant information is the VNet's age (18 months). It was included to lead the reader to alternative A, which assumes a retroactive propagation behavior that doesn't exist. AVNM applies configurations to the scope defined by the Network Group, regardless of when the VNet was created.
The most dangerous distractor is alternative A. Acting based on it would lead the team to redeploy or recreate the VNet, a high-impact and completely unnecessary operation. The correct action is simply to add the VNet to the Network Group.
Answer Key — Scenario 2
Answer: C
The observed behavior stems from a fundamental characteristic of AVNM's security evaluation model: Security Admin rules are evaluated before NSG rules, but rules with Allow action in Security Admin don't block subsequent NSG evaluation. However, rules with Deny action in Security Admin must block traffic regardless of NSG. The issue is in the reverse direction: Azure NSG default outbound rules include the AllowInternetOutBound rule with priority 65001, which allows all outbound traffic to the Internet. A Security Admin rule with Deny action cannot be overridden by NSG, but alternative C describes the inverse reasoning.
The real cause is different: Security Admin rules with Deny action effectively block traffic and cannot be bypassed by NSGs. This means that the described behavior (external RDP working despite the Deny rule in Security Admin) indicates that VNet vnet-prod-eastus is not actually receiving the rule, despite the Portal indicating successful deployment. The VM migration between subscriptions three days ago is the clue: if the VM was migrated and its IP address was maintained, but the source VNet in another subscription still appears as a Network Group member, the actual traffic may be occurring through a path not covered by the current AVNM scope.
Alternative C represents the most common conceptual error: believing that NSGs can override Security Admin rules with Deny action, which is not true. Security Admin Deny is incontrovertible by NSG, making this distractor pedagogically important.
The most dangerous distractor is alternative C precisely because it inverts the real hierarchy: acting based on it would lead the team to add Allow rules in the NSG to "fix" the problem, which wouldn't solve anything and would add configuration noise.
Answer Key — Scenario 3
Answer: C
The scenario presents three constraints that need to be satisfied simultaneously: there's an active vulnerability that needs immediate mitigation, AVNM modification requires committee approval that only occurs in the maintenance window, and the team has immediate permission to modify NSGs. Alternative C is the only one that respects all constraints: immediately mitigates risk with the available resource (NSG), and reserves structural correction (AVNM) for the appropriate moment with necessary approval.
Alternative A ignores the committee approval constraint for AVNM modifications, plus redeploying to 22 VNets in less than 45 minutes is operationally unfeasible given the estimated time of 15 to 30 minutes per VNet.
Alternative B is the most dangerous distractor: removing the complete Security Admin Configuration would eliminate not only the incorrect rule, but all security rules managed by AVNM across the 22 production VNets, creating a much larger exposure window than the original vulnerability.
Alternative D is incorrect because the vulnerability is active and there's a means of mitigation available immediately without need for approval. Not acting when you have the capacity to mitigate is a security process failure.
Answer Key — Scenario 4
Answer: B
When AVNM manages a Hub-and-Spoke type Connectivity Configuration, it creates and manages the peerings between spoke VNets and the hub VNet. By removing vnet-spoke-02 from Network Group A, the Connectivity Configuration associated with that group no longer includes this VNet in its scope. As a consequence, the AVNM-managed peering between vnet-spoke-02 and vnet-hub-central is automatically removed. If any production traffic depended on this peering to route packets through the hub, this communication will be interrupted.
Alternative A describes a propagation latency behavior that doesn't exist as a documented SLA for membership removal; removal is processed asynchronously, but there's no 24-hour maintenance guarantee.
Alternative C is incorrect: a VNet can be a member of multiple Network Groups within the same AVNM simultaneously, which is precisely one of the features that allows applying different configurations to overlapping sets of VNets.
Alternative D describes an automatic extension behavior that doesn't exist. Connectivity Configurations have scope defined by the Network Group they're associated with; they don't automatically expand to other groups.
Troubleshooting Tree: Implement and manage virtual network security by using Azure Virtual Network Manager
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: validation or intermediate verification before proceeding
How to navigate the tree when facing a real problem: always start from the root node and first verify if the Security Admin Configuration deployment was completed successfully, as a silent failure here invalidates all subsequent analysis. Next, confirm if the affected VNet is in the correct Network Group scope, checking the membership type to understand if the absence is intentional or a configuration error. When reaching an orange node, execute the indicated verification before advancing. Red nodes indicate confirmed cause; follow to the corresponding green node and execute the corrective action. Use Network Watcher as final validation after any AVNM configuration changes.