Service principals and managed identities — quick notes
Service principals vs managed identities — quick notes
| Need | Choose |
|---|---|
| Eligible Azure-hosted workload without user sign-in, web-API, or multitenant needs | Managed identity — no credential to store |
| External workload with an OIDC identity provider | Federate to a user-assigned managed identity or app registration |
| Identity should die with the resource | System-assigned |
| Many resources, same role assignments | User-assigned |
- System-assigned: created and deleted with the resource; one resource only.
- User-assigned: standalone, shared across resources, survives deletion.
- RBAC role-assignment records can outlive either identity and need separate cleanup.
Rule: prefer managed identity when the workload and app capabilities are eligible. For external federation, choose either supported trust target and avoid a stored Entra secret.
Sources: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-400 · https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview · https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/managed-identity-best-practice-recommendations · https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals · https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration · https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation