User-assigned managed identity

Understand the concept

In plain English

A user-assigned managed identity is an Azure identity you create once and attach to workloads that need it. Unlike a system-assigned identity, it is not automatically deleted with one app, VM, or service. Teams use it when several resources should share the same permissions, or when an identity must survive blue-green deployments, slot swaps, rebuilds, and resource replacement. It removes stored passwords while keeping identity ownership explicit. That makes it a durable permission anchor for workloads.

Why it matters

User-assigned managed identities matter because production systems change faster than their permissions should. If an application is rebuilt, moved to a slot, or deployed in parallel, a system-assigned identity can force new role assignments and break access. A user-assigned identity provides a stable security principal that can be reused, audited, and transferred deliberately. It is also safer than client secrets because there is no password to rotate or leak. The tradeoff is governance: a shared identity must have clear ownership, narrow roles, and review cycles so it does not become a hidden superuser. This balance is why naming, tagging, and scope discipline matter.

Technical context

In Azure architecture, a user-assigned managed identity is a Microsoft Entra service principal represented as an Azure resource. It has a resource ID, client ID, principal ID, tenant, and role assignments. Compute services such as VMs, App Service, Functions, AKS components, automation jobs, and data services can attach it when supported. Access is granted through Azure RBAC or service-specific permissions, while token acquisition happens from the workload environment without embedded secrets. It is governed through Azure Resource Manager.

Exam context

Compare with

Where it is used

Where you see it

1. The managed identity resource page shows client ID, principal ID, tenant ID, Azure resource ID, tags, and activity history for the identity. used in automation outputs.
2. Workload identity settings in App Service, Functions, VM, or AKS configuration list the user-assigned identity attached to the resource. during deployment validation and incident checks.
3. Role assignment output shows the identity principal granted access to Key Vault, Storage, Container Registry, database, or subscription scopes during quarterly least-privilege access review evidence collection.

Common situations

• Keep the same workload identity through blue-green deployments, slot swaps, or VM replacement.
• Grant several related services shared read access to a Key Vault without copying client secrets.
• Separate production and nonproduction authorization by giving each environment its own managed identity.
• Attach a tightly scoped identity to automation that needs to deploy or inspect resources at a fixed scope.
• Replace expired service-principal secrets with identity-based access for Azure-hosted workloads.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

Azure CLI is one of the best ways to manage user-assigned managed identities because identity work crosses resource, RBAC, and application boundaries. As an Azure engineer, I use CLI to create identities, capture client and principal IDs, attach them to workloads, assign roles at exact scopes, and export evidence for access reviews. The portal is fine for one-off checks, but CLI keeps deployments repeatable and makes drift visible. It also prevents confusion between resource ID, client ID, and object ID during troubleshooting. During incidents, CLI output quickly shows whether the identity exists, is attached, and has the role the application expects.

az identity create --name <identity-name> --resource-group <resource-group>

az identity show --name <identity-name> --resource-group <resource-group>

az identity list --resource-group <resource-group> --output table

az role assignment create --assignee <principal-id> --role <role-name> --scope <scope>

az role assignment list --assignee <principal-id> --all --output table

Architecture context

Architecturally, a user-assigned managed identity is a reusable workload identity, not a human account and not a secret. It should be designed around a specific application capability, such as reading Key Vault secrets, pulling from a registry, writing to Storage, or connecting to a database. The identity belongs in infrastructure-as-code with role assignments, naming standards, and ownership tags. It can support zero-secret deployment patterns and stable access during resource replacement. Good designs avoid one identity for everything, because that makes blast radius and audit findings painful. It is a security dependency that should be promoted, tested, and retired with the application architecture.

Security

Security impact is direct because the identity carries real permissions. User-assigned managed identities remove stored credentials, but they do not remove authorization risk. Assign least-privilege roles at the narrowest scope, separate identities by workload and environment, and review unused or overprivileged assignments. Protect who can attach the identity to resources; otherwise, another workload may inherit access it should not have. Monitor sign-in and resource-access patterns where available, and document emergency removal steps. Avoid using one broad identity across many unrelated services because compromise becomes harder to contain. Conditional access for humans does not protect an overbroad workload identity already attached to compute.

Cost

The identity resource itself is not usually a meaningful cost item, but it affects cost through the actions it authorizes. An overprivileged identity can create expensive resources, read large datasets, trigger automation, or allow workloads to keep running after ownership is unclear. Poor identity design also increases operational cost because access failures take longer to diagnose when one identity serves many applications. FinOps and platform teams should tag identities, link them to workloads, review role scopes, and remove unused identities with their role assignments during decommissioning. Tagging and ownership prevent identities from surviving long after the paid workload was retired completely.

Reliability

Reliability improves when access survives normal deployment changes. A user-assigned identity can remain stable while compute resources are recreated, scaled out, swapped, or replaced, which avoids outages caused by missing role assignments. Reliability still depends on correct attachment, supported service behavior, token acquisition, and downstream permissions. If an identity is deleted or a role assignment is removed, every attached workload can fail at once. Reliable designs treat identity changes like production changes, validate token retrieval after deployment, and maintain rollback instructions for role and attachment changes. Health checks should verify downstream access, not only that the compute resource started successfully after deployment.

Performance

Runtime performance is usually indirect. Managed identity token acquisition is designed to be lightweight, but applications can still create latency by requesting tokens too often, failing to cache them correctly, or retrying authorization failures as if they were transient network errors. A stable user-assigned identity can speed deployments because role assignments do not need to be recreated for every replacement resource. Operators should measure dependency latency separately from token acquisition and watch for throttling or misconfiguration in identity endpoints, SDK settings, and downstream service authorization. Centralized identity reuse can also reduce deployment delays when new instances join an existing permission model cleanly.

Operations

Operators inspect user-assigned managed identities by checking where they are attached, what roles they hold, when they were created, and whether they still have an owner. Common tasks include creating identities, assigning RBAC, attaching to workloads, validating token-based access, removing stale assignments, and responding to access failures. Documentation should capture client ID, principal ID, intended workloads, approved scopes, and break-glass contacts. During incidents, operators compare application errors with role assignment history and identity attachment state before rotating secrets that should no longer exist. They should reconcile Azure Resource Manager state with application configuration because both must reference the same identity correctly after each deployment.

Common mistakes

• Confusing client ID, principal ID, and resource ID during attachment or role assignment automation.
• Using one shared identity for many unrelated applications because it was convenient during the first rollout.
• Granting subscription-wide Contributor when the workload only needs data-plane access to one resource.
• Deleting the identity during cleanup without checking every workload and role assignment that depends on it.