Manage identity, access, and governance

This domain is where the exam tests standing privilege hardest. If you remember one thing: almost every keyed answer here removes a permanent permission, narrows a scope, or moves a credential out of a configuration file. Guess in that direction when you are unsure.

1.1 Privileged Identity Management

PIM turns permanent role assignments into eligible ones that a user activates when they need them. It covers three things, and the exam expects you to know which is which:

• PIM for Microsoft Entra roles — Global Administrator, Security Administrator and friends.
• PIM for Azure resources — Azure RBAC roles at management group, subscription, resource group or resource scope.
• PIM for Groups — membership or ownership of a role-assignable group, which is how you make anything group-based eligible, including third-party SaaS access and Azure roles assigned to a group.

flowchart TB
  E["Eligible assignment — the user holds zero standing permission"] --> A["The user requests activation in PIM"]
  A --> C{"What did you require on the role setting?"}
  C -->|"MFA, justification, a ticket number"| S["Self-service activation, immediate"]
  C -->|"Approval"| P["An approver grants or denies; the requester is notified"]
  S --> ACT["Active for the maximum activation duration — configurable from 1 to 24 hours"]
  P --> ACT
  ACT --> EXP["Deactivates automatically · request, approval and activation are all audited"]

Settings you need to be able to place

1.2 Conditional Access

Conditional Access is the Zero Trust policy engine: if these signals, then these controls. It runs after first-factor authentication succeeds, and it is the last gate before a token is issued.

flowchart TB
  A["Sign-in attempt — first factor has already succeeded"] --> B{"Does every assignment and condition match?<br/>users and workload identities · target resources · network · device · risk"}
  B -->|"No"| D["This policy does not apply to this sign-in"]
  B -->|"Yes"| E{"Is the policy set to Block?"}
  E -->|"Yes"| F["Access denied — no grant control can override a block"]
  E -->|"No"| G["Grant controls — MFA · authentication strength · compliant device<br/>hybrid joined · approved app · app protection · terms of use · password change"]
  G --> H["Session controls attached to the token — sign-in frequency · CAE<br/>persistent browser · app enforced restrictions · token protection"]
  H --> I["Access granted, with those session constraints"]

The anatomy of a policy

Authentication strengths

"Require MFA" is coarse. Authentication strength lets you demand a specific class of credential. Three are built in, and you can author custom strengths from the allowed combinations list:

• Multifactor authentication — anything that counts as MFA, the equivalent of the old checkbox.
• Passwordless MFA — Windows Hello for Business, passkeys (FIDO2), certificate-based authentication (multifactor), Microsoft Authenticator passwordless phone sign-in.
• Phishing-resistant MFA — Windows Hello for Business, passkeys (FIDO2), certificate-based authentication (multifactor). Authenticator push is not phishing-resistant.

1.3 Authentication methods, MFA and passwordless

Methods are managed in one place: Microsoft Entra admin center → Entra ID → Authentication methods → Policies. Each method is enabled for all users or for named groups, with exclusions, and most carry their own configuration.

1.4 Application identity, consent and permissions

Two objects, one application. Getting them straight is worth several marks.

Delegated versus application permissions

• Delegated — the app acts on behalf of a signed-in user. Effective access is the intersection of the app's granted scope and the user's own rights, so a delegated Files.ReadWrite.All still only reaches files that user can already reach.
• Application — the app acts as itself, with no user present. There is no intersection to save you: an application-permission Files.Read.All reads every file in the tenant. These always require admin consent.

Consent settings

1.5 Managed identities and workload identity federation

A managed identity is a service principal Azure creates and rotates for you, so a resource can authenticate to Microsoft Entra ID without a credential stored anywhere. It is the answer to almost every "remove the connection string from the app" question.

Code retrieves a token from the local Azure Instance Metadata Service endpoint; in practice you use DefaultAzureCredential or ManagedIdentityCredential from the Azure Identity library and never see it.

1.6 Azure Key Vault

Key Vault is where SC-500 puts almost all of its "protect the credential" marks. Know the deployment choices, the two access models, the network controls and the two safety nets.

Choosing the offering

The two safety nets

• Soft delete — always on and cannot be turned off. A deleted vault or object goes into a recoverable state for the retention period (7 to 90 days, default 90), during which it can be recovered or explicitly purged.
• Purge protection — optional, and irreversible once enabled. It blocks the purge operation entirely, so nothing can be permanently destroyed before the retention period elapses. Several services that use customer-managed keys (Azure Storage, Azure SQL TDE, disk encryption sets) require it.

Getting to the secret

flowchart TB
  R["A caller asks a key vault for a secret"] --> N{"Does the request reach<br/>the vault at all?"}
  N -->|"Public access disabled,<br/>or the firewall rejects<br/>the source"| BLOCK["Forbidden at the network layer —<br/>the permission model is<br/>never consulted"]
  N -->|"Allowed by a firewall rule,<br/>a selected virtual network, a trusted<br/>services bypass or a private endpoint"| P{"Which permission model<br/>is the vault configured for?"}
  P -->|"Azure RBAC —<br/>recommended"| RB["Needs a data-plane role such as<br/>Key Vault Secrets User — Owner and<br/>Contributor alone grant nothing here"]
  P -->|"Vault access<br/>policy — legacy"| AP["Needs an access policy entry<br/>granting Get on Secrets"]
  RB --> OK["Secret returned"]
  AP --> OK

Network controls

• Firewall — allow all networks, allow selected networks (IP ranges plus virtual network subnets via service endpoints), or disable public access entirely.
• Trusted Microsoft services — a bypass checkbox that lets platform services such as Azure Disk Encryption, Azure Backup and App Service reach the vault when the firewall would otherwise refuse. The caller still needs permissions.
• Private endpoint — a private IP inside your virtual network. The pairing the exam wants is private endpoint plus public network access disabled; a private endpoint alone leaves the public path open.

Detection: two different features, easily confused

1.7 Governance with Azure Policy

Three objects: a definition is a rule; an initiative (policy set) bundles definitions so they can be assigned and reported on together; an assignment applies either to a scope. Compliance is evaluated on change and on a roughly 24-hour cycle, and can be triggered on demand.

flowchart TB
  A["A create or update request arrives at Azure Resource Manager"] --> B["Disabled — the rule is skipped entirely"]
  B --> C["Append and Modify — the request is altered before it is written"]
  C --> D["Deny — the request is rejected outright"]
  D --> E["Audit — the request proceeds; non-compliance is recorded"]
  E --> F["The resource provider creates or updates the resource"]
  F --> G["AuditIfNotExists and DeployIfNotExists — evaluated once the resource exists"]

{
  "policyRule": {
    "if": {
      "allOf": [
        { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
        {
          "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
          "notEquals": "false"
        }
      ]
    },
    "then": { "effect": "deny" }
  }
}

1.8 RBAC, custom roles and over-privileged access

A role assignment is three things: a security principal (user, group, service principal, managed identity), a role definition, and a scope. Assignments are additive and inherit downwards.

When no built-in role fits, write a custom one. The definition is JSON with Actions/NotActions for the control plane and DataActions/NotDataActions for the data plane; AssignableScopes lists where it may be used.

{
  "Name": "Virtual Machine Operator",
  "IsCustom": true,
  "Description": "Start, restart and monitor virtual machines, but never delete one.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Insights/alertRules/*",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/providers/Microsoft.Management/managementGroups/contoso-platform"
  ]
}

Finding and fixing over-privileged assignments

• Defender for Cloud identity and access recommendations — "there should be more than one owner", "accounts with owner permissions should be MFA enabled", "external accounts with owner permissions should be removed", "deprecated accounts should be removed".
• Access reviews for Azure resource roles in PIM — recurring attestation of who still needs what.
• Defender CSPM attack path analysis — surfaces the toxic combination of an over-permissioned identity that can reach an internet-exposed, sensitive-data resource.
• The role assignment view itself — filter for Owner and Contributor at subscription scope and for assignments inherited from a management group, which are the two that surprise people.

1.9 Resource locks

• Apply at subscription, resource group or resource — not at a management group.
• Locks inherit downwards, and the most restrictive lock in the chain wins.
• Managing locks needs Microsoft.Authorization/locks/* — in practice Owner or User Access Administrator.
• They apply to the control plane only. Data inside a locked resource can still be deleted.

1.10 Azure Backup security

Backups are the last line against ransomware, which makes them a target. Four controls, in the order the exam layers them:

1.11 Security controls through infrastructure as code

The exam treats IaC as both a way to apply controls consistently and a surface that itself needs securing.

• Deploy controls as code. Bicep and ARM templates, Terraform, and Azure Verified Modules express hardened baselines — private endpoints, diagnostic settings, TLS minimums — so a compliant resource is the default rather than a remediation task. Deployment stacks add deny settings, which behave like a managed deny assignment over everything the stack manages.
• Scan the code before it ships. Defender for Cloud's DevOps security connects to Azure DevOps, GitHub and GitLab and surfaces IaC misconfigurations, exposed secrets, code and dependency findings as recommendations in the same secure score as the running estate. The Microsoft Security DevOps extension runs the analysers inside the pipeline itself.
• Authenticate the pipeline without secrets. Use workload identity federation for the deployment service connection, and never a long-lived client secret.
• Pair it with Azure Policy. IaC covers what your pipelines create; Policy covers everything else, including what somebody creates by hand in the portal at two in the morning.

Skill 1 checklist

Next: Skill 2, the heaviest domain on the exam.