This chapter covers Managed Identities for Azure Resources, a critical feature for securely authenticating Azure resources to Azure services without storing credentials. Managed Identities are a core topic in the AZ-500 exam, appearing in approximately 5-10% of questions, especially those related to identity and access management (Objective 1.3). Understanding how to configure and use system-assigned and user-assigned managed identities, as well as their limitations and best practices, is essential for passing the exam.
Jump to a section
Imagine a large hotel where employees need to access various rooms and services without carrying a physical key for each door. Instead, each employee receives a key card that is automatically issued by the hotel's security system when they check in. This key card contains a digital token that is automatically rotated every few hours. When an employee wants to enter a room, they swipe the card at the door. The door's reader checks with the central security system to verify that the card is valid and has the right permissions. The employee never needs to remember a password or carry a separate key; the card is tied to their identity and is automatically managed by the hotel. If the employee leaves, the card is deactivated, and no one else can use it. Similarly, a Managed Identity in Azure is an automatically managed service principal that Azure resources (like a virtual machine or an app) can use to authenticate to any service that supports Azure AD authentication, without needing to store credentials in code or configuration. The identity is tied to the resource's lifecycle and is automatically rotated by Azure.
What Are Managed Identities and Why Do They Exist?
Managed Identities for Azure Resources (formerly known as Managed Service Identities, MSI) provide an automatically managed identity in Azure Active Directory (Azure AD) that applications can use when connecting to resources that support Azure AD authentication. The primary purpose is to eliminate the need for developers to manage credentials, such as keys or secrets, in code or configuration files. Instead, Azure automatically handles the creation, rotation, and secure storage of the identity's credentials.
Before managed identities, developers had to store connection strings, API keys, or service principal credentials in configuration files, environment variables, or Azure Key Vault. This introduced security risks (credential leakage) and operational overhead (manual rotation). Managed identities solve this by tying the identity to the Azure resource itself — the resource becomes a security principal that can authenticate to Azure AD.
How Managed Identities Work: The Mechanism
When you enable a managed identity on an Azure resource (e.g., a Virtual Machine, App Service, or Function), Azure performs the following steps:
Creation of a Service Principal: Azure AD creates a service principal (an identity) in the tenant that is tied to the Azure resource's lifecycle. For system-assigned identities, this service principal is created in the same Azure AD tenant as the subscription. For user-assigned identities, the service principal is created when you create the user-assigned identity resource.
Credential Provisioning: Azure automatically generates a certificate (for system-assigned) or uses a certificate-backed credential (for user-assigned) and stores it securely. For system-assigned identities, the certificate is stored on the resource itself (e.g., in the VM's metadata service). The certificate is automatically rotated by Azure every 90 days.
Token Acquisition: When the application needs to authenticate to an Azure service (e.g., Azure Key Vault, Azure SQL Database, Azure Storage), it requests an access token from the Azure Instance Metadata Service (IMDS) endpoint (for VMs) or from the local MSI endpoint (for App Services). The IMDS endpoint is at http://169.254.169.254/metadata/identity/oauth2/token for VMs. The request must include the API version and the resource URI for the target service.
Token Validation: Azure AD validates the request, checks that the resource has the managed identity enabled, and returns a JSON Web Token (JWT) with claims about the identity (e.g., object ID, tenant ID, application ID). The token is valid for a default lifetime of 8 hours (configurable up to 24 hours).
Using the Token: The application then uses the token as a Bearer token in the Authorization header when calling the target service's API. The target service validates the token with Azure AD and grants access based on the RBAC roles assigned to the managed identity.
Key Components, Values, Defaults, and Timers
System-Assigned Managed Identity: Enabled directly on an Azure resource (e.g., a VM). It has the same lifecycle as the resource — if the resource is deleted, the identity is automatically deleted. Each resource can have only one system-assigned identity.
User-Assigned Managed Identity: Created as a standalone Azure resource. It can be assigned to multiple Azure resources. It has an independent lifecycle — you can delete the identity without deleting the resources that use it. Each resource can have multiple user-assigned identities (up to 20 per VM).
Token Lifetime: Default is 8 hours, configurable between 1 hour and 24 hours using Azure AD policy. The token is cached by the Azure infrastructure.
Certificate Rotation: For system-assigned identities, the certificate is rotated automatically every 90 days. For user-assigned identities, you can manage the certificate or use a system-assigned certificate that is also rotated.
IMDS Endpoint: Accessible only from within the VM at http://169.254.169.254/metadata/identity/oauth2/token. It requires the header Metadata: true and the query parameters api-version and resource.
Azure CLI Commands:
- Enable system-assigned 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 a token using Azure CLI from within a VM: az account get-access-token --resource https://vault.azure.net (this uses the managed identity)
Interaction with Related Technologies
Azure Key Vault: Managed identities are commonly used to access secrets, keys, and certificates from Key Vault. The managed identity is granted permissions via Key Vault access policies or RBAC.
Azure Storage: Managed identities can authenticate to Azure Storage using Azure AD authentication (instead of account keys). The identity is assigned RBAC roles like "Storage Blob Data Contributor".
Azure SQL Database: Managed identities can be used to authenticate to Azure SQL using Azure AD authentication. The identity is added as a contained database user or as an Azure AD admin.
Azure Functions and App Services: These services can use managed identities to authenticate to other Azure services without storing connection strings.
Azure Kubernetes Service (AKS): AKS can use managed identities to access Azure resources like load balancers or storage. The AKS cluster itself can have a managed identity.
Configuration and Verification
To verify that a managed identity is working, you can:
- For VMs: SSH into the VM and use the following PowerShell command to get a token:
$response = Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -Headers @{Metadata='true'}For App Services: Check the environment variables IDENTITY_ENDPOINT and IDENTITY_HEADER available at runtime.
Use Azure Monitor: Enable diagnostic settings for the managed identity to log token requests.
Limitations
Managed identities cannot be used across tenants. They are scoped to a single Azure AD tenant.
Not all Azure services support managed identities. Check the documentation for each service.
For on-premises resources, you cannot use managed identities directly; you need Azure Arc or other solutions.
The token is cached; if you change RBAC assignments, it may take up to 8 hours for the new permissions to take effect (unless you force token refresh).
Enable Managed Identity on Resource
First, you decide whether to use a system-assigned or user-assigned managed identity. For system-assigned, you enable it directly on the Azure resource (e.g., a Virtual Machine) through the Azure portal, CLI, or ARM template. Azure AD then creates a service principal for the resource in the same tenant. For user-assigned, you first create a managed identity resource, which creates a service principal, and then assign it to one or more Azure resources. This step is typically done by an administrator with Contributor or Owner permissions on the resource.
Grant Permissions to the Identity
After the identity exists, you must grant it permissions to access the target Azure service (e.g., Key Vault, Storage Account). This is done via Azure RBAC role assignments or service-specific access policies. For example, to allow a VM's managed identity to read secrets from Key Vault, you add the identity to the Key Vault's access policy with Get and List permissions. Alternatively, you can assign the RBAC role 'Key Vault Secrets User' to the identity at the Key Vault scope. Permissions are evaluated at runtime when the identity presents a token.
Application Requests Token from IMDS
When the application running on the Azure resource (e.g., a script on a VM) needs to authenticate to a service, it makes an HTTP GET request to the Azure Instance Metadata Service (IMDS) endpoint: http://169.254.169.254/metadata/identity/oauth2/token. The request must include the header 'Metadata: true' and query parameters 'api-version' (e.g., 2018-02-01) and 'resource' (the URI of the target service, e.g., https://vault.azure.net). For user-assigned identities, you also include the 'client_id' parameter to specify which identity to use.
Azure AD Validates and Returns Token
The IMDS endpoint forwards the request to Azure AD, which validates that the resource has a managed identity enabled. Azure AD then issues a JSON Web Token (JWT) containing claims such as 'aud' (audience, set to the resource URI), 'iss' (issuer, the Azure AD tenant), 'oid' (object ID of the managed identity), and 'appid' (application ID). The token is signed by Azure AD. The default token lifetime is 8 hours, but it can be configured via Azure AD policy. The token is returned in the HTTP response body as an access_token.
Application Uses Token to Access Service
The application extracts the access_token from the response and includes it as a Bearer token in the Authorization header of its request to the target Azure service's API. For example, to access Azure Key Vault, the request would be: GET https://myvault.vault.azure.net/secrets/mysecret?api-version=7.0 with header 'Authorization: Bearer <token>'. The target service validates the token by checking its signature, expiry, and audience. If valid and the identity has the necessary permissions (via RBAC or access policies), the service grants access.
Enterprise Scenario 1: Secure Access to Key Vault from a Virtual Machine
A financial services company runs a batch processing application on Azure VMs that needs to read database credentials from Azure Key Vault. Previously, developers stored the Key Vault URI and a client secret in the VM's configuration files, which posed a security risk if the VM was compromised. They migrated to using a system-assigned managed identity on each VM. The operations team enabled managed identity on the VM scale set using ARM templates. They then granted the managed identity 'Get' and 'List' permissions on the Key Vault via access policies. The application code was updated to use the IMDS endpoint to request a token for 'https://vault.azure.net' and then use that token to fetch secrets. This eliminated hardcoded credentials. A challenge they faced was that if the VM was cloned or reimaged, the identity remained the same (since it's tied to the VM resource ID), but they had to ensure the new VM had the identity enabled. They also set up monitoring to alert if token acquisition failed, which indicated a misconfiguration or network issue blocking access to the IMDS endpoint (which requires a route to 169.254.169.254).
Enterprise Scenario 2: Multi-Tier App with User-Assigned Identities
A SaaS provider built a multi-tier application on Azure App Service and Azure SQL Database. They have multiple environments (dev, test, prod) and wanted a consistent identity model. They created a user-assigned managed identity per environment, e.g., 'mi-dev-app', 'mi-prod-app'. Each identity was assigned to all App Services in that environment. The SQL Database was configured to allow Azure AD authentication, and each managed identity was added as a contained database user with appropriate permissions. When a new App Service was added, they simply assigned the existing user-assigned identity, and it automatically had access to the database. A common pitfall was that the managed identity's token was cached for up to 8 hours; if they changed database permissions, they had to wait or force a restart of the App Service to refresh the token. They also learned that user-assigned identities have a separate lifecycle — if they deleted the identity by accident, all App Services lost access immediately.
Common Scale and Performance Considerations
At scale, token acquisition from IMDS is fast (usually under 100ms) because it's a local endpoint. However, if thousands of VMs request tokens simultaneously, Azure AD can handle the load, but there is a rate limit of 2000 requests per second per tenant for token issuance. Applications should cache tokens and reuse them until they expire to reduce load. Also, if you use user-assigned identities, each VM can have up to 20 identities, but the token request must specify which identity to use via the 'client_id' parameter; otherwise, the default is the system-assigned identity if present.
What AZ-500 Tests on This Topic
The AZ-500 exam covers Managed Identities under Objective 1.3: Configure and manage Azure AD identities. Specifically, you need to:
Differentiate between system-assigned and user-assigned managed identities.
Understand when to use each type.
Know how to grant permissions to managed identities via RBAC and access policies.
Understand the token acquisition process and the IMDS endpoint.
Know the limitations: not all services support it, cannot cross tenants, token caching.
Common Wrong Answers and Why Candidates Choose Them
"Managed identities can be used for on-premises resources." – This is false. Managed identities are only for Azure resources. Candidates confuse it with Azure Arc, which extends Azure management to on-premises but does not provide managed identities for on-premises VMs.
"System-assigned identities can be assigned to multiple resources." – False. A system-assigned identity is tied to a single resource and is deleted with it. User-assigned identities can be shared. Candidates mix up the two types.
"The token is valid indefinitely." – False. The default lifetime is 8 hours, configurable up to 24 hours. Candidates may think it's like a certificate that doesn't expire, but tokens have a limited lifetime.
"You need to store the client secret in the application code." – False. The whole point of managed identities is to eliminate the need for secrets. Candidates who are used to service principals might think a secret is required.
Specific Numbers, Values, and Terms on the Exam
Token lifetime: default 8 hours, max 24 hours.
IMDS endpoint IP: 169.254.169.254 (link-local address).
Header required: 'Metadata: true'.
Maximum user-assigned identities per VM: 20.
Certificate rotation: every 90 days (automatic).
Resource URI examples: https://vault.azure.net, https://storage.azure.com, https://database.windows.net.
Edge Cases and Exceptions
If a VM is stopped (deallocated), the managed identity still exists but token acquisition may fail if the IMDS endpoint is not reachable (e.g., during provisioning).
For App Services, the token endpoint is different: $IDENTITY_ENDPOINT environment variable.
Managed identities cannot be used with Azure AD B2C.
If you assign a user-assigned identity to a VM and then delete the identity, the VM will have a broken identity reference; token requests will fail.
How to Eliminate Wrong Answers
Focus on the lifecycle: system-assigned = tied to resource, user-assigned = independent. If the question involves sharing an identity across resources, eliminate system-assigned. If the question involves automatic deletion with the resource, eliminate user-assigned. Also, remember that managed identities are only for Azure resources; if the scenario involves on-premises, the answer is likely not managed identity.
Managed identities eliminate the need for credentials in code by providing an automatically managed Azure AD identity for Azure resources.
System-assigned identities are tied to a single resource and are deleted with it; user-assigned identities are standalone and can be shared.
Tokens are obtained from the Azure Instance Metadata Service (IMDS) at http://169.254.169.254/metadata/identity/oauth2/token with header 'Metadata: true'.
Default token lifetime is 8 hours, configurable up to 24 hours via Azure AD policy.
Managed identities must be granted permissions via RBAC or access policies on the target service.
Managed identities are scoped to a single Azure AD tenant and cannot be used across tenants.
Not all Azure services support managed identities; verify support before implementation.
User-assigned identities can be assigned to up to 20 VMs per identity, and a VM can have up to 20 user-assigned identities.
Certificate backing the identity is automatically rotated every 90 days.
For App Services, the token endpoint is exposed via environment variables IDENTITY_ENDPOINT and IDENTITY_HEADER.
These come up on the exam all the time. Here's how to tell them apart.
System-Assigned Managed Identity
Created automatically when enabled on a resource.
Tied to the resource lifecycle: deleted when resource is deleted.
One system-assigned identity per resource.
Cannot be shared across resources.
Simpler to set up for single-resource scenarios.
User-Assigned Managed Identity
Created as a standalone Azure resource.
Independent lifecycle: persists even if resources are deleted.
Can be assigned to multiple resources (up to 20 per VM).
Ideal for scenarios where multiple resources need the same identity.
Requires additional step to assign to resources.
Mistake
Managed identities require storing a secret or certificate in the application code.
Correct
No. Azure automatically manages the credentials (certificates) and provides a token via the IMDS endpoint. The application never needs to handle secrets directly.
Mistake
A system-assigned managed identity can be assigned to multiple Azure resources.
Correct
False. A system-assigned identity is unique to a single resource and is deleted when that resource is deleted. User-assigned identities can be assigned to multiple resources.
Mistake
Managed identities can authenticate to any Azure service without additional configuration.
Correct
False. The target service must support Azure AD authentication, and the managed identity must be granted permissions (RBAC or access policy) to access the resource.
Mistake
The token obtained from IMDS is valid indefinitely.
Correct
False. The token has a default lifetime of 8 hours, configurable up to 24 hours. After expiry, a new token must be requested.
Mistake
Managed identities work across Azure AD tenants.
Correct
False. Managed identities are scoped to the tenant where the Azure resource resides. They cannot be used to access resources in another tenant without additional configuration (e.g., using Azure B2B collaboration).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
System-assigned managed identities are created directly on an Azure resource and have the same lifecycle — if you delete the resource, the identity is also deleted. They are unique to that resource and cannot be shared. User-assigned managed identities are created as a separate Azure resource and can be assigned to multiple Azure resources (e.g., several VMs). They have an independent lifecycle; deleting the resource does not delete the identity. Use system-assigned for simple, single-resource scenarios, and user-assigned when you need the same identity across multiple resources or want to manage the identity separately.
From within the VM, send an HTTP GET request to the Azure Instance Metadata Service (IMDS) endpoint: http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net (replace resource URI with your target service). Include the header 'Metadata: true'. The response contains the access_token. For user-assigned identities, also include the 'client_id' parameter with the identity's client ID. You can test this using PowerShell or curl.
Yes, if Azure SQL Database is configured to support Azure AD authentication. You need to create an Azure AD admin for the SQL server, then add the managed identity as a contained database user (e.g., CREATE USER [identity-name] FROM EXTERNAL PROVIDER) or grant it server-level roles. The application then acquires a token for resource 'https://database.windows.net' and uses it as the password in the connection string (e.g., 'Authentication=Active Directory Managed Identity').
The VM will have a broken identity reference. Any application running on the VM that tries to acquire a token for that identity will fail because the service principal no longer exists. You must remove the identity assignment from the VM before deleting the identity, or reassign a different identity. This is a common mistake that leads to application downtime.
Yes, but within the same Azure AD tenant. Managed identities are scoped to the tenant. You can assign RBAC roles to a managed identity for resources in different subscriptions within the same tenant. However, you cannot use a managed identity to access resources in a different tenant directly.
Azure automatically rotates the certificate every 90 days. This is transparent to the application; the token acquisition process continues to work because the IMDS endpoint returns a token signed by the current certificate. No action is required from the administrator.
The default lifetime is 8 hours. You can configure it between 1 hour and 24 hours using Azure AD policy (for the entire tenant or specific applications). The token is cached by the Azure infrastructure, so if you change RBAC permissions, it may take up to the token lifetime for the new permissions to take effect.
You've just covered Managed Identities for Azure Resources — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?