Troubleshooting Lab: Evaluate network security recommendations identified by Microsoft Defender for Cloud attack paths
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team reports that Microsoft Defender for Cloud is showing an attack path with Critical classification for three days, even after the infrastructure team claims they applied all necessary fixes. The responsible engineer shares the action history:
- NSG rule created blocking inbound traffic on port 3389 to VM
prod-dc-01 - Tag
Environment: Productionadded to the resource for governance purposes - Defender for Cloud plan upgraded from Foundational CSPM to Defender CSPM on the subscription
The current attack path in the portal shows the following state:
Attack path status: Active
Risk level: Critical
Path:
[Internet]
--> [Public IP: 20.85.110.44 | associated with NIC of prod-dc-01]
--> [VM: prod-dc-01 | RDP port 3389 reachable from Internet]
--> [Managed Disk: disk-prod-dc-01 | unencrypted]
Recommendations pending:
- [HIGH] Enable disk encryption on prod-dc-01
- [MEDIUM] Apply Just-in-Time VM access
The team believes the issue was resolved because the NSG rule was created. Defender for Cloud disagrees.
What is the root cause of the attack path remaining active?
A) The Defender CSPM plan has not been fully provisioned yet, preventing reevaluation of the security graph.
B) The NSG rule blocks inbound traffic, but the Public IP is still directly associated with the VM's NIC, and the disk remains unencrypted, keeping the final destination vulnerable.
C) The Environment: Production tag applied to the resource changes Defender for Cloud's evaluation behavior, requiring manual approval to close the attack path.
D) Defender for Cloud detected that the NSG rule was created with incorrect priority, making it ineffective against internet-originated traffic.
Scenario 2 — Action Decision
The root cause has been identified: an Azure Application Gateway in production environment is operating without Web Application Firewall (WAF) enabled, and this configuration is the entry node of an attack path classified as High by Defender for Cloud. The attack path connects this gateway to a SQL database with unrestricted network access.
The operational context is as follows:
- The Application Gateway processes approximately 850,000 requests per hour during peak hours
- The approved maintenance window starts in 6 hours
- The security team has permission to apply configuration changes immediately, without additional approval
- The network team informs that the current Application Gateway SKU is Standard V2
- The SQL database is being actively used by a critical payment application
What is the correct action to take at this moment?
A) Enable WAF immediately on the Application Gateway, as the team has permission and the risk is classified as High.
B) Wait for the approved maintenance window in 6 hours and, at that time, migrate the Application Gateway SKU to WAF V2 before enabling WAF.
C) Immediately apply an NSG rule restricting access to the SQL database, mitigating the final destination of the attack path while the gateway change is planned for the maintenance window.
D) Create an exception ticket in Defender for Cloud disabling the WAF recommendation until the next maintenance window, avoiding unnecessary alerts.
Scenario 3 — Root Cause
An engineer analyzes the following output extracted from Defender for Cloud via CLI:
az security attack-path list --query "[].{Name:name, RiskLevel:properties.riskLevel, Status:properties.status}" -o table
Name RiskLevel Status
-------------------------------------------- ----------- --------
Internet-VM-StorageAccount-path-001 Critical Active
Internet-AppGW-AKS-KeyVault-path-002 High Active
Internet-VM-SQLServer-path-003 High Dismissed
Internet-PublicIP-VM-path-004 Medium Active
The engineer notices that path Internet-VM-SQLServer-path-003 has status Dismissed and questions why Defender for Cloud is not monitoring this path. He checks the environment and collects the following additional information:
- The VM involved in path 003 has the Microsoft Monitoring Agent installed and reporting correctly to the Log Analytics workspace
- The referenced SQL Server has Defender for SQL enabled and no active alerts
- The subscription has the Defender CSPM plan active
- A security team member applied an exemption on the SQL Server public access recommendation two weeks ago, with justification of "risk accepted by business"
The engineer asks a colleague why the path is dismissed. The colleague responds that it's probably because of the agent installed on the VM. This hypothesis is incorrect.
What is the actual root cause of the Dismissed status in attack path 003?
A) Defender for SQL enabled on the SQL Server signaled to Defender for Cloud that the resource is protected, resulting in automatic attack path closure.
B) The exemption applied to the recommendation of SQL Server public access caused Defender for Cloud to disregard this vulnerability when calculating the attack path, resulting in Dismissed status.
C) The presence of the Microsoft Monitoring Agent on the VM indicates that the resource is being actively monitored, which reduces the path's risk score below the display threshold.
D) The path was automatically dismissed because no exploitation activity was detected in the last 14 days, according to Defender CSPM's default behavior.
Scenario 4 — Diagnostic Sequence
An engineer receives the following report:
"Defender for Cloud stopped displaying attack paths for our subscription. Yesterday there were 7 active paths. Today the list is empty. No fixes were applied by the team."
The engineer needs to diagnose the cause of this unexpected absence of attack paths. He has the following investigation steps available, presented out of order:
- Verify if the Defender CSPM plan remains enabled on the subscription
- Confirm if there were recent permission or role assignment changes that may have restricted Defender for Cloud's visibility scope
- Access the Defender for Cloud portal and check if there's an error message or warning in the Cloud Security Graph section
- Query the subscription's Activity Log to identify administrative actions performed in the last 24 hours
- Try to list attack paths via CLI with
az security attack-path listto confirm if the absence is only visual or also in the API
What is the correct investigation sequence?
A) 3 -> 1 -> 4 -> 5 -> 2
B) 1 -> 3 -> 5 -> 4 -> 2
C) 5 -> 2 -> 1 -> 4 -> 3
D) 4 -> 1 -> 3 -> 5 -> 2
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The central clue is in the portal output itself: the attack path still points to the unencrypted disk as the vulnerable destination node, and the pending recommendations confirm this. The NSG rule may have reduced the attack surface on port 3389, but two problems persist: the Public IP remains associated with the NIC, meaning the VM is still directly addressable from the internet, and the disk remains unencrypted, keeping the final destination exposed. An attack path is only removed when all critical links in the chain are fixed.
The irrelevant information in the scenario is the Environment: Production tag, which has no effect on Defender for Cloud's behavior in attack path evaluation. Alternative A is a plausible distractor, as the plan change is a real action in the scenario, but Defender CSPM was already active before the evaluation was displayed. Alternative D confuses the NSG rule mechanism with Defender for Cloud's evaluation model, which doesn't analyze rule priority to decide if an attack path is valid.
The most dangerous distractor is alternative A: acting based on it would lead the team to wait for a provisioning that has already been completed, delaying the actual fix.
Answer Key — Scenario 2
Answer: B
The critical constraint in the scenario is the SKU: the Application Gateway is on Standard V2 SKU, which doesn't natively support WAF. Enabling WAF requires migration to WAF V2 SKU, and this migration represents a structural change with potential impact on processing 850,000 requests per hour. Applying this outside the maintenance window, even with permission, would be technically incorrect given the operational risk.
Alternative A is the most dangerous distractor: the team has permission and the risk is real, but ignoring the SKU requirement would lead to a configuration attempt that would simply fail or require resource recreation. Alternative C is valid as partial mitigation, but the question asks what is the correct action at this moment, and protecting only the destination without treating the entry point doesn't address the main cause of the attack path. Alternative D represents a practice that masks risk without fixing it.
Answer Key — Scenario 3
Answer: B
The root cause is in the exemption applied to the recommendation of SQL Server public access. When a recommendation is exempted in Defender for Cloud, it ceases to be treated as an active vulnerability in the Cloud Security Graph. Since the attack path is calculated based on this graph, the absence of the vulnerability as an active node results in Dismissed status for the path that depended on it.
The colleague in the scenario points to the VM agent as the cause, which is the deliberate irrelevant information in the scenario. The presence or absence of the Microsoft Monitoring Agent doesn't affect the attack path calculation logic in Defender CSPM.
Alternative A represents a common misconception: Defender for SQL provides detection and alerts, but doesn't instruct Defender for Cloud to automatically close attack paths. Alternative D describes behavior that doesn't exist in the platform; Defender for Cloud doesn't dismiss attack paths due to temporal inactivity.
The most dangerous distractor is alternative A, as it would lead the engineer to conclude that the SQL Server is protected when, in reality, the exemption only hid the risk from Defender for Cloud's visibility.
Answer Key — Scenario 4
Answer: B
The correct sequence follows progressive diagnostic logic: starting from the broadest and structural to the most specific and contextual.
Step 1 (verify if Defender CSPM is enabled) is the starting point because, without the correct plan, no attack paths are generated. With the plan confirmed, step 3 (check for error messages in Cloud Security Graph) identifies if there's an internal processing failure. Step 5 (query via CLI) confirms if the problem is interface or actual data. Step 4 (Activity Log) investigates administrative changes that may have caused the problem. Step 2 (permissions and role assignments) is last because it's the most specific and contextual cause, and only makes sense to investigate after ruling out more likely causes.
Alternative A starts with the visual symptom (step 3) before confirming if the platform is operational, which is inefficient. Alternative C starts with CLI without first confirming if the plan is active, skipping the most basic validation. Alternative D starts with Activity Log, which is useful but not the most direct step to confirm if the problem is plan configuration or data.
Troubleshooting Tree: Evaluate network security recommendations identified by Microsoft Defender for Cloud attack paths
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue (#1a1a2e) | Initial symptom or entry point |
| Blue (#0077b6) | Diagnostic question |
| Red (#d62828) | Identified cause |
| Green (#2d6a4f) | Recommended action or resolution |
| Orange (#f4a261) | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node describing the observed symptom (attack path unexpectedly active or absent without reason) and follow the branches by answering each question based on what is directly observable in the portal or via CLI. Each answer eliminates a set of hypotheses and directs reasoning toward the most likely cause, avoiding premature corrective actions on nodes that are not the real origin of the problem.