Managed identities let Azure workloads authenticate to services that support Microsoft Entra ID without storing an application password, certificate, or account key in code. Azure creates and manages the identity relationship, the workload requests a token at runtime, and the destination service authorizes that identity according to its assigned permissions. The result is a credential model that is easier to rotate, audit, and protect than embedded secrets.<\/p>\n
For AZ-104<\/a>, managed identity connects identity administration to workload operations. In real environments, the design question is not merely how to turn the feature on. Administrators must choose system-assigned or user-assigned identity, grant least privilege, understand lifecycle, and troubleshoot token and role-assignment behavior.<\/p>\n Traditional application authentication often begins with a client ID and a secret or certificate. The application stores that credential somewhere, someone must rotate it, and every copy becomes a security risk. Managed identity removes the need for the workload to manage that credential directly. Azure exposes an identity endpoint or platform integration that can issue Microsoft Entra access tokens to the workload.<\/p>\n The token is still scoped to a destination resource. A VM, App Service, Function, or other supported Azure resource can request a token for Azure Storage, Key Vault, SQL, or another service that accepts Entra authentication. The destination then evaluates the identity\u2019s permissions. Managed identity therefore solves authentication credential management; it does not automatically grant authorization.<\/p>\n This is why RBAC remains central. Enabling an identity creates or associates the principal, but a separate role assignment is usually required at the target service. The identity should receive only the actions and scope the workload genuinely needs.<\/p>\n Token audience is an important detail. A token issued for Azure Storage cannot simply be presented to Key Vault, because each service validates the intended resource or scope. Supported Azure SDKs handle this by requesting tokens for the service being called. When a custom client receives an authentication error despite a valid-looking token, confirm that the token was requested for the correct destination before changing role assignments.<\/p>\n A system-assigned managed identity is enabled directly on one Azure resource. Azure creates the corresponding service principal, and the identity\u2019s lifecycle is tied to that resource. When the resource is deleted, the system-assigned identity is deleted as well. The identity cannot simply be attached to a second resource as a shared principal.<\/p>\n This can be a clean design when one resource needs its own unique access. The ownership relationship is obvious, and removing the resource also removes the identity. It is useful for workloads where one compute instance or application should have permissions that no sibling resource shares.<\/p>\n The lifecycle coupling can complicate automated deployment when role assignments must exist before the workload is recreated. A newly created system-assigned identity receives a new principal, so deployment code may need to wait for identity creation and then create the downstream role assignment. This is one reason Microsoft recommends user-assigned identities for many broader scenarios.<\/p>\n The lifecycle tie is useful during cleanup because deleting the resource removes the identity object that existed only for that workload. However, downstream role assignments can become stale references when resources are repeatedly recreated. Deployment and governance tooling should remove obsolete assignments and not assume that a new resource with the same name has the same principal ID as the resource it replaced.<\/p>\n A user-assigned managed identity is created as its own Azure resource and can be associated with multiple supported compute resources. Its lifecycle is independent of those resources. You can create the identity first, assign permissions to it, and then attach it to workloads as part of deployment.<\/p>\n Microsoft currently recommends user-assigned managed identities for most scenarios because they reduce repeated identity and role-assignment administration and allow permissions to be prepared before compute exists. A shared identity can be appropriate when several resources intentionally require the same downstream access.<\/p>\n Reuse should still follow least privilege. Sharing one identity across unrelated applications because it is convenient increases the blast radius: every resource using the identity gains the permissions assigned to it. Create separate identities when workloads have meaningfully different security boundaries or when you need independent auditing and revocation.<\/p>\n Reusability also enables blue-green or scale-out deployment patterns. New compute instances can attach the existing identity and receive the same downstream access without creating a new principal for every instance. That can simplify role-assignment limits and operational review. The security team should still know every resource allowed to attach the identity, because each one effectively gains the identity\u2019s permissions.<\/p>\n A user-assigned managed identity has identifiers that are easy to confuse. The client ID identifies the application identity when a workload or SDK needs to select which user-assigned identity should be used. The principal ID identifies the service principal object in Microsoft Entra ID and is commonly used when assigning Azure roles.<\/p>\n Using the wrong identifier can cause automation failures that look like missing permissions. A deployment may successfully attach the identity to a resource but fail when the RBAC step tries to assign a role to an object that Azure cannot resolve. Infrastructure code should name the identifier explicitly rather than using a generic variable called The identity administration concepts overlap with SC-300<\/a>. An overview of the Microsoft identity and access administrator<\/a> role provides broader context for service principals, groups, authentication, and governance, while managed identity applies those principles to Azure-hosted workloads.<\/p>\n The full Azure resource ID is a third identifier that appears in templates and resource associations. It identifies the user-assigned identity resource inside Azure Resource Manager, while the client and principal IDs identify aspects of its Entra application\/service-principal representation. Clear variable names such as Managed identity is most valuable when it eliminates secrets without replacing them with broad privilege. If a web application only needs to read one Key Vault or one storage container, grant the identity the smallest built-in role and practical scope that supports that operation. Avoid subscription Contributor because it is easy to assign.<\/p>\n Data-plane roles matter. A managed identity that needs blob data should receive an appropriate Storage Blob Data role; permission to configure the storage account is not the same as permission to read data through Microsoft Entra authorization. Key Vault, databases, Service Bus, and other services have their own access models and supported roles.<\/p>\n Review inherited permissions too. A role assigned at a subscription or resource group can make the identity far more powerful than the workload designer intended. The effective authorization is the sum of applicable assignments, so least privilege requires understanding the full scope hierarchy.<\/p>\n Secretless authentication improves credential hygiene, but it does not remove dependency risk.<\/strong><\/p>\n Eliminating an application secret removes rotation failures, secret leakage, and many deployment-time credential problems. It also creates a dependency on Microsoft Entra token issuance and the target service\u2019s support for Entra authentication. Workloads should handle token acquisition errors and service unavailability according to their reliability requirements.<\/p>\n Applications should use supported Azure Identity libraries or service integrations rather than manually calling identity endpoints unless there is a specific need. Those libraries handle token caching and selection patterns that would otherwise be easy to implement incorrectly. They also make local development easier by supporting developer credentials while the deployed workload uses managed identity.<\/p>\nManaged identity replaces stored credentials with an Azure identity<\/h3>\n
System-assigned identities share the resource lifecycle<\/h3>\n
User-assigned identities are reusable Azure resources<\/h3>\n
Client ID and principal ID serve different purposes<\/h3>\n
id<\/code>.<\/p>\nidentityResourceId<\/code>, clientId<\/code>, and principalId<\/code> prevent a surprising number of deployment errors.<\/p>\nAuthorization should be narrow and attached to the target resource<\/h3>\n