Unit 8 (Full) — Capstone: Zero Trust Strategy, MCRA/MCSB/CAF/WAF, Landing Zones, BCDR & Ransomware Resiliency

Unit 8 (Full) — Capstone: Zero Trust Strategy, MCRA/MCSB/CAF/WAF, Landing Zones, BCDR & Ransomware Resiliency

This is the synthesis capstone of the AZ-500 → SC-100 guide. The blueprint mapping is honest about one important thing: for this unit, az500: []. There is genuinely no AZ-500 operational analog for the framework/strategy layer. AZ-500 is an engineer exam — it tests whether you can configure an NSG, enable PIM, rotate a key, or turn on a Defender plan. SC-100 is an architect exam — it tests whether you can take all of those controls (taught across the prior seven units) and arrange them against a recognized framework, set priorities, and justify a strategy.

So for this unit the AZ-500 (operate) ↔ SC-100 (architect) relationship is not “the same topic at two depths.” It is: every concrete control you operated in AZ-500 becomes a building block you now compose. Throughout, prior units are referenced by Wikilink rather than re-taught, so the Full guides compose without duplication.

0. How to read this unit

This unit presupposes every concrete building block from the prior seven. Wherever a control appears, it is cited to its home unit rather than re-explained:

The mental model: prior units gave you the controls; this capstone gives you the strategy that arranges them.

1. The Microsoft security framework landscape

SC-100 expects you to treat five frameworks as a toolkit and select the right one for each design question. Confusing them is the single most common point loss in this domain.

1.1 MCRA — Microsoft Cybersecurity Reference Architectures

A continually updated set of reference architecture diagrams showing how Microsoft’s security capabilities map across the whole estate: identity & access, security operations (SOC), endpoint & device, hybrid/multicloud infrastructure, OT/IoT, information protection, and more. MCRA is descriptive and capability-oriented — it answers “which Microsoft technology addresses this part of the architecture, and how do the pieces fit together?” It explicitly incorporates Zero Trust principles, the MCSB, and an attack-chain / MITRE perspective. On the exam, “align with MCRA” signals: produce a design that names the right Microsoft capability for each domain and shows the integration.

1.2 MCSB — Microsoft cloud security benchmark

A prescriptive control framework — successor to the Azure Security Benchmark — organized into control families:

• NS Network Security · IM Identity Management · PA Privileged Access · DP Data Protection · AM Asset Management · LT Logging and Threat Detection · IR Incident Response · PV Posture and Vulnerability Management · ES Endpoint Security · BR Backup and Recovery · DS DevOps Security · GS Governance and Strategy.

Each control carries a security principle, the risk it mitigates, MITRE ATT&CK mapping, and multicloud implementation guidance (Azure, AWS, GCP). Critically for the operate↔architect bridge: MCSB is the default compliance standard in Microsoft Defender for Cloud, so the Secure Score you raised in 05-posture-governance-defender-cloud is literally a measure of MCSB adherence. “Align with MCSB” on the exam means: pick the prescriptive control and the measurable target.

1.3 CAF — Cloud Adoption Framework for Azure

The organization-wide adoption lifecycle: Strategy → Plan → Ready → Adopt → Govern → Secure → Manage. CAF is about the journey of the whole estate. Two methodologies matter most here:

• Ready → produces Azure landing zones (Section 4).
• Secure → a security methodology covering risk insights, resiliency, access control, security operations, asset protection, innovation security, and governance — aligned to Zero Trust and MCSB.

CAF also defines the DevSecOps guidance (Section 7) and the governance disciplines you implement with Azure Policy (cross-ref 05-posture-governance-defender-cloud).

1.4 WAF — Azure Well-Architected Framework

A single-workload quality framework built on five pillars:

1. Reliability — resilient, available, recoverable.
2. Security — as secure as the workload needs to be.
3. Cost Optimization — sufficient return on investment.
4. Operational Excellence — responsible dev/ops.
5. Performance Efficiency — accomplishes its purpose in acceptable time.

Each pillar offers principles, recommendations, and explicit tradeoffs (e.g., more reliability often costs more; tighter security can reduce performance). WAF evaluates one workload’s design quality.

1.5 Zero Trust — the model under everything

Three principles:

• Verify explicitly — authenticate and authorize on all available signals (identity, device health, location, risk).
• Use least-privilege access — JIT/JEA, risk-based adaptive policies, just-enough data access.
• Assume breach — minimize blast radius, segment, verify end-to-end encryption, use analytics for detection.

Microsoft’s Zero Trust deployment model defines seven technology pillars:

These pillars deliberately mirror the structure of this guide — each prior unit is “Zero Trust applied to one pillar,” and this capstone is where they unify.

2. Zero Trust adoption and the Rapid Modernization Plan (RaMP)

Objectives covered: SC-100 “Design solutions that align with best practices for Zero Trust security, including A Rapid Modernization Plan for Zero Trust (RaMP)“.

2.1 What RaMP is

The Rapid Modernization Plan (RaMP) is project-management guidance — a set of prioritized checklists that enumerate the technical objectives of each Zero Trust deployment area, document the steps, and name the owners in a sponsorship → program → project hierarchy (e.g., CISO/CIO sponsor → identity-security program lead → security architect advises → identity admin implements → governance monitors). Its explicit purpose is to identify quick wins and let leadership track measurable progress (often via Microsoft Secure Score and, more recently, the Zero Trust initiative in Microsoft Security Exposure Management).

RaMP is not a product and not a deep technical deployment guide — it sits between the aspirational strategy and the detailed deployment plans.

2.2 The two RaMPs (don’t conflate)

1. Zero Trust RaMP — checklists for securing user access and productivity (explicitly validate trust for all access requests), data / compliance / governance, and modernizing security operations.
2. Privileged access RAMP — a roadmap to adopt Microsoft’s privileged access strategy, structured as OKR-style initiatives (objective, why, who, how, key results), prioritizing stopping the accumulation of new risk first, then cleaning up legacy risk. Built on the enterprise access model (Section 3) + PAWs + PIM.

They are complementary, not the same checklist — and the exam may probe whether you know the difference.

2.3 The non-negotiable priority: secure privileged access first

Microsoft is unambiguous: securing privileged access is the top security priority because of the high potential business impact and the high likelihood of attackers compromising it. Human-operated ransomware repeatedly exploits weak privileged access to gain broad control quickly. Therefore, in any “where do we start?” SC-100 question about Zero Trust modernization or ransomware hardening, the lead answer is secure privileged access, then BCDR.

2.4 Staged adoption

Microsoft’s adoption model frames the work in four illustrative stages:

1. Identify risks/gaps, capture initial Exposure Management scores, set leadership expectations.
2. Build a response-readiness plan, inventory the digital estate, basic hygiene, capture Compliance Manager status.
3. Visualize posture via dashboards, manage shadow IT (Defender for Cloud Apps — see 07-apps-m365-strategy-capstone), establish a patching/updating methodology.
4. Continuously educate users, evolve SecOps, keep managing risk.

3. The enterprise access model and privileged access architecture

Objective alignment: feeds SC-100 “Design solutions that align with best practices for Zero Trust security” and the privileged-access priority in ransomware mitigation. The model is the SC-100 design layer over the AZ-500 controls you operated in 01-identity-access-foundations (PIM, Conditional Access, RBAC).

The enterprise access model supersedes the legacy AD administrative tier model (tier 0/1/2).

3.1 Planes

• Control plane — identity systems (Entra ID, AD DS), the components that grant access to everything else.
• Management plane — resource and subscription administration.
• Data / workload plane — the applications and data themselves.

The cardinal rule: enforce hierarchy so lower planes cannot control higher planes — preventing an attacker who compromises a workload from escalating to control of the directory.

3.2 The privileged access strategy components

• Dedicated admin identities (separate from daily-driver accounts), security groups for role assignment, and emergency break-glass accounts.
• Privileged Access Workstations (PAWs) — hardened, dedicated, security-baselined, patched, encrypted, minimal-software devices for administration.
• PIM for time-bound, approval-based just-in-time (JIT) elevation (cross-ref 01-identity-access-foundations). PIM role settings can require a Conditional Access authentication context on role activation (e.g., enforce phishing-resistant MFA + compliant PAW at the moment of elevation).
• Conditional Access gating role activation — require strong authentication and compliant devices; block on high sign-in / user risk (cross-ref 01-identity-access-foundations).
• Continuous monitoring of privileged role activations and anomalies (cross-ref 06-secops-siem-xdr-soar).

3.3 Securing tenant administration & CIEM

SC-100 extends this to securing administration of cloud tenants (including SaaS and multicloud) and cloud infrastructure entitlement management (CIEM) — discovering and right-sizing permissions across clouds (Defender for Cloud’s CIEM / Permissions Management). The enterprise access model is the conceptual spine; CIEM is the multicloud enforcement of least privilege.

4. Azure landing zones (CAF “Ready” made concrete)

Objective covered: SC-100 “Design solutions for implementing and governing security by using Azure landing zones”.

4.1 Definition and purpose

An Azure landing zone is the standardized, recommended foundation for operating in Azure at scale: a repeatable, modular environment that applies consistent configuration, security, and governance to every subscription. It is the implementation of CAF’s Ready methodology and the place where governance (05-posture-governance-defender-cloud) and networking (02-secure-networking) converge.

4.2 The eight design areas

Every landing zone is built across eight design areas:

1. Azure billing & Microsoft Entra tenant — tenant creation, enrollment, billing.
2. Identity and access management — the primary security boundary in cloud.
3. Resource organization — subscription design + management-group hierarchy. (Microsoft’s canonical label is “management group and subscription organization.”)
4. Governance — Azure Policy, compliance, cost controls.
5. Network topology and connectivity — hub-spoke or Virtual WAN, DNS, connectivity.
6. Security — controls, Defender for Cloud, encryption posture.
7. Management — monitoring, logging, operations.
8. Platform automation and DevOps — IaC, pipelines, drift control.

(Microsoft’s diagrams may label these A–I with some splits; know the set of concerns rather than a fixed letter order.)

4.3 Platform vs application landing zones

• Platform landing zone — shared foundational services run by central team(s), typically split into Identity, Management, and Connectivity subscriptions (hub VNet / Virtual WAN, DDoS plan, Log Analytics, central security tooling).
• Application landing zone — hosts a single workload, with a separate landing zone per environment (dev/test/prod). Each consists of one or more subscriptions to respect service limits. Provisioned via subscription vending (code-driven onboarding) and nested under management groups (e.g., Corp for internal, Online for internet-facing) so they inherit Azure Policy from the parent — governance by inheritance, not by bolt-on.

4.4 Management-group hierarchy & governance

A typical hierarchy: Tenant root → Intermediate root (e.g., “Contoso”) → {Platform, Landing zones (Corp / Online), Sandbox, Decommissioned}. Azure Policy assigned at management-group scope enforces controls on every child subscription automatically (cross-ref 05-posture-governance-defender-cloud). This is how “secure by default” is operationalized at enterprise scale.

4.5 Networking topology choices

Two reference topologies (cross-ref 02-secure-networking):

• Hub-and-spoke — central hub VNet with shared services (firewall, gateways), spokes peered in.
• Virtual WAN — Microsoft-managed hub with secured virtual hub (Azure Firewall integrated).

4.6 Hybrid/multicloud and AI

Azure Arc projects on-premises and other-cloud resources (servers, Kubernetes clusters, data services) into Azure Resource Manager so they inherit landing-zone governance and security controls (Policy, RBAC, Defender) just like native resources (cross-ref 05-posture-governance-defender-cloud for Arc + Defender for Cloud multicloud).

5. BCDR and ransomware resiliency (the densest exam zone)

Objectives covered: SC-100 “Design a resiliency strategy for ransomware and other attacks based on Microsoft Security Best Practices”, “Design a security strategy to support business resiliency goals, including identifying and prioritizing threats to business-critical assets”, “Design solutions for business continuity and disaster recovery (BCDR), including secure backup and restore for hybrid and multicloud environments”, “Design solutions for mitigating ransomware attacks, including prioritization of BCDR and privileged access”.

5.1 Microsoft’s prioritization for ransomware

Microsoft’s ransomware guidance reduces to three prioritized outcomes:

1. Prepare — have a secure backup and a tested recovery plan so you can restore without paying. This is the highest BCDR priority.
2. Limit scope of damage — protect privileged access (Section 3) so attackers can’t reach the controls that would let them disable defenses and destroy backups.
3. Make it harder to get in — incremental hygiene: MFA, patching, attack-surface reduction.

The combined headline Microsoft repeats: for ransomware, prioritize BCDR and privileged access. Those two, together, are the answer to “how do we become resilient to ransomware?“

5.2 Why backups are the battleground

Modern human-operated ransomware targets backups first, then encrypts production — because a victim with working backups won’t pay. MITRE ATT&CK maps this to Impact / Inhibit System Recovery (T1490) and Defense Evasion / Impair Defenses (T1562). Therefore a backup an administrator can delete is a backup an attacker (with a stolen admin credential) can delete. Resiliency design = make the backup itself tamper-resistant.

5.3 The defense-in-depth backup stack (Azure Backup / Recovery Services & Backup vaults)

This builds directly on the AZ-500 data-protection controls in 03-data-storage-keyvault but composes them into a strategy:

5.4 The canonical layered answer

“Stop a compromised Backup Operator from destroying all recovery points.” Soft delete alone is insufficient (a sufficiently privileged actor can disable it), so layer:

• Immutable vault (irreversible) — recovery points cannot be deleted before expiry, period.
• MUA + Resource Guard — disabling protection requires a second approver the attacker doesn’t control. Place the Resource Guard in a separate subscription / tenant with separate admins for true separation of duties.
• PIM — even legitimate destructive operations are JIT, approved, and audited.

5.5 Detection-driven preservation

Defender for Cloud generates ransomware alerts (e.g., “Ransomware indicators detected,” “Behavior similar to ransomware detected”). A Logic App (SOAR; cross-ref 06-secops-siem-xdr-soar) can react to that signal and pause recovery-point expiry, preserving backups during an active incident so the attacker’s encryption can’t run out your retention clock.

5.6 Hybrid and multicloud BCDR

SC-100 calls for secure backup and restore for hybrid and multicloud:

• On-prem via MARS agent / MABS / DPM with the same security features (passphrase protection, deletion alerting, 14-day deletion retention); enable MUA on the vault.
• Use Private Endpoints for backup traffic so data never traverses public IPs (including on-prem servers using the MARS agent backing up into a vault inside a VNet).
• For workloads outside Azure, project them with Azure Arc and apply consistent backup governance; for AWS/GCP, design native or third-party backup with equivalent immutability + access controls, monitored centrally.
• Azure Site Recovery (ASR) provides DR (failover / replication) — distinct from Azure Backup (data recovery). A complete BCDR design uses both: ASR for availability, Backup for recoverability.

5.7 Business resiliency & prioritizing business-critical assets

The strategy layer above the tooling: identify and prioritize threats to business-critical assets. Design steps — inventory the digital estate, classify assets by business impact (which systems, if lost, stop the business?), map threats to those assets, and concentrate the strongest controls (immutability, MUA, privileged-access hardening, tighter RPO/RTO) on the crown jewels. This connects to Microsoft Security Exposure Management (attack paths, attack-surface insights — cross-ref 05-posture-governance-defender-cloud) for prioritizing by real exposure rather than guesswork.

6. Security updates / patching strategy

Objective covered: SC-100 “Evaluate solutions for security updates”.

• Azure Update Manager (the successor to Update Management Center / Automation Update Management) — unified assessment and deployment of OS updates for Azure VMs and, via Azure Arc, on-prem and multicloud servers. Supports scheduled maintenance windows, on-demand patching, and compliance reporting.
• Evaluate any update solution on: platform coverage (Windows / Linux / Arc), scheduling & maintenance-window control, compliance / reporting visibility, ring-based / phased rollout to limit blast radius, and integration with Defender for Cloud recommendations (unpatched-vulnerability findings) and Defender Vulnerability Management (cross-ref 05-posture-governance-defender-cloud).
• Patching is simultaneously a Zero Trust hygiene item (Section 2.4 stage 3) and a ransomware “make it harder to get in” control (Section 5.1).

7. DevSecOps aligned to CAF

Objective covered: SC-100 “Design a DevSecOps process that aligns with best practices in the Microsoft Cloud Adoption Framework for Azure (CAF)”.

The shape:

• Shift-left: threat modeling early (cross-ref 07-apps-m365-strategy-capstone), then security gates in the pipeline.
• Defender for Cloud DevOps Security connectors for GitHub, Azure DevOps, GitLab — IaC scanning, dependency scanning, secret scanning, exposing findings in Defender for Cloud (cross-ref 05-posture-governance-defender-cloud). This is also the core supply-chain attack mitigation.
• Workload identities / managed identities for pipeline and runtime auth — no secrets stored in pipelines (cross-ref 01-identity-access-foundations + 07-apps-m365-strategy-capstone).
• Policy-as-code + landing-zone guardrails so deployments are governed by default (Section 4).
• Map outcomes to WAF Operational Excellence and Security pillars; map controls to MCSB DS (DevOps Security).

8. Defending insider, external, and supply-chain attacks

Objectives covered: SC-100 “Design solutions that align with best practices for protecting against insider, external, and supply chain attacks” and “…for cybersecurity capabilities and controls”.

SC-100 explicitly tests designing for these three threat classes:

• External attackers — MFA + Conditional Access (verify explicitly), Defender EASM for internet-facing attack surface, WAF + DDoS Protection for web workloads (cross-ref 02-secure-networking / 07-apps-m365-strategy-capstone), Defender for Cloud CWPP for workloads, Defender XDR + Sentinel for detection (cross-ref 06-secops-siem-xdr-soar).
• Insiders — least privilege + PIM to limit what insiders can do, access reviews / entitlement management, Microsoft Purview Insider Risk Management and DLP to detect/limit data misuse (cross-ref 07-apps-m365-strategy-capstone), and separation of duties (e.g., MUA so no single admin destroys backups).
• Supply chain — Defender for Cloud DevOps Security (Section 7), signed/verified artifacts and trusted registries (cross-ref 04-secure-compute-containers for ACR content trust), least-privilege workload identities, and third-party / SaaS governance via Defender for Cloud Apps (cross-ref 07-apps-m365-strategy-capstone).

9. Putting it together — the architect’s playbook (operate ↔ architect, explicit)

This is the explicit AZ-500 (operate) ↔ SC-100 (architect) bridge for the unit. Because az500: [], the bridge is not “same topic, two depths” — it is “the controls you operated, now composed into a strategy.”

10. Top exam traps (rapid recall)

See also

• 01-Cheat-Sheet — last-mile tables (Strategy-frameworks subsection)
• 02-High-ROI-Explanations — five “understand once” concepts with worked examples
• 99-Appendix — objective-to-unit index, glossary, and currency-drift alerts
• Prereq units (all seven): 01-identity-access-foundations · 02-secure-networking · 03-data-storage-keyvault · 04-secure-compute-containers · 05-posture-governance-defender-cloud · 06-secops-siem-xdr-soar · 07-apps-m365-strategy-capstone