Managed Identities & Workload Identities: AZ-500 Guide

The Problem: Service Account Sprawl

Historically, applications needed service principal credentials (client ID plus secret) to authenticate to Azure services. Secrets expire, get leaked in code, and require manual rotation. Managed identities solve this for workloads running inside Azure.

System-Assigned vs User-Assigned

Exam tip: If a VM is deleted and it had a system-assigned identity, the identity is gone. A user-assigned identity survives and can be re-attached to a new resource.

How It Works

Azure automatically issues and rotates a certificate for the managed identity. The workload requests a token from the Instance Metadata Service (IMDS) endpoint at 169.254.169.254: no credentials in code, no secrets to manage.

The token is a standard OAuth 2.0 JWT bound to the resource's identity. You then assign Azure RBAC roles to the managed identity just like a user.

Federated Identity Credentials

Federated credentials extend the zero-secret model to workloads outside Azure: GitHub Actions, Kubernetes pods (AKS Workload Identity), and other OIDC providers. GitHub Actions example: A GitHub repo is configured as a trusted issuer. A GitHub Actions workflow requests an OIDC token from GitHub, presents it to Entra ID, and receives an Azure access token in return: no secrets in the repo.

Service Principals

A service principal is the local representation of an application in a tenant. Unlike managed identities, service principals require credential management (secrets or certificates). The exam tests when you must use a service principal: the answer is when the workload runs outside Azure and federated credentials are not supported.