AZ-104
Deep Dive
Eliminates credentials from code. An app or VM gets an identity managed by Azure and can authenticate against other services without passwords or hardcoded secrets.
Contents
❌ Without Managed Identity
# App needs to read a secret from Key Vault
# How does it authenticate?
CLIENT_ID = "abc-123" # hardcoded
CLIENT_SECRET = "s3cr3t!" # ← DANGER
credential = ClientSecretCredential(
tenant_id, CLIENT_ID, CLIENT_SECRET
)
client = SecretClient(vault_url, credential)
secret = client.get_secret("db-password")✓ With Managed Identity
# App uses Managed Identity — zero credentials
credential = DefaultAzureCredential()
# Azure injects the token automatically ↑
client = SecretClient(vault_url, credential)
secret = client.get_secret("db-password")| Dimension | System-assigned | User-assigned |
|---|---|---|
| Lifecycle | Tied to the resource — created/deleted with it | Independent — persists even if the resource is deleted |
| Shareable | No — only that resource can use it | Yes — multiple resources can share it |
| Creation | Automatic when enabled on the resource | A standalone resource in Azure (type: Managed Identity) |
| Typical case | A VM that accesses Key Vault only for itself | A fleet of VMs or apps that share the same access |
| Role management | Assign roles to the resource identity's Object ID | Assign roles to the User-assigned MI once, attach it to many resources |
| Recommended when | A single resource with specific access | Multiple resources need the same permissions |
Enabling System-assigned on a VM
Portal
VM → Identity → System assigned → Status: On → SaveCLI
az vm identity assign --name myVM --resource-group myRGPowerShell
Update-AzVM -VM $vm -IdentityType SystemAssignedBicep/ARM
identity: { type: "SystemAssigned" } on the resourceFull flow: VM → Key Vault
App Service → Key Vault
Key Vault References in App Settings avoid even having the value show up in the portal.
VM / Function → Storage Blob
Storage Blob Data Contributor allows reading/writing data but not managing the account itself.
Resources compatible with Managed Identity
| Aspect | Service Principal (manual) | Managed Identity |
|---|---|---|
| Credentials | Client Secret or Certificate — manual management | None — Azure manages the token |
| Rotation | Manual (must remember the expiration) | Automatic |
| Use in code | ClientSecretCredential(tenant, client_id, secret) | DefaultAzureCredential() — no parameters |
| Application | External apps, CI/CD pipelines, external scripts | Azure resources (VMs, Apps, Functions) |
| Leak risk | High — secret can leak in logs/repos | None — there's no secret to leak |
| When to use SP | GitHub Actions, Terraform, apps outside Azure | If the resource lives in Azure → always prefer MI |
Workload Identity Federation lets external workloads (GitHub Actions, GitLab CI, Kubernetes, Terraform Cloud) obtain Entra ID tokens without needing to store Client Secrets. It uses the OIDC standard.
How it works — GitHub Actions example
Advantages vs Client Secret
✓ Zero secrets stored in GitHub, GitLab, Terraform Cloud
✓ No secret rotation to manage
✓ If the repository becomes public, there's no secret to steal
✓ Each pipeline/branch can have its own granular identity
✓ The token has a temporary scope — it expires after each job
Supported providers
In AKS, the modern approach is Workload Identity (formerly called AAD Pod Identity). It lets individual pods have their own identity in Entra ID, without sharing credentials with other pods on the same node.
Architecture
Node-level MI (old method): The AKS node's VM has a Managed Identity. ALL pods on that node share the same identity. If a pod is compromised, it has access to the same resources as every other pod.
Workload Identity (recommended method):
• Each pod uses an annotated Kubernetes Service Account
• The Service Account is federated with a User-assigned MI or App Registration in Entra ID
• Only that pod obtains the token for that specific identity
• Principle of least privilege at the pod level
Basic configuration
Pod Identity v1/v2 (deprecated) vs Workload Identity
The AAD Pod Identity addon (v1 and v2) is deprecated. Microsoft recommends migrating to Workload Identity, which uses the OIDC standard. The main difference: Workload Identity doesn't require additional CRDs or daemonsets — it uses the native OIDC federation mechanism.
Did you get this topic?
Test what you just learned
What is the main advantage of using a Managed Identity for a VM to access Azure Key Vault?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.