L4. Managed Identities & Workload IDs
Course outlineLesson 4 of 18
How do Azure workloads authenticate without passwords? Managed identities eliminate secrets for Azure-to-Azure calls. Federated credentials extend this to GitHub Actions and Kubernetes. Know the difference for the exam.
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
| Type | Lifecycle | Use Case |
|---|---|---|
| System-assigned | Tied to the resource; deleted when resource is deleted | Single resource that needs identity |
| User-assigned | Independent resource; can be shared across multiple resources | Shared identity for multiple VMs or functions |
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.
- ✓System-assigned identity dies with the resource; user-assigned identity is independent and reusable
- ✓Token is fetched from IMDS endpoint 169.254.169.254: no secrets, no code changes required
- ✓Assign Azure RBAC roles to a managed identity exactly as you would to a user
- ✓Federated credentials = zero-secret auth for GitHub Actions, AKS pods, and other OIDC providers
- ✓Use a service principal (with secret/cert) only when the workload is outside Azure and OIDC federation is not available
1. What is the key operational difference between a system-assigned and user-assigned managed identity?
2. A GitHub Actions workflow needs to deploy to Azure without storing credentials as secrets. Which feature enables this?
3. Which statement about managed identities is correct?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured video courses, hands-on Azure labs, and timed practice exams to make it stick before exam day.