Managed Identities: Stop Treating Credentials as Application Configuration
Many Azure security problems begin with a perfectly understandable shortcut: an application needs to call another service, so somebody gives it a secret. The secret lands in an app setting, a deployment variable, a configuration file, or a vault reference. From that moment on, the team owns a credential lifecycle problem. Someone must generate the secret, distribute it, rotate it, prevent it from leaking, and coordinate every consumer when it changes.
Managed identities change that operating model. Instead of treating a credential as application configuration, Azure gives a workload an identity in Microsoft Entra ID and lets the platform obtain tokens for that identity. The application still needs authorization to the target resource, but the team no longer has to manufacture and distribute a reusable password-like secret for the workload.
This is a core administrative pattern for AZ-104, but its value becomes clearer when it is viewed as an identity-design decision rather than a feature toggle. A managed identity is useful because it separates authentication from secret handling and lets Azure RBAC or service-specific authorization determine what the workload can actually do.
Managed identity solves secret handling, not authorization design
Enabling a managed identity does not give a workload useful permissions by itself. It creates or associates an identity that can request tokens. The administrator still has to decide what the identity should access and at what scope.
That separation is healthy. Authentication answers “who is this workload?” Authorization answers “what is this workload allowed to do?” If an application running on a virtual machine needs to read blobs from one storage account, the identity should receive a role that grants the necessary data access at the narrowest practical scope. Giving it Contributor at the subscription simply because that is easy defeats much of the security benefit.
The same principle appears throughout identity and access management: identity is not the same thing as privilege. A clean design minimizes permissions, limits scope, and documents the business or technical reason for each assignment.
Managed identities therefore reduce one class of risk while making authorization discipline more important. The team no longer has a secret to rotate, but a compromised workload can still use every permission granted to its identity. Least privilege remains the control that limits the blast radius.
System-assigned and user-assigned identities have different lifecycle behavior
A system-assigned managed identity belongs to one Azure resource. Azure creates the identity when it is enabled on that resource and removes it when the resource is deleted. That coupling is useful when the permissions should disappear with the workload and when each resource should have a distinct audit identity.
A user-assigned managed identity is a separate Azure resource. It can exist before the workload and can be associated with multiple supported resources. Its lifecycle is independent, which makes it useful when several instances perform the same job, when identity and workload deployment are owned by different teams, or when permissions must be prepared before compute resources are created.
The names can be misleading if they are read too literally. “User-assigned” does not mean the identity represents a human user. It is still a workload identity. The term describes how the identity is created and attached to resources.
Microsoft currently recommends user-assigned managed identities for many scenarios because they reduce repeated role assignments and decouple identity provisioning from compute lifecycle. System-assigned identities remain useful when one resource should have one unique identity and its permissions should disappear automatically when the resource is deleted.
Deployment sequencing is one of the practical reasons identity type matters
Imagine an application deployment that creates a compute resource and then needs that workload to access Key Vault or Storage immediately. With a system-assigned identity, the principal does not exist until the resource is created. The deployment process may then need enough privilege to create role assignments after the identity appears.
A user-assigned identity can be created earlier, reviewed, granted access, and then attached to the workload during deployment. That can make infrastructure pipelines easier to separate by responsibility. A platform or security team can own the identity and permissions, while an application team receives only the right to attach the approved identity to its resource.
This separation is especially relevant in larger environments where the people deploying applications should not also be able to grant arbitrary access across the subscription. Administrators preparing for AZ-500 encounter the same concern from the perspective of secure access design: deployment convenience should not expand privilege unnecessarily.
Shared identities reduce administration but can blur accountability
Attaching one user-assigned identity to many equivalent resources can simplify operations. Instead of maintaining dozens of near-identical role assignments, the team grants the shared identity the required access once and attaches it to the workloads that perform the same function.
That simplification has a trade-off. If logs show that the shared identity accessed a target resource, the identity alone may not tell you which source resource performed the action. When per-resource attribution matters, a system-assigned identity can produce a clearer audit boundary.
The design question is therefore not “which type is more secure?” It is “which lifecycle and audit boundary matches the workload?” A stateless fleet performing the same task may benefit from a shared user-assigned identity. A sensitive automation process that needs distinct accountability may justify a separate identity.
Teams should also be careful about who can attach a powerful user-assigned identity to another resource. If an operator can assign an identity that already has access to sensitive data, that operator may effectively be able to obtain the same access by attaching the identity to code they control. Identity assignment permission is therefore part of the privilege model, not a harmless resource-management action.
Token behavior explains several confusing permission failures
Applications using managed identity request access tokens for a target resource. Azure infrastructure obtains and caches those tokens so applications do not need to handle credentials directly. This is convenient, but it also means authorization changes may not appear instantly in every scenario.
Changes involving group or role membership expressed in token claims can take time to propagate because managed identity tokens are cached. Microsoft specifically warns that group- or role-membership changes for managed identities can take several hours to become effective in some cases. That matters during incident response and troubleshooting.
An administrator who removes an identity from a group and immediately retests may conclude that the permission removal failed. The more reliable approach is to understand which permissions are direct assignments, which are inherited through group or role membership, and what token caching behavior applies.
This is one reason Microsoft recommends directly applying permissions to a user-assigned managed identity in scenarios where rapid permission changes matter, rather than relying on group membership as an indirection layer. The architecture should match the operational need for revocation speed.
Managed identities work best when the target service supports Entra authorization cleanly
The strongest pattern is a source workload using a managed identity to obtain a token for a target service that supports Microsoft Entra authentication and granular authorization. Storage data roles, Key Vault permissions, Azure SQL authentication patterns, Service Bus access, and many other Azure services fit this model.
The application code should request a token through an Azure identity library or supported platform integration and then call the target service. It should not need to know a client secret. Development environments can use developer credentials, while production uses the managed identity through the same credential chain when the SDK supports it.
This makes local development and production security compatible rather than forcing developers to copy production-style secrets onto laptops. It also makes rotation mostly an identity-platform concern instead of an application release event.
For teams building deeper expertise in SC-300, managed identities fit into the broader picture of workload identity, role assignment, conditional access boundaries where applicable, privileged administration, and access governance. They are not an isolated Azure compute trick.
Troubleshooting should separate identity, token, and authorization failures
When a managed-identity workload cannot reach a target service, administrators often change role assignments immediately. That can make the problem harder to understand. A cleaner diagnostic sequence asks three questions.
First, does the source resource actually have the intended managed identity attached and enabled? Second, can the workload obtain a token for the correct target resource? Third, does the identity represented by that token have the required permission at the correct scope?
The distinction matters because different failures can produce similar application messages. The wrong client ID may cause a user-assigned identity selection problem. A valid token may be issued but lack the role required for a data operation. A role may be assigned at the wrong resource scope. A service may use its own authorization model. A firewall or private endpoint may block network access before identity is even evaluated.
Logs are essential. Azure Activity logs show management operations involving identities and role assignments. Microsoft Entra sign-in data can provide visibility into managed identity sign-ins. Target services often record authorization failures. Combining those records is much faster than repeatedly granting broader roles until the application works.
Identity cleanup should be part of workload cleanup
System-assigned identities disappear with their resource, which naturally removes the principal. User-assigned identities do not. That is a feature, but it creates a lifecycle obligation. When a workload is retired, the team should decide whether its user-assigned identity is still used elsewhere, whether its role assignments remain justified, and whether the identity should be deleted.
Unused identities with lingering permissions are a form of access debt. They may not create an immediate outage, so they survive migrations and reorganizations. Months later, nobody remembers whether deleting one is safe. Clear naming, ownership tags, infrastructure-as-code definitions, and periodic access review reduce that ambiguity.
The same applies to shared identities. If multiple applications use one identity, changes to its permissions affect every consumer. That makes ownership and dependency records important. Convenience at deployment time should not create an identity that nobody can safely modify later.
Managed identity is a better default because it changes who owns the secret problem
The biggest benefit of managed identities is not that the application has “no credentials.” The workload still proves its identity and receives tokens. The benefit is that Azure manages the underlying credential material and token acquisition infrastructure, so application teams do not have to create a long-lived secret and invent a process around it.
That shifts the administrator’s attention to the right questions: which identity should this workload use, what should it be allowed to access, who can attach that identity, how will access be audited, and what happens when the workload is retired?
Those are the same questions that define mature Microsoft Identity and Access Administrator practice. Managed identities are valuable not because they remove identity management, but because they let teams manage identity directly instead of disguising it as secret distribution.
For an Azure Administrator, that is the practical takeaway: whenever Azure-hosted code needs to authenticate to another service, managed identity should be one of the first patterns considered. The goal is not to use the feature everywhere by rule. The goal is to stop accepting manually handled application secrets as the automatic starting point.