cheat

Cheat Sheet

AZ-500 / SC-100 Master Cheat Sheet

One-page, exam-critical recall layer for the whole study guide. Organized by the unit hierarchy. Each section carries a delta callout mapping the AZ-500 (operate/configure) skill to the SC-100 (design/evaluate) skill for the same concept, and links to its [[full guide]] note and [[02 High-ROI]] entry.

The defining pattern of both exams: AZ-500 turns the knobs; SC-100 decides which knobs exist and why.

Unit map: 1 Identity · 2 Data/Key Vault · 3 Compute/Containers · 4 SecOps · 5 Capstone


1 Identity, Access & Privileged Access

Notes: Identity Access & Privileged Access — Full Guide · 02 High-ROI — Identity Access & Privileged Access

Two RBAC systems (NEVER conflate — top exam trap)

Azure RBACMicrosoft Entra roles
ControlsAzure resources (control + data plane)Tenant/directory objects (users, groups, apps, CA)
ScopeMgmt group → subscription → RG → resource (inherits down)Tenant-wide (some scopable to AU / app)
DefinitionActions/NotActions/DataActions/NotDataActions + AssignableScopesFixed set; custom via Entra role permissions
Stored inAzure Resource ManagerMicrosoft Entra ID
ExampleOwner, Contributor, Reader, User Access Administrator, RBAC AdministratorGlobal Admin, Privileged Role Admin, User Admin
  • 3 elements of an Azure role assignment = security principal + role definition + scope.
  • Custom Azure role limits: 5,000/tenant (2,000 for 21Vianet); one wildcard per action string; DataActions ⇒ cannot assign at mgmt-group scope; only one mgmt group in AssignableScopes; no / (root) or wildcards in AssignableScopes.
  • NotActions/NotDataActions are NOT deny rules — just subtraction; a second role granting the action wins. True deny = Azure deny assignments.
  • Owner = full + grant access; User Access Administrator = grant access only; RBAC Administrator = grant access but constrained (least-priv delegation).

PIM (just-in-time privilege)

  • Requires Entra ID P2 or Entra ID Governance (per eligible/approver/reviewer user).
  • Eligible (must activate) vs Active (standing). Goal: zero standing/permanent active except break-glass.
  • Activation controls: max duration, MFA on activation, justification, ticket, approval (≥2 approvers), CA authentication context.
  • Manages: Entra roles, Azure resource roles, PIM for Groups → activating Azure role via group = activate group then role (double activate).
  • 2 cloud-only break-glass Global Admins, permanently active, excluded from CA/PIM.

MFA / Conditional Access (Zero Trust policy engine)

  • CA = if-then, enforced after first-factor auth; needs Entra ID P1.
  • Signals: user/group, IP/location, device (compliant / hybrid-joined / filter), app, real-time risk (ID Protection), Defender for Cloud Apps.
  • Grant: block / require MFA / authentication strength (phishing-resistant) / compliant / hybrid-joined / approved app / app-protection / password change / ToU. Session: sign-in frequency, persistent browser, CAE, app-enforced restrictions.
  • MFA rollout order: CA-based MFA (best) > per-user MFA (legacy, avoid) > security defaults (free, all-or-nothing). Microsoft mandates MFA for Azure portal/CLI/PowerShell admin sign-ins (2024–25 enforcement).
  • CAE: near-real-time revocation; token life 24h (vs 60–90 min); critical events = disable/delete, password reset, MFA enabled, admin token revoke, ID Protection high risk, location-based CA.
  • Protected actions: CA-auth-context gate on highest-risk Entra ops (edit CA policies, cross-tenant access) — defends the defenses.

App identities (4 things — don’t confuse)

  • App registration = global application object (template in home tenant) → scopes, redirect URIs, credentials, permissions.
  • Service principal = local identity (instance) per tenant; gets role assignments / consent. Enterprise app = SP UI.
  • Managed identity = SP whose secret Azure manages: system-assigned (1:1, dies with resource) vs user-assigned (standalone, reusable). Token via IMDS, no secrets in code.
  • Workload identity federation = trust external OIDC IdP (GitHub Actions, K8s, AWS, GCP) → no secret. On user-assigned MI or app reg (NOT system-assigned MI). Audience api://AzureADTokenExchange.
  • Delegated (scopes, on-behalf-of user, capped by user’s rights) vs Application (app roles, app-only/daemon, always needs admin consent).
  • User consent (low-risk delegated) vs admin consent (app perms + high-priv delegated). Configure user consent settings + admin consent workflow.
  • Result objects: delegated → oauth2PermissionGrant; application → appRoleAssignment.

External identities

  • B2B collaboration (guest object in your tenant) vs B2B direct connect (mutual trust, Teams shared channels, no guest object) vs External ID in external tenants (CIAM, replaces Azure AD B2C for new tenants).
  • Cross-tenant access settings: inbound/outbound + trust MFA & device claims from partner; no partner limit.
  • Microsoft Entra Verified ID = decentralized identity (verifiable credentials).

CIEM — MAJOR DRIFT

  • Standalone Microsoft Entra Permissions Management RETIRED Oct 1, 2025 (not sold since Apr 1, 2025).
  • CIEM now lives in Microsoft Defender for Cloud (Defender CSPM plan) → least-privilege / overprovisioned-identity recs across Azure, AWS, GCP; attack-path + Cloud Security Explorer. “Use Entra Permissions Management” is a stale answer.

Enterprise access model & PAW

  • Replaces legacy AD tier model. Tier 0 = control plane; Tier 1 → management + data/workload plane; Tier 2 → user + app access. Lower planes never control higher.
  • PAW = dedicated hardened admin workstation (Credential/Device/Exploit Guard, AppLocker, BitLocker, deny-default web) — the only path to the control plane.
  • AD DS hardening: tier isolation, Windows LAPS, remove standing Domain/Enterprise Admins, protect Tier 0, detect Kerberoasting/DCSync/Golden Ticket via Defender for Identity.

2 Data, Storage & Key Management

Notes: Data Storage & Key Management — Full Guide · 02 High-ROI — Data Storage & Key Management

Key Vault tiers & access

StandardPremiumManaged HSM
BackingSoftwareHSM keys, FIPS 140-2 L2Dedicated single-tenant, FIPS 140-2 L3 (Security Domain)
  • TWO planes: management (Azure RBAC on vault — create/delete, network) vs data (read keys/secrets/certs).
  • Data-plane = Azure RBAC (recommended) OR vault access policy (legacy, no deny). One model per vault. RBAC = granular, central, PIM-able, deny-able.
  • Soft-delete ALWAYS ON, cannot disable (7–90 days, default 90). Purge protection optional; once on, NOBODY (incl. Microsoft) can purge before retention elapses — anti-ransomware key-wipe defense, but irreversible.
  • Backup/restore: per-object encrypted blob; restore only to vault in same subscription + same Azure geography.
  • Key rotation: auto-rotation policy per key + on-demand Rotate Now; role Key Vault Crypto Officer; Policy “Keys should have a rotation policy.”
  • Network: firewall (selected vnets/IPs) + Private Endpoint + Trusted Microsoft services bypass.

Storage access control

  • Two access keys (key1/key2): rotate one while the other serves → zero downtime. Keys = full account access.
  • SAS: Account SAS (Shared Key, multi-service) · Service SAS (Shared Key, one service) · User delegation SAS (Entra-signed, Blob only, RECOMMENDED, revoke via delegation key).
  • allowSharedKeyAccess=false → only Entra ID / user-delegation SAS work; required for Conditional Access on storage.
  • Anonymous public blob access disabled by default on new accounts.
  • Azure Files identity-based SMB: on-prem AD DS / Entra Domain Services / Entra Kerberos. One identity source per account.

Storage data protection

  • Soft delete (blob+container), versioning, point-in-time restore, immutable (WORM).
  • Immutable: time-based retention (1 day–400 yrs, lock for SEC 17a-4(f)) vs legal hold. Container-level WORM (no prereq) vs version-level WORM (requires versioning). Locked = irreversible.
  • Encryption at rest: SSE always-on, 256-bit AES. CMK (Blob+Files always; Queue/Table only if account-encryption-key set at creation). Infrastructure (double) encryption = 2nd layer, separate key — MUST be set at account/scope creation, immutable.
  • In transit: “Require secure transfer” (supportsHttpsTrafficOnly) + minimum TLS version.

SQL / Synapse / Cosmos

  • TDE = at-rest encryption for whole DB. ON by default for new Azure SQL. Service-managed (auto-rotate yearly) OR customer-managed (BYOK) = TDE Protector in KV/Managed HSM; revoke key → DB inaccessible. Applies SQL DB, MI, Synapse dedicated pools.
  • Always Encrypted = column-level, keys NEVER seen by SQL engine (protects from DBAs). CMK → CEK. Deterministic (equality/join/index, leaks patterns) vs Randomized (stronger). Secure enclaves (VBS software / Intel SGX DC-series hardware) enable LIKE/ranges/in-place re-encrypt + need randomized.
  • TDE vs AE: TDE = at-rest, transparent, protects files/backups, NOT from admins. AE = in-use, protects from privileged users, app-side keys, column-scoped.
  • Entra DB auth (recommended; Windows auth not supported). Auditing → Log Analytics/Storage/Event Hub. Dynamic Data Masking = result-set obfuscation, NOT a security boundary (bypassable; UNMASK perm; admins always see).

Defender (data-plane plans)

  • Defender for Storage: agentless, malware scanning (per-GB on-upload), sensitive-data detection, detects leaked/abused SAS (“entities without identities”). No logs needed.
  • Defender for Databases: SQL DB, SQL-on-machines, OSS (PG/MySQL), Cosmos DB (NoSQL API only) — SQLi, anomalous access, exfiltration → Sentinel.

3 Secure Compute, Containers & Endpoint Baselines

Notes: Secure Compute Containers & Endpoint Baselines — Full Guide · 02 High-ROI — Secure Compute Containers & Endpoint Baselines

VM remote access (two orthogonal controls)

ControlDoesGotcha
Azure BastionBrowser/portal RDP/SSH over TLS 443; VM needs no public IPSubnet named exactly AzureBastionSubnet, ≥/26 (Standard/Premium). Standard adds native client, IP-Connect, shareable links
JIT VM accessDefender feature; mgmt ports closed until time-boxed approved request from requester IPRequires Defender for Servers Plan 2

Bastion = how you connect; JIT = when the port opens. They compose.

Disk encryption (know the 4)

OptionEncryptsKeyCPUDefender status
SSE (default, always on)OS+data at rest only (NOT temp/cache)PMK or CMK via DESnoneUnhealthy
Encryption at host+ temp disk, caches, compute↔storage flowPMK; CMK via DESnone (host)Healthyrecommended for new VMs
ADEOS+data via BitLocker/dm-crypt (in-guest)KEK in Key VaultyesHealthy — retires Sept 15, 2028
Confidential diskOS disk bound to VM vTPMCMK via DESyesN/A — confidential VMs (DCasv5/ECasv5)

CMK path = Key Vault Premium/Managed HSM → Disk Encryption Set (DES).

AKS — isolation, auth, monitor

  • Isolation: private cluster (private API), network policy (Azure/Calico/Cilium), egress via Azure Firewall/UDR, authorized IP ranges.
  • Auth: Entra integration (recommended; inherits CA/MFA/PIM) → Azure RBAC for Kubernetes OR native K8s RBAC. Disable local accounts (--disable-local-accounts) + Policy enforce. Break-glass via AKS Contributor role. kubelogin for non-interactive.
  • Workload→Azure: Microsoft Entra Workload ID (OIDC federation; replaces deprecated pod-managed identity).
  • Monitor: Defender for Containers (runtime + image scan via MDVM), Azure Policy add-on (Gatekeeper/OPA), Container Insights.

Container monitoring (ACI / ACA)

  • ACI/ACA: managed identity for registry pulls (no admin creds); Azure Monitor/Log Analytics; ACA built on managed K8s (Dapr, EasyAuth).

ACR access

  • Admin account: disabled by default — single shared cred, testing only. Policy-enforce off.
  • RBAC mode (classic): AcrPull, AcrPush, AcrDelete, AcrImageSigner (deprecating, removal 2028-03-31).
  • ABAC mode (“RBAC Registry + ABAC Repository Permissions”): AcrPull/AcrPush/AcrDelete NOT honored → use Container Registry Repository Reader/Writer/Contributor (+ optional repo-scoped ABAC); Catalog Lister to list repos.
  • Tokens + scope maps: non-Entra repo-scoped creds (content/metadata read|write|delete); can’t list catalog.
  • Workload pulls via managed identity + AcrPull. Lock down with Private Link, disable public access.

SC-100 baselines / endpoint

  • Baselines: MCSB + per-service Azure baselines; Defender for Cloud regulatory compliance dashboard; Azure Policy initiatives; OS hardening (CIS/Microsoft) via Intune / Defender for Endpoint / Azure guest config.
  • Windows LAPS: auto-rotates+backs up built-in local admin password → defeats pass-the-hash/lateral movement. Backup to AD (ACL + optional encryption) OR Entra ID (RBAC). Config via Intune (Entra/hybrid) or Group Policy (AD). Reset-LapsPassword = early rotation. GA w/ Entra Oct 23, 2023.
  • Servers (multi-OS/hybrid): onboard via Azure Arc → Defender for Servers + MDVM + baselines.
  • Mobile/clients: Intune (MDM/MAM, compliance, hardening) + Defender for Endpoint.

IoT / OT and Azure AI

  • Defender for IoT = the answer for OT/ICS. Agentless passive network monitoring (SPAN/TAP) → asset discovery + anomaly detection → Sentinel. MITRE ATT&CK for ICS for OT coverage design. Enterprise IoT → Defender for Endpoint.
  • Azure AI services security (SC-100): private endpoints, managed identity over keys, content filtering/abuse monitoring, data residency, CMK, RBAC.

4 Security Operations (Sentinel, XDR, SOAR)

Notes: Security Operations Sentinel XDR SOAR & MITRE — Full Guide · 02 High-ROI — Security Operations Sentinel XDR SOAR

Sentinel = SIEM + SOAR on a Log Analytics workspace

  • One Sentinel per LAW. Defender portal: 1 primary + unlimited secondary workspaces/tenant.
  • Portal convergence: Sentinel onboarding after July 1, 2025 w/ Owner or User Access Administrator → auto-onboarded to Defender portal. Azure portal Sentinel retires March 31, 2027 → Defender portal only.

Data connectors & DCRs

  • Native: Defender XDR, Defender for Cloud, Entra ID/ID Protection, M365, AWS, GCP. Standards: Syslog, CEF, Windows Security Events (via AMA + DCR), CCP, Logstash.
  • AMA replaced MMA (retired Aug 31 2024). AMA collection governed by DCRs.
  • DCR = what to collect + transform + where. Ingestion-time KQL transformations drop/mask/enrich BEFORE billing/storage (cost + PII control). DCE needed for custom logs / network-isolated AMA. Contrast: analytics-rule KQL = query-time (already billed).

Analytics rule types

TypeEngineNotes
ScheduledKQL on lookbackWorkhorse; frequency+lookback+threshold; map MITRE + entities
NRT~every 1 minLimited subset; single-table
AnomalyML baselineNo alerts → writes to Anomalies table
Microsoft securitypassthroughIncidents from other MS alerts — disabled under Defender portal/XDR integration
FusionML multistage correlationLow-volume/high-fidelity; disabled under Defender portal/XDR integration
Threat Intelligence (matching)MS TI vs CEF/Syslog/DNSNot customizable; high-fidelity

Custom detections (Defender portal) = unified successor for new rules across Sentinel+XDR.

SOAR: automation rules vs playbooks

  • Automation rule = central orchestrator; triggers on incident create/update OR alert create; can tag/assign/close/add-tasks/run-playbook without a playbook; ordered; expiration date.
  • Playbook = Logic Apps workflow. Triggers: Incident (recommended, callable by automation rules), Alert (preview, NOT callable by automation rules), Entity (manual only).
  • Sentinel service account needs Microsoft Sentinel Automation Contributor on the playbook’s RG to run it.
  • Defender for Cloud workflow automation ≠ Sentinel automation rules — separate native trigger (alert/recommendation/regulatory-compliance change) → Logic App.

MITRE ATT&CK

  • Matrices: Enterprise, Mobile, ICS (SC-100 names all three).
  • Sentinel MITRE page (Preview, aligned ATT&CK v18): current coverage (active scheduled+NRT rules) + simulated coverage (available-but-unconfigured). Tactics=columns, Techniques=cells.

Centralized logging / auditing (SC-100)

  • Purview Audit: Standard vs Premium (longer retention 1yr+, intelligent insights incl. MailItemsAccessed for BEC forensics, higher API bandwidth).
  • LAW retention: interactive (≤2yr) + long-term/archive (≤12yr). Hybrid/multicloud: Azure Arc + AMA/DCR; AWS/GCP connectors.

5 Capstone — Apps/API, M365 Data Protection & Strategy

Notes: Capstone Apps M365 & Strategy — Full Guide · 02 High-ROI — Capstone Apps M365 & Strategy

APIM security (the one AZ-500 hook)

  • AuthN: prefer OAuth 2.0 over preshared keys. Validate Entra tokens with validate-azure-ad-token; non-Entra JWTs with validate-jwt. Subscription key (Ocp-Apim-Subscription-Key) = weak alone → use in addition to real auth (no built-in expiry/rotation; key A/key B pair, script it).
  • Offload to policy: validate-jwt, ip-filter, validate-headers, validate-content, rate-limit/quota, set-header (strip leaky headers). No API tracing in prod.
  • Network hide: VNet internal mode / Private Link; WAF (App Gateway/Front Door) upstream of APIM.
  • Backend auth: APIM managed identity → backend/Key Vault. TLS 1.2+. Turn on Defender for APIs.
  • Defense-in-depth: backend must re-validate tokens even when the gateway validates (gateway config drifts, tokens replay). Don’t publish open/no-subscription products or wildcard * operations.

M365 data protection (SC-100)

ServiceProtectsNote
Defender for Office 365email/Teams/SharePoint: Safe Links/Attachments, anti-phishP1=protection, P2=Threat Explorer/AIR/Attack Sim
Defender for Cloud AppsSaaS/CASB: Shadow IT, OAuth app governance, session policiesvia CA App Control reverse proxy
Intunedevice/app mgmt: compliance, config, MAMcompliance feeds Conditional Access
Purviewdata: sensitivity labels, DLP, retention, eDiscovery, Auditlabels = cornerstone
Secure Score (M365)productivity posture metricDISTINCT from Defender for Cloud Secure Score (Azure)

Copilot for M365 data controls (high-yield)

  • Operates inside M365 service boundary; honors existing permissions — never exceeds the user’s rights.
  • Encryption: returns content only with EXTRACT + VIEW usage rights; VIEW-only → can reference w/ link, can’t summarize.
  • Label inheritance: generated content inherits highest-priority (most restrictive) label of sources.
  • DLP for Copilot: block grounding on labeled files/emails; block prompts w/ specified SITs. Endpoint DLP blocks paste into 3rd-party AI (ChatGPT).
  • Oversharing = #1 risk → fix with Restricted Access Control + default site labels + Purview before licensing.
  • Audited via Purview Audit/eDiscovery/retention (prompts+responses are M365 data).

App security lifecycle / DevSecOps

  • Threat modeling = STRIDE (Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation).
  • DevSecOps (CAF): shift-left; Defender for Cloud DevOps Security connects GitHub/Azure DevOps/GitLab → CodeQL/secret/IaC scan.
  • WAF (App Gateway regional / Front Door global): OWASP CRS + custom; Detection vs Prevention mode.
  • Workload identities: managed identity > SP w/ secret; federated credentials for CI/CD.

Strategy frameworks — know the deltas (SC-100 core, ~20-25%)

FrameworkWhat it isUse for
MCRAtechnical reference architectures (slides, Apr 2025); part of SAF”design aligns with MCRA”
MCSBprescriptive control benchmark; v1=12 domains, v2(preview) adds AI Security; maps CIS/NIST/PCI; in DfC Reg-Compliancebaseline + compliance posture
CAForg/process lifecycle (Strategy→Plan→Ready→Adopt→Govern→Manage)landing zones, governance, DevSecOps
WAF (Well-Architected)5 pillars (Reliability, Security, Cost, OpEx, Performance)workload-level tradeoffs
Zero Trustverify explicitly, least privilege, assume breachoverarching principle
RaMPRapid Modernization Plan — prioritized quick-win checklistssequencing what to do first
  • Azure landing zones = CAF enterprise-scale: mgmt groups, policy guardrails, hub-spoke, identity/connectivity subs.
  • DON’T confuse: WAF the framework (Well-Architected) vs WAF the firewall (Web App Firewall) — both in this unit.
  • Two RaMPs: Zero Trust RaMP (access) and Privileged Access RaMP (OKR-based).

BCDR / ransomware resiliency (SC-100)

  • 3-2-1 + immutable/offline: Azure Backup immutable vault + soft delete (on by default) + multi-user authorization (MUA) via Resource Guard → stops admin-deletes.
  • Ransomware priority order: (1) secure backups → (2) privileged access (PAW, PIM, tiering) → (3) rest. Backups are the attacker’s first target.
  • ASR (Azure Site Recovery) = DR replication/failover, ≠ backup. GRS/GZRS for region loss. Azure Update Manager for patch cadence.
  • Coverage required for insider / external / supply-chain attacks.