Unit 5 — Posture, Governance, Compliance & Multicloud

Unit 5 — Posture, Governance, Compliance & Multicloud (Azure Policy, Defender for Cloud, Secure Score, Arc, Purview/Priva)

Unit 5 of 8. Medium-depth worked examples: High-ROI · Unit 5 · Quick reference: 01-Cheat-Sheet · Dates, control-weights & glossary: 99-Appendix

Prerequisites (the workloads this unit governs): 02-secure-networking · 03-data-storage-keyvault · 04-secure-compute-containers

The defining pattern: AZ-500 turns the posture knobs (enable plans, write policies, remediate recommendations); SC-100 decides which knobs must exist and why (CSPM/CWPP architecture, multicloud/Arc integration, regulatory translation, exposure-driven prioritization).

This is AZ-500’s single largest domain (part of the ~30–35% Defender/Sentinel slice) and the posture backbone SC-100 builds its multicloud CSPM, Azure Arc, Security Exposure Management and regulatory-compliance design onto. It deliberately sits after the workloads it observes: you cannot assess the posture of a VM, storage account, or AKS cluster that does not yet exist. Two engines anchor everything here — Azure Policy (the enforcement/assessment substrate) and Microsoft Defender for Cloud (CSPM posture + CWPP workload protection) — with Azure Arc extending both to hybrid/multicloud, Security Exposure Management (MSEM) prioritizing by attack path, and Purview/Priva rolling it up into compliance and privacy governance.

Part A — Azure Policy (the governance substrate)

Azure Policy is the engine that evaluates resources against rules and acts on them. It is distinct from Azure RBAC: RBAC controls who can do an action; Policy controls what configuration state is allowed, regardless of who. Even an Owner is blocked from creating a non-compliant resource by a deny policy. The two compose to give full governance.

A.1 Objects: definition → initiative → assignment → scope

• Policy definition — a single rule in JSON: an if condition (a logical evaluation over resource fields/aliases) and a single effect. Built-in (e.g. “Allowed locations” with a deny effect) or custom.
• Initiative (policy set) — a group of policy definitions assigned and tracked together to serve one compliance goal. Every regulatory standard in Defender for Cloud is implemented as an initiative, and MCSB is the default built-in initiative. Assign the initiative once instead of dozens of policies.
• Assignment — binds a definition or initiative to a scope (management group → subscription → resource group), inheriting downward. Supports exclusions (carve out a child scope) and parameters (reuse one definition with different values — e.g. parameterize the effect so one definition is audit in dev and deny in prod).

A.2 Effects and evaluation order

Order of evaluation: disabled → append / modify → deny → audit → manual → auditIfNotExists → deployIfNotExists → denyAction. (Effect basics — order of evaluation)

Interchangeability guidance (useful for elimination on the exam): audit/deny/modify are often interchangeable for a “report vs block vs fix” choice; auditIfNotExists/deployIfNotExists are often interchangeable; manual and disabled are special cases.

A.3 Remediation & identity

• DINE and modify need a managed identity (system- or user-assigned) on the assignment. The MI must hold a role sufficient to create/update the targets (e.g. Contributor). Forgetting the role grant is why remediation silently fails.
• New/updated resources matching a DINE/modify assignment are remediated automatically; existing non-compliant resources require an explicit remediation task, which deploys the template/operations across selected resources (with failure thresholds and parallel-deployment counts). Azure deletes remediation-task resources 60 days after last modification. (Remediation structure)
• RBAC for Policy: Resource Policy Contributor covers most Policy operations; User Access Administrator is needed to assign a DINE/modify policy because the assignment grants the MI a role; plain Contributor can trigger remediation but cannot create definitions or assignments. (Policy overview — getting started)

A.4 Safe deployment

Best practice: assign new enforcement policies as audit (or auditIfNotExists) first, observe the impact on the compliance dashboard, then graduate to deny/DINE using resource selectors and effect overrides, rolling out tier-by-tier (region by region). This prevents an enforcement policy from breaking existing automation. (Policy overview)

Part B — Defender for Cloud: CSPM & Secure Score

Microsoft Defender for Cloud splits cleanly into two halves you must never conflate:

• CSPM (posture) — Are my resources configured securely? Recommendations, secure score, asset inventory, attack paths. Foundational tier is free; a paid Defender CSPM plan adds advanced posture.
• CWPP (workload protection) — Is this running resource under attack? Per-resource-type Defender plans (Servers, Databases, Storage, …) generating runtime threat alerts. (Part C.)

B.1 CSPM tiers — Foundational (free) vs Defender CSPM (paid)

Enabling Defender for Cloud on a subscription automatically turns on Foundational CSPM at no cost.

B.2 MCSB — the default benchmark

The Microsoft cloud security benchmark (MCSB) is auto-assigned on enabling Defender for Cloud and begins assessing in-scope resources immediately — it is the basis for the (classic) secure score, and only built-in MCSB recommendations affect that score. MCSB is a prescriptive, cloud-agnostic control set (Azure + AWS + GCP) mapped to CIS, NIST SP 800-53 and PCI-DSS. MCSB v2 (preview) introduces an Artificial Intelligence Security domain with seven recommendations and over 420 Azure Policy built-in definitions; enable it from the Regulatory Compliance dashboard. (MCSB introduction)

B.3 Secure Score — two distinct models (the #1 distractor)

There are two secure scores, and exam questions hinge on telling them apart.

Classic Secure Score (Azure portal):

• Aggregates findings into a percentage of a maximum. Recalculated every 8 hours per subscription and per AWS/GCP cloud connector. (Secure score calculation)
• Recommendations are grouped into security controls; a control awards points only when all of its recommendations are healthy for all resources. Partial fixes inside a control don’t move the needle.
• Equation: score per resource = max score / (healthy + unhealthy); current score = score per resource × healthy resources. Example: control max 6, 78 resources, 4 healthy → 6/78 × 4 = 0.31. (Score calculation equations)
• Only built-in MCSB recommendations affect the score; recommendations flagged Preview are excluded; risk prioritization does not affect the classic score. (Secure score & security controls)

Classic control weights (high-yield — memorize the top tier):

(Secure score controls table)

Cloud Secure Score / risk-based (Defender portal):

• Range 0–100. Calculated from open recommendations weighted by recommendation risk level × asset risk factors (internet exposure, data sensitivity) × asset criticality (likelihood and impact). Enables smarter prioritization — fixing a high-risk recommendation on an internet-facing, business-critical VM moves the score more than fixing a low-risk one on an isolated dev box. (Cloud secure score formula)
• A different model from the classic score — distinct calculation and values. Never average or equate them. It sits within the unified Microsoft Secure Score experience (note the family: Microsoft Secure Score for identity/Entra; Exposure/Device score for Defender for Endpoint; Cloud Secure Score for Defender for Cloud/multicloud).

Improving the score: Fix (bulk remediation), Enforce (auto-deploy a policy on non-compliant new resources), Deny (block non-compliant new resources). (Improve a secure score)

B.4 Inventory & asset management

The asset inventory is the single searchable view of all monitored resources (Azure + Arc + AWS/GCP), filterable/sortable, with software inventory (via MDVM). It is the backbone of “implement security controls for asset management” and of governance rules (Defender CSPM) that assign remediation owners and due dates so posture work is tracked like a ticket.

Part C — CWPP: workload protection plans

Enable per-plan under Environment settings → Defender plans. The plan set: Servers, Databases, Storage, Containers, App Service, Key Vault, Resource Manager, APIs (plus legacy DNS). Alerts surface in Defender for Cloud and export to Microsoft Sentinel (SecOps unit). This unit configures Servers, Databases, Storage in depth; Containers is taught in 04-secure-compute-containers and Key Vault config in 03-data-storage-keyvault.

C.1 Defender for Servers — Plan 1 vs Plan 2

Defender for Servers protects Windows/Linux machines across Azure, AWS, GCP and on-prem. It no longer uses the Log Analytics agent or Azure Monitor Agent for most features — agentless machine scanning and the Defender for Endpoint integration replace those agents. (Defender for Servers overview)

(Select a Defender for Servers plan)

• Agentless scanning takes a point-in-time snapshot of the VM disk and scans it out-of-band — no installed agent, no network connectivity required, no performance impact, but not real-time (refreshes periodically). It is on by default when Defender for Servers Plan 2 or the Defender CSPM plan is enabled. (Agentless data collection)
• Agentless VA = Plan 2 only; agent-based VA (via the Defender for Endpoint sensor) is available in Plan 1 and Plan 2. (Auto-deploy VA) Agentless malware scanning is Plan 2 with agentless scanning enabled. (Agentless malware scanning)
• MDVM (Microsoft Defender Vulnerability Management) is the integrated scanning engine, enabled by default when Defender for Servers is enabled. BYOL (Qualys/Rapid7) remains an option. Permissions: Owner at the resource-group level to deploy the scanner; Security Reader to view findings. (Deploy MDVM)

C.2 Defender for Databases

Family covering: Azure SQL Database, SQL Servers on machines (Azure VM or Arc-enabled, including AWS/GCP), open-source relational DBs (MySQL/PostgreSQL/MariaDB), and Azure Cosmos DB. Provides vulnerability assessment (SQL) and threat protection (SQL injection, anomalous access, brute force). SQL-on-machines requires the Arc agent plus AMA and auto-discovery/registration; on-premises and multicloud SQL servers must be onboarded as Azure Arc-enabled VMs, and deploying the plan needs Subscription Owner. (Defender for SQL on machines) The data-protection design for these stores lives in 03-data-storage-keyvault.

C.3 Defender for Storage

Protects storage accounts with malware scanning (Defender Antivirus, on-upload, an add-on), sensitive data threat detection, and activity/anomaly alerts (unusual access, data-exfiltration patterns). Agentless — no resource logs required. Enable per-subscription (recommended — auto-covers new accounts) or per-storage-account.

Part D — Multicloud & hybrid (AWS, GCP, Azure Arc)

D.1 Connectors

Add via Environment settings → Add environment. AWS uses a CloudFormation template; GCP uses a Terraform/gcloud script. Connectors deliver CSPM recommendations and can enable CWPP plans (Servers, Containers, SQL) on AWS/GCP. They auto-provision the Azure Arc agent (via AWS SSM / GCP OS-config agent) so the workloads become Azure resources. (Onboard AWS · Onboard GCP)

D.2 Azure Arc — the hybrid keystone

Azure Arc-enabled servers install the Connected Machine agent, making a non-Azure/on-prem machine a first-class Azure resource with an Azure Resource Manager ID. Consequences:

• Azure Policy (including machine configuration / guest config) applies.
• Defender for Cloud assesses it and protects it with Defender for Servers.
• MDVM scans it; it appears in Inventory and contributes to the secure score.

On-premises (and Azure VMware Solution) machines onboard directly as Arc; AWS/GCP machines onboard automatically through the connectors. (On-prem machines can alternatively onboard directly via the MDE agent, but Arc is recommended for full functionality — some premium P2 features beyond P1 depend on it.) Once connected to a subscription with Defender for Servers enabled, an Arc machine appears in Defender for Cloud like any other Azure resource. (Onboard machines · Azure Arc overview)

D.3 Default standards & freshness

• Azure subscriptions → MCSB.
• AWS accounts → AWS Foundational Security Best Practices (CIS, PCI-DSS also available).
• GCP projects → GCP Default (CIS, ISO 27001, NIST SP 800-53, PCI-DSS also available).
• AWS/GCP compliance monitoring freshness = every 4 hours. (Determine compliance requirements (multicloud))

Part E — Compliance, standards & translation

E.1 The Regulatory Compliance dashboard

Manage compliance standards for Azure/AWS/GCP. Standards are Azure Policy initiatives evaluated continuously; the dashboard shows % passing controls per control with drill-down to the failing resources and remediation guidance. Assigning a standard needs Owner or Policy Contributor. (Assign regulatory compliance standards)

E.2 Adding & customizing standards

• Add built-in standards (PCI DSS v4, ISO 27001, NIST SP 800-53, SOC 2, CIS, FedRAMP, regional frameworks): requires at least one paid plan — specifically, onboard any Defender plan except Defender for Servers Plan 1 or Defender for API Plan 1 — plus Owner or Policy Contributor. A standard with no in-scope assessed resources won’t display. Assign at the highest applicable scope (MG / AWS management account / GCP org) to aggregate. (Regulatory compliance dashboard)
• Custom standards & custom recommendations (KQL assessment logic) require the Defender CSPM plan. A custom recommendation lives in a custom standard, surfaces alongside built-ins, and contributes to posture. (Security policy concept)

E.3 Translating compliance into controls (SC-100)

The SC-100 design skill “translate compliance requirements into security controls” is the human side of E.1 — turn a regulatory clause into concrete Microsoft controls and a validation method:

1. Map the requirement to a benchmark control (the MCSB → CIS/NIST/PCI cross-walk does most of this for you).
2. Select the implementing control — e.g. “encrypt data at rest with customer keys” → CMK + Disk Encryption Set / TDE BYOK (from 03-data-storage-keyvault); “MFA for admins” → Conditional Access (from 01-identity-access-foundations).
3. Enforce via an Azure Policy initiative (audit/deny/DINE).
4. Validate continuously via the Regulatory Compliance dashboard + secure score, and evidence it via compliance reports and Purview Compliance Manager improvement actions.

E.4 Purview & Priva — the SC-100-only governance layer

Microsoft Purview Compliance Manager — the centerpiece for “design a solution to address compliance requirements using Microsoft Purview”:

• A risk-based compliance score rolled up from improvement actions — discrete, assignable tasks (with test status, evidence upload, and owner) mapped to controls.
• Prebuilt assessment templates for industry and regional standards (GDPR, HIPAA, ISO 27001, NIST, SOC 2, regional laws), each decomposing a regulation into Microsoft-managed controls (evidenced for you) and customer-managed controls (your tasks). (Purview service description — Compliance Manager)
• Defender for Cloud compliance data flows automatically into Compliance Manager, including standards monitoring AWS and GCP — one compliance view across the digital estate. (Regulatory compliance dashboard)

The division of labor: Defender for Cloud validates the technical posture of Azure/multicloud resources; Compliance Manager governs the broader organizational/M365 compliance program (including non-technical controls). A complete SC-100 compliance design usually names both.

Microsoft Priva — the privacy-operations suite for “design a solution to address privacy requirements, including Microsoft Priva”:

• Privacy Risk Management — customizable policies that detect privacy risks: data overexposure, risky data transfers, and data minimization / over-retention, with admin/data-owner alerting and remediation. The core “reduce privacy risk” control.
• Subject Rights Requests (SRR) — automate and scale DSR/DSAR fulfillment: find a data subject’s personal data across Exchange, SharePoint, OneDrive and Teams (and beyond M365), review, redact, and produce — with a repeatable workflow.
• Consent Management — capture and honor user consent preferences across platforms.
• Tracker Scanning — detect and categorize website tracking technologies (cookie/consent compliance).
• Privacy Assessments (preview) — automate documentation of how personal data is used across business processes.

Priva integrates with Compliance Manager — completing a Priva action (e.g. setting up a Privacy Risk Management policy) can earn points toward Compliance Manager assessment completion and the compliance score — and complements Purview DLP. (Priva data privacy solutions · How Priva works with Purview)

Part F — DevOps Security (code-to-cloud)

Defender for Cloud DevOps Security connects GitHub, Azure DevOps, and GitLab for unified posture across repos, pipelines, IaC and container images. Available in Foundational CSPM (free) and Defender CSPM. (DevOps posture management overview)

• DevOps posture management scanners (Azure DevOps / GitHub) run every 24 hours across builds, secure files, variable groups, service connections, organizations, repositories — finding misconfigurations and weak access controls.
• Agentless code scanning (preview): no pipeline changes — the connector scans code, dependencies (SBOM) and IaC. Posture re-assessed every 8 hours; code/IaC scanned daily; scans typically finish in 15–60 minutes in the connector’s geo. Scope by org/project/repo with include/exclude and auto-discovery of new repos. (Agentless code scanning)
• In-pipeline scanning via the Microsoft Security DevOps (MSDO) GitHub Action / Azure DevOps extension (categories: 'IaC' for IaC), or the Defender for Cloud CLI for build-time gating.
• Findings produce DevOps security recommendations (enable secret scanning, code scanning, Dependabot, etc.) and use code-to-cloud contextualization to prioritize vulnerabilities actually reachable in production. Setup needs Project Collection Admin + Subscription Contributor; viewing needs Security Admin/Reader.

Part G — External Attack Surface Management (EASM)

Microsoft Defender EASM gives an outside-in (attacker’s) view of internet-facing infrastructure. Microsoft’s proprietary recursive discovery starts from discovery seeds — domains, IP address blocks, hosts, email contacts, ASNs, WHOIS organizations — and follows WHOIS/DNS/SSL/ASN connections outward to uncover unknown assets (domains, hosts, IP blocks, pages, SSL certs, WHOIS contacts) — shadow IT and forgotten subsidiaries you didn’t know you owned. (EASM overview)

• Discovery groups organize seed clusters on recurrence schedules; a Quick Start offers prebuilt attack surfaces by org name.
• Inventory distinguishes confirmed inventory vs candidate assets (“Requires Investigation”). Dashboards surface vulnerabilities, compliance and hygiene risks.
• EASM is a separate Azure resource, billed independently (priced on inventory size), distinct from the internal Defender for Cloud Inventory and from CWPP runtime protection. It integrates as an MSEM EASM initiative.

Part H — Security Exposure Management (MSEM) — SC-100 only

Microsoft Security Exposure Management (Defender portal, GA November 2024) implements Gartner’s Continuous Threat Exposure Management (CTEM), unifying posture across endpoints, identities, cloud (Azure/AWS/GCP via Defender for Cloud) and external surface (EASM) into one enterprise exposure graph. Not available in US Government clouds (GCC, GCC High, DoD). (Security Exposure Management · What’s new — Nov 2024) It supplies the SC-100 objective “specify requirements and priorities for a posture management process that uses attack paths, attack surface reduction, security insights, and initiatives.”

Core constructs (SC-100 names these explicitly):

• Attack paths — simulated end-to-end chains from an entry point to a critical asset, including hybrid on-prem→cloud paths and DACL-based permission paths. Attack-path value depends on defining critical assets and licensing the relevant workloads. (Attack paths overview)
• Choke points — nodes where many attack paths converge — the highest-leverage remediation targets (fix-once, break-many).
• Attack surface map + enterprise exposure graph — visual and KQL-queryable graph of assets and relationships across all environments; supports blast-radius and entry-point/target analysis.
• Critical asset management — predefined + custom classification rules tag “crown-jewel” resources so prioritization focuses there.
• Security initiatives — workload initiatives (endpoint/identity/cloud), horizontal threat initiatives (e.g. ransomware protection, BEC), threat analytics initiatives, a Zero Trust initiative, and the EASM initiative — each tracking exposure metrics over time with recommendations and events. (Exposure insights — security initiatives)
• Exposure insights aggregate posture data to prioritize.

The AZ-500 (operate) ↔ SC-100 (architect) relationship — the unit at a glance

The pattern to carry into the exam: AZ-500 asks “which switch/effect/plan, and where do I flip it”; SC-100 asks “given this requirement (regulation, multicloud estate, privacy law, attacker exposure), which combination is the right architecture, and how do I prove it works.”

Gotchas & exam tells

Authoritative references

Consolidated, deduplicated list also lives in Appendix · section C.

• Azure Policy overview
• Azure Policy effects & order of evaluation
• Remediate non-compliant resources (remediation structure)
• Secure score & security controls in Defender for Cloud
• Defender for Servers overview
• Select a Defender for Servers plan
• Agentless machine scanning
• Auto-deploy vulnerability assessment
• Agentless malware scanning
• Deploy MDVM
• Microsoft cloud security benchmark introduction
• Security policy & recommendations concept
• Assign regulatory compliance standards
• Regulatory compliance dashboard
• Regulatory compliance FAQ
• Determine compliance requirements (multicloud)
• Connect AWS accounts to Defender for Cloud
• Connect GCP projects to Defender for Cloud
• Onboard machines to Defender for Cloud (Arc)
• Azure Arc overview
• Defender for SQL Servers on machines
• DevOps posture management overview
• Agentless code scanning
• Defender EASM overview
• What is Microsoft Security Exposure Management?
• MSEM attack paths overview
• MSEM exposure insights & initiatives
• Microsoft Purview service description — Compliance Manager
• Priva data privacy solutions (learning path)
• How Priva works with Microsoft Purview
• AZ-500 study guide
• SC-100 study guide

Navigation: ← Prev 04-secure-compute-containers · Next → 06-secops-siem-xdr-soar · Index 00-Strategy-and-Map · Appendix 99-Appendix