SC-500 identity, access and governance
Manage identity, access, and governance is worth 20–25% of SC-500. It has three parts: securing access with Microsoft Entra ID, protecting secrets with Azure Key Vault, and enforcing governance across the estate. Experienced engineers tend to be strong on the first two and casual about the third — which is where the marks leak.
Securing access with Entra ID
Six objectives, each with a clear scenario signature:
| Objective | The scenario that wants it |
|---|---|
| Privileged Identity Management | Standing admin access must become time-bound and approved |
| Conditional access | Access depends on conditions — device, location, risk |
| MFA and passwordless | Authentication strength must increase |
| Identity for applications | An app needs its own identity (enterprise apps, app registrations) |
| OAuth permission grants and consent | Users are consenting to third-party apps unchecked |
| Managed identities | An Azure resource must authenticate without a stored secret |
The distinction worth drilling: PIM controls how long you hold a role, conditional access controls the conditions under which you sign in. Questions frequently offer both, and only one matches the requirement.
Managed identities remain the reliable heuristic across the whole exam: whenever an option removes a stored credential, it is usually right.
Key Vault
Deploy it, configure its settings, control access to it, and configure its firewall. Manage keys, secrets and certificates. Then two protection objectives that are easy marks because they name the product:
- Scan for secrets using Defender CSPM — finding credentials that escaped into code and configuration.
- Defender for Key Vault — threat protection on the vault itself.
Key Vault questions usually hinge on layering: a vault with permissive network access is not secured by access policies alone, and a vault reachable from anywhere is a finding regardless of who can read it.
Governance
Nine objectives and the most underestimated section of the domain:
- Azure Policy, built-in and custom definitions — the mechanism for enforcing a configuration standard rather than reporting on it.
- Regulatory compliance in Defender for Cloud — evaluating against frameworks.
- Security standards and recommendations in Defender for Cloud — assessing posture.
- Resource locks — preventing deletion or modification of a resource.
- Built-in role assignments and custom roles, both Azure and Entra.
- Remediating overprivileged access with RBAC — finding and cutting excessive permissions.
- Backup protection with Azure Backup security features.
- Security controls through infrastructure as code.
The recurring distinction here is enforce versus assess. Azure Policy prevents or remediates non-compliant resources. Defender for Cloud evaluates and recommends. A scenario saying “must not be able to create” wants Policy; one saying “need visibility into compliance” wants Defender for Cloud.
Sample questions
Question 1. Storage accounts must not be creatable with public blob access enabled, anywhere in the subscription. Reporting on violations after the fact is not acceptable. What should you implement?
- A. An Azure Policy definition with a deny effect
- B. A Defender for Cloud recommendation
- C. A regulatory compliance dashboard in Defender for Cloud
- D. A resource lock on the subscription
Show answer
Answer: A
Azure Policy with a deny effect prevents non-compliant resources from being created, which is what a requirement that rules out after-the-fact reporting demands. Defender for Cloud recommendations and a compliance dashboard both report rather than prevent, and a resource lock stops changes to existing resources rather than governing new ones.
Question 2. A review finds several service principals with Contributor on production subscriptions, far beyond what their workloads use. What should you do?
- A. Enable MFA for the service principals
- B. Apply a resource lock to each production subscription
- C. Evaluate and remediate the overprivileged assignments using Azure RBAC
- D. Rotate the service principal credentials
Show answer
Answer: C
Evaluating and remediating overprivileged assignments with Azure RBAC is the objective that directly addresses excessive standing permissions, replacing them with least-privilege roles. Enabling MFA does not apply to service principals in this sense, a resource lock does not reduce permissions, and rotating credentials leaves the excessive access intact.
Question 3. Developers occasionally commit connection strings into repositories. Security wants these detected across the cloud estate. What should you use?
- A. Defender for Key Vault
- B. Secret scanning using Defender CSPM
- C. A conditional access policy on developer accounts
- D. A custom Entra role for developers
Show answer
Answer: B
Scanning for secrets using Defender CSPM is the objective covering discovery of exposed credentials across the estate. Defender for Key Vault protects the vault rather than finding secrets elsewhere, a conditional access policy governs sign-in, and a custom Entra role changes permissions rather than detecting exposure.
What to practise
Set up PIM on one role and actually activate it. Write one custom Azure Policy with a deny effect and watch a deployment fail. Put a firewall on a Key Vault and break your own access, then fix it. Those three exercises cover the shape of most questions in this domain far better than reading the objective list again.