Recommend a Solution for Managing Compliance — Lesson

Compliance in Azure is not a one-time project — it is a continuously enforced design constraint. This lesson walks you through the architect's toolbox for answering a single exam-style question: "Contoso must comply with ISO 27001 across all production subscriptions. What do you recommend?" You will learn to compose Azure Policy, Microsoft Defender for Cloud, management groups, Deployment Stacks, and Template Specs into a design that auto-enforces, audits, and reports on compliance without relying on human vigilance.

Why This Matters

Every architecture decision you make on AZ-305 is evaluated against five Well-Architected pillars, and Security sits at the top of the list for a reason — one non-compliant storage account can land an entire organization on the front page of a breach report. Regulators do not care that you intended to deploy encryption; they care whether the control was enforced on day one and continuously after. Designing a compliance solution means choosing mechanisms that shift security from a detect-and-apologise posture to a prevent-and-prove posture — and the exam will expect you to pick the right mechanism for each requirement. This LO threads together three of the most heavily tested services on AZ-305: Azure Policy, Defender for Cloud's Regulatory Compliance dashboard, and the landing-zone patterns that stitch them together into a governance fabric. If you can hold those three in one mental model, the compliance questions on the exam become almost mechanical.

Prerequisites

• Azure resource hierarchy (tenant root → management groups → subscriptions → resource groups → resources). Self-check: At which scope does a policy assignment inherit downward, and can a child scope override it?
• Role-Based Access Control (RBAC) basics from LO6. Self-check: Which RBAC role is required to author a policy definition at a management group?
• ARM/Bicep resource model. Self-check: Which resource type represents a policy assignment in ARM?
• Regulatory framework familiarity (ISO 27001, NIST 800-53, PCI DSS, HIPAA, CIS). Self-check: Which of those is industry-agnostic versus domain-specific?
• Defender for Cloud plans and Secure Score (touched on in LO9). Self-check: What is the difference between a "foundational" (free) recommendation and a Defender-plan recommendation?

Learning Objectives

By the end of this lesson you will be able to:

1. Analyse a regulatory requirement and map it to the correct Azure Policy effect (Audit, Deny, Modify, DeployIfNotExists, etc.).
2. Design a management-group-scoped initiative hierarchy that satisfies enterprise-scale governance without drift.
3. Evaluate when to use Azure Policy alone versus Deployment Stacks, Template Specs, or an Azure Landing Zone accelerator.
4. Recommend a continuous-compliance monitoring pattern using Defender for Cloud's Regulatory Compliance dashboard.
5. Design exemption workflows that let you meet regulatory deadlines while tolerating temporary non-compliance.
6. Compose a SIEM-integrated compliance pipeline that satisfies both the CISO and the external auditor.

Building Blocks

• Azure Policy — Analogy: a border guard stationed at every PUT/PATCH request to Azure Resource Manager. Formal: a declarative engine that evaluates resource properties against conditions and applies effects (Audit/Deny/Modify/etc.) either synchronously (Deny) or asynchronously (DeployIfNotExists). Why it matters: it is the only Azure-native mechanism that prevents non-compliant resources from being created in the first place.

• Policy Definition — Analogy: a single traffic law (e.g., "speed limit 60 km/h"). Formal: a JSON document describing a policyRule (if/then) and parameters. Built-in definitions ship with Azure; custom definitions live at the tenant, MG, or subscription scope. Why it matters: granularity — one definition equals one rule equals one control you can toggle independently.

• Initiative (Policy Set) — Analogy: the Highway Code — a bundle of related laws. Formal: a grouping of policy definitions under a single assignable unit, often mapped to a regulatory framework (e.g., ISO 27001:2013). Why it matters: you assign one initiative, not fifty individual policies, and the Regulatory Compliance dashboard keys off the initiative-to-control-domain mapping.

• Policy Assignment — Analogy: posting the law at a specific junction. Formal: the binding of a definition or initiative to a scope (MG/subscription/RG), optionally with parameter values, exclusions, and an identity for remediation. Why it matters: scope and parameters are where one-size-fits-all policy becomes tenant-specific governance.

• Management Group (MG) — Analogy: a filing cabinet of subscriptions. Formal: a container above the subscription level used for organising policy and RBAC inheritance. A tenant has a single Tenant Root MG and up to six levels of nesting. Why it matters: policy assigned at an MG inherits to every child — this is how you govern hundreds of subscriptions from one place.

• Azure Blueprint — Analogy: a factory stamp that imprints ARM templates, RBAC assignments, and policy assignments at subscription creation time. Formal: an artefact bundle (RG templates + policy + RBAC + ARM) versioned and assigned to a subscription. Why it matters: historically the recommended "landing zone in a box" pattern, now being deprecated — Microsoft has announced retirement and recommends migrating to Template Specs + Policy + Deployment Stacks. Still appears on AZ-305.

• Microsoft Defender for Cloud — Analogy: the CCTV room watching every camera across the estate. Formal: a CSPM + CWPP platform combining agentless posture management with agent-based workload protection. Its Regulatory Compliance blade cross-references your environment against initiatives like ISO 27001:2013 and reports per-control status. Why it matters: this is where leadership sees a single score; architects who cannot design for the compliance dashboard will get called into uncomfortable meetings.

• Azure Landing Zone (ALZ) — Analogy: a pre-fabricated neighbourhood with roads, sewers, and zoning laws already in place. Formal: a Microsoft reference implementation combining management-group topology, policy initiatives, subscription vending, and network hub-and-spoke, delivered via the ALZ Accelerator (Bicep or Terraform). Why it matters: the current Microsoft guidance for enterprise-scale governance — the exam expects you to know ALZ is the successor pattern to Blueprints.

• Policy Exemption — Analogy: a formal waiver card you hand the border guard. Formal: a declarative JSON object (Microsoft.Authorization/policyExemptions) attached to a resource/RG/subscription that temporarily or permanently excludes it from policy evaluation, with a category of Waiver or Mitigated. Why it matters: auditors want to see the documented exception, not a disabled policy.

• Microsoft Cloud Security Benchmark (MCSB) — Analogy: the opinionated default security kit every new Azure tenant gets. Formal: Microsoft's own control framework, assigned automatically by Defender for Cloud at Tenant Root. It maps to NIST, CIS, and PCI. Why it matters: the exam treats MCSB as the baseline you add everything else on top of — not an alternative to regulatory frameworks.

Deep Dive

1. Policy Effects — the Verbs of Governance

Choosing the right effect is the single most tested decision on this LO. Each effect behaves differently in the ARM request pipeline and has different RBAC and identity implications.

[!TIP] Deny fires before the resource is written to ARM's database, so a denied resource never exists — no cleanup required. DeployIfNotExists, by contrast, runs after creation, which means there is a measurable window where a non-compliant resource is live. Exam-wise, if the scenario says "must prevent", you want Deny. If it says "must ensure" with an implementation detail, you are usually looking at DeployIfNotExists.

[!WARNING] Modify and DeployIfNotExists assignments require a user-assigned or system-assigned managed identity with the correct permissions at the target scope. Forgetting to grant the identity the appropriate role (typically Contributor or a tightly-scoped built-in role) causes remediation to silently fail — the dashboard shows the resource as non-compliant with a vague error.

2. Initiatives and Regulatory Mapping

Azure ships built-in initiatives that map one-to-one to major frameworks. The pattern you are expected to know:

The policyDefinitionGroups array is the magic — this is what Defender for Cloud reads to render the per-control compliance view. When you create a custom initiative for an industry-specific framework (say, the UK's Cyber Essentials), you provide your own groups and Defender will render them verbatim.

3. Scope Strategy — Management Groups and Inheritance

Policy assignments inherit downward and can be overridden only by exclusion or exemption, never by a child policy "winning" — all matching assignments are evaluated and the most restrictive effect applies (Deny beats Audit).

The Enterprise-Scale / ALZ MG topology you are expected to recognise:

[!IMPORTANT] Attach baseline initiatives (MCSB, Deny public IPs on VM NICs) at Tenant Root or Platform. Attach industry-specific initiatives (e.g., SWIFT CSP) only to the MG that contains the in-scope subscriptions — over-scoping a sensitive initiative creates noise on the dashboard and wastes engineering cycles on exemptions.

4. Defender for Cloud — the Continuous-Compliance Loop

Defender for Cloud's Regulatory Compliance dashboard reads the assigned initiatives on the selected scope and renders:

• Compliance score — percentage of passing controls weighted by criticality.
• Control family rollups — clickable drilldown into each control with evidence.
• Exportable PDF/CSV reports — what auditors actually consume.
• Continuous export to Log Analytics / Event Hubs / Storage for SIEM integration.

[!NOTE] The Microsoft Cloud Security Benchmark (MCSB) is assigned by default at the root when you enable Defender for Cloud. You do not need to manually assign it — but you do need to be aware it exists so you do not double-count baseline controls.

5. Policy, Deployment Stacks, and Landing Zones — Choosing the Pattern

This is the most nuanced decision on the LO. Use the table below as your on-exam flow.

[!WARNING] Azure Blueprints is deprecated. Microsoft announced retirement and recommends Template Specs + Deployment Stacks + Azure Policy for new designs. On AZ-305 you should still recognise Blueprints when the scenario explicitly names them, but your recommendation for new work should be ALZ or Template Specs unless the customer has existing Blueprint investment.

Worked Examples

Example 1 (Easy) — Deny Public Blob Containers

Problem: Contoso's security team has mandated that no storage account in the Prod MG may allow public (anonymous) blob access. You need to enforce this prevention, not just audit, and existing storage accounts that violate it must be flagged.

Step-by-step solution:

1. Use the built-in definition Storage accounts should prevent public access (definition ID 4fa4b6c0-31ca-4c0d-b10d-24b96f62a751).
2. Assign it at the Prod MG with the effect parameter set to Deny.
3. For existing drift, change the parameter to Audit temporarily, review the dashboard, remediate, then flip back to Deny.

[!NOTE] enforcementMode: 'DoNotEnforce' is the "dry-run" switch — the engine evaluates and reports but does not actually deny. It is the right switch for a change-management window, not for an audit-only control (use effect Audit for that).

Example 2 (Medium) — Tag Enforcement with Modify

Problem: Finance needs every resource tagged with CostCentre=<value> and will not accept Deny because it would block emergency hotfixes. Any missing tag must be back-filled from the parent resource group automatically.

Step-by-step solution: Use the built-in Inherit a tag from the resource group if missing with effect Modify. This rewrites the incoming request to append the tag at create time and, via a remediation task, back-fills existing resources.

Then grant the assignment's managed identity the Tag Contributor role at MG scope, and trigger a remediation task.

[!NOTE] Modify requires a managed identity because remediating existing resources calls ARM as that identity. The identity must have permission to write the target property. For tags, Tag Contributor suffices; for httpsTrafficOnly on a storage account, you would need at least Storage Account Contributor.

Example 3 (Hard) — Multi-Region FSI Landing Zone

Problem: A global retail bank must host a new payments platform in Azure across West Europe and UK South. Requirements:

• SWIFT Customer Security Programme (CSP) must apply only to the payments subscription.
• ISO 27001:2013 must apply to the whole bank.
• PCI DSS v4.0 must apply to any subscription tagged pci=true.
• Architects must be able to exempt specific non-compliant legacy VMs for 90 days with auditor sign-off.
• Compliance state must flow into the bank's Splunk SIEM.

Step-by-step solution:

1. Deploy the Azure Landing Zones reference implementation to establish the MG topology.
2. At Tenant Root, assign ISO 27001:2013 and MCSB.
3. Create a new MG fsi-payments under Landing Zones/Corp; move the payments subscription under it; assign SWIFT CSP initiative there only.
4. Create a custom initiative wrapping PCI DSS v4.0 with an additional condition tags['pci'] == 'true' and assign it at Tenant Root — the condition limits real evaluation to tagged subscriptions.
5. Author exemptions as Microsoft.Authorization/policyExemptions resources in Bicep, with exemptionCategory: 'Waiver', expiresOn set to 90 days hence, and a metadata.approver field referencing the ticket system.
6. Enable continuous export from Defender for Cloud to an Event Hub, with a Splunk HEC connector subscribed to that hub.

[!TIP] Exemptions are audit artefacts — treat them as code. Store the Bicep in Git, require PR approval from the security team, and tag the exemption with the compensating-control ticket. Auditors love a provable paper trail.

Visual Explanations

Decision Tree: Picking the Right Effect

Caption: Start from the top; the first Yes wins. This mirrors the flow an architect uses in an exam question — identify the imperative verb ("prevent", "ensure", "report"), map it to an effect, and move on.

TikZ: Management-Group Policy Inheritance

Caption: The payments subscription inherits three initiatives from three different MG scopes. The design rule: attach each initiative at the highest scope where it applies, then exclude or exempt outliers — never the reverse.

Comparison Table: Policy vs Deployment Stacks vs ALZ vs Template Specs

Caption: Use Policy for guardrails, Deployment Stacks for lifecycle-managed resource deployments, ALZ for the enterprise operating model, and Template Specs for reusable versioned templates.

Common Mistakes

❌ Myth: Deny policies apply retroactively and will delete existing non-compliant resources.

✅ Reality: Deny evaluates on create/update only. Existing resources are shown as non-compliant but remain live until someone acts.

Why it is tricky: The word "deny" suggests aggressive action. In reality Azure never deletes your data — the dashboard just shames the resource. Use Modify or DeployIfNotExists with a remediation task when you need to fix drift.

❌ Myth: If I assign ISO 27001:2013 initiative, my environment is ISO 27001 compliant.

✅ Reality: The initiative audits Azure-specific technical controls that map to ISO 27001 clauses. ISO 27001 certification requires procedural, legal, and organizational controls that no tool can evaluate.

Why it is tricky: The dashboard percentage feels definitive. Architects who pitch it as "compliance" to stakeholders get burned when auditors ask about access reviews, supplier agreements, and BCP drills.

❌ Myth: A DeployIfNotExists policy will immediately remediate every non-compliant resource in the environment.

✅ Reality: DeployIfNotExists applies to new resources automatically; existing non-compliant resources require an explicit remediation task to be created and executed against the assignment.

Why it is tricky: The effect name suggests continuous action. In practice, DINE evaluates continuously for compliance state, but the remediation is a separate user-initiated operation (or an automated one via Policy Remediation).

❌ Myth: Exemptions and exclusions are the same thing.

✅ Reality: An exclusion is a scope filter on the assignment (e.g., "do not evaluate resource group X"). An exemption is a first-class tracked artefact with a reason, category (Waiver/Mitigated), and optional expiry, surfaced to auditors.

Why it is tricky: Both produce the same run-time outcome — the resource is skipped. But exemptions generate an audit trail; exclusions are silent. Always use exemptions for regulatory concessions.

Practice Exercises

🟢 Exercise 1 — Effect Selection

A new regulation requires you to guarantee that no SQL database is provisioned below Business Critical tier in the prod-finance subscription. Which effect do you choose and why?

▶💡 Hint

The word "guarantee" implies prevention, not detection.

▶✅ Solution

Deny — it evaluates synchronously at create time, preventing the non-conforming resource from ever existing. Audit would let it be created and only flag it post-facto, which violates the "guarantee" requirement.

🟢 Exercise 2 — Scope Placement

You need MCSB to apply to every subscription in the tenant, including any new ones added in the future. Where do you assign the initiative?

▶💡 Hint

Inheritance travels only downward. What is the highest scope?

▶✅ Solution

The Tenant Root Management Group. Any new subscription created in the tenant lands under this root by default, so it automatically inherits the assignment.

🟡 Exercise 3 — Identity and Remediation

You assign a DeployIfNotExists policy to enable diagnostic settings for Key Vaults. Two weeks later the Regulatory Compliance dashboard still shows 200 non-compliant Key Vaults. What are the two most likely causes?

▶💡 Hint

Think identity plus remediation task.

▶✅ Solution

(1) The assignment's managed identity lacks the RBAC role required at the target scope (typically Log Analytics Contributor + Monitoring Contributor). (2) No remediation task has been triggered for existing resources — DINE only auto-remediates new resources; the initial backlog requires a manual or automated remediation task.

🟡 Exercise 4 — Exemption Design

The finance team needs a 60-day window to bring three legacy SQL servers into compliance with a Deny TLS < 1.2 policy. How do you design the exemption?

▶💡 Hint

Waiver vs Mitigated. Think about what the auditor needs to see.

▶✅ Solution

Create three Microsoft.Authorization/policyExemptions resources — one per server — with exemptionCategory: 'Waiver', expiresOn set to 60 days hence, description explaining the legacy constraint, and metadata fields linking to the remediation ticket and the approver. Store the Bicep in Git so the change has a reviewable history.

🔴 Exercise 5 — Framework Composition

Contoso Healthcare must comply with HIPAA HITRUST in the US and ISO 27001 globally. A single workload is deployed across East US 2 (HIPAA scope) and North Europe (ISO-only scope). How do you design the assignments to avoid double-auditing resources that fall under both?

▶💡 Hint

Two MGs, targeted assignments.

▶✅ Solution

Split the workload into two subscriptions, each in a region-aligned MG (us-health, eu-health). Assign HIPAA HITRUST only to us-health and ISO 27001:2013 to both MGs. A common baseline (MCSB) lives at the parent. Overlap of controls is fine on the dashboard — they report independently — but the evaluation runs once per initiative per resource, so cost and noise are bounded.

🔴 Exercise 6 — Blueprint Migration

A customer has 30 subscriptions stamped from a single Blueprint that bundles four RG templates, two custom policy assignments, and three RBAC role assignments. Microsoft has deprecated Blueprints. Design the migration.

▶💡 Hint

Decompose the bundle into its component types and use the current replacement for each.

▶✅ Solution

(1) Convert the four RG templates to Bicep and publish them as a Template Spec at the MG scope. (2) Reassign the two custom policies at the MG scope using policyAssignments Bicep — they already existed as first-class policy, so this is a scope migration. (3) Move the RBAC assignments into a Bicep roleAssignments deployment at the MG. (4) Wrap the three in a Deployment Stack at the subscription scope to preserve the "stamped together" semantics Blueprints used to provide. (5) Remove the Blueprint assignment last, after verifying drift is zero.

🟡 Exercise 7 — Dashboard Gap

A CISO asks why CIS Microsoft Azure Foundations Benchmark shows 73% compliance but the internal security review shows only 60%. What is the likely cause?

▶💡 Hint

Initiative-to-environment mapping. What is in scope for each?

▶✅ Solution

The Defender for Cloud score reports on assessed resources only — resources in subscriptions where Defender is enabled and where the initiative is assigned. The internal review likely includes subscriptions outside the Defender scope or controls that Azure Policy cannot evaluate (e.g., physical access controls). The fix: align the assignment scope, enable Defender on all subscriptions, and reconcile the delta with Manual-effect controls for procedural items.

🔴 Exercise 8 — End-to-End Design

Design a compliance solution for a retail company with 200 subscriptions, a 99.95% uptime SLA, and a requirement to prove PCI DSS compliance monthly to an external auditor. Constraints: use managed services only, no custom scripts, budget for SIEM integration is $$2{,}500$ per month.

▶💡 Hint

Compose ALZ + Policy + Defender + continuous export.

▶✅ Solution

(1) ALZ Accelerator establishes the MG hierarchy and baseline. (2) Assign PCI DSS v4.0 initiative at a dedicated pci MG; move the $\sim 20$ in-scope subscriptions there. (3) Assign MCSB at Tenant Root. (4) Enable Defender for Cloud Plan 2 on all 200 subscriptions for continuous posture. (5) Configure continuous export of regulatory compliance data to an Event Hub, with a Logic App or Azure Monitor workbook producing the monthly PDF for the auditor. (6) A budget of $$2{,}500$/month is comfortable for a single Event Hub namespace plus Log Analytics retention of 90 days on PCI subs; the Defender plans are separate but required for the compliance score. (7) Lock the initiative assignment in a Deployment Stack with denySettings.mode: denyDelete so it cannot be accidentally unassigned.

Summary & Concept Map

• Effects are verbs: Deny prevents, Audit reports, Modify/Append rewrite, DeployIfNotExists remediates — pick based on the imperative in the requirement.
• Scope upward: assign at the highest MG where the policy applies; use exclusions or exemptions for outliers, never the reverse.
• Initiatives are dashboards: a framework-mapped initiative unlocks the Regulatory Compliance view in Defender for Cloud.
• Blueprints are deprecated: for new designs, recommend ALZ + Template Specs + Deployment Stacks.
• Exemptions are audit artefacts: treat them as code, with expiries and approver metadata.
• Identity is required for Modify and DeployIfNotExists — without the correct RBAC grant, remediation fails silently.
• Compliance is continuous: export Defender data to a SIEM; do not rely on humans checking a dashboard.

Caption: Every arrow is a decision point in an exam question — trace the path from the requirement to the mechanism, then to the evidence the auditor receives.