What's changed: Added per-section figures (cert-figure-retrofit). New SC-500 Chapter 1 (Domain 1 "Manage identity, access, and governance": Entra ID = PIM/conditional access/MFA-passwordless/app identities-OAuth consent/managed identities; Key Vault = RBAC vs access policies/network restriction/soft-delete-purge protection/Defender CSPM secret scanning-Defender for Key Vault; governance = Azure Policy/Defender for Cloud regulatory compliance/RBAC over-privilege remediation/resource locks/Azure Backup/IaC)
1.1Securing access with Microsoft Entra ID
Learn the identity foundations of SC-500: Privileged Identity Management (PIM), conditional access, multifactor authentication (MFA) and passwordless, application identities (enterprise apps / app registrations) and OAuth consent management, and managed identities for Azure resources—implemented through least privilege and Zero Trust.
Every SC-500 domain starts from identity. In the cloud the perimeter shifts from network to identity, so controlling who can access what, under which conditions is the heart of defense. This is exactly Zero Trust (verify explicitly, grant least privilege, assume breach). The core directory is Microsoft Entra ID (formerly Azure AD), which centrally manages identities and access for users, groups, apps, and devices.
1.1.1Privileged Identity Management (PIM)—just-in-time elevation
PIM (Privileged Identity Management) makes powerful roles like Global Administrator eligible rather than permanently assigned, so users elevate only when needed for a limited time (just-in-time, JIT). Elevation can require approval, MFA, and a justification, all captured in audit logs. This shrinks the window in which a powerful account is a target. PIM applies to Entra roles and to Azure resource roles (RBAC), and periodic access reviews prune assignments that are no longer needed.
1.1.2Conditional access—signal-based control
Conditional Access evaluates sign-in signals (user/group, app, location, device state, sign-in risk) and applies access controls (allow, block, require MFA, require compliant device, etc.). It reads as "if (conditions) → then (controls)." Example: "Access to admin portals requires MFA and a compliant device"; "block high-risk sign-ins from unfamiliar locations." Feeding user risk / sign-in risk from Entra ID Protection into the signals enables risk-based automatic response.
1.1.3MFA and passwordless authentication
Multifactor authentication (MFA) requires two or more of something you know (password), something you have (phone/token), or something you are (biometric), so a leaked password alone cannot pass. Passwordless goes further by removing the password, using phishing-resistant methods such as Windows Hello for Business, FIDO2 security keys, and Microsoft Authenticator passwordless sign-in. For SC-500, remember the strength order: "need phishing resistance → FIDO2 / Windows Hello," and "SMS is the weakest MFA factor."
1.1.4Application identities and OAuth consent management
Apps have identities too. An app registration is the app definition (a "blueprint" in the tenant); the instance materialized in a tenant is the enterprise application (service principal). Apps request OAuth 2.0 delegated permissions (on behalf of a user) and application permissions (the app itself), which a user or admin must consent to. Because attackers lure victims into over-consenting to malicious apps ("consent phishing / illicit OAuth apps"), an admin consent workflow, restricting user consent, and reviewing granted consents are essential.
1.1.5Managed identities—secretless resource authentication
A managed identity is an Entra ID identity that lets an Azure resource (VM, App Service, Functions, etc.) authenticate to other Azure services (Key Vault, Storage, SQL, etc.) without connection strings or secrets. Azure rotates the credentials automatically, reducing leakage risk. Two kinds exist: system-assigned (same lifecycle as the resource, one-to-one) and user-assigned (created independently and shareable across resources). It is the first choice whenever you want to "keep secrets out of code / eliminate connection strings."
| Goal (example) | Feature to use | Key point |
|---|---|---|
| Avoid standing admin roles | PIM (eligible + JIT elevation) | Approval, MFA, audit, access reviews |
| Control by location/device/risk | Conditional access | if conditions → then controls (MFA/block) |
| Phishing-resistant auth | FIDO2 / Windows Hello (passwordless) | SMS weakest; FIDO2 strongest-tier |
| Prevent over-permissioned apps | Admin consent workflow / restrict consent | Counter consent phishing; review grants |
| Connect without secrets | Managed identity | System- or user-assigned |
Scenario: operator privileged access. No standing rights (PIM eligible assignment); elevate only during work for a few hours with approval + MFA. Conditional access requires a compliant device + phishing-resistant MFA (FIDO2) for that elevated access. The operator’s automation uses a managed identity to pull secrets from Key Vault, removing connection strings from code. Quarterly access reviews remove eligible assignments that are no longer needed.
Watch the mix-ups: (1) authentication (who you are = MFA/passwordless) vs authorization (what you can do = RBAC/PIM). (2) app registration (blueprint) vs enterprise application = service principal (the instance in the tenant). (3) delegated permissions (on behalf of a user) vs application permissions (app alone; admin consent). (4) managed identity system-assigned (one-to-one) vs user-assigned (shareable).
Questions often map a requirement → the right identity control. E.g., "no standing admin rights" = PIM; "require MFA only under certain conditions" = conditional access; "phishing resistance required" = FIDO2 / Windows Hello; "prevent over-consent to apps" = admin consent workflow; "remove secrets from code" = managed identity.
1.1.6Section summary
- Identity is the cloud perimeter = Zero Trust (verify explicitly, least privilege, assume breach); core is Microsoft Entra ID
- PIM = JIT elevation of privilege (approval/MFA/audit/access reviews); applies to Entra roles and Azure RBAC
- Conditional access = if conditions → then controls. MFA/passwordless vary in strength (SMS < … < FIDO2/Windows Hello)
- App registration vs enterprise app, manage OAuth consent (counter consent phishing). Managed identities for secretless access
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which feature avoids standing assignment of powerful roles and instead elevates them just-in-time, with approval and MFA, only when needed?
Q2. Which policy engine evaluates signals such as location, device state, and risk to require MFA or block access?
Q3. Which authentication method is recommended when phishing resistance is most important?
Q4. Which helps prevent "consent phishing," where users grant excessive permissions to a malicious app?
Q5. Which identity lets an Azure resource authenticate to Key Vault or Storage without connection strings or secrets?
Q6. Which correctly describes the relationship between an app registration and an enterprise application?