12.2 Workload Protection Plans and Multicloud Connectors
Key Takeaways
- CWPP plans (Servers, Storage, Containers, Databases, Key Vault, App Service, and others) add threat protection and workload-specific defenses beyond CSPM recommendations.
- Enable and configure plans per subscription (or connector) in Defender for Cloud Environment settings; coverage differs by plan and resource type.
- Native AWS and GCP connectors use federated authentication with short-lived credentials; CSPM assessment is agentless after onboarding, while many CWPP features need Azure Arc and extensions on multicloud machines.
- Hybrid servers join through Azure Arc so Defender for Servers and related protections extend beyond Azure-native VMs.
- SC-500 expects you to choose the correct plan for a workload and to know multicloud connector high-level requirements and coverage differences.
12.2 Workload Protection Plans and Multicloud Connectors
Quick Answer: Enable Defender for Cloud workload protection plans (Servers, Storage, Containers, Databases, Key Vault, App Service, and related plans) for threat detection and workload defenses. Connect AWS and GCP with native connectors (federated trust, short-lived credentials) and onboard hybrid machines with Azure Arc. CSPM after connector onboarding is largely agentless; many CWPP features need Arc + extensions and plan-specific components.
SC-500 skills include enable and configure Defender for Cloud workload protection plans and connect hybrid and multicloud environments, including AWS and GCP. This section is the operational map: which plans protect which workloads, how to turn them on, and what multicloud/hybrid coverage really requires.
CSPM vs CWPP — why plans exist
Section 12.1 covered posture. Cloud workload protection platform (CWPP) plans answer a different question: Is something actively wrong or exploitable inside this workload’s runtime/data plane?
| Concern | Primary tool |
|---|---|
| Misconfigured NSG / public storage / weak TLS | CSPM recommendations + Secure Score |
| Malware on a VM, suspicious SQL login, anomalous storage upload | CWPP plan alerts (Servers, Databases, Storage, …) |
| Multicloud inventory and benchmark assessment | Connectors + CSPM |
| EDR-quality protection on EC2/GCE | Defender for Servers + Arc + MDE integration |
You often need both: CSPM reduces attack surface; CWPP detects residual threat activity.
Major workload protection plans
Plans are enabled primarily from Defender for Cloud → Environment settings on a subscription or multicloud connector. Once enabled, supported resources in scope are protected, and new matching resources typically inherit protection.
Plan catalog (exam-focused)
| Plan | Protects | High-level capabilities |
|---|---|---|
| Defender for Servers | Azure VMs, Arc servers, multicloud VMs when onboarded | Threat detection, MDE integration, vulnerability assessment options, JIT (plan-dependent), agentless scanning options (P2), FIM (P2), etc. |
| Defender for Storage | Blob, Files, Data Lake | Activity monitoring, sensitive-data threat context, malware scanning options |
| Defender for Containers | AKS/EKS/GKE and related container assets | Hardening recommendations, vulnerability assessment, runtime protection (sensor where required), audit log insights |
| Defender for Databases / SQL-related plans | Azure SQL, SQL on machines, open-source DB offerings (scope varies) | Vulnerability assessment, advanced threat protection signals |
| Defender for Key Vault | Azure Key Vault | Anomalous access patterns against vaults |
| Defender for App Service | App Service workloads | Threat detection for web app hosting scenarios |
| Defender for Resource Manager, DNS, AI services, etc. | Control plane / DNS / AI resource scopes | Specialized detections when those plans are in scope for the tenant design |
Exact plan names and feature matrices evolve; exams test matching workload → plan and enablement location, not obscure SKU trivia.
Defender for Servers plans (P1 vs P2) — coverage difference that matters
Defender for Servers is frequently split into Plan 1 and Plan 2:
- Plan 1: Strong focus on Microsoft Defender for Endpoint integration for EDR on connected machines; agent-based vulnerability assessment via MDE.
- Plan 2: Includes Plan 1 capabilities plus additional server defenses such as agentless scanning, just-in-time (JIT) VM access, file integrity monitoring, and other expanded features Microsoft documents for P2.
Exam trap: JIT VM access and agentless machine scanning are not “any Defender for Cloud toggle”—they ride on the correct Servers plan (and related settings). Do not assume Foundational CSPM alone delivers full server CWPP.
Enabling and configuring plans
Typical enablement flow:
- Open Microsoft Defender for Cloud in the Azure portal (or unified Defender portal experiences as Microsoft converges UI).
- Go to Environment settings.
- Select the subscription (or AWS/GCP connector).
- Choose the plan, set it to On, and open Settings for plan-specific features (for example malware scanning on Storage, vulnerability assessment method on Servers, agentless scanning toggles).
- Save and verify resources appear in inventory with expected recommendations/alerts after discovery intervals.
Permissions: plan enablement generally requires elevated subscription rights (commonly Owner or Security Admin patterns—confirm least privilege for your org). Some agentless features require the enabler to have sufficient rights for the scanner components to activate.
Scenario: A team enables Defender for Storage but still has open blob containers. CSPM recommendations continue to flag exposure; Storage CWPP may alert on suspicious downloads. Fix both: close public access (posture) and keep the plan for residual threat detection.
Multicloud connectors: AWS and GCP
Why connectors exist
Organizations run multicloud. Defender for Cloud provides a single control plane for posture and (with plans) workload protection across Azure, AWS, and GCP. Native connectors avoid brittle custom collectors for baseline CSPM.
Authentication architecture (high level)
For AWS, Microsoft uses federated trust and short-lived credentials rather than storing long-lived AWS access keys in Azure. Onboarding creates the trust relationship and IAM roles Defender assumes. GCP onboarding similarly establishes a controlled access path (service account / organization-level patterns per current docs) without embedding permanent user passwords.
Exam-friendly takeaway: Prefer native connectors with federated authentication; do not design permanent shared secrets as the primary multicloud security architecture.
Onboarding outline (AWS example)
- Prerequisites: Azure subscription with Defender for Cloud, AWS account access, sufficient Azure RBAC (often Contributor on the target subscription; Owner for some autoprovisioning scenarios).
- Environment settings → Add environment → Amazon Web Services.
- Choose single account or management account (management account can auto-discover member accounts).
- Select regions, subscription/resource group for the connector resource, scan interval.
- Select plans to enable on the connector (CSPM-related posture, Servers, Containers, databases, etc.).
- Deploy the provided CloudFormation (or equivalent) template in AWS to create roles/policies.
- Validate connector health, inventory population, and recommendations.
GCP onboarding follows the same conceptual pattern: add environment, configure project/organization scope, select plans, deploy the Google-side resources Microsoft specifies, validate.
Notes that show up in real deployments (and can appear as distractors):
- AWS connector availability may differ on national cloud Azure environments—do not assume feature parity with commercial Azure.
- If an AWS account is already connected to Microsoft Sentinel in conflicting ways, Microsoft documents special guidance—connectors can interact; follow current Learn articles when both products must share an account.
- Inventory and recommendations can lag hours after first connect; missing resources are often permissions, region scope, or plan selection issues rather than “Defender is broken.”
CSPM vs CWPP coverage on multicloud
| Capability | After AWS/GCP connector | Extra dependencies |
|---|---|---|
| CSPM assessments, many recommendations, Secure Score contribution | Agentless assessment once connector is healthy | Correct IAM permissions for discovery |
| Defender for Servers full CWPP | Plan enabled on connector/subscription | Azure Arc on machines; often SSM (AWS) or OS config agents (GCP) for Arc autoprovision; MDE and VA components as required |
| Defender for Containers | Plan enabled | Arc for clusters where required; Defender sensor, policy add-ons, audit log collection per design |
| SQL on machines | Plan enabled | Arc + discovery/registration components |
Critical distinction for SC-500:
- CSPM multicloud ≈ connect account/project → agentless posture.
- CWPP multicloud servers ≈ connect and Arc-enable machines and enable Servers plan and required extensions.
If a question says “recommendations appear for AWS S3 misconfigurations but EC2 has no EDR,” the likely gap is Servers plan / Arc / MDE, not the absence of a connector entirely.
Hybrid coverage with Azure Arc
Azure Arc-enabled servers project on-premises or other-cloud machines into Azure Resource Manager as first-class resources. Defender for Cloud then treats them more like Azure machines for plan deployment:
- Autoprovision monitoring/security extensions
- Apply Defender for Servers protections
- Include hybrid assets in inventory and recommendations
Networking prerequisites for Arc (outbound connectivity to Azure endpoints) must be met. Machines that disappear or stay Disconnected/Expired are cleaned up from the Defender view after Microsoft’s retention window so inventory stays accurate.
Scenario: A factory runs Windows servers on-premises. You install Arc, enable Defender for Servers on the hosting subscription, confirm MDE onboarding, and vulnerability findings flow into Defender for Cloud. CSPM alone would not deliver the same endpoint detection depth.
Designing coverage differences deliberately
Use this decision table when exam cases describe incomplete protection:
| Symptom | Likely missing piece |
|---|---|
| No multicloud resources in inventory | Connector not created, wrong account/project, insufficient IAM, region not selected |
| Inventory exists, weak Secure Score, no advanced attack paths | Defender CSPM plan not enabled |
| VMs lack EDR/VA depth | Defender for Servers not enabled or Arc/MDE missing on multicloud/hybrid |
| Kubernetes runtime gaps | Defender for Containers + sensor/audit configuration |
| Storage malware not scanned | Defender for Storage plan/settings (malware feature) not configured |
| Key Vault anomalous access not detected | Defender for Key Vault plan off |
Exam traps checklist
| Trap | Reality |
|---|---|
| “Connector alone equals full multicloud EDR” | Connector + CSPM ≠ Servers CWPP without Arc/MDE/plans |
| “All plans are free with Foundational CSPM” | CWPP plans and Defender CSPM are separate enablement/billing decisions |
| “Store long-lived AWS keys in Key Vault as the recommended connector design” | Native federated connectors are the supported pattern |
| “Hybrid servers cannot use Defender for Servers” | Arc onboarding is the bridge |
| “CSPM requires agents on every EC2 for recommendations” | CSPM is agentless after successful connector onboarding |
Enable the right CWPP plans for each workload, connect AWS/GCP with native federated connectors, extend hybrid via Arc, and always separate agentless CSPM coverage from plan-and-agent/extension CWPP coverage when diagnosing gaps.
An organization connects an AWS account to Defender for Cloud and immediately sees posture recommendations for cloud resources, but EC2 instances show no Defender for Endpoint-style EDR protection. What is the best explanation?
Which authentication approach does Microsoft emphasize for the native AWS connector in Defender for Cloud?
Where do you primarily enable Defender for Cloud workload protection plans for an Azure subscription?
A factory needs Defender for Servers protections on on-premises Windows machines. What onboarding bridge does Microsoft use so those machines appear as manageable resources for Defender for Cloud plans?