High-ROI Explanations

High-ROI Explanations — Learn Once, Pass Both

This is the medium-depth layer of the guide. For each of the eight units it teaches the few highest-yield concepts with a concrete worked scenario and the why-it-matters split: AZ-500 makes you operate the control, SC-100 makes you design and evaluate it. Master what is here and you answer the bulk of both exams.

The one pattern that defines this entire guide: AZ-500 turns the knobs; SC-100 decides which knobs exist and why.

Unit map: 1 Identity · 2 Networking · 3 Data/Key Vault · 4 Compute/Containers · 5 Posture/Governance · 6 SecOps · 7 Apps/M365 · 8 Capstone

Unit 1 — Identity, Access & Privileged Access

Full coverage: 01-identity-access-foundations · Quick reference: 01-Cheat-Sheet · Dates/licensing: 99-Appendix

Understand-it-once concepts that pay off on both exams. Each comes with a worked scenario and the “operate (AZ-500) vs design (SC-100)” framing.

1. The identity object model — get this right and half the unit clicks

Why it matters: Almost every wrong answer on identity questions comes from confusing four objects: app registration (application object), service principal, system-assigned MI, and user-assigned MI. Every other unit (a function reading Key Vault, a VM scanning storage, a pipeline deploying ARM) authenticates as one of these.

The mental model:

• App registration creates a global Application object — the blueprint living in your home tenant (how tokens are issued, what perms it wants).
• A Service principal is the local instance of that blueprint in a given tenant. One app object → potentially many SPs (one per tenant for a multitenant app). The SP is what you assign roles and consent to.
• A Managed identity is a special service principal that Azure creates and rotates for you — the whole point is no credentials in your code.
  • System-assigned: born with one resource, dies with it (1:1).
  • User-assigned: a standalone Azure resource you attach to many resources; survives deletion of any one consumer. Microsoft’s recommended default.

Workload identities = applications + service principals + managed identities (the non-human identities).

Worked example. You have three workloads:

1. An Azure Function that reads one Key Vault → system-assigned MI (single resource, simplest, auto-cleanup).
2. Five VMs in a scale set that all need the same storage role → user-assigned MI (one identity, assign the RBAC role once, attach to all five).
3. A GitHub Actions pipeline (runs outside Azure) deploying to Azure → it can’t have a managed identity natively, so you use workload identity federation: configure a federated identity credential on a user-assigned MI (or app registration) that trusts GitHub’s OIDC token. The pipeline exchanges its GitHub token for an Entra access token — no secret stored in GitHub.

AZ-500 (operate): Create the MI, assign it an RBAC role, configure the federated credential (issuer = GitHub OIDC URL, subject = repo:org/repo:ref:refs/heads/main). Max 20 federated credentials per app/UAMI; issuer+subject must be unique; no wildcards. SC-100 (design): “Design a solution for workload identities to authenticate and access Azure resources” → the answer pattern is managed identity > workload identity federation > service principal with cert > service principal with secret (last resort). You’re choosing the credential-elimination strategy, not clicking the portal.

2. Azure RBAC vs. Entra roles — two separate authorization planes

Why it matters: This is the single most tested distinction in the identity domain, and it’s an architecture fork on SC-100.

• Azure RBAC authorizes Azure resources (VMs, storage, Key Vault) through Azure Resource Manager. Scope hierarchy: management group → subscription → resource group → resource, inheriting downward. Roles: Owner, Contributor, Reader, User Access Administrator, plus custom.
• Microsoft Entra roles authorize the directory itself (manage users, Conditional Access, app registrations). Roles: Global Administrator, Privileged Role Administrator, User Administrator, etc.

They do not overlap. A Global Administrator has no Azure resource access until they elevate (the “Access management for Azure resources” toggle grants the User Access Administrator role at root). Contributor on a subscription cannot edit a Conditional Access policy.

Worked example — custom role. A team needs to restart VMs but never resize or delete them. No built-in role fits. You author a custom Azure role:

{
  "Actions": ["Microsoft.Compute/virtualMachines/restart/action",
              "Microsoft.Compute/virtualMachines/read"],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<sub-id>"]
}

Effective permission = Actions − NotActions. DataActions/NotDataActions govern data-plane operations (e.g. read a blob), kept separate from management-plane. Deny assignments trump allows but today are only system-created (e.g. by Blueprints/Managed Apps).

AZ-500: “Manage built-in role assignments” + “manage custom roles (Azure and Entra)” — you write the JSON, set AssignableScopes, assign at the right scope. SC-100: You don’t write JSON — you delegate via the enterprise access model (see §5) and recommend least-privilege built-in roles + PIM over standing custom Owner grants.

3. PIM — turn standing privilege into just-in-time

Why it matters: Standing admin access is the #1 attack surface. PIM is the answer to “reduce privileged blast radius,” and it shows up on both exams constantly.

The core distinction:

• Eligible assignment: the user can activate when needed (must perform an action — MFA, justification, maybe approval). They have zero standing privilege until then.
• Active assignment: usable immediately, no action.

Both can be permanent or time-bound. On activation, PIM injects a temporary active assignment and removes it within seconds when the activation window expires — that’s just-in-time (JIT) access.

Worked example. An SRE needs Owner on a production subscription a few times a month for incident response. Instead of permanent Owner:

1. Make them eligible for Owner (scoped to that subscription) via PIM.
2. Role settings: max activation 4 hours, require MFA, require justification, require approval (≥1 approver — for Azure resource roles / PIM for Groups there is no default approver, so you must name one), and optionally require a CA authentication context (forcing a compliant PAW + phishing-resistant MFA at activation — see §4).
3. The SRE activates, justifies, an approver approves, they get Owner for 4 hours, then it auto-revokes.

Critical nuance: “Require MFA on active assignment” enforces MFA when the assignment is created, not when the role is used — PIM can’t step up an already-active role. That’s why eligible+activate is stronger than active.

PIM for Groups gotcha: To give JIT access to roles backed by SharePoint/Exchange/Purview, make users active members of the group and the group eligible for the role — the reverse (group active, users eligible to the group) causes long activation delays.

AZ-500: “Plan and manage Azure resources in PIM, including settings and assignments” — you configure eligibility, role settings, approvers. Needs Entra ID P2 or Entra ID Governance license. SC-100: “Evaluate the security and governance of Entra ID, including PIM, entitlement management, and access reviews” — you design the governance program: PIM for elevation + Access Reviews to recertify + Entitlement Management access packages for lifecycle. You’re judged on whether the design eliminates standing access, not on portal clicks.

4. Conditional Access + CAE + protected actions — modern auth as a system

Why it matters: CA is literally called “the Zero Trust control plane.” It’s the connective tissue between identity and every resource, and SC-100 explicitly asks you to validate CA alignment with Zero Trust.

Conditional Access = if [signals] then [grant/block + session controls]. Signals include user/group, target resource, named location, device state (compliant / Hybrid-joined), client app, and — with P2 — sign-in risk and user risk from ID Protection.

Worked example — a layered policy set:

• Policy A: All users, all cloud apps → require MFA (baseline).
• Policy B: Admin roles → require authentication strength = phishing-resistant MFA + compliant device (raise the bar for privilege).
• Policy C: Sign-in risk = High → block; sign-in risk = Medium → require MFA. User risk = High → require secure password change (lets the user self-remediate — automatic risk remediation, the big benefit of risk-based policies).
• All policies exclude the break-glass account (or you lock yourself out).
• Roll out in report-only mode first to see impact before enforcing.

CAE (Continuous Access Evaluation) fixes the “token is valid for ~1 hour even after I disable the account” gap. CAE-aware services (Exchange Online, SharePoint Online, Teams, Graph) get near-real-time revocation on critical events — account disabled/deleted, password reset, MFA enabled, admin revokes refresh tokens, high user risk. Critical-event evaluation needs no CA policy and works in any tenant. Bonus: token lifetimes can stretch to 28 hours (MSAL refreshes proactively) because revocation no longer depends on short expiry → more resilient and more secure. (Note: SharePoint Online doesn’t honor user-risk events.)

Protected actions put a CA requirement (via authentication context, of which you can define up to 99: c1–c99) on specific high-risk Entra permissions — e.g. deleting a Conditional Access policy or changing protected-actions config. So even a compromised Global Admin token can’t nuke your CA posture without re-satisfying a strong auth context. Requires P1. It’s not for blocking by identity (that’s role assignment) — it gates the action.

AZ-500: “Implement Conditional Access policies” + “implement MFA” — you build the policies, pick grant/session controls, configure authentication strengths. SC-100: “Design a modern authentication and authorization strategy, including Conditional Access, continuous access evaluation, risk scoring, and protected actions” and “validate alignment of CA with Zero Trust” — you assemble CA + CAE + risk + protected actions into a coherent verify-explicitly / least-privilege / assume-breach design and audit an existing policy set for gaps (e.g. no break-glass exclusion, legacy auth not blocked, no risk policies).

5. Enterprise access model + privileged access (the SC-100 capstone)

Why it matters: This is the architecture frame SC-100 hangs the whole identity domain on. AZ-500 gives you PIM and CA as tools; SC-100 asks how to organize delegation across an enterprise.

The enterprise access model evolves the legacy AD tier model into planes that span on-prem + multicloud:

• Control plane (was Tier 0): identity systems, PIM, CA — who can configure everything else. Highest protection.
• Management plane + Data/workload plane (Tier 1 split): enterprise-wide IT management vs. per-workload admin (accommodates DevOps).
• User access + App access (Tier 2 split): all B2B/B2C/public user scenarios vs. API/app access pathways.

Privileged access provides the only administrative path to the control plane, so the design rules are:

1. Explicitly controlled — PIM, approval, time-bound elevation, no standing access.
2. Isolated — separate admin accounts + Privileged Access Workstations (PAWs) / secure workstations; privileged actions never originate from a daily-driver device.
3. Continuously monitored — feed sign-ins, role activations, policy changes to Microsoft Sentinel.

Worked example — delegating storage-team admin without giving them the kingdom: They get eligible (PIM) Contributor scoped to their resource groups (data/workload plane), activation gated by a CA authentication context requiring a compliant PAW + FIDO2 (control-plane-grade auth for an elevation), recertified quarterly by Access Reviews, with all activations alerting in Sentinel. No one holds standing Owner; control-plane roles (Global Admin) live in a separate, even more locked-down population.

CIEM rounds this out: Microsoft Entra Permissions Management measures the Permission Creep Index (PCI) and right-sizes unused permissions across Azure + AWS + GCP — the multicloud entitlement layer that PIM (Azure/Entra-only) doesn’t cover.

AZ-500: mostly out of scope — AZ-500 stops at PIM + RBAC mechanics. SC-100: “Design a solution for assigning and delegating privileged roles using the enterprise access model,” “Design a solution for CIEM,” “Design secure workstations for privileged access,” “Design a solution for securing administration of cloud tenants (SaaS + multicloud).” This is pure architecture — pick the right plane, the right elevation gate, the right monitoring.

6. Enterprise apps & OAuth consent — the illicit-consent attack surface

Why it matters: OAuth consent phishing (illicit grant) is a top real-world attack, and the app-registration/consent topics are explicit AZ-500 objectives.

• App registration = the application object you own. Enterprise application = the service principal representing an app in your tenant (yours, gallery SaaS, or another tenant’s multitenant app).
• Delegated permissions: app acts on behalf of a signed-in user, capped by the user’s own rights. Application permissions: app acts as itself (daemon, no user) → always require admin consent.
• Consent settings: restrict user consent to verified-publisher apps / low-risk permissions; route the rest through the admin consent workflow. The OAuth permission grant is the stored consent record (delegated → oauth2PermissionGrants; application → app role assignments).

Worked example: A user gets a phishing link granting a malicious multitenant app Mail.Read (delegated). If user consent is unrestricted, the app now reads their mail. Mitigation: set consent to “allow user consent for apps from verified publishers, for selected permissions”, enable the admin consent workflow, and audit existing grants for over-privileged or unverified apps.

AZ-500: “Manage access to enterprise applications, including OAuth permission grants,” “manage app registrations,” “configure permission scopes,” “manage permission consent,” “manage and use service principals.” You operate consent settings and audit grants. SC-100: folds into “modern authorization strategy” and tenant-administration security — design consent governance + app-identity hygiene as part of the Zero Trust app-access plane.

Unit 2 — Secure Networking & Edge Protection

Full coverage: see the networking section of 01-Cheat-Sheet (no standalone full-guide note) · Dates/SKUs: 99-Appendix

The whole unit is one idea applied at every layer: default-deny, then authorize each flow explicitly (Zero Trust “assume breach” at the network). AZ-500 asks you to build the controls; SC-100 asks you to choose between them for a stated requirement. Master the seven concepts below and you cover most of both.

1. NSG + ASG + service tags — segmentation without IP spreadsheets

Why it matters (both exams): This is the most-tested networking primitive on AZ-500 and the foundation SC-100 assumes when it says “evaluate network designs.” An NSG is a stateful L3-L4 allow/deny list attached to a subnet and/or a NIC; rules have priority 100-4096 (lowest number wins) and default rules at 65000-65500 allow intra-VNet + load-balancer traffic and deny all inbound from the Internet.

The trap with raw NSGs is IP management. Application Security Groups fix this: you tag NICs into a logical group (asg-web, asg-db) and write the rule against the group, not addresses.

Worked example — 3-tier app: You want web→app→db and nothing else.

• Put web VMs in asg-web, app VMs in asg-app, db VMs in asg-db (all in the same VNet — ASG members must share a VNet).
• NSG rules: allow asg-web → asg-app:443, allow asg-app → asg-db:1433, then a low-priority deny-all. The db tier never needs to know the app tier’s IPs; autoscale adds NICs to the ASG and they inherit policy instantly.
• Use the service tag AzureLoadBalancer to permit health probes and Internet/Storage/AzureKeyVault instead of curating Microsoft IP ranges by hand.

Exam reflex: “effective security rules” (a Network Watcher view) is how you prove the union of subnet+NIC NSGs actually permits a flow. NSG is stateful → no separate return rule needed.

2. Private Endpoint vs Service Endpoint — the single most confused pair

Why it matters: Microsoft writes at least one AZ-500 item and frequently an SC-100 design question that hinges on this distinction. Get it wrong and you expose a storage account to the Internet you thought was private.

Worked example — lock down a storage account: Create a Private Endpoint for the blob sub-resource. It gets a private IP in your subnet. Then set the storage firewall to deny public network access. Critically, link a Private DNS zone privatelink.blob.core.windows.net to the VNet so account.blob.core.windows.net resolves (via CNAME) to the private IP. Skip the DNS zone and the app silently keeps hitting the public endpoint — the #1 “it worked in the portal but broke in code” failure.

SC-100 angle: Private Endpoints are how you shrink the public attack surface for PaaS — they also reduce DDoS exposure (fewer public IPs). Private Link service is the inverse: you publish your own service (behind a Standard LB) to other tenants/VNets privately, no peering.

3. Azure Firewall SKU choice + Premium TLS/IDPS

Why it matters: AZ-500 makes you pick the SKU; SC-100 makes you justify it against a regulatory or Zero Trust requirement.

• Basic — SMB, threat intelligence in alert-only.
• Standard — TI alert-and-deny, web categories, FQDN filtering.
• Premium — TLS inspection, IDPS, URL filtering, ~100 Gbps, PCI DSS.

Worked example — regulated workload needs to inspect encrypted egress: Only Premium can decrypt outbound TLS. It uses a customer CA certificate stored in Azure Key Vault, decrypts→inspects→re-encrypts, and that’s what makes IDPS and URL filtering effective on HTTPS. Set IDPS to Alert and Deny (Basic supports alert only). Define private IP ranges so the firewall classifies flows as inbound/outbound/east-west. All rules live in a Firewall Policy (Basic/Standard/Premium tiers, hierarchical parent/child) processed DNAT → Network → Application.

Exam reflex: Downgrading Premium→Standard fails until you remove TLS inspection, IDPS deny mode, URL filtering, and web categories.

4. App Gateway (regional L7 + WAF) vs Front Door (global L7 + CDN + WAF)

Why it matters: Both exams test “where does the WAF go?” The discriminator is scope.

• Application Gateway = regional L7 reverse proxy/LB. WAF is the WAF_v2 tier (OWASP CRS, custom rules, end-to-end + mutual TLS). Use for a single-region app or internal L7.
• Azure Front Door = global L7 + CDN + WAF at the edge. Premium adds Private Link to origins, managed rule sets, and bot protection. Use for multi-region, global users, edge caching.

Worked example: Global e-commerce site, users worldwide, WAF + caching + DDoS at the edge → Front Door Premium, origins reached over Private Link so the backends have no public IP. A single-region internal API needing mTLS to backends → App Gateway WAF_v2. WAF runs in Detection (log) then Prevention (block); rate-limiting and geo-filtering are custom rules.

5. DDoS — IP Protection vs Network Protection (the “recommend when” objective)

Why it matters: AZ-500 literally lists “recommend when to use DDoS Protection.” The answer is a number.

• IP Protection = pay per protected public IP. Best for <15 public IPs.
• Network Protection = per-plan, covers up to 100 IPs tenant-wide, best for >15 IPs — and adds DDoS Rapid Response, cost protection, and the WAF discount (App Gateway WAF billed at the non-WAF rate inside a protected VNet).
• Free infrastructure DDoS protection covers all Azure public IPs already; the paid tiers add adaptive tuning, telemetry, alerts, and SLA.

Exam reflex: “Many public IPs + need rapid response + cost guarantee” → Network Protection. “A handful of IPs, budget-sensitive” → IP Protection.

6. Secure hybrid edge — VPN P2S auth, ExpressRoute encryption, secured vWAN hub

Why it matters: SC-100 evaluates the connectivity fabric; AZ-500 configures each piece.

• P2S VPN auth = certificate / Microsoft Entra ID / RADIUS over OpenVPN/IKEv2/SSTP. Entra ID auth lets you apply Conditional Access to VPN.
• ExpressRoute is private but NOT encrypted — a classic gotcha. Add MACsec (Layer-2, on ExpressRoute Direct ports) or IPsec over private peering (Layer-3) when a compliance regime mandates encryption-in-transit.
• Secured virtual hub = a Virtual WAN hub with Azure Firewall integrated via Firewall Manager; routing intent forces spoke-to-spoke and Internet traffic through the firewall — the scalable replacement for hand-built hub-spoke + UDR.

7. SSE — Entra Internet Access + Private Access (the SC-100-only delta)

Why it matters: This is the entire SC-100 networking delta and appears on no AZ-500 objective. Same Zero Trust goal, identity-delivered instead of VNet-delivered.

Global Secure Access (GSA) is the unified Entra portal for Microsoft’s Security Service Edge (SSE):

• Entra Internet Access = identity-aware secure web gateway (SWG) — applies Conditional Access to Internet and Microsoft 365 traffic, including cross-tenant configurations for Microsoft Services (e.g., block personal-tenant M365 from corp devices).
• Entra Private Access = ZTNA — per-app, Conditional-Access-gated access to private resources on any port/protocol, built on Entra application proxy, without a legacy VPN. Needs a Private Network Connector and Quick Access.

Worked example — replace the VPN (SC-100 design): Instead of full-tunnel VPN that grants broad network access, deploy Entra Private Access: the GSA client captures only the private-app traffic via a Private access forwarding profile, each app is gated by Conditional Access, and there’s no inbound firewall rule because the connector dials outbound. Internet browsing is steered through Entra Internet Access for CA + logging. GSA coexists with third-party SSE (Cisco, Palo Alto, Netskope).

The throughline: AZ-500 = operate the boxes (NSG/ASG, Firewall, PE, WAF, DDoS, gateways). SC-100 = architect: evaluate the design against ZT/MCSB and decide which control — including whether the answer is identity-delivered SSE (Internet/Private Access) rather than a traditional VNet appliance.

Unit 3 — Data, Storage & Key Management

Full coverage: 03-data-storage-keyvault · Quick reference: 01-Cheat-Sheet · Dates/limits: 99-Appendix

These are the five concepts that, understood once with their worked example, carry the most marks on both exams. Identity primitives (RBAC, managed identities) are assumed from 01-identity-access-foundations.

1. The envelope-encryption model: SSE → CMK → infrastructure encryption

The one idea that unlocks half this unit. Almost every Azure data service encrypts the same way: a fast symmetric Data Encryption Key (DEK) encrypts the actual bytes, and that DEK is itself wrapped (“enveloped”) by a Key Encryption Key (KEK). Who owns the KEK is the only thing that changes.

• Service-level encryption (SSE) is AES-256, FIPS 140-2 compliant, always on, and cannot be turned off on Azure Storage. By default the KEK is a Microsoft-managed key (MMK).
• Customer-managed key (CMK) / BYOK: you swap the KEK for your key, held in Key Vault or Managed HSM. Your key wraps the DEK — it never touches the data directly. This is why you can rotate or revoke your key instantly: revoking it makes the DEK un-unwrappable, so the data becomes inaccessible while staying encrypted.
• Infrastructure (double) encryption adds a second, independent layer: a different algorithm and a separate Microsoft-managed key. The two layers come from independent key hierarchies managed by different operators (you control the service-level key, Microsoft controls the infrastructure key).

Worked example — a regulated bank’s blob account. Compliance demands “two layers of encryption, customer control of at least one.” You create the storage account with infrastructure encryption enabled at creation time (it’s immutable afterward — you cannot retrofit it), then configure CMK for the service layer pointing at a Key Vault key. Result: layer 1 = your CMK-wrapped DEK; layer 2 = Microsoft’s separate infrastructure key. If one algorithm is ever broken, the other still protects the data.

The trap both exams set: CMK and double encryption are different axes. CMK = who holds the key. Double encryption = how many layers. Storage with CMK alone is still one layer (just your key). By contrast, Cosmos DB CMK is automatically double (MMK layer + CMK layer) — but only on transactional storage, not Synapse Link or continuous-backup tiers.

• AZ-500 asks you to enable infrastructure encryption and configure BYOK.
• SC-100 asks you to choose: does this workload’s compliance regime actually require double encryption, or is single-layer CMK sufficient? (Microsoft’s own guidance: infrastructure encryption is for specific compliance needs; for most workloads SSE is enough.)

2. Key Vault authorization: control plane vs data plane, RBAC vs access policies

This is the single most-tested Key Vault concept and the source of a classic privilege-escalation question.

Key Vault has two planes:

• Control plane — manage the vault itself (create, delete, configure network, read properties). Always Azure RBAC, via Azure Resource Manager.
• Data plane — actually use the contents: get/wrap/unwrap keys, read secrets, manage certs. This plane has two authorization models you choose between: Azure RBAC (recommended) or the legacy vault access policy model.

Worked example — the access-policy escalation. A developer is given Contributor on a resource group to deploy apps. With the access-policy model, Contributor includes Microsoft.KeyVault/vaults/write — so the developer can simply edit the vault’s access policy and grant themselves Get-Secret. They now read every production secret, with zero data-plane permission originally intended. Switching the vault to the Azure RBAC model closes this: data-plane roles (e.g. Key Vault Secrets User) are separate from management, and only Owner / User Access Administrator can hand out permissions. This is separation of security duties from administration, and it’s exactly the kind of design decision SC-100 rewards.

Managed HSM sharpens the distinction: its data plane uses Managed HSM local RBAC (enforced inside the HSM), and granting control-plane access does NOT grant data-plane access — by design. Even a subscription owner cannot read keys unless they’re a data-plane administrator.

• AZ-500: configure access policies and RBAC; know which roles exist.
• SC-100: design the secrets-management authorization model — pick RBAC, enforce least privilege, separate who-administers from who-uses.

3. TDE vs Always Encrypted vs Dynamic Data Masking — three different threats

Candidates lose marks by treating these as interchangeable “SQL encryption.” They defend against three different adversaries:

Worked example — a healthcare app storing SSNs.

• TDE (on by default) means if someone steals the backup files, they’re ciphertext. But your DBA can still SELECT the SSN in plaintext — TDE doesn’t stop them.
• To hide SSNs from the DBA, you apply Always Encrypted to the SSN column: the client driver encrypts it with a Column Encryption Key (CEK), which is wrapped by a Column Master Key (CMK) stored in Key Vault or the Windows cert store. The SQL engine only ever sees ciphertext. Without secure enclaves you get equality lookups only; Always Encrypted with secure enclaves adds range, LIKE, and pattern matching.
• For a call-center rep who only needs the last 4 digits, DDM masks the column on read — but DDM does not stop db_owner, CONTROL, or anyone running ad-hoc inference queries, and you cannot mask and Always-Encrypt the same column.

The exam trap: DDM looks like a security control but is a data-exposure-reduction feature, not a boundary. SC-100 wants you to layer: TDE (at rest) + Always Encrypted (from operators) + DDM (from over-curious app users) + RBAC. AZ-500 wants you to implement TDE, plan DDM, and recommend when Always Encrypted is appropriate (answer: when you must hide data from the platform/DBA itself).

4. Storage data-threat protections: soft delete, versioning, immutable/WORM

These four features defend against the ransomware / accidental-deletion / tamper threat — a top SC-100 priority (“design resiliency for ransomware”).

• Soft delete (blob + container level) = recycle bin; deleted blobs recoverable for a retention window. Enable it first, before anything else.
• Versioning automatically keeps a prior version on every overwrite — protects against malicious overwrite, not just delete.
• Point-in-time restore rewinds a whole container (needs versioning + change feed). Note: incompatible with version-level WORM and last-access tracking.
• Immutable storage (WORM) is the hard guarantee: time-based retention (1 day to 400 years) and/or legal hold make blobs un-modifiable and un-deletable.

Worked example — ransomware-proof audit logs. A SOC must retain SQL audit logs tamper-proof for 7 years to satisfy SEC 17a-4(f). You write audit to a blob container with a version-level WORM time-based retention policy of 7 years, then lock it. While unlocked, a policy is for testing only and provides no delete protection; once locked it is irreversible and Cohasset-validated against SEC 17a-4(f), FINRA 4511, and CFTC 1.31 — not even a global admin can delete those blobs before expiry. (Because SQL audit appends, set the storage account’s “Allow protected append writes.”)

Gotchas worth a mark: version-level WORM is not supported on hierarchical-namespace (Data Lake Gen2) accounts, nor on accounts with NFS 3.0 or SFTP enabled.

• AZ-500: turn on soft delete, versioning, and configure immutable policies.
• SC-100: design the BCDR/anti-ransomware data strategy — which tier of protection each data class needs, and where WORM is legally mandated.

5. Defender for Storage & Defender for Databases — the detection layer

Encryption and immutability are preventive; Defender plans are detective, and SC-100 explicitly asks you to “design a security solution that includes Microsoft Defender for Storage and Microsoft Defender for Databases.”

• Defender for Storage (agentless, enable at subscription scope): activity monitoring (anomalous access, exfiltration, leaked-SAS use by entities with no identity), malware scanning (Microsoft Defender Antivirus, on-upload or on-demand, billed per GB), and sensitive data threat detection (uses Microsoft Purview sensitive-information types to prioritize alerts on the data that matters). No diagnostic logs required.
• Defender for Databases: covers Azure SQL, SQL-on-VM, open-source (PostgreSQL/MySQL), and Cosmos DB. For SQL = Vulnerability Assessment (finds misconfigs/excess permissions) + Advanced Threat Protection (SQL injection, anomalous login/access patterns).

Worked example — a public upload portal. Users upload files to a blob container. Defender for Storage malware scanning scans each blob on upload and quarantines/flags malicious files before they propagate downstream; sensitive data threat detection raises the severity if an alert touches a container Purview tagged as holding PII. Meanwhile Defender for SQL alerts when the app’s connection string is abused for an injection attempt. Together they give the SOC the detect-and-respond half that encryption can’t provide.

• AZ-500: enable and configure the Defender for Storage / Databases plans.
• SC-100: decide which workloads warrant which plan and how their alerts flow into Defender for Cloud / Sentinel (see 05-posture-governance-defender-cloud and 06-secops-siem-xdr-soar).

Unit 4 — Secure Compute, Containers & Endpoints

Full coverage: 04-secure-compute-containers · Quick reference: 01-Cheat-Sheet · Dates/retirements: 99-Appendix

This unit hardens the workloads inside the perimeter from Unit 2, authenticated by the identities from Unit 1, encrypting their disks with the key primitives from Unit 3. Seven concepts carry most of the marks. The split is constant: AZ-500 configures the control on a resource; SC-100 specifies the requirement / chooses the control across platforms.

1. Bastion vs JIT — two different exposure-reduction tools

Why it matters: Open RDP/SSH on a public IP is the most-scanned attack surface in Azure, and both exams test how you remove it. The discriminator is connectivity broker vs time-boxed port opening.

• Azure Bastion is a managed PaaS jump host in a dedicated AzureBastionSubnet. You reach the VM over RDP/SSH inside a TLS session in the portal, and the VM needs no public IP at all. The exposure is eliminated, not merely scheduled.
• Just-in-Time (JIT) VM access is a Microsoft Defender for Servers Plan 2 feature. The management port stays denied in the NSG; on an approved request Defender opens a higher-priority allow rule scoped to (port, source IP, time window), then auto-closes it. Defaults: 22, 3389, 5985, 5986. Requires an NSG or Azure Firewall; Classic VMs are unsupported.

Worked example. A jump-box VM that admins use daily → Bastion (no public IP ever, no port to scan). A rarely-touched production VM that must occasionally be reached on a real NSG port → JIT (port denied by default, opened only for an approved 3-hour window from the requester’s IP, every request audited). The strongest answer combines them: Bastion for connectivity + JIT-governed exception + PIM-eligible admin role + Conditional Access, so the operator is just-in-time on identity and network.

AZ-500: deploy Bastion; enable/tune JIT in Defender for Cloud; lock the NSG. SC-100: design the privileged-remote-access strategy (Bastion + JIT + PIM + CA), extended to hybrid/multicloud via Azure Arc.

2. The four disk-encryption layers (and the ADE → encryption-at-host pivot)

Why it matters: Managed disks always have Server-Side Encryption (SSE) — AES-256, free, transparent — but SSE excludes temp disks and caches, so Defender for Cloud marks an SSE-only VM “Unhealthy” against the disk-encryption recommendation. The exam wants you to pick the right additional layer.

• Encryption at host encrypts temp/cache and the compute→storage flow at host level, with no VM CPU cost and custom-image support — but must be enabled at the subscription level (feature registration) first. It’s now the recommended baseline.
• ADE does in-guest BitLocker/DM-Crypt via a Key Vault KEK, costs CPU, and doesn’t support custom Linux images. Critically, ADE is retiring (Sept 15, 2028) — after that date ADE disks fail to unlock on reboot, so migrate ADE → encryption at host.
• Confidential disk encryption is only on Confidential VMs (AMD SEV-SNP); it binds the OS-disk key to the VM’s vTPM, releases keys bypassing the hypervisor/host, has Secure Boot on by default, and is immutable after deployment.

Worked example. A modern VM needs temp-disk coverage and runs a custom image → encryption at host. A workload that must exclude Microsoft operators/host from data-in-use → Confidential VM + confidential OS-disk encryption. A legacy app pinned to ADE → keep ADE but plan the migration before 2028. CMK for SSE/host/confidential uses a Disk Encryption Set; key custody and rotation themselves live in 03-data-storage-keyvault.

AZ-500: configure ADE/host/confidential + DES. SC-100: map the layer to data-sensitivity tiers; mandate “encryption at host” (or confidential) in landing-zone Azure Policy.

3. AKS authentication — Entra ID + disable local accounts

Why it matters: Kubernetes has no identity store, so AKS hardening starts at the control plane. This is the most testable AKS idea on both exams.

Deploy AKS with Microsoft Entra ID authentication so API-server requests validate against Entra and inherit Conditional Access, MFA, PIM. Then disable local accounts (--disable-local-accounts): the built-in cluster-admin is a certificate kubeconfig that bypasses Entra entirely — anyone who can list it gets unaudited cluster-admin. For an Entra outage, the break-glass path is to temporarily re-enable local accounts and run az aks get-credentials --admin, which requires the AKS Contributor role (an ARM-evaluated permission, so it works even when Entra sign-in is down). Authorization is then either Kubernetes RBAC (namespace Roles/RoleBindings) or Azure RBAC for Kubernetes (--enable-azure-rbac, so Azure role assignments + PIM govern the cluster).

Worked example. A bank requires every cluster admin to be MFA-gated and audited. You enable Entra integration, --disable-local-accounts to kill the bypass kubeconfig, and --enable-azure-rbac so cluster-admin is a PIM-eligible Azure role. Pods that need Azure resources use Entra Workload ID (OIDC + federated service-account tokens) — no stored secrets, replacing the deprecated pod-managed-identity.

AZ-500: configure Entra + Azure RBAC, disable local accounts, workload identity. SC-100: design the enterprise-access model for cluster admin (PIM-gated, control-plane isolation).

4. AKS network isolation — private cluster vs authorized IP ranges

Why it matters: “How do I keep the API server off the public Internet?” is a recurring design item, and the gotcha is reversibility.

• Private cluster — the API server gets an internal IP reachable only via an Azure Private Endpoint in the cluster VNet; you disable the public FQDN. For standard private clusters you cannot convert an existing public cluster to private — decide at creation. (Clusters built with API Server VNet Integration are the exception: private mode can be toggled after provisioning.)
• API server authorized IP ranges — keep the cluster public but allowlist CIDRs (≤200 ranges; ≤2000 with VNet Integration). Mutually exclusive with private clusters.
• Pod-to-pod traffic is governed by a Network Policy engine — Cilium (eBPF, L3-L7 + FQDN, recommended), Azure NPM (no IPv6, ≤250 nodes), or Calico.

Worked example. A regulated cluster with no Internet exposure → private cluster chosen at creation, with ACR Private Link into the cluster VNet so image pulls stay private. An existing public cluster you can’t rebuild → fall back to authorized IP ranges. Layer on the Azure Policy add-on (Gatekeeper/OPA) to enforce “only signed images / no privileged pods / approved registries” at admission.

AZ-500: configure private cluster / authorized ranges / network policy. SC-100: design the AKS landing-zone isolation (private cluster in hub-spoke, Private Link to ACR/Key Vault).

5. ACR supply chain — Notation, not Docker Content Trust

Why it matters: “Ensure only trusted/signed images” is a classic exam stem, and the correct answer just changed.

• Authentication, least-privilege first: prefer Entra identities (user / SP / managed identity — the right choice for ACI/ACA/AKS pulls). Disable the admin account (a single shared cred that defeats per-identity audit). For scoped CI/CD, use repository-scoped tokens. Roles: AcrPull, AcrPush, AcrDelete.
• Image signing: Docker Content Trust (DCT) is deprecated — it cannot be enabled on new registries after May 31, 2026 and is removed Mar 31, 2028. The replacement is the Notary Project / Notation CLI: OCI-standard portable signatures stored alongside the image, with signing keys in Azure Key Vault, integrated into pipelines and verifiable at AKS admission.

Worked example. A pipeline must guarantee only signed images reach production. You sign each image with Notation (Key Vault-held key), store the signature in ACR, and configure AKS admission + Defender gated deployment to reject unsigned images. On the exam, if the answer choices include DCT, it’s the distractor — choose Notation.

AZ-500: manage ACR access (disable admin, AcrPull/AcrPush, Private Endpoint). SC-100: design the end-to-end container supply chain — sign (Notation+Key Vault) → scan (Defender) → gate (Azure Policy / Defender gated deployment) → pull via managed identity over Private Link.

6. Windows LAPS — kill the shared local-admin password

Why it matters: This is a pure-SC-100 design objective (“Evaluate Windows LAPS”), and it’s the canonical answer to Pass-the-Hash / lateral movement.

Windows LAPS auto-rotates a per-device local administrator password so one cracked hash no longer unlocks the whole fleet. Two deployment paths you must distinguish:

• Microsoft Entra-joined → Microsoft Intune policy; password backed up to Entra ID, retrieval secured by Entra RBAC (and you can layer Conditional Access on the recovery role).
• AD-joined → Group Policy; password stored in Active Directory, secured by ACLs + optional encryption.

It is not supported on Entra-registered devices or non-Windows.

Worked example. A company’s helpdesk uses the same local-admin password on every laptop — one phished hash = domain-wide lateral movement. Design answer: Windows LAPS via Intune for the Entra-joined fleet (password in Entra ID, retrieval RBAC-gated and audited) and via GPO for AD-joined servers, eliminating the shared credential entirely.

7. Defender for IoT (OT/ICS) + AI-services security — the two niche SC-100 designs

Why it matters: Both are SC-100-only “evaluate” objectives that reward knowing the mechanism.

• Defender for IoT (OT) is agentless, passive, network-layer monitoring. An OT sensor (VM or appliance) receives mirrored traffic from a SPAN port or TAP and does Deep Packet Inspection on-sensor — ideal for air-gapped / low-bandwidth plants where only telemetry leaves. It maps devices to the Purdue model, baselines behavior (NISTIR 8219), and runs cloud-connected (alerts to the portal + Sentinel) or locally managed / air-gapped. Enterprise IoT (printers, cameras) is instead an add-on to Defender for Endpoint surfaced in Defender XDR.
• Azure AI services security mirrors any PaaS data plane: set disableLocalAuth = true for keyless Entra ID auth (Cognitive Services RBAC), front it with Private Link, encrypt at rest with CMK (enabling CMK auto-creates a system-assigned MI granted Key Vault access), and add content filtering / abuse monitoring.

Worked example — manufacturing plant. PLCs and RTUs that can’t run agents → deploy a Defender for IoT OT sensor on a SPAN port, segment per Purdue, and stream alerts to Sentinel (using the ICS MITRE matrix). For a customer-facing Azure OpenAI app → the design answer is keyless (disableLocalAuth) + Private Link + CMK + Cognitive Services RBAC.

AZ-500: configures the AI-services knobs (disable local auth, RBAC, Private Link) where in scope. SC-100: evaluate Defender for IoT for OT/ICS and evaluate AI-services security as part of the workload design.

Unit 5 — Posture, Governance, Compliance & Multicloud

Full coverage: 05-posture-governance-defender-cloud · Quick reference: 01-Cheat-Sheet · Dates/control-weights: 99-Appendix

These are the concepts that pay the most across AZ-500 and SC-100. Each has a worked scenario and the why-it-matters for both exams. Plan enablement is consumed from prior units — this unit governs and measures the resources those units built.

1. Azure Policy effects: audit → deny → deployIfNotExists

The concept: A policy definition has one effect that decides what happens on a match. The three you must choose between: audit (log only), deny (block the create/update), and deployIfNotExists/DINE (auto-deploy a fix). modify/append mutate the request; denyAction blocks an operation like delete.

Worked example: Compliance requires every storage account to deny public blob access.

1. Author a definition with the effect parameterized.
2. Assign it at the management group in audit mode first and watch the compliance dashboard — 40 of 120 accounts are noncompliant, but nothing breaks.
3. Graduate the effect to deny. New noncompliant accounts are blocked at creation. But the existing 40 are not fixed — deny only stops future drift.
4. To fix the 40 existing accounts you use a modify or DINE policy plus a remediation task (which needs a managed identity with rights to change those resources). New/updated resources remediate automatically; existing ones need the explicit task.

Why it matters: AZ-500 tests the mechanics (pick the effect, know DINE needs an MI + remediation task, existing-vs-new behavior). SC-100 tests the design (“design Azure Policy solutions for compliance” = MG-scoped initiatives + audit-then-deny safe rollout + DINE for landing-zone auto-hardening). Gotcha: a policy assigned at a management group still only evaluates resources at subscription/RG level.

2. The Policy ⟷ Defender for Cloud through-line (MCSB)

The concept: This is the single idea that unifies the whole unit. Every regulatory standard in Defender for Cloud is an Azure Policy initiative. When you enable Defender for Cloud, the MCSB initiative is auto-assigned and immediately starts assessing resources. Each MCSB control is a group of policy-backed assessments; a failing assessment becomes a recommendation; remediating recommendations raises your secure score.

Worked example: You enable Defender for Cloud. Without doing anything else, the regulatory compliance dashboard shows MCSB controls like “Storage accounts should restrict network access” — behind that control is an Azure Policy assessment. A storage account with open network rules shows as a recommendation; fix it (or click Enforce to deploy the policy, or Deny to block future ones) and both the MCSB control and the secure score improve.

Why it matters: AZ-500 — explains why “create policies” and “assess compliance with Defender for Cloud” are the same domain. SC-100 — this is the backbone of “translate compliance requirements into security controls”: clause → control → initiative → assessed recommendation.

3. Secure Score — the two models (and which one a question means)

The concept: There are two secure scores and exam questions hinge on telling them apart.

• Classic (Azure portal): percentage of a max, built from fixed control weights, recalculated every 8 hours, driven only by built-in MCSB recommendations. A control gives points only when all its recs are healthy for all resources.
• Cloud Secure Score / risk-based (Defender portal): 0–100, weighting recommendations by risk level × asset criticality × asset risk factors (internet exposure, data sensitivity).

Worked example: You remediate one of three “Secure management ports” recommendations on half your VMs. In the classic model that control (weight 8) gives zero extra points until all its recs are healthy for all VMs — partial fixes don’t move the needle. In the risk-based model, 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.

Why it matters: AZ-500 — the classic control-weight table is high-frequency (MFA=10 is the top); know “all-or-nothing per control” and the 8-hour cadence. SC-100 — “evaluate posture using Secure Score and Defender for Cloud” expects the risk-based/criticality model for prioritization. Gotcha: preview recommendations and risk prioritization do not affect the classic secure score.

4. Defender for Servers P1 vs P2 (and agentless scanning)

The concept: P1 = Defender for Endpoint EDR integration + agent-based vulnerability assessment. P2 = everything in P1 plus agentless scanning (VA, malware, secrets, EDR-config — snapshot-based, no agent, no performance hit), premium MDVM, file integrity monitoring, JIT VM access, OS baseline/update assessment, regulatory compliance, and a free 500 MB/day data benefit.

Worked example: A team runs latency-sensitive VMs and forbids extra agents, but you need malware + vulnerability data. Answer: enable P2 and rely on agentless scanning — it reads from disk snapshots, so no in-guest agent and no perf impact, yet you still get VA, malware, and secrets findings. If they only needed real-time EDR and accepted the MDE agent, P1 would suffice.

Why it matters: AZ-500 — “configure Defender for Servers” + “implement agentless scanning” + “implement MDVM”; know agentless is P2 only, agent-based VA is P1 and P2. SC-100 — “select cloud workload protection solutions”: P1 vs P2 by agent tolerance, performance, and feature need.

5. Azure Arc as the hybrid/multicloud keystone

The concept: Defender for Cloud can only govern Azure resources — so Azure Arc turns on-prem and AWS/GCP machines into first-class Azure resources (via the Connected Machine agent). Once Arc-enabled, Azure Policy, Defender for Servers, and MDVM all apply, and the machine shows in Inventory and secure score.

Worked example: 200 on-prem Windows servers + an AWS EC2 fleet to bring under one posture pane. On-prem → onboard as Arc-enabled servers. AWS → add the AWS connector, which auto-deploys the Arc agent to the EC2 instances. Now all of them are assessed against MCSB, protected by Defender for Servers, and scanned by MDVM — exactly as Azure VMs are.

Why it matters: AZ-500 — “connect hybrid and multicloud environments to Defender for Cloud, including AWS and GCP.” SC-100 — “design a solution for integrating hybrid and multicloud environments by using Azure Arc”; Arc is the canonical design answer for a single multicloud posture view.

6. Custom standards/recommendations & the compliance→Purview flow

The concept: Beyond built-in standards (PCI DSS, ISO 27001, NIST, SOC 2 — addable once ≥1 paid plan is enabled), you can author custom standards and custom recommendations using KQL — but only with the Defender CSPM plan. All Defender for Cloud compliance data flows automatically into Purview Compliance Manager.

Worked example: An internal rule not covered by any framework (“all prod VMs must have tag owner”). You write a KQL custom recommendation, place it in a custom standard, and it appears in the regulatory compliance dashboard alongside MCSB and contributes to posture. Simultaneously your PCI DSS results surface in Compliance Manager, where a compliance officer sees improvement actions across Azure, AWS, and M365 in one place.

Why it matters: AZ-500 — “add custom standards” + “manage compliance standards.” SC-100 — “design a solution to address compliance requirements using Microsoft Purview.”

7. MSEM attack paths & choke points (SC-100’s posture-process answer)

The concept: Microsoft Security Exposure Management (Defender portal, GA Nov 2024) reframes posture from “fix every recommendation” to “cut the attacker’s path.” Attack paths run from an entry point to a critical asset; choke points are where many paths converge; the enterprise exposure graph (KQL-queryable) and attack surface map visualize it; security initiatives track exposure over time.

Worked example: Instead of remediating 800 flat recommendations, you define your critical assets (the crown-jewel SQL database), and MSEM shows that 30 attack paths converge on one mis-permissioned jump host — a choke point. Fixing that one node collapses many paths at once.

Why it matters: SC-100 only — “specify requirements and priorities for a posture management process that uses MSEM attack paths, attack surface reduction, security insights, and initiatives.” AZ-500 does not test MSEM — don’t spend AZ-500 study time here, but know it cold for SC-100.

8. EASM — the outside-in view

The concept: Defender EASM discovers internet-facing assets the attacker can see, starting from seeds (domains, IP blocks, hosts, email contacts, ASNs, WHOIS orgs) and recursing through DNS/WHOIS/SSL/ASN links into a confirmed-vs-candidate inventory.

Worked example: You seed contoso.com. EASM finds a forgotten staging subdomain on an unpatched host nobody tracked — an asset outside the firewall and outside your CMDB. It lands in inventory as “Requires Investigation” for triage.

Why it matters: AZ-500 — “implement and use Defender EASM.” SC-100 — “design a solution for Defender EASM” and how its external findings feed the MSEM EASM initiative.

Unit 6 — Security Operations (Sentinel, XDR, SOAR)

Full coverage: 06-secops-siem-xdr-soar · Quick reference: 01-Cheat-Sheet · Dates/portal-retirement: 99-Appendix

These concepts recur across AZ-500 case questions and SC-100 design scenarios. Posture/Defender-for-Cloud plan enablement is a prerequisite (05-posture-governance-defender-cloud) — this unit consumes the connectors, DCRs, and Defender plans you stood up there.

1. The product map: Sentinel (SIEM+SOAR) vs Defender XDR (XDR) vs the Defender portal

The single most clarifying mental model: three layers, one console.

• Microsoft Defender XDR is the XDR — it natively correlates signals from Defender for Endpoint, Identity, Office 365, Cloud Apps, and Defender for Cloud into a single incident with the full attack story. Microsoft-first-party, deep, largely automatic.
• Microsoft Sentinel is the cloud-native SIEM + SOAR — it ingests everything (Microsoft, third-party, AWS/GCP, on-prem syslog) into a Log Analytics workspace, runs analytics rules over it (KQL), and orchestrates response with playbooks. The breadth layer.
• The Microsoft Defender portal is the unified console that now hosts both, plus Security Exposure Management and Security Copilot.

Worked example: A laptop runs ransomware. Defender for Endpoint detects it, XDR auto-correlates the related identity compromise and mailbox rule into one incident, and attack disruption isolates the device. Meanwhile your Palo Alto firewall logs (third-party, not seen by XDR) flow into Sentinel via a CEF/AMA connector; a Sentinel Fusion rule correlates the firewall’s C2 beacon with the XDR endpoint alert into a higher-fidelity multistage incident. You investigate it all in one queue in the Defender portal.

AZ-500: “Configure data connectors / enable analytics rules / configure automation” — wire up Sentinel. SC-100: “Design a solution for detection and response that includes XDR and SIEM” — decide that you use XDR for Microsoft-native depth and Sentinel for breadth/multicloud, and how they integrate.

Current critical fact: Sentinel in the Azure portal retires March 31, 2027; new customers onboarding after July 2025 with Owner/User Access Administrator are auto-onboarded to the Defender portal. Both exams now assume the unified portal as target state.

2. Data Collection Rules (DCRs) — the ingestion control plane (AZ-500 heavy)

A DCR is an Azure Monitor object that answers three questions for a stream of telemetry: what source, what transformation, what destination. It’s used by the Azure Monitor Agent (AMA) and the Logs Ingestion API.

The exam favorite is the ingestion-time transformation: a KQL snippet inside the DCR that runs against every record before it lands in the workspace. You use it to filter noise (cut cost), mask PII before persistence, or reshape/enrich to match a destination schema.

Worked example: You collect Linux syslog via the Syslog-via-AMA connector. Auth logs are valuable; cron chatter is not. In the DCR transformation you write source | where Facility != "cron" and project only the fields you need. The dropped data never hits the workspace, so you never pay for it — and Sentinel-enabled workspaces are exempt from Azure Monitor’s filtering ingestion charge, so aggressive filtering is free.

Two DCR flavors: a standard DCR attached to a data source (AMA on specific VMs / a Logs Ingestion API call), and a workspace transformation DCR (one per workspace) that transforms data for built-in connectors that don’t bring their own DCR. Custom-log gotcha: a custom table must end in _CL and (for Custom Logs via AMA) contain TimeGenerated + RawData.

AZ-500: “Monitor network security events and performance data by configuring DCRs in Azure Monitor.” SC-100: DCRs are the mechanism behind “centralized logging” and “cost-optimized monitoring” — you design what to keep vs filter and where it lands.

3. Analytics rule types — knowing which detection engine fits

Worked example (Fusion, the high-yield one): An impossible-travel sign-in alert (Entra ID Protection) plus a mass-file-download alert (Defender for Cloud Apps) are individually noisy. Fusion’s ML correlates them — same user entity, attack chain across Initial Access → Exfiltration — into a single high-confidence “data exfiltration following suspicious sign-in” incident. The catch the exam tests: Fusion only works if the contributing scheduled rules have entity mapping and MITRE tactics configured. Forget entity mapping and Fusion silently can’t correlate.

AZ-500: “Enable analytics rules” — install templates, configure KQL/schedule/entity mapping. SC-100: “Design and evaluate threat detection coverage” — choose the rule mix and ensure entity/MITRE hygiene so correlation works.

4. SOAR: automation rules vs playbooks, and the unified-portal twist

Two distinct objects people conflate:

• Automation rule = the lightweight orchestration/triage layer. Trigger (incident created/updated, or alert created) → conditions → ordered actions: assign owner, set severity/status, add tags, create tasks, run a playbook. No code.
• Playbook = an Azure Logic Apps workflow that does the heavy lifting (isolate a device via MDE, block an Entra user, open a ServiceNow ticket). Incurs Logic Apps cost.

The recommended pattern is incident-triggered automation: an automation rule fires on incident creation and calls a playbook built on the Sentinel incident trigger.

Worked example: Analytics rule detects credential stuffing → incident created → automation rule (Order 100) assigns it to the IR team, sets severity High, and runs the “Block-Entra-User-and-Isolate-Device” playbook. The playbook authenticates with a managed identity (least privilege, no stored secrets).

Two exam-critical gotchas:

1. Unified portal: when Sentinel is onboarded to the Defender portal, Defender owns incident creation, so you disable incident creation on the analytics rule and use alert-triggered automation.
2. Deprecation: attaching a playbook directly to an analytics rule (the legacy method) is deprecated — those stop running March 2026. Migrate to automation rules.

AZ-500: “Configure automation in Microsoft Sentinel” — build the automation rule + wire the playbook + grant the Microsoft Sentinel Playbook Operator role. SC-100: “Design a SOAR solution including Sentinel and Defender XDR” — decide which responses are XDR-native (attack disruption, AIR) vs Sentinel-orchestrated (cross-tool playbooks).

5. Defender XDR automated response — the XDR half of SOAR

Don’t think Sentinel is the only automation engine. Defender XDR brings its own:

• AIR (Automated Investigation & Response) acts as a virtual analyst: an alert triggers an automated investigation that reaches a verdict (malicious / suspicious / no threat) and proposes or executes remediation, with self-healing of devices, identities, and mailboxes.
• The automation level is configured per device group — Microsoft recommends Full – remediate automatically.
• Automatic attack disruption is the headline: high-confidence, machine-speed containment (isolate a device, disable an account) without a human, stopping lateral movement mid-attack.

Worked example: MDE flags a device running a known ransomware family. Attack disruption isolates the device and disables the implicated account within seconds; AIR quarantines the dropped files and the Action center logs every action. No Sentinel playbook fired — this is XDR-native SOAR.

AZ-500: touches this via “respond to security alerts in Defender for Cloud.” SC-100: “Design a SOAR solution including … Defender XDR” — architect when to rely on XDR’s native automation vs Sentinel orchestration. Rule of thumb: Microsoft-native, high-confidence containment → XDR; cross-tool/third-party/custom → Sentinel playbooks.

6. MITRE ATT&CK coverage design (SC-100 signature objective)

ATT&CK is the lingua franca for measuring detection coverage. Sentinel is aligned to ATT&CK v18 and surfaces a MITRE page overlaying your detections onto the tactic×technique matrix, distinguishing active coverage (rules currently running) from simulated coverage (templates you could enable).

Worked example: The matrix shows strong Initial Access / Execution coverage but a gap at Exfiltration. You enable a simulated rule template for “mass file download,” tag it with the relevant technique — active coverage now closes the gap, and SOC optimization tells you the ingestion impact so you can prioritize.

For SC-100 you must know there are three matrices: Enterprise (cloud/endpoint/identity — default), Mobile, and ICS (industrial/OT — pair with Defender for IoT). A coverage design for an OT/manufacturing environment must reach for the ICS matrix, not Enterprise alone.

AZ-500: tag analytics rules with MITRE tactics/techniques (hygiene). SC-100: “Design and evaluate threat detection coverage using MITRE ATT&CK matrices, including Enterprise, Mobile, and ICS” — gap analysis and prioritization at the architecture level.

7. Centralized logging & Purview Audit (SC-100)

Detection is only as good as the logs feeding it. SC-100’s “centralized logging and auditing” spans two ideas:

1. Operational/security logs → Sentinel’s Log Analytics workspace (via connectors + DCRs), with Defender for Cloud continuous export and the DfC connector funneling cloud-posture alerts in. For hybrid/multicloud you Arc-enable servers and connect AWS/GCP to Defender for Cloud.
2. Audit/forensic logs → Microsoft Purview Audit. Know the tiering: Audit (Standard) gives baseline logging; Audit (Premium) adds audit log retention policies (longer retention), more high-value events, and supports forensic investigation of compromised accounts.

Worked example: A compromised-mailbox investigation needs to know which messages the attacker accessed. That MailItemsAccessed event and extended retention are Purview Audit (Premium) features — a Standard tenant wouldn’t have the evidence. SC-100 design answers for “investigate the blast radius of an account compromise” should specify Audit (Premium).

Unit 7 — Application, API & M365 Data Protection

Full coverage: 07-apps-m365-strategy-capstone · Quick reference: 01-Cheat-Sheet · Dates/licensing: 99-Appendix

Seven concepts carry most of the exam weight. The unifying insight: AZ-500 makes you configure exactly one thing in this unit (APIM); SC-100 makes you choose the right product/plan/mode/policy. Learn the decision tables once and you pass both.

1. APIM policy chain — the one place you operate

Scenario: A partner-facing API fronts a legacy backend that can’t speak OAuth. Requirement: callers authenticate with Entra-issued tokens; the legacy backend must trust only the gateway; no secrets in source control.

Design:

1. At the gateway, add validate-azure-ad-token (preferred over validate-jwt because the issuer is Entra) — it checks signature, expiry, audience, and allowed client app IDs before the request reaches the backend.
2. Secure the gateway→backend hop with mTLS or APIM’s managed identity — the legacy backend never sees the caller’s token, only a trusted gateway connection.
3. Publish through a product that requires a subscription (never an open product) so every caller carries a subscription key for identification/throttling.
4. Any secret goes in a named value integrated with Key Vault, authenticated via APIM’s managed identity.
5. Harden: ip-filter allowlist, disable TLS 1.0/1.1, strip response headers, no API tracing in prod, enable Defender for APIs.

Why it matters: AZ-500 asks “which policy/setting” (it’s validate-azure-ad-token + named values + mTLS). SC-100 asks “design API management & security end-to-end” — same controls, plus you justify internal-VNet isolation and gateway placement. The validate-token-then-secure-the-backend-hop pattern is the single most testable APIM idea on both exams.

2. Defender for Office 365 — Plan 1 vs Plan 2 is a verb test

Scenario: Security team wants to (a) block malicious attachments and links, and (b) run phishing simulations and auto-investigate compromised mailboxes.

Design: (a) is Plan 1 — Safe Attachments (sandbox detonation), Safe Links (time-of-click rewriting), anti-phishing with impersonation protection. (b) requires Plan 2 — Attack simulation training, Automated Investigation and Response (AIR), Threat Explorer, and Defender XDR integration.

The tell: if the requirement is prevent/block, it’s P1. If it’s investigate / automate / simulate / hunt, it’s P2 (AIR is the clearest P2 marker). EOP underneath both provides baseline anti-spam/malware. Safe Documents is a trap — it’s not in either MDO plan; it needs M365 A5 / Defender suite.

Why it matters: SC-100 “evaluate solutions that include Defender for Office 365” is almost always a plan-selection question.

3. Defender for Cloud Apps — pick the right one of three modes

Scenario A — “we don’t know what SaaS our users adopted”: Cloud Discovery. Feed it proxy/firewall logs or integrate Defender for Endpoint to see off-network traffic. It scores ~31,000 apps against ~90 risk factors; tag risky apps unsanctioned to block them.

Scenario B — “prevent download of confidential files to unmanaged devices in real time”: Conditional Access App Control (CAAC). An Entra Conditional Access policy routes the session through MDCA (reverse proxy), then a session policy blocks download / forces label-on-download. Note: CAAC is app-level, not file-level — you can’t exempt a single file.

Scenario C — “continuously monitor sanctioned M365 + Salesforce for anomalies and risky OAuth apps”: API connectors + app governance.

Why it matters: SC-100 pairs MDO and MDCA in one objective; the exam discriminates on mode: discovery (visibility) vs API connector (monitoring) vs CAAC (real-time inline control). CAAC’s dependency on Entra CA and its app-level granularity are favorite distractors.

4. Intune — three policy types, and who enforces

Scenario: Contractors use personal phones (BYOD) you can’t fully manage, but corporate email must stay contained; employees’ laptops must be encrypted and compliant before reaching M365.

Design:

• BYOD phones → App protection policy (MAM) — contains data inside managed apps (block copy/paste/save-out), no device enrollment required — enforced via app-based Conditional Access.
• Employee laptops → Compliance policy (encryption, min OS, MTD risk) → reported to Entra → device-based Conditional Access gates M365.
• Fleet hardening baseline → Configuration profile.

The non-negotiable fact: Intune evaluates compliance; Microsoft Entra Conditional Access enforces it (the CA node is identical in both portals; CA needs Entra ID P1/P2).

Why it matters: SC-100 “evaluate device management solutions that include Intune” tests whether you map a requirement (BYOD containment vs managed-device gating vs baseline config) to the right policy type — and whether you know CA, not Intune, is the enforcement point.

5. Copilot for M365 — the two DLP controls and their licensing cliff

Scenario: Contoso wants Copilot to (a) refuse prompts containing SSNs, and (b) never summarize files labeled “Highly Confidential.”

Design: Both are Purview DLP for the “Microsoft 365 Copilot and Copilot Chat” location, but:

• (a) Restrict by sensitive information type (SIT) safeguards prompts — available to ALL Copilot licenses.
• (b) Restrict files/emails by sensitivity label blocks grounding/summarization — requires M365 E5 / Purview suite. The labeled item still appears in citations, but its content isn’t used.
• Authoring gotcha: you can’t put a SIT condition and a label condition in the same rule — make a separate rule per condition in the same policy.

Foundationally, Copilot already honors each user’s permissions and sensitivity labels (VIEW-without-EXTRACT → no summarization, link only) and inherits the highest-priority label on generated content.

Why it matters: This is a newer, high-yield SC-100 objective. The prompt-vs-label distinction and its licensing asymmetry (prompts = all tiers, labels = E5) are exactly what the exam rewards.

6. The two Secure Scores — the classic trap

Scenario: “Evaluate posture for productivity and collaboration workloads using a metric.” → Microsoft Secure Score (Defender portal), grouped into Identity / Device / Apps / Data, spanning M365 products and third-party SaaS.

Contrast: “Evaluate Azure/multicloud workload posture” → Microsoft Defender for Cloud Secure Score, which is MCSB-based and lives in 05-posture-governance-defender-cloud. Different portal, different math, different scope.

Why it matters: SC-100 deliberately conflates these in distractors. The discriminator is the workload: M365/collaboration → Microsoft Secure Score; Azure/AWS/GCP infra → Defender for Cloud Secure Score. Memorize the four groups (Identity/Device/Apps/Data) as the fingerprint of the M365 one.

7. Threat modeling + DevSecOps — the design discipline

Scenario: A new business-critical web app. Before code, the architect runs a design-phase threat model.

Design: Use the Microsoft Threat Modeling Tool (a core element of the Microsoft SDL) and classify threats with STRIDE — Spoofing→require HTTPS/Entra auth, Tampering→validate TLS, Repudiation→Azure Monitor logging, Information disclosure→encrypt at rest, DoS→rate-limit/WAF, Elevation→PIM/least privilege. Then shift-left in CI/CD: SAST (static) + DAST (runtime), via GitHub Advanced Security / Defender for Cloud DevOps security. MCSB control DS-1 formalizes threat modeling of the pipeline itself, not just runtime.

Why it matters: SC-100 has four lifecycle objectives (full lifecycle, dev-process standards, threat modeling, map technologies to requirements). They all reduce to: model with STRIDE during design, embed SAST/DAST in DevSecOps, and map each requirement to a concrete Microsoft control (e.g., “no stored credentials” → managed identity/workload identity).

Unit 8 — Capstone (Zero Trust, MCRA/MCSB/CAF/WAF, Landing Zones, BCDR)

Full coverage: 07-apps-m365-strategy-capstone (capstone half) · Quick reference: 01-Cheat-Sheet · Dates/frameworks: 99-Appendix

This is the capstone. There’s almost no AZ-500 operational content here (the blueprint is honest: this unit is pure SC-100 synthesis). The value is a single mental shift: AZ-500 taught you to configure individual controls; SC-100 tests whether you can choose a framework, set priorities, and sequence those controls into a defensible strategy. Master the five concepts below.

1. The Five Frameworks — pick the right lens for the question

Why it matters (both exams): SC-100 questions rarely say “configure X.” They say “design a strategy aligned with best practices.” The examiners check that you reach for the correct framework:

• MCRA (Microsoft Cybersecurity Reference Architectures) — reference diagrams mapping Microsoft’s security capabilities across identity, SecOps, endpoints, OT/IoT, multicloud. Answers “which Microsoft capability covers this domain?”
• MCSB (Microsoft cloud security benchmark) — prescriptive controls (Network Security, Identity Management, Privileged Access, Data Protection, Backup & Recovery…) with Azure/AWS/GCP guidance. Answers “what’s the secure configuration and how do I measure compliance?” MCSB is the default compliance standard inside Defender for Cloud.
• CAF (Cloud Adoption Framework) — the org-wide adoption lifecycle: Strategy → Plan → Ready → Adopt → Govern → Secure → Manage. Answers “how does the whole organization adopt cloud securely?”
• WAF (Well-Architected Framework) — five pillars (Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency) for one workload’s quality. Answers “is this specific workload well-designed?”
• Zero Trust — the security model (Verify explicitly · Least privilege · Assume breach) that underpins all the others.

Worked example: A retailer asks you to (a) standardize how every new app team gets a secure Azure subscription, and (b) review whether their flagship e-commerce app is resilient and cost-efficient. Two questions, two frameworks: (a) is a CAF / landing zone problem (whole estate, governance at scale); (b) is a WAF problem (single workload, five pillars). Answering “WAF” for the org-wide standardization is the single most common SC-100 trap. CAF = the estate; WAF = the workload.

2. Zero Trust + RaMP — strategy with a priority order

Why it matters (both exams): SC-100 explicitly tests “design solutions aligned with Zero Trust, including RaMP.”

• Three principles: Verify explicitly, Use least-privilege access, Assume breach.
• Seven technology pillars: Identities, Endpoints, Data, Apps, Infrastructure, Network — plus a seventh, cross-cutting pillar that Microsoft officially names Visibility, automation, and orchestration (the SecOps pillar). These map almost 1:1 onto the prior seven units.
• RaMP (Rapid Modernization Plan) is a set of project-management checklists that enumerate technical objectives in priority order with named owners (executive sponsor → program lead → security architect → admin). RaMP’s job is to surface quick wins.

The single most important priority to memorize: Microsoft says secure privileged access first. Attackers exploit weak privileged access in nearly every human-operated ransomware case. If an SC-100 question asks “what do you do first in a Zero Trust modernization / ransomware-hardening effort?” the answer is privileged access (dedicated admin accounts + PAWs + PIM JIT + Conditional Access auth context), then BCDR.

Worked example: “A bank wants to start Zero Trust but has limited budget for year one. Which initiative gives the biggest risk reduction?” → Don’t answer “deploy everything.” Answer “use RaMP to prioritize securing privileged access” — dedicated admin identities, PIM for JIT elevation, Conditional Access requiring phishing-resistant MFA + compliant PAW. That’s the canonical RaMP quick win.

Two RaMPs exist: the Zero Trust RaMP (user access & productivity, data governance, modernize SecOps) and the privileged-access RAMP (adopt the privileged-access strategy via the enterprise access model). They’re complementary, not the same checklist.

3. The Enterprise Access Model — how privileged access is architected

Why it matters (both exams): AZ-500 had you operate PIM and Conditional Access (01-identity-access-foundations). SC-100 asks you to design the model they plug into — the enterprise access model, which replaced the legacy AD “tier 0/1/2” model.

• Three planes: Control plane (identity systems, Entra ID) → Management plane (resource/subscription admin) → Data/workload plane (apps and data). Lower planes must never control higher planes — otherwise an attacker who owns a workload VM can pivot to owning the directory.
• Architecture = dedicated admin accounts + Privileged Access Workstations (PAWs) + PIM JIT elevation + Conditional Access authentication context gating role activation + emergency break-glass accounts.

Worked example: A workload team requests Owner on the subscription that hosts the central Entra Connect server “for convenience.” Under the enterprise access model you refuse: that server is control plane, the workload team operates at the data/workload plane, and granting them control-plane access collapses the hierarchy that prevents lateral escalation. Their access stays scoped to their application landing zone; control-plane admin is a separate, PAW-only, PIM-gated path.

4. Azure Landing Zones — governed foundation at scale

Why it matters (both exams): This is CAF’s “Ready” methodology made concrete, where the governance controls (05-posture-governance-defender-cloud) and the networking (hub-spoke, Virtual WAN) come together into a repeatable foundation.

• A landing zone = a pre-built, governed environment with eight design areas: Azure billing & Entra tenant, Identity & access management, Resource organization, Governance, Network topology & connectivity, Security, Management, and Platform automation & DevOps.
• Platform landing zone = shared services (typically Identity, Management, Connectivity subscriptions) owned by a central platform team.
• Application landing zone = one workload, with a separate landing zone per environment (dev/test/prod), provisioned through subscription vending, inheriting Azure Policy from its parent management group (e.g., Corp vs Online).

Worked example: A company spins up subscriptions ad hoc; each team configures its own networking and policies, and the security team can’t enforce anything consistently. The design answer: deploy Azure landing zones — a management-group hierarchy (Platform / Landing zones / Sandbox / Decommissioned), Azure Policy at management-group scope for governance-by-default, a platform landing zone for shared identity/connectivity/management, and subscription vending so every new app team lands in a pre-secured environment. Governance becomes inherited, not bolted on.

5. Ransomware Resiliency & BCDR — protect the backup itself

Why it matters (both exams): The densest single exam topic in the unit, where AZ-500 (you configured Azure Backup, soft delete, immutable storage in 03-data-storage-keyvault) and SC-100 (you design the resiliency strategy) meet most directly.

Microsoft’s ransomware guidance has a clear prioritization: (1) secure privileged access, and (2) BCDR — specifically, protect your backups so the attacker can’t destroy your recovery path. Modern human-operated ransomware targets the backups first, so a backup an admin can delete is a backup the attacker can delete.

The defense-in-depth stack for Azure Backup / Recovery Services vault:

Worked example: “A ransomware actor compromises a Backup Operator account and tries to delete all recovery points before encrypting production. What design stops them?” Soft delete alone is insufficient — a compromised admin can disable soft delete. The correct layered answer: immutable vault (irreversible) so recovery points can’t be deleted before expiry, plus MUA via Resource Guard so disabling protection requires a second approver the attacker doesn’t control, plus PIM so even legitimate destructive operations are JIT and audited. That’s the difference between an AZ-500 “I enabled soft delete” answer and an SC-100 “I designed a tamper-resistant recovery path” answer.

Tie-in: Defender for Cloud ransomware alerts can trigger a Logic App that pauses recovery-point expiry, preserving backups during an active incident — connecting this unit back to 06-secops-siem-xdr-soar (SOAR automation).