Managed Identities & App Identity
System-assigned · User-assigned · Service principals · Workload identity federation
Practice questions for this topic →
Which kind of identity?
| Scenario | Recommendation |
|---|---|
| Several resources need the same permissions | User-assigned (one identity, fewer role assignments) |
| Role assignments must exist before the resource is deployed | User-assigned |
| Rapidly creating many resources (avoid HTTP 429 on Entra object creation) | User-assigned |
| Identity must be deleted with the resource or be unique per resource | System-assigned |
| Code running outside Azure (GitHub Actions, any Kubernetes, another cloud) | Workload identity federation: no stored secret |
| On-prem server needs an Azure identity | Azure Arc-enabled server managed identity |
Facts to know
- Managed identities let Azure-hosted workloads get Entra tokens without managing credentials, which aren't even accessible to you. They can authenticate to any resource that supports Entra authentication, and they cost nothing extra.
- System-assigned: created with the resource, a service principal tied to its lifecycle, deleted with it, usable only by that resource, named after the resource (a deployment slot is
/slots/ ). - User-assigned: a standalone resource you create and attach to one or more resources; its lifecycle is separate.
- Workload identity federation: configure a user-assigned managed identity or app registration to trust tokens from an external identity provider (GitHub, any Kubernetes cluster, Google…). The workload exchanges the external token for an Entra access token, so there's no secret or certificate to store or rotate. Workloads that run outside Azure otherwise need an app secret or certificate.
- Service principals (app registrations) are for non-Azure callers, such as a third-party SaaS app, using a certificate credential.
Exam Tips
Tick each tip once you can answer it without looking.
“App on Azure must read Key Vault secrets without storing any credentials” → Managed identity + RBAC role on Key Vault.
“Twenty VMs need the same access, minimize administration” → One user-assigned managed identity.
“Identity lifecycle tied to the VM; deleted when VM is deleted” → System-assigned managed identity.
“GitHub Actions deploys to Azure without a client secret” → Workload identity federation (OIDC) on an app registration / user-assigned MI.
“AKS pods access Azure resources without secrets” → Microsoft Entra Workload ID.
“Third-party SaaS must call your API” → App registration (service principal) with certificate credential. Trap: Managed identities only work for Azure-hosted code.
“Least privilege for a managed identity” → Assign the narrowest built-in role at the smallest scope.
“System-assigned identity lifecycle” → A service principal tied to the resource, deleted with it, usable only by that resource, named after it. Trap: A deployment slot's identity is
“Cost and credentials of managed identities” → No extra cost; you can't see or handle the credentials. Trap: They replace keys, passwords and certificates for service-to-service access.
“Workload identity federation” → An identity trusts tokens from an external IdP (GitHub, Kubernetes, Google); the workload swaps them for Entra tokens. Trap: No secret or certificate to store or rotate.
“Workload outside Azure needs Azure access without secrets” → Workload identity federation. Trap: Managed identities exist only for Azure-hosted resources.