Managed identity questions on the AZ-104 exam test whether you understand the difference between system-assigned and user-assigned identities, when each is appropriate, and how they eliminate the need to manage credentials.
What a Managed Identity Is
A managed identity is an identity in Azure Active Directory (Entra ID) that is created automatically for an Azure resource. The resource uses this identity to authenticate to other Azure services (like Key Vault, Storage, or SQL Database) without any credentials being embedded in code or configuration.
Azure handles the lifecycle of the identity's credentials automatically — the certificates rotate periodically without any administrator action required.
Why it matters: without managed identities, developers store connection strings, passwords, or API keys in code or environment variables. This creates a security risk if credentials are exposed. Managed identities eliminate the need to store credentials entirely.
System-Assigned Managed Identity
A system-assigned managed identity is tied to a specific Azure resource:
- Created when you enable it on the resource (VM, App Service, Function App, etc.)
- Deleted automatically when the resource is deleted
- One-to-one relationship: one identity per resource, shared with nothing else
When to use: when the identity is only needed for that one specific resource. If a single VM needs to read secrets from Key Vault, a system-assigned identity is the right choice — it is simple, and its lifecycle is managed automatically.
User-Assigned Managed Identity
A user-assigned managed identity is an independent Azure resource:
- Created separately, then assigned to one or more resources
- Lives independently — deleting the resources it is assigned to does not delete the identity
- Shared across resources: the same identity can be assigned to multiple VMs, containers, or applications
When to use: when multiple resources need the same permissions, or when you need the identity to persist independently of specific resource lifecycles.
Exam scenario: "A company has 50 VMs that all need read access to the same Azure Key Vault. Which type of managed identity minimises administrative overhead?"
User-assigned managed identity. Create one identity, grant it Key Vault read permissions, then assign it to all 50 VMs. If you used system-assigned identities, you would need to configure 50 separate permission grants.
Comparison Table
| Feature | System-Assigned | User-Assigned |
|---|---|---|
| Created by | Enabling on the resource | Creating as a standalone resource |
| Lifecycle | Tied to the resource | Independent |
| Shared across resources | No | Yes |
| Best for | Single resource, simple use case | Multiple resources, shared permissions |
Granting Permissions to a Managed Identity
After creating the identity, you assign Azure RBAC roles to it:
Key Vault → Access control (IAM) → Add role assignment
Role: Key Vault Secrets User
Assign access to: Managed identity
Select: [your VM or user-assigned identity]
The resource can then use its identity to call the Key Vault API without any stored credentials. The Azure SDK handles the token exchange automatically.
The Exam Trap
Candidates sometimes confuse managed identities with service principals. A managed identity is a special type of service principal, but its credentials are managed entirely by Azure — you never see the certificate or secret. A regular service principal requires you to create and rotate credentials yourself.
"Which option allows an Azure Function to access Azure Blob Storage without storing credentials?" — Managed identity (either type, but system-assigned is simpler if it is just one function).
"What happens to a system-assigned managed identity when the VM it is assigned to is deleted?" — The identity is deleted automatically.
Practice AZ-104 identity and governance questions to solidify the difference between identity types.
How Managed Identity Authentication Actually Works — The Flow
Understanding the authentication flow helps you answer "why" questions on the exam, not just "what" questions.
When a VM with a system-assigned managed identity needs to authenticate to Azure Key Vault (or any Azure service):
- The application code calls the Azure Instance Metadata Service (IMDS) at the link-local address
http://169.254.169.254/metadata/identity/oauth2/tokenwith the target resource URI. - IMDS returns a short-lived JWT (JSON Web Token) access token, signed by Entra ID.
- The application includes this token in the Authorization header of its API call to Key Vault.
- Key Vault validates the token with Entra ID and checks the RBAC role assignment.
- Access is granted or denied based on the role.
No password is stored anywhere. No certificate is rotated. No secret appears in code or configuration files. The Azure platform manages the underlying credential lifecycle entirely.
The exam sometimes asks: "Which endpoint does the application use to obtain an access token when using managed identity?" Answer: Azure Instance Metadata Service at 169.254.169.254. Candidates who haven't seen this before guess "Azure AD endpoint" or "Key Vault directly."
RBAC Assignment for Managed Identity — The Exact Steps in Portal
Enabling managed identity on a VM does not grant it access to anything. You must assign RBAC roles explicitly.
Portal path: Key Vault (or target resource) → Access control (IAM) → Add role assignment → Role: [e.g., Key Vault Secrets User] → Assign access to: Managed identity → Select: [your VM's identity].
Scope matters. If you assign the role at the resource group level, the identity gets access to all resources in that resource group. If you assign at the subscription level, it gets access across all resource groups. Best practice is to scope as narrowly as possible — assign at the individual resource level when you can.
The RBAC assignment for a managed identity is identical to assigning a role to a user or group. The only difference is selecting "Managed identity" as the type in the "Assign access to" dropdown. The exam tests this as a scenario: "A VM needs read access to secrets in a specific Key Vault. How do you configure this?" — Enable managed identity on the VM, then assign Key Vault Secrets User role scoped to that Key Vault.
User-Assigned Identity Across Multiple VMs — The Real Advantage
A system-assigned identity is tied to the VM lifecycle. Delete the VM, and the identity is gone. User-assigned identities are standalone resources that exist independently.
This decoupling has two practical benefits the exam tests:
Multiple VMs, one identity: create the user-assigned identity once, assign it to 20 VMs, and configure the RBAC role assignment once on the target resource. If you add a 21st VM, just attach the existing identity — the RBAC assignment already covers it.
VM replacement without RBAC reconfiguration: if a VM is replaced (decommissioned and redeployed), detach the identity from the old VM, attach it to the new one. The RBAC assignments on target resources stay intact.
Creating a user-assigned managed identity:
az identity create --name myIdentity --resource-group myRG --location eastus
Assigning it to a VM:
az vm identity assign --name myVM --resource-group myRG --identities myIdentity
Exam pattern: "A company has 15 VMs that all need the same access to Azure Storage. A new VM is added every month. Which identity type minimises administrative overhead?" → User-assigned managed identity.
Federated Identity Credentials — The External Workload Use Case
Managed identities only work for resources running inside Azure. For GitHub Actions pipelines, Kubernetes pods running on-premises, or other external workloads that need to access Azure resources, the solution is workload identity federation.
Workload identity federation lets an external identity provider (GitHub, Kubernetes, etc.) exchange its own token for an Entra ID access token, without any shared secret or certificate. The trust relationship is configured on a user-assigned managed identity or an app registration.
For GitHub Actions specifically:
- Create a user-assigned managed identity (or app registration).
- Add a federated credential for the GitHub repo and branch.
- Grant the identity RBAC roles on Azure resources.
- In the GitHub workflow, use the
azure/loginaction with OIDC — no secrets stored in GitHub.
The exam tests this as: "A CI/CD pipeline running in GitHub Actions needs to deploy resources to Azure. The solution must not store any credentials in GitHub Secrets." → Workload identity federation with a user-assigned managed identity.
Managed Identity vs Service Principal — When Each Is Used
Both managed identities and service principals are types of application identity in Entra ID. The distinction:
Managed identity — For Azure resources (VMs, App Service, Azure Functions, AKS pods, Logic Apps). Credential managed by Azure platform. No rotation needed. Cannot be used outside Azure.
Service principal — For any workload, including non-Azure. Requires a client secret or certificate. Secret expires and must be rotated. Supports more complex scenarios (multi-tenant, custom permissions). If the secret is leaked, it's a security incident.
When the exam says "an on-premises application needs to access Azure resources," the answer is a service principal — managed identity doesn't work for on-premises. When the exam says "an Azure VM needs to access Azure resources without storing credentials," the answer is managed identity.
The maintenance burden is the key differentiator: service principals require credential rotation (typically every 6–24 months), which means automation to rotate and distribute new secrets. Managed identities have zero credential rotation burden because there are no credentials to rotate.
The Exam Pattern: Eliminate Credential Management
Any question that contains the phrase "without storing credentials in code," "without managing secrets," "eliminate the need for credential rotation," or "most secure way to access Azure services from an Azure resource" — the answer is managed identity.
Wrong answers the exam offers: "Store the connection string in app settings" — still a credential. "Use a service principal with a certificate stored in Key Vault" — still a credential that needs management. "Store the client secret as an environment variable" — even worse. "Use a SAS token embedded in the application" — still a credential.
The only answer that genuinely eliminates credential management for Azure-to-Azure calls is managed identity. When the exam gives you this pattern, don't second-guess it.