Managed Identities for Azure Resources is a critical feature for securely authenticating Azure services to each other without storing credentials. This chapter covers the two types of managed identities (system-assigned and user-assigned), how they work internally, and how to configure and use them. On the AZ-104 exam, this topic appears in approximately 10-15% of questions related to identity governance, often in scenarios involving secure access to Azure resources like Key Vault or Storage. You must understand when to use each type, how RBAC roles are assigned, and the limitations of managed identities.
Jump to a section
Imagine a large corporate building with multiple departments. Each employee has a personal badge that identifies them individually. However, there are also generic 'service badges' that are assigned to specific roles, like 'Maintenance' or 'IT Support'. These service badges are not tied to a specific person; they are issued to the role itself. When a maintenance worker picks up the badge at the start of their shift, they can access maintenance-only areas without exposing their personal identity. The badge automatically expires at the end of the shift, and the same badge can be used by the next worker. This is exactly how Managed Identities work in Azure. Instead of storing credentials in code or configuration files, Azure resources (like a virtual machine or a function app) are assigned a managed identity – essentially a service principal that acts as a 'badge' for that resource. This identity can be granted permissions to other Azure resources (e.g., Key Vault, Storage Account) via Azure RBAC. The identity is managed by Azure itself: when the resource is created, Azure automatically creates a corresponding service principal in Azure AD and rotates the credentials (certificates) automatically. There are two types: System-assigned (tied directly to the resource, deleted when the resource is deleted) and User-assigned (a standalone identity that can be assigned to multiple resources). Using managed identities eliminates the need for developers to handle secrets, reducing the risk of credential leakage.
What Are Managed Identities and Why Do They Exist?
Managed Identities provide an Azure Active Directory (Azure AD) identity for an Azure resource, such as a Virtual Machine, App Service, or Azure Function. This identity can be used to authenticate to any service that supports Azure AD authentication, including Key Vault, Storage, SQL Database, and more. The primary purpose is to eliminate the need for developers to manage credentials (like connection strings or certificates) in code or configuration files. Managed identities are automatically managed by Azure – the lifecycle, credential rotation, and security are handled by the platform.
How They Work Internally – The Mechanism
When you enable a managed identity on a resource, Azure performs several actions: 1. Creates a service principal in Azure AD that represents the resource. This service principal is either tied to the resource (system-assigned) or exists independently (user-assigned). 2. For system-assigned identities, the service principal is automatically deleted when the resource is deleted. 3. Azure manages the authentication credentials (certificates) automatically. The resource obtains tokens from Azure AD using the Azure Instance Metadata Service (IMDS) endpoint (169.254.169.254) for VMs, or via the App Service authentication token store for App Services. 4. The token is used to authenticate to other Azure services. The resource can request a token for a specific audience (e.g., https://vault.azure.net for Key Vault) by calling the local managed identity endpoint. 5. The token is valid for a default of 8 hours (configurable up to 24 hours) and is automatically cached. The resource can request a new token before expiration.
Key Components, Values, Defaults, and Timers
System-assigned identity: Enabled directly on a resource. One identity per resource. Deleted with the resource. Cannot be shared across resources.
User-assigned identity: Created as a standalone Azure resource. Can be assigned to multiple resources. Persists even if the resource is deleted. Supports multiple identities per resource (up to 20 per VM).
Token lifetime: Default 8 hours, but can be configured via Conditional Access or custom policies (not directly on the identity). The token is cached and refreshed automatically.
IMDS endpoint: For Azure VMs, the endpoint is http://169.254.169.254/metadata/identity/oauth2/token. API version: 2018-02-01 or later.
Service principal naming: For system-assigned, the name is the same as the resource name (e.g., MyVM). For user-assigned, the name is the identity name.
RBAC assignment: You assign roles to the managed identity just like any other security principal. For example, assign 'Key Vault Secrets User' to the identity to allow reading secrets.
Configuration and Verification Commands
Azure CLI:
Enable system-assigned identity on a VM: az vm identity assign -g MyResourceGroup -n MyVm
Create a user-assigned identity: az identity create -g MyResourceGroup -n MyIdentity
Assign user-assigned identity to a VM: az vm identity assign -g MyResourceGroup -n MyVm --identities /subscriptions/.../Microsoft.ManagedIdentity/userAssignedIdentities/MyIdentity
Get token for Key Vault from a VM: curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -H Metadata:true
PowerShell:
Enable system-assigned: Update-AzVM -ResourceGroupName MyResourceGroup -Name MyVm -IdentityType SystemAssigned
Create user-assigned: New-AzUserAssignedIdentity -ResourceGroupName MyResourceGroup -Name MyIdentity
Assign: $vm = Get-AzVM -ResourceGroupName MyResourceGroup -Name MyVm; $identity = Get-AzUserAssignedIdentity -ResourceGroupName MyResourceGroup -Name MyIdentity; Update-AzVM -ResourceGroupName MyResourceGroup -VM $vm -IdentityType UserAssigned -IdentityId $identity.Id
Azure Portal:
Under the resource's 'Identity' blade, you can enable system-assigned or attach user-assigned identities.
Interaction with Related Technologies
Managed identities integrate with: - Azure Key Vault: VMs can retrieve certificates and secrets without storing credentials. - Azure Storage: Use managed identity to authenticate to Blob or Queue storage (via Azure AD authentication). - Azure SQL Database: Use managed identity for Azure AD authentication (requires an Azure AD admin). - Azure Container Instances, Kubernetes (AKS): Pods can use managed identities via pod identity. - Azure Functions and Logic Apps: Use managed identity to connect to other services.
Managed identities cannot be used to authenticate to third-party services or on-premises resources unless they support Azure AD tokens. Also, they are not supported for all resource types – check the Azure documentation for the latest list.
Exam-Relevant Details
The AZ-104 exam tests your ability to choose between system-assigned and user-assigned identities based on scenarios. Common scenarios: a single VM needing access to Key Vault (system-assigned), multiple VMs needing the same permissions (user-assigned), or a resource that must be deleted without affecting others (user-assigned).
Know that managed identities are service principals in Azure AD. They appear in the Enterprise Applications blade.
Understand that you must assign RBAC roles to the identity, not to the resource directly. For example, to allow a VM to read secrets from Key Vault, you assign the 'Key Vault Secrets User' role to the VM's managed identity at the Key Vault scope.
The token request uses the IMDS endpoint with a specific header Metadata: true to prevent Server-Side Request Forgery (SSRF) attacks.
Managed identities are free – there is no additional cost.
Limitations
Not all Azure services support managed identities. Always verify.
User-assigned identities can be assigned to a maximum of 200 resources per identity (soft limit).
A resource can have up to 20 user-assigned identities.
Managed identities cannot be used across Azure AD tenants.
For on-premises resources, you must use service principals or other methods.
Enable Managed Identity on Resource
First, you decide whether to use a system-assigned or user-assigned identity. For system-assigned, you simply enable it on the resource (e.g., a VM) via portal, CLI, or PowerShell. Azure automatically creates a service principal in Azure AD with the same name as the resource. For user-assigned, you first create the identity as a separate resource, then assign it to the target resource. The identity is represented as a service principal in Azure AD. This step is a one-time configuration; no credentials are stored in the resource.
Grant Permissions via RBAC
After the identity exists, you must grant it permissions to access other Azure resources. This is done via Azure Role-Based Access Control (RBAC). For example, to allow the identity to read secrets from Key Vault, you assign the 'Key Vault Secrets User' role to the identity at the Key Vault scope. You can do this in the Azure portal under the target resource's Access Control (IAM) blade, or via CLI: `az role assignment create --assignee <object-id-of-identity> --role 'Key Vault Secrets User' --scope /subscriptions/.../resourceGroups/.../providers/Microsoft.KeyVault/vaults/MyVault`. The identity is treated like any other security principal.
Request Token from Azure AD
When the resource (e.g., a VM) needs to access a target service, it requests an access token from Azure AD. For a VM, the request is made to the Azure Instance Metadata Service (IMDS) endpoint at http://169.254.169.254/metadata/identity/oauth2/token. The request includes the API version, the resource URL (e.g., https://vault.azure.net), and the header `Metadata: true`. The IMDS endpoint forwards the request to Azure AD, which validates the identity and returns a JWT token. The token is valid for a default of 8 hours. The VM caches the token and automatically refreshes it before expiration.
Use Token to Authenticate to Target Service
The resource presents the token to the target service (e.g., Key Vault) in the Authorization header as a Bearer token. The target service validates the token with Azure AD and grants access based on the permissions assigned to the identity. For example, to read a secret from Key Vault using the REST API, the VM sends a GET request to https://myvault.vault.azure.net/secrets/mysecret?api-version=7.0 with the header `Authorization: Bearer <token>`. The Key Vault service checks the token's claims and the RBAC permissions to determine if the request is allowed.
Token Expiration and Rotation
Tokens have a default lifetime of 8 hours. Before the token expires, the resource can request a new token using the same IMDS endpoint. Azure automatically rotates the underlying credentials (certificates) of the managed identity periodically. This rotation is transparent to the resource. The resource never needs to handle secrets or certificates. If the resource is deleted, the system-assigned identity is automatically removed, but user-assigned identities persist until explicitly deleted.
Enterprise Scenario 1: Secure Access to Key Vault from a Virtual Machine
A financial services company runs a batch processing application on Azure VMs. The application needs to read database credentials from Azure Key Vault. Previously, developers stored the Key Vault URL and a client secret in the VM's environment variables, which posed a security risk. By enabling a system-assigned managed identity on each VM and assigning the 'Key Vault Secrets User' role to the identity, the application can now retrieve secrets without any stored credentials. The code uses the IMDS endpoint to get a token and then accesses Key Vault. This eliminated the risk of credential leakage and simplified deployment. In production, they have hundreds of VMs, and each VM gets its own system-assigned identity. The main performance consideration is the token request latency (typically <100ms) and the token cache. They configure the token cache to minimize repeated requests. A common misconfiguration is forgetting to assign the RBAC role – the identity exists but has no permissions, causing authentication failures.
Enterprise Scenario 2: Multi-Resource Access with User-Assigned Identity
A SaaS provider runs a microservices architecture on Azure App Services. Multiple services need to write logs to the same Azure Storage account. Instead of enabling system-assigned identity on each service and assigning permissions individually, they create a single user-assigned identity named 'log-writer-identity' and assign it to all App Services. They then grant the 'Storage Blob Data Contributor' role to this identity on the storage account. This centralizes permissions management: if a new service is added, they just assign the same identity. If the storage account changes, they update the role assignment once. This scenario is common in exam questions: when multiple resources need the same permissions, a user-assigned identity is the correct choice. A mistake candidates make is using system-assigned identities and assigning roles to each – which works but is harder to manage. The exam tests this trade-off.
Scenario 3: Azure Function Accessing SQL Database
A logistics company uses Azure Functions to process incoming orders and write to an Azure SQL Database. The function uses a managed identity (system-assigned) to authenticate to SQL Database. They create an Azure AD admin for the SQL server and then create a contained database user mapped to the function's managed identity. The function code uses the managed identity to get a token for 'https://database.windows.net' and uses it as the password in the connection string. This avoids storing credentials in the function's configuration. A common issue is that the managed identity must be added as a user in the SQL database with appropriate permissions – forgetting this step leads to login failures. Also, the function's identity must be enabled before adding the database user.
The AZ-104 exam tests Managed Identities under Objective 1.1: 'Manage identities in Azure AD'. Specifically, you need to be able to 'implement and manage identities for Azure resources' and 'manage Azure AD identity protection'. The exam expects you to differentiate between system-assigned and user-assigned identities, understand how to assign RBAC roles to identities, and know the token acquisition process.
Common Wrong Answers and Why Candidates Choose Them
'Managed identities can be used to authenticate to any service.' This is wrong because managed identities only work with services that support Azure AD authentication. Some services like Azure Redis Cache or third-party services may not support it. Candidates overgeneralize.
'System-assigned identities can be shared across multiple resources.' This is false – each system-assigned identity is unique to a resource. Candidates confuse it with user-assigned identities.
'You need to store the client ID and secret of the managed identity in the application code.' This defeats the purpose. The identity is managed by Azure; the resource requests tokens without any secrets. Candidates who are used to service principals may think they need to store credentials.
'Managed identities are only available for VMs.' This is incorrect – they are available for many Azure services including App Services, Functions, AKS, Logic Apps, and more. Candidates may not know the full list.
Specific Numbers and Terms on the Exam
Token lifetime: default 8 hours (not 1 hour or 24 hours).
IMDS endpoint IP: 169.254.169.254 (a link-local address).
Header required: Metadata: true.
Maximum user-assigned identities per resource: 20.
Maximum resources per user-assigned identity: 200 (soft limit).
Edge Cases and Exceptions
If a VM is moved to another resource group or subscription, the system-assigned identity is not automatically transferred. You must recreate it.
For Azure Kubernetes Service (AKS), managed identities are used via pod-managed identities (add-on) or via OIDC issuer – this is more advanced but may appear.
Managed identities cannot be used to authenticate to Azure AD itself (e.g., to call Microsoft Graph) unless the identity is granted appropriate permissions via admin consent. This is a common trap.
How to Eliminate Wrong Answers
If a question asks about sharing an identity across multiple resources, choose user-assigned.
If a question asks about automatic credential management, choose managed identity over service principal.
If a question mentions storing credentials in code, eliminate that option – managed identities avoid that.
If a question involves on-premises resources, managed identities are not directly applicable.
Managed identities eliminate the need for storing credentials in code or configuration.
System-assigned identities are tied to a single resource and are deleted with it.
User-assigned identities are standalone and can be shared across multiple resources.
Token requests use the IMDS endpoint at 169.254.169.254 with the header Metadata: true.
Default token lifetime is 8 hours; Azure automatically rotates credentials.
You must assign RBAC roles to the identity to grant permissions to target resources.
Managed identities are free and available for many Azure services, not just VMs.
These come up on the exam all the time. Here's how to tell them apart.
System-Assigned Managed Identity
Tied directly to a single resource; deleted when the resource is deleted.
Cannot be shared across resources.
Simpler to set up – just enable on the resource.
The service principal name matches the resource name.
Ideal for resources that need a unique identity.
User-Assigned Managed Identity
Created as a standalone Azure resource; persists independently.
Can be assigned to multiple resources (up to 20 per resource).
Requires extra step to create and assign.
The service principal name is the identity name you choose.
Ideal for scenarios where multiple resources need the same permissions.
Mistake
Managed identities are the same as service principals.
Correct
Managed identities are a type of service principal, but they are automatically managed by Azure. Service principals are manually created and require credential management. Managed identities have automatic certificate rotation and are tied to Azure resources.
Mistake
System-assigned identities can be assigned to multiple resources.
Correct
Each system-assigned identity is unique to a single resource. To share an identity across resources, you must use a user-assigned identity.
Mistake
You need to store the managed identity's client ID and secret in your application.
Correct
The application does not need any secrets. It requests a token from the local metadata endpoint (IMDS) using the identity's client ID (for user-assigned) or without it (for system-assigned). Azure handles authentication.
Mistake
Managed identities can be used to authenticate to any Azure service.
Correct
Only services that support Azure AD authentication can accept tokens from managed identities. For example, Azure Redis Cache does not support Azure AD authentication, so managed identities cannot be used there.
Mistake
Managed identities are only available for Azure VMs.
Correct
Managed identities are supported for many Azure resources, including App Services, Azure Functions, Azure Logic Apps, Azure Kubernetes Service, Azure Container Instances, and more.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
System-assigned identities are created directly on an Azure resource and have a one-to-one relationship with that resource. They are automatically deleted when the resource is deleted. User-assigned identities are created as standalone resources and can be assigned to multiple Azure resources. They persist even if the resources are deleted. Use system-assigned for a single resource needing a unique identity; use user-assigned for multiple resources that need the same permissions (e.g., several VMs accessing the same storage account).
First, enable a managed identity on your resource (e.g., VM). Then, assign the 'Key Vault Secrets User' role to that identity at the Key Vault scope. In your code, request a token from the local metadata endpoint (http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net) with the header 'Metadata: true'. Use the token as a Bearer token in the Authorization header when calling Key Vault's REST API. No secrets are stored in the application.
Yes, you can. Enable a managed identity on your resource (e.g., an Azure Function). Then, create an Azure AD admin for the SQL server. Next, create a contained database user mapped to the managed identity using the CREATE USER statement. Finally, grant appropriate permissions. In your application code, acquire a token for resource 'https://database.windows.net' and use it as the password in the connection string. This eliminates the need for SQL authentication credentials.
The Azure Instance Metadata Service (IMDS) endpoint is a REST API available at http://169.254.169.254. It provides metadata about a virtual machine, including managed identity tokens. To get a token, you make a GET request to /metadata/identity/oauth2/token with parameters like api-version and resource. The request must include the header 'Metadata: true' to prevent SSRF attacks. The endpoint returns a JSON object containing the access token, which you can then use to authenticate to other Azure services.
No, managed identities are designed for Azure resources only. For on-premises applications, you must use service principals or other authentication methods like managed service identities (which are different). However, you can use Azure Arc to extend Azure management to on-premises servers and enable managed identities on those servers.
You assign RBAC roles to the managed identity exactly as you would to a user or group. In the Azure portal, navigate to the target resource (e.g., Key Vault) and go to Access Control (IAM). Click 'Add role assignment', select the role (e.g., 'Key Vault Secrets User'), and then search for the managed identity by name or object ID. You can also use Azure CLI: az role assignment create --assignee <object-id> --role <role-name> --scope <scope>. The managed identity must have the appropriate permissions to perform actions.
For system-assigned identities, the identity is automatically deleted when the resource is deleted. For user-assigned identities, the identity persists as a standalone resource even after the resource is deleted. You must manually delete the user-assigned identity if it is no longer needed. This is why user-assigned identities are useful when you need to reuse the same identity across multiple resources.
You've just covered Managed Identities for Azure Resources — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?