SC-100: Cybersecurity Architect — Zero-Trust Strategy & Reference Designs

Every other security exam asks how do I configure this control? SC-100 asks a harder question: given a whole organisation — its identities, its clouds, its regulators, its budget, its existing mess — what should the security architecture be, and how do I get there from here? It is the capstone of Microsoft’s security certifications, and it is deliberately decision-oriented. You are not asked to click through a blade; you are asked to choose between defensible designs and justify the trade-off. That is exactly the job of a cybersecurity architect, and it is why this lesson is written as a strategy lesson, not a feature tour.

The good news is that Microsoft hands you two reference frameworks that do most of the heavy lifting, and the exam expects you to lean on them: the Microsoft Cybersecurity Reference Architectures (MCRA) — a living set of diagrams that show how every Microsoft security capability fits together and maps onto Zero Trust — and the Microsoft Cloud Security Benchmark (MCSB) — a prescriptive, control-by-control benchmark that turns “be secure” into an auditable checklist mapped to CIS, NIST and PCI. Master those two, layer a Zero-Trust strategy over identity, endpoints, network, apps, data and infrastructure, and wrap it in posture management, a modern SOC, a compliance strategy and an incident-response plan, and you have both the SC-100 syllabus and a genuinely useful mental model for designing security at scale. This lesson builds that model.

If you have already read the course’s Zero-Trust & multi-layer security model lesson, treat this as the level above it: that lesson taught the seven layers and which service sits on each; this one teaches how to design the strategy that decides those things across a real, messy estate — and how to defend that design in an exam or a steering committee.

Learning objectives

By the end of this lesson you can:

• Explain what the MCRA and the MCSB are, how they differ, and use each one as the architect intends — MCRA to see the whole board and map capabilities to Zero Trust, MCSB to prescribe and audit specific controls.
• Design a Zero-Trust strategy across the six technical pillars — identity, endpoints/devices, network, applications, data and infrastructure — plus visibility/automation/governance, and justify the maturity stages.
• Recommend a security-posture and governance strategy using Defender for Cloud’s CSPM, Secure Score, Azure Policy regulatory-compliance initiatives and the MCSB.
• Architect a modern SOC that unifies Microsoft Sentinel (cloud-native SIEM/SOAR) with Microsoft Defender XDR (extended detection and response) — and decide what each is for.
• Translate regulatory and resiliency requirements (ISO 27001, PCI-DSS, NIST 800-53, sovereignty, RTO/RPO) into security-architecture decisions, including an incident-response strategy anchored to NIST 800-61.
• Approach an SC-100 case-study question methodically: extract requirements and constraints, choose a defensible design, and state the trade-off you accepted.

Prerequisites & where this fits

SC-100 is the senior exam in Microsoft’s security track, and Microsoft recommends — though does not strictly require — that you hold one of SC-200 (security operations), SC-300 (identity and access), AZ-500 (Azure security engineer) or MS-500/SC-401 (information protection) first. In course terms, you should already be comfortable with Microsoft Entra ID, Conditional Access and PIM, with Defender for Cloud and Microsoft Sentinel, and with the network controls (NSGs, Azure Firewall, Private Link). This is the Security module’s strategy capstone (lesson G3) of the Azure Zero-to-Hero course — the lesson that turns the individual security services you have already met into a coherent, defensible architecture. The next lesson moves from theory to practice with real architecture case-study walkthroughs, where these security decisions show up inside full system designs.

Core concept: the architect’s job and the four SC-100 domains

A cybersecurity architect does not operate controls; they decide which controls exist, how they relate, who owns them, and how the organisation matures toward a target state. SC-100 organises that job into four skill domains, and it is worth holding the shape in your head because every exam question lands in one of them:

Notice the recurring theme: strategy first, products second. The exam punishes “reach for a product” answers and rewards answers that start from a principle or a framework and then name the capability. Two design philosophies underpin everything:

• Zero Trust — verify explicitly, use least-privilege access, assume breach. The strategy that replaces network-perimeter trust (see the dedicated lesson for the full treatment). Every design below is, at bottom, a Zero-Trust design.
• Defence in depth — independent, layered controls so that the failure of any one layer is contained by the next. Zero Trust tells you what to assume; defence in depth tells you how to survive being wrong.

The Microsoft Cybersecurity Reference Architectures (MCRA)

The MCRA is the single most important artefact for the “design to best practices” domain, and it is genuinely useful in real life. It is a regularly-updated set of slide-style reference diagrams, published by Microsoft, that show how Microsoft’s security capabilities fit together, how they integrate with third-party and multi-cloud platforms, and — critically — how they map onto Zero Trust and the attack chain. Think of it as the architect’s map of the whole board: when a case study throws a tangle of requirements at you, the MCRA tells you which capability families are even in play.

The MCRA is not one diagram but a deck of interlocking views. The ones SC-100 cares about most:

How to use the MCRA in an exam answer: when you read a case study, mentally drop its requirements onto these views and ask “where are the gaps?” The MCRA is fundamentally a gap-finding tool. If the scenario has rich identity but no SOC, the SecOps view screams; if it spans three clouds, the multi-cloud view tells you to standardise on Defender for Cloud’s multi-cloud connectors and a single Sentinel workspace rather than three native toolsets. The MCRA’s job is to stop you designing in a silo.

MCRA vs the others — don’t confuse them. The MCRA is the technical capability map (what protects what, and how it integrates). The Cloud Adoption Framework (CAF) Secure methodology gives the organisational journey (how to mature a security programme over time). The Well-Architected Framework (WAF) Security pillar gives workload-level design principles for a single solution. SC-100 expects you to know which to reach for: estate-wide capability design → MCRA; programme/operating-model maturity → CAF; one workload’s design → WAF.

The Microsoft Cloud Security Benchmark (MCSB)

Where the MCRA shows you the board, the MCSB tells you the moves. The Microsoft Cloud Security Benchmark is Microsoft’s prescriptive, control-by-control security baseline — the successor to the older “Azure Security Benchmark”, broadened to be multi-cloud (it carries explicit guidance for Azure and AWS and GCP). For each control it gives concrete guidance, the security principle behind it, and — the part that makes it audit-grade — mappings to industry frameworks: CIS Controls, NIST SP 800-53, and PCI-DSS. That mapping is the bridge an architect needs: it lets you tell an auditor “control X satisfies NIST AC-2 and PCI requirement 8” without re-deriving it.

The MCSB is organised into control domains. You should be able to recall the set and what each governs:

The MCSB is not just paper: it is built into Microsoft Defender for Cloud as the default security policy. Every Azure (and connected AWS/GCP) subscription is assessed against the MCSB initiative automatically, and the result is your Secure Score. This is the elegant bit of the Microsoft model that SC-100 loves: the benchmark (MCSB) → becomes the policy (Defender for Cloud’s default initiative) → produces a measurable posture (Secure Score) → which you drive up by remediating recommendations. Benchmark, control, measurement and remediation are one continuous loop.

How an architect uses the MCSB: as the baseline you tailor, not gospel you apply blindly. Start from the MCSB, then overlay the customer’s regulatory initiatives (PCI, ISO, etc.), then deviate only with a documented risk acceptance. In an exam, “apply the MCSB and track compliance via Defender for Cloud’s regulatory-compliance dashboard / Secure Score” is almost always part of the right posture answer.

Designing the Zero-Trust strategy across the six pillars

Zero Trust is the spine of the SC-100 syllabus. Microsoft frames implementation across six technical pillars, surrounded by three cross-cutting capabilities — visibility & analytics, automation & orchestration, and governance — that make the whole thing self-improving. The architect’s job is to set a target maturity for each pillar and sequence the journey (traditional → advanced → optimal). Here is the strategy, pillar by pillar, with the primary Microsoft capability and the signature design decision for each.

Two strategic points the exam probes hard:

• Identity is the control plane. In a Zero-Trust design, identity — not the network — is where policy is enforced, because every request begins with who/what is asking. Conditional Access is the engine that fuses all the signals (user risk, device compliance, location, app sensitivity, real-time session risk) into an allow / block / step-up decision. When in doubt on SC-100, the access-control answer routes through Conditional Access.
• Maturity is staged, not switch-flipped. You do not “turn on Zero Trust”. You move each pillar from traditional (perimeter trust, on-prem identity) → advanced (cloud identity, CA, central visibility) → optimal (real-time risk-based policy, automated response, data-aware controls). An architect’s deliverable is the roadmap across these stages, sequenced by risk and effort — which is precisely what CAF’s Secure methodology helps you structure.

The diagram ties it together: the MCRA gives the capability map and Zero-Trust principles at the top; the six pillars (identity, endpoints, network, apps, data, infrastructure) sit on the MCSB control baseline; and the cross-cutting SOC (Sentinel + Defender XDR), posture (Defender for Cloud + Secure Score) and governance/compliance planes wrap the whole estate — the exact shape of an SC-100 answer.

Designing security posture & governance strategy

“Posture” is your measurable security state — how well your estate is configured against best practice, before any attack. Governing it is a core architect deliverable, and Microsoft gives you a tight toolchain:

• Cloud Security Posture Management (CSPM) in Microsoft Defender for Cloud continuously assesses resources against the MCSB and surfaces misconfigurations as recommendations, each weighted into the Secure Score. The Defender CSPM paid plan adds the high-value architect features: attack-path analysis and the cloud security graph (which chains misconfigurations + exposure + permissions into actual attack routes, so you fix what is genuinely exploitable, not just what scores points), agentless vulnerability and secret scanning, data-aware security posture, and regulatory-compliance standards beyond the default MCSB.
• Secure Score turns posture into a single number and a prioritised backlog — the metric you take to the steering committee and track over time. The architect’s move is to set a target, assign recommendation ownership, and govern the trend.
• Azure Policy is the enforcement arm: regulatory-compliance initiatives (ISO 27001, PCI-DSS, NIST SP 800-53, CMMC, and more) deploy as policy sets, with effects from audit (observe) through deny (block) to deployIfNotExists (auto-remediate). Posture you only measure drifts back; posture you enforce via Policy and Azure Landing Zone guardrails stays put.
• Governance ties it to people: define security roles and responsibilities (RACI), set the enterprise segmentation strategy, and use Defender for Cloud’s governance rules to assign recommendations to owners with due dates and track remediation as an accountable programme — not a dashboard nobody reads.

The strategic sequence the exam wants: benchmark (MCSB) → enforce (Azure Policy + landing-zone guardrails) → measure (Secure Score / regulatory-compliance dashboard) → assign & remediate (governance rules) → repeat. That loop is the posture-management strategy.

Designing the modern SOC: Microsoft Sentinel + Defender XDR

If posture is about preventing the incident, the Security Operations Centre (SOC) is about detecting and responding when prevention fails (assume breach). Microsoft’s modern SOC is a deliberate pairing of two products, and SC-100 tests whether you know which is for what:

The design pattern Microsoft recommends — and the exam’s expected answer — is both, integrated: Defender XDR provides best-in-class, automatically-correlated detection and response across the Microsoft estate, and its incidents flow into Sentinel as the enterprise-wide SIEM/SOAR that also ingests non-Microsoft sources, runs custom KQL analytics and hunting, and automates response with SOAR playbooks. The native Defender XDR ↔ Sentinel integration (and the unified portal experience) means analysts get one queue without losing XDR’s deep automation.

Architect-level SOC decisions you must be ready to make:

• Workspace strategy. One Sentinel/Log Analytics workspace vs many — driven by data-residency (a workspace per sovereign region), RBAC/tenant boundaries, and cost. Default to centralised for correlation; split only when residency or isolation forces it.
• What to ingest, and the cost lever. SIEM cost scales with ingestion. Send high-value security logs to analytics tiers, route high-volume/low-query data to basic/auxiliary logs or an archive tier, and use the data-collection rules to filter noise. Ingestion strategy is SOC cost strategy.
• Detection content & automation. Analytics rules (built-in + custom KQL), UEBA for behavioural detection, threat-intelligence feeds, and automation rules + playbooks so common incidents are triaged or contained without a human. Maturity = more automated response, less manual toil.

Designing identity, application & data security strategy

These three are where most breaches actually start and end, so the architect’s strategy for each must be explicit.

Identity security strategy. Identity is the perimeter, so this is the highest-leverage pillar. The target design: a single centralised identity provider (Entra ID) as the control plane; Conditional Access enforcing risk- and device-aware policies on every request; phishing-resistant MFA (FIDO2/passkeys, certificate-based) trending to passwordless; privileged access locked down with PIM (just-in-time, time-bound, approval-gated, with access reviews) under a tiered admin / Privileged Access Workstation model so that Tier-0 (identity) admins never touch lower-trust devices; Identity Protection feeding user/sign-in risk back into Conditional Access; and Entra ID Governance (access reviews, entitlement management, lifecycle) to keep entitlements from sprawling. For external collaboration, B2B/External ID governs guests under the same policy engine.

Application security strategy. Cover both running apps and the pipeline that ships them. For running apps: discover and govern SaaS/shadow IT with Defender for Cloud Apps (CASB); front internet-facing apps with a Web Application Firewall; publish internal apps securely with Entra Application Proxy instead of VPN; protect APIs with API Management + authentication + WAF. For the pipeline — DevSecOps / secure SDLC — shift security left: threat-model, scan code and dependencies (SAST/SCA), scan IaC and container images (Defender for DevOps / Defender CSPM DevOps posture), and enforce that secrets never enter source.

Data security strategy. Zero Trust for data means protection that travels with the data. Use Microsoft Purview to classify data, apply sensitivity labels that carry encryption and usage rights, and enforce Data Loss Prevention across endpoints, email and cloud apps; encrypt at rest (platform keys, or customer-managed keys / Managed HSM for sovereignty) and in transit (TLS); centralise secrets, keys and certificates in Key Vault; and watch the data plane itself with Defender for Storage / SQL / Databases and data-aware security posture in Defender CSPM. The decision the exam probes: when is platform-managed encryption enough, and when do regulatory/sovereignty requirements force customer-managed keys or HSM? (Answer: default to platform keys for simplicity; move to CMK/HSM when a regulation or sovereignty requirement demands customer control of the key.)

Designing for compliance, resiliency & incident response

Regulatory compliance strategy. Translate each obligation into architecture. The pattern: load the matching Azure Policy regulatory-compliance initiative (ISO 27001, PCI-DSS, NIST 800-53, HIPAA/HITRUST, CMMC, FedRAMP…), monitor adherence on Defender for Cloud’s regulatory-compliance dashboard, manage the evidence and improvement actions in Microsoft Purview Compliance Manager, and lean on the MCSB’s framework mappings so one control demonstrably satisfies multiple regimes. Where data residency or sovereignty applies, the architecture decisions follow: choose compliant regions, use data-residency boundaries, and apply customer-managed keys / Managed HSM / confidential computing for key sovereignty. (The dedicated compliance & sovereignty lesson goes deep on this.)

Resiliency & business-continuity strategy. Security includes surviving an attack, especially ransomware. The architect designs immutable, isolated, tested backups (Azure Backup with immutability + soft delete; the offline/isolated copy), aligns the design to the workload’s RTO/RPO (recovery-time / recovery-point objectives), and ensures backups themselves are protected (the BR domain of the MCSB) — because attackers target backups first.

Incident-response strategy. Anchor to the NIST SP 800-61 lifecycle and design capability for each phase:

The exam’s expected shape: a documented plan (preparation), unified detection (XDR + Sentinel), automated containment (playbooks / attack disruption), tested recovery (immutable backups), and a feedback loop that hardens posture after every incident.

Hands-on lab: read your estate’s posture & compliance like an architect

SC-100 is a design exam, so the lab is diagnostic: you will use the CLI to read the same posture and compliance signals an architect uses to ground a strategy — Secure Score, the MCSB-driven recommendations, and the regulatory-compliance standards in scope. Everything here is read-only and uses free Azure CLI/Resource Graph queries; you do not need a paid Defender plan to read your current Secure Score and recommendations.

Prerequisites: an Azure subscription you can read, and either the Azure Cloud Shell (Bash, zero local setup, recommended) or a local az CLI logged in with az login. Add the Resource Graph extension once if prompted.

Step 1 — set context and confirm access.

az account show --query "{subscription:name, id:id, tenant:tenantId}" -o table
# Ensure the Resource Graph extension is available (used below)
az extension add --name resource-graph 2>/dev/null; az extension show --name resource-graph -o table

Step 2 — read your Secure Score (the MCSB-driven posture number).

az security secure-scores list \
  --query "[].{name:displayName, current:score.current, max:score.max, percent:score.percentage}" \
  -o table

Expected output: one or more rows (typically an ascScore aggregate) showing your current vs maximum points and the percentage. This number is your MCSB compliance, made measurable. If it returns empty, your account may lack the Security Reader role — ask for it; an architect always needs at least read access to posture.

Step 3 — list the top posture recommendations (these are MCSB controls).

az security assessment list \
  --query "[?status.code=='Unhealthy'].{control:displayName, severity:metadata.severity}" \
  -o table | head -25

Expected output: a table of failing assessments — e.g. “Management ports of virtual machines should be protected”, “Storage accounts should restrict network access”. Each maps to an MCSB control and a Secure Score weight. This is the prioritised backlog you would assign owners to.

Step 4 — enumerate the regulatory-compliance standards in scope. Using Resource Graph (works on the free tier):

az graph query -q "securityresources
  | where type == 'microsoft.security/regulatorycompliancestandards'
  | project standard = name, state = properties.state" -o table

Expected output: the compliance standards assessed for your subscription — you will see Microsoft cloud security benchmark by default, plus any others enabled (e.g. ISO 27001, PCI DSS). This is exactly the regulatory-compliance dashboard, read from the CLI.

Step 5 — sanity-check identity hygiene (a Zero-Trust read).

# How many users have privileged directory roles right now? (needs directory read access)
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/directoryRoles" \
  --query "value[].displayName" -o table

Expected output: the activated directory roles in your tenant. An architect reads this to ask “are privileged roles minimised and PIM-eligible rather than permanently assigned?” — the Privileged Access (PA) control in action.

Validation: you have grounded a strategy in evidence if you can now state, in one sentence each: (1) your current Secure Score percentage, (2) your single highest-impact unhealthy control, and (3) which regulatory standards are assessed. That triplet is the opening of any real SC-100-style recommendation.

Cleanup: nothing to delete — every command above is read-only and created no resources. (If you enabled a Defender plan to explore, disable it from Defender for Cloud → Environment settings to avoid charges.)

Cost note (INR): the lab is free — Secure Score, recommendations and the regulatory-compliance dashboard for the MCSB standard are available at no cost; Resource Graph and CLI queries are free. The paid layer is Defender for Cloud plans (CSPM and the workload plans), billed per resource/hour — e.g. Defender CSPM at roughly US$5–7 per billable resource per month (≈ ₹430–600) and server protection around US$15/server/month (≈ ₹1,300). For exam study, the free tier is enough; in production, scope paid plans to the subscriptions and resource types that warrant attack-path analysis and workload protection rather than enabling everything blanket.

Common mistakes & troubleshooting

Best practices

• Lead with frameworks, land on capabilities. Anchor every recommendation to Zero Trust + MCRA + MCSB, then name the Microsoft service. This is how the exam — and a good architecture review board — wants decisions justified.
• Make posture a loop, not a snapshot. Benchmark (MCSB) → enforce (Azure Policy + landing-zone guardrails) → measure (Secure Score / compliance dashboard) → assign owners (governance rules) → remediate → repeat.
• Design the SOC as XDR and Sentinel. Use Defender XDR for deep Microsoft-estate detection/auto-response and Sentinel as the enterprise SIEM/SOAR that correlates everything and automates response with playbooks.
• Treat identity as the control plane. One IdP (Entra), Conditional Access everywhere, phishing-resistant MFA, PIM for all privilege, tiered admin + PAWs for Tier-0.
• Stage the journey. Set a target maturity per Zero-Trust pillar and sequence the roadmap (traditional → advanced → optimal) by risk and effort; use CAF Secure to structure the programme.
• Protect the data and the backups. Sensitivity labels + DLP + encryption that travels with the data; immutable, isolated, tested backups for ransomware resilience.
• Standardise across clouds. Use Defender for Cloud’s multi-cloud connectors and the MCSB’s AWS/GCP guidance and Azure Arc so one posture/threat-protection plane covers the whole estate.

Security notes

The meta-point of an SC-100 design is that security is a property of the whole system and the operating model, not of any one control. Three things separate an architect’s answer from an engineer’s. First, assume breach is a design input, not a slogan: it justifies micro-segmentation, least privilege, immutable backups and a real SOC — design as though the attacker is already inside. Second, least privilege spans humans and machines: workload identities, managed identities and service principals need the same JIT, scoping and review discipline as admins — over-permissioned automation is a top breach path. Third, the human/operating-model layer is in scope: roles and responsibilities (RACI), an enterprise segmentation strategy, governance rules with owners, and a rehearsed incident-response plan are architecture deliverables — the MCRA explicitly includes the security organisational functions. A flawless tool deployment with nobody accountable for the alerts is not a secure design.

Interview & exam questions

1. What is the difference between the MCRA and the MCSB, and when do you use each? — MCRA is the capability map: interlocking reference diagrams showing how Microsoft (and third-party/multi-cloud) security capabilities fit together and map onto Zero Trust and the attack chain — use it to see the whole board and find gaps. MCSB is the prescriptive control baseline: control-by-control guidance with mappings to CIS/NIST/PCI, built into Defender for Cloud as the default policy and surfaced as Secure Score — use it to prescribe and audit specific controls.

2. A customer runs workloads in Azure, AWS and on-prem. Design a unified security posture. — Connect AWS and GCP to Defender for Cloud via its multi-cloud connectors and onboard on-prem servers with Azure Arc, giving one CSPM/CWPP plane assessed against the MCSB (which has explicit AWS/GCP guidance); centralise detection in Defender XDR + a Sentinel workspace that ingests all three; standardise governance with Azure Policy/landing-zone guardrails. One posture, one SOC, one benchmark.

3. Sentinel or Defender XDR — which, and why? — Both, integrated. Defender XDR delivers deep, automatically-correlated detection and response (and automatic attack disruption) across the Microsoft estate (endpoints, identities, email, cloud apps); Sentinel is the cloud-native SIEM/SOAR that correlates everything (including non-Microsoft sources and XDR incidents), runs custom KQL hunting, and automates response via playbooks. XDR for depth in the Microsoft world; Sentinel for org-wide breadth and SOAR.

4. How does the MCSB relate to Defender for Cloud’s Secure Score? — The MCSB is built into Defender for Cloud as the default security policy/initiative; resources are continuously assessed against it, and the weighted result of healthy vs unhealthy controls is the Secure Score. Benchmark → policy → measurable posture, in one loop.

5. Walk through a posture-management strategy. — Benchmark with the MCSB; enforce with Azure Policy regulatory-compliance initiatives + landing-zone guardrails (audit → deny → deployIfNotExists); measure with Secure Score and the regulatory-compliance dashboard; assign & remediate via Defender for Cloud governance rules with owners and due dates; use Defender CSPM attack-path analysis to prioritise genuinely exploitable risks; repeat.

6. Design a Zero-Trust identity strategy for a regulated enterprise. — Single IdP (Entra ID) as the control plane; Conditional Access enforcing risk-, device- and location-aware policy on every request; phishing-resistant MFA trending to passwordless; PIM for all privileged access (JIT, time-bound, approval-gated, access reviews); tiered admin + PAWs so Tier-0 admins are isolated; Identity Protection feeding risk into CA; Entra ID Governance for lifecycle and access reviews.

7. How do you translate “we must be PCI-DSS compliant” into architecture? — Load the PCI-DSS Azure Policy regulatory-compliance initiative, monitor it on Defender for Cloud’s regulatory-compliance dashboard, manage evidence/improvement actions in Purview Compliance Manager, and use the MCSB’s framework mappings so controls demonstrably satisfy PCI (and overlap with ISO/NIST). Add network segmentation, encryption, key management and logging controls the standard mandates.

8. What does “assume breach” change about a design? — It shifts effort from purely keeping attackers out to containing and detecting them: micro-segmentation to limit blast radius, least privilege for humans and workloads, immutable/isolated backups for ransomware recovery, end-to-end encryption, and a real detection-and-response capability (XDR + Sentinel). You design to survive being wrong.

9. Outline an incident-response strategy for an Azure estate. — Map to NIST 800-61: Preparation (IR plan, runbooks, RBAC, break-glass, pre-wired playbooks), Detection & analysis (Defender XDR auto-investigation + Sentinel analytics/hunting), Containment/eradication/recovery (XDR automatic attack disruption, SOAR playbooks, isolated backups), Post-incident (lessons learned feeding back into posture, detections and Conditional Access).

10. When do you choose customer-managed keys or Managed HSM over platform-managed encryption? — Default to platform-managed keys for simplicity and full Microsoft management. Move to CMK (Key Vault) when you need control over key lifecycle/rotation or separation of duties, and to Managed HSM (FIPS 140-2/3 Level 3, single-tenant) when regulatory or sovereignty requirements demand exclusive customer control of keys.

11. What is attack-path analysis and why does it matter to an architect? — A Defender CSPM capability that uses the cloud security graph to chain misconfigurations, exposure and excessive permissions into actual attack routes (e.g. internet-exposed VM → key → storage with sensitive data). It lets you prioritise the few fixes that break real attack paths rather than chasing every recommendation by score alone.

12. How would you structure Sentinel workspaces for a multinational with residency rules? — Default to a centralised workspace for cross-estate correlation and cheaper management, but split by sovereign region where data-residency law requires logs to stay in-country, and by tenant/RBAC boundary where isolation demands it — then correlate across them (cross-workspace queries / Defender XDR integration). Residency and isolation drive the split; correlation and cost favour central.

Quick check

1. Which framework would you use to find gaps in capability coverage across an estate, and which to prescribe and audit a specific control?
2. Name three of the MCSB control domains.
3. In a Zero-Trust design, which component is the policy engine that fuses signals into an access decision?
4. What single number expresses your MCSB compliance in Defender for Cloud, and what raises it?
5. In the modern SOC pairing, what is Defender XDR best at versus Microsoft Sentinel?

Answers:

1. MCRA to find capability gaps (it maps capabilities to Zero Trust and the attack chain); MCSB to prescribe and audit a specific control (control-by-control baseline with CIS/NIST/PCI mappings).
2. Any three of: Network Security (NS), Identity Management (IM), Privileged Access (PA), Data Protection (DP), Asset Management (AM), Logging and Threat Detection (LT), Incident Response (IR), Posture and Vulnerability Management (PV), Endpoint Security (ES), Backup and Recovery (BR), DevOps Security (DS), Governance and Strategy (GS).
3. Conditional Access — it combines identity, device-compliance, location, app-sensitivity and real-time risk signals into an allow / block / step-up decision.
4. Secure Score — driven by the MCSB default policy; it rises as you remediate unhealthy recommendations (controls).
5. Defender XDR is best at deep, automatically-correlated detection and response within the Microsoft ecosystem (auto-investigation, automatic attack disruption); Sentinel is best at org-wide SIEM correlation across any source, custom KQL hunting, and SOAR automation.

Exercise

Take a one-paragraph scenario (write your own or reuse one): “A mid-size fintech runs payment APIs in Azure and analytics in AWS, must meet PCI-DSS, has had a phishing incident, and the board wants ransomware resilience.” Produce a one-page security strategy an SC-100 candidate could defend:

1. Requirements & constraints — extract them (regulatory: PCI; multi-cloud: Azure+AWS; threat: phishing → identity; resilience: ransomware → backups).
2. Frameworks — state how you use the MCRA (capability map + gap-finding) and the MCSB (baseline + PCI mappings).
3. Zero-Trust design across the six pillars — one decision per pillar (e.g. identity → phishing-resistant MFA + CA + PIM; data → labels + CMK; infrastructure → Defender for Cloud + Arc over both clouds).
4. Posture & governance — MCSB via Defender for Cloud, PCI Policy initiative, Secure Score target, governance rules with owners.
5. SOC & IR — Defender XDR + a Sentinel workspace correlating both clouds; NIST 800-61 IR plan with automated containment; immutable, isolated, tested backups.
6. The trade-off you accepted — name one explicitly (e.g. “centralised Sentinel workspace except where AWS log-residency forced a split”). Stating the trade-off is what turns a list into an architecture.

Certification mapping

This lesson maps directly to SC-100: Microsoft Cybersecurity Architect across all four skill domains — design solutions that align with security best practices and priorities (MCRA, MCSB, CAF/WAF, Zero Trust), design security operations, identity and compliance capabilities (Sentinel + Defender XDR, Entra/CA/PIM, Purview, regulatory initiatives), design security solutions for infrastructure (Defender for Cloud plans, Arc, MCSB controls), and design security solutions for applications and data (DevSecOps, Key Vault, Purview, encryption/CMK/HSM). It also reinforces upstream material from AZ-500 (Azure security engineer), SC-200 (security operations) and SC-300 (identity and access) — the exams Microsoft recommends as preparation — and complements AZ-305 architecture design. Use it as the strategy layer above the course’s hands-on security lessons.

Glossary

• MCRA (Microsoft Cybersecurity Reference Architectures) — Microsoft’s regularly-updated set of reference diagrams mapping security capabilities (Microsoft + third-party/multi-cloud) to Zero Trust and the attack chain; the architect’s capability map.
• MCSB (Microsoft Cloud Security Benchmark) — Microsoft’s prescriptive, multi-cloud security control baseline (successor to the Azure Security Benchmark), organised into control domains with mappings to CIS, NIST 800-53 and PCI-DSS; built into Defender for Cloud as the default policy.
• Zero Trust — security strategy of verify explicitly, least-privilege access, assume breach; treats every request as if from a hostile network.
• Defence in depth — layering independent controls so the failure of one is contained by the next.
• CSPM (Cloud Security Posture Management) — continuous assessment of resource configuration against best practice; in Defender for Cloud, surfaces recommendations and drives Secure Score; the paid Defender CSPM plan adds attack-path analysis, the cloud security graph and agentless scanning.
• Secure Score — Defender for Cloud’s single, weighted measure of posture against the MCSB; rises as recommendations are remediated.
• Microsoft Defender XDR — extended detection and response correlating signals across Microsoft endpoints, identities, email and cloud apps, with automated investigation and attack disruption.
• Microsoft Sentinel — cloud-native SIEM + SOAR; ingests any source via connectors, runs KQL analytics/hunting, and automates response with playbooks.
• Conditional Access — Entra ID’s policy engine that fuses identity, device, location, app and risk signals into an allow/block/step-up access decision; the Zero-Trust control plane.
• PIM (Privileged Identity Management) — just-in-time, time-bound, approval-gated, reviewable privileged access in Entra ID.
• Defender for Cloud — Azure’s CSPM + CWPP platform; assesses posture against the MCSB and protects workloads across cloud, hybrid (via Arc) and multi-cloud.
• Azure Arc — extends Azure management, policy and Defender protection to on-prem and other clouds.
• Microsoft Purview — data governance and protection: classification, sensitivity labels, DLP, and Compliance Manager for assessments and evidence.
• NIST SP 800-61 — the computer-security incident-handling lifecycle (preparation; detection & analysis; containment, eradication & recovery; post-incident activity).
• RTO / RPO — recovery-time objective (how fast you must recover) and recovery-point objective (how much data loss is tolerable); the targets a resiliency design is sized against.
• CMK / Managed HSM — customer-managed keys (in Key Vault) and the single-tenant, FIPS-validated hardware security module for exclusive customer key control, used where sovereignty/regulation demands it.

Next steps

• Azure Architecture Case Studies: Real Proposal Walkthroughs — see these security decisions land inside full, end-to-end system designs (the next lesson).
• Azure Zero-Trust & the Multi-Layer Security Model — the layer-by-layer foundation beneath this strategy lesson.
• Azure Compliance, Sovereignty & Regulated Cloud — go deep on Compliance Manager, regulatory initiatives and data residency.
• Azure Mission-Critical / Always-On Architecture — how resiliency and security combine in the highest-stakes designs.