Managed Identities
A managed identity is an Entra ID identity that Azure creates and manages for a workload, so the workload authenticates to other Azure services — Key Vault, Storage, SQL — without any credential stored in code, config, or a pipeline. The platform issues and rotates the tokens; your application just asks for one and uses it.
Managed identities are the answer to the oldest cloud security problem: where do you put the credential. The answer is nowhere — there is no secret to store, leak, or rotate. Any time you find yourself about to put a connection string or key somewhere, a managed identity is almost always the better design.
System-Assigned vs User-Assigned
A system-assigned identity is created with a resource and shares its lifecycle — deleted when the resource is deleted, and tied to exactly that one resource. A user-assigned identity is a standalone resource you create once and attach to many resources, with its own independent lifecycle. Use system-assigned for a one-to-one identity; use user-assigned when several resources should share one identity or when the identity must outlive any single resource.
| Lifecycle | Sharing | |
|---|---|---|
| System-assigned | Tied to the resource | One resource only |
| User-assigned | Independent resource | Shared across many resources |
How It Works
A workload requests a token from the local identity endpoint; Azure returns an Entra ID access token scoped to the target service, and the workload presents it like any bearer token. The Azure SDKs do this transparently through DefaultAzureCredential, so the same code uses a managed identity in Azure and a developer's own login locally — no code change between environments.
Granting Access
A managed identity is a principal like any other, so you grant it access with RBAC role assignments — give the app's identity the Key Vault Secrets User role on a vault, or the Storage Blob Data Reader role on a container. The identity carries only the permissions you assign, which is where least privilege is enforced.
System-assigned — Created with and bound to a single resource; deleted with it. Choose it for a one-to-one identity that needs no sharing.
User-assigned — A standalone identity attached to many resources, with its own lifecycle. Choose it for shared identities or ones that outlive a resource.
- Storing service-principal secrets or connection strings in code when a managed identity would remove the credential entirely.
- Using a system-assigned identity where several resources need to share one identity — they cannot, so use user-assigned.
- Granting the identity broad roles at subscription scope instead of least-privilege roles at the resource scope.
- Forgetting that a system-assigned identity is deleted with its resource, breaking access for anything that depended on it.
- Not using DefaultAzureCredential, so code needs different auth paths for local development and Azure.
- Leaving stale user-assigned identities and role assignments around after the resources that used them are gone.
- Default to managed identities for every workload-to-Azure-service authentication; eliminate stored credentials.
- Use system-assigned for one-to-one identities and user-assigned when an identity is shared or must outlive a resource.
- Assign least-privilege RBAC roles at the narrowest scope the workload needs.
- Use DefaultAzureCredential so the same code authenticates locally and in Azure with no branching.
- Clean up user-assigned identities and role assignments when their workloads are decommissioned.
- Combine managed identities with Key Vault so even the secrets an app does need are fetched without a stored credential.
Knowledge Check
What problem does a managed identity solve?
- It removes stored credentials — the workload gets platform-issued, auto-rotated tokens with no secret to leak
- It encrypts all of the application's data at rest on disk using platform-managed keys that the service holds and rotates
- It provides a public endpoint and DNS name to expose the workload externally to internet clients
- It load-balances inbound client traffic across multiple regions for high availability
Several resources must share one identity that outlives any single resource. Which type fits?
- A user-assigned managed identity
- A system-assigned managed identity
- A separate system-assigned identity per resource
- A service-principal secret stored in Key Vault
How does a managed identity get permission to read a Key Vault secret?
- By an RBAC role assignment (e.g. Key Vault Secrets User) at the appropriate scope
- By embedding the vault access key directly in the application's configuration file
- Automatically — managed identities can read every secret in the vault with no role assignment
- Through a Conditional Access policy scoped directly to the target vault resource
You got correct