The SC-500: Cloud and AI Security Engineer Associate exam validates the skills to design, implement, and manage end-to-end security controls across Azure, hybrid, and AI-enabled environments, protecting identities, data, applications, infrastructure, and AI workloads while maintaining regulatory compliance. It went live in beta in May 2026 as Microsoft's successor to AZ-500 (Azure Security Engineer Associate), which retires August 31, 2026, and folds AZ-500's identity, network, storage, database, and compute security scope together with a substantial new AI-security domain covering Microsoft Purview DSPM, Copilot Studio agent protection, Microsoft Entra Agent ID, and Microsoft Foundry guardrails. Candidates should already be comfortable administering Azure and hybrid environments and have strong familiarity with Microsoft Entra ID, plus working knowledge of Microsoft 365 administration. The AI-security domain is the exam's real differentiator from its predecessor: knowing how to lock down a storage account or an NSG covers a quarter of the questions, but reasoning about agent identity blast radius, DSPM overexposure findings, and Foundry guardrails the way you'd reason about a classic RBAC assignment is now just as testable.
What This Cheat Sheet Covers
This topic spans 27 focused tables and 298 indexed concepts, 9 practice tests with 355 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Privileged Access, Conditional Access & Authentication Methods
Secure access to resources by using Microsoft Entra ID: reducing standing privilege with Privileged Identity Management, gating access with Conditional Access signals and controls, and moving sign-in to modern, phishing-resistant authentication methods.
| Concept | Example | Description | |
|---|---|---|---|
Eligible: activate -> 8 hr windowActive: role usable immediately | Eligible needs an action (activation, MFA, justification, or approval) before use; active grants the role's privileges right away. • Same access level either way, only the need to activate differs. • Not "reduced access until activated". | ||
Select role -> set duration <= max-> MFA check -> reason -> active | Activating an eligible role can require an MFA check, a business justification, and sometimes approval, then grants the role only for a limited window. • Access expires on its own, it is not standing access an admin must manually revoke. | ||
If: user in Finance + app = SharePointThen: require compliant device | A Conditional Access policy is an if-then rule: assignments (who, what, where) trigger access controls (grant with conditions, or block). • Enforced only after first-factor sign-in completes, never before it. • Not the same as an org-wide MFA switch. | ||
Migration status: In Progress-> Migration Complete: legacy grayed out | The unified Authentication methods policy centrally manages every sign-in and SSPR method by user or group, replacing the separate legacy per-user MFA and SSPR policies. • Once migration is Complete, the legacy settings are grayed out and no longer apply. | ||
Sign-in -> select passkey -> devicesigns a challenge; private key stays local | Passkeys use origin-bound public-key cryptography plus a biometric or PIN unlock, satisfying MFA while resisting phishing and replay. • A passkey created for one site only works on that exact site. | ||
Phase 1: collect signals (enabled + report-only)Phase 2: enforce, block wins first | Phase 1 collects session details for every applicable policy, including report-only ones; Phase 2 enforces, blocking first if any policy requires it. • Multiple applicable policies combine with AND, so all their requirements must be met. | ||
Require authentication strength:Phishing-resistant MFA (FIDO2, WHfB, cert-based) | A Conditional Access grant control that limits sign-in to specific method combinations, using a built-in or custom strength. • Can't be combined with Require multifactor authentication in the same policy. • Doesn't restrict a user's very first sign-in attempt. | ||
Request activation -> approver notified-> approve/deny within a 24 hr window | Roles configured to require approval route the activation request to one or more delegated approvers, who have a fixed 24-hour window to act. • An unapproved request after 24 hours must be resubmitted; the window isn't configurable. | ||
Policy state = Report-only-> evaluated + logged, never enforced | Report-only mode evaluates a policy against real sign-ins and logs the result to the sign-in logs and Insights workbook, without blocking or prompting anyone. • Used to validate a new or changed policy before switching it to On. | ||
PIM: Global Admin = permanent activeCA: excluded from blocking/restricting policies | Emergency access accounts get Global Administrator as permanent active (not eligible) and are excluded from any Conditional Access policy that blocks or restricts sign-in, so they work when normal admin sign-in fails. • Report-only policies don't need this exclusion, they never block access. | ||
Device-bound: FIDO2 key, stays on deviceSynced: encrypted, copied to cloud provider | Device-bound passkeys (FIDO2 keys, Authenticator) never leave one physical device; synced passkeys are encrypted and synced to a cloud passkey provider so other devices can use them. • Only device-bound passkeys support attestation; synced passkeys are excluded when attestation is enforced. | ||
Enable any Entra security/M365 group-> users get JIT eligible member/owner | PIM for Groups gives just-in-time eligible membership or ownership of a group, and any Microsoft Entra security or Microsoft 365 group can be enabled for it. • The group doesn't have to be role-assignable, that requirement applies only to assigning an Entra role directly. • Dynamic-membership and on-premises-synced groups can't be enabled. | ||
Sign-in frequency: 1 hour-> reauth prompt after grant controls pass | Session controls like sign-in frequency and persistent browser session apply only after every grant control (MFA, compliant device, etc.) in the policy is already satisfied. • Use app enforced restrictions works only with Exchange Online and SharePoint Online, not every cloud app. |