Lesson256 words
Service principals and managed identities
Choose between service principals and managed identities
Both are Microsoft Entra identities an application can authenticate as. The difference is who manages the credential.
| Service principal (app registration) | Managed identity | |
|---|---|---|
| Credential | Secret or certificate you create, store and rotate | Managed by Azure — none for you to store |
| Works from | Anywhere | Only from a supported Azure resource |
| Lifecycle | Independent of any resource | Tied to the resource (system-assigned) or standalone (user-assigned) |
System-assigned versus user-assigned
| System-assigned | User-assigned | |
|---|---|---|
| Lifecycle | Created with the resource, deleted with it | Standalone; survives resource deletion |
| Sharing | One resource only | Shared across many resources |
| Use when | A single resource needs its own identity | Several resources need the same role assignments |
The exam framing is usually one of two shapes: "identity must be cleaned up automatically with the resource" → system-assigned; "ten VMs need identical access and I do not want ten sets of role assignments" → user-assigned.
The rule of thumb
Prefer a managed identity wherever the workload runs on an Azure resource that supports one, because there is no secret to leak, rotate or expire. Reach for a service principal when the caller is outside Azure — a GitHub Actions runner, an on-premises agent, a third-party service — and then prefer workload identity federation so even that has no stored secret.
Primary sources