Manage and monitor security posture
Defender for Cloud Posture Management
CoreUse Defender for Cloud to prioritize posture, map compliance, enable workload plans, connect multicloud estates, manage VM vulnerability coverage, and discover internet-facing assets.
Aligned to the live SC-500 guide, which publishes no skills-measured date; guide and product behavior verified September 23, 2026.
Why this matters
Posture and workload protection depend on inventory and scope. Unconnected clouds, disabled plans, stale vulnerability data, or unknown external assets create blind spots even when a dashboard appears healthy.
Must Know
- Foundational CSPM supplies core posture visibility; Defender CSPM adds advanced capabilities such as attack-path analysis, cloud security explorer, governance, and sensitive-data context according to current plan support.
- Regulatory compliance maps resource assessments to framework controls. A control can contain multiple assessments and requires reviewing the resources behind the aggregate status.
- Workload protection plans are enabled per environment or subscription and protect distinct resource types; enabling one plan does not enable every other plan.
- AWS and GCP connectors require provider-side trust, permissions, account or project selection, and plan configuration; coverage must be verified after connection.
- Microsoft Defender Vulnerability Management integration and agentless scanning have separate prerequisites and coverage signals for Azure VMs.
- Defender EASM discovers externally observable assets from seed data and attack-surface relationships; discovered ownership and risk require validation and remediation in the responsible system.
Compare and Distinguish
- CSPM identifies posture risk and attack paths; workload protection plans detect threats against covered resources.
- Regulatory compliance organizes assessments by framework; secure score prioritizes posture improvement but is not a certification result.
- EASM observes an external attacker view; Defender for Cloud inventory and connectors establish cloud control-plane context.
Scenario examples
- Scenario: A framework control is failing in one subscription. Think: drill into its assessments and affected resources rather than treating the framework summary as a single setting.
- Scenario: AWS accounts appear connected but container findings are absent. Think: verify provider permissions, selected scope, and the relevant Defender plan components.
- Scenario: Security discovers an unknown public host related to the company. Think: validate ownership through EASM evidence and route remediation to the asset owner.
Exam traps
- A high secure score does not prove regulatory compliance or absence of active threats.
- Connecting an account does not automatically enable every paid workload protection plan.
- A vulnerability-management setting does not patch the VM by itself.
- An EASM-discovered domain should not be deleted or blocked until ownership and business use are confirmed.
Key takeaways
- Start with accurate inventory and explicit plan coverage.
- Prioritize attack paths and recommendations using scope, exposure, sensitivity, and exploitability.
- Treat compliance and external discovery as evidence that drives owned remediation.
How it works
- Connectors and Azure control planes supply inventory and configuration that Defender for Cloud evaluates against assessments and threat analytics.
- Plans and extensions add workload-specific data while EASM independently maps public-facing relationships from the outside.
Objects and administrative surfaces
- Defender for Cloud overview, recommendations, attack paths, security explorer, secure score, and regulatory compliance.
- Environment settings, Defender plans, AWS and GCP connectors, provisioning status, and coverage workbooks.
- Vulnerability findings for VMs and Defender EASM discovery groups, inventories, attack-surface priorities, and ownership.
When to use it
- Use attack paths to prioritize chains of exploitable posture issues rather than isolated low-context findings.
- Use EASM to find unknown external exposure and cloud connectors to establish governed multicloud coverage.
Security and governance implications
- Assign owners and due dates to high-impact recommendations, monitor exemptions, and protect plan or connector changes.
- Review coverage gaps and stale findings across every subscription, AWS account, GCP project, and external asset group.
Troubleshooting signals
- For missing findings, verify inventory, connector health, permissions, plan status, component provisioning, and assessment recency.
- For framework discrepancies, inspect the exact assessment logic, scope, exemptions, and resource state.
More detail
- Investigate Defender CSPM recommendations and attack paths.
- Interpret framework compliance without overclaiming attestation.
- Enable workload protection and multicloud connectors at the intended scope.
- Configure VM vulnerability coverage and validate EASM discoveries.
Ready for the quiz?
- How does Defender CSPM differ from a workload protection plan?
- What must be checked after an AWS or GCP connector reports connected?
- Why is an EASM discovery not automatically proof of asset ownership?
Related objectives
- D4.1.S1 — Identify security risks by using Defender CSPM
- D4.1.S2 — Evaluate compliance against security frameworks by using Defender for Cloud
- D4.1.S3 — Enable and configure Defender for Cloud workload protection plans
- D4.1.S4 — Connect hybrid cloud and multicloud environments to Defender for Cloud, including Amazon Web Services (AWS) and Google Cloud Platform (GCP)
- D4.1.S5 — Configure Microsoft Defender Vulnerability Management settings for Azure VMs
- D4.1.S6 — Discover unprotected assets and vulnerabilities by using Microsoft Defender External Attack Surface Management (EASM)