4.1.1. Choosing the Right Workload Identity
💡 First Principle: Match the identity to where the workload runs and what it must reach. Ask two questions — does it run on an Azure resource? and must a human never touch its credential? — and the decision usually makes itself.
| Managed identity | Service principal | User account as service account | |
|---|---|---|---|
| Runs where | Azure resources only | Anywhere | Anywhere (wrongly) |
| Credential you manage | None | Secret or certificate (or federated credential) | Password |
| CA / MFA applicability | Workload identity policies (premium) | Workload identity policies | User policies break automation (MFA prompts) |
| Expiry/rotation burden | None | Yours (or none with federation) | Password policies fight you |
| Exam verdict | Default for Azure workloads | Default for everything else | Anti-pattern; migrate away |
Amplifications the exam draws on: group managed service accounts (gMSA) remain the on-premises Windows service answer (AD-managed password rotation) — they appear in stems about on-prem agents (e.g., Cloud Sync agents run under a gMSA). Workload identity federation deserves special attention as the modern answer for external platforms: a GitHub Actions pipeline or AWS/GCP workload exchanges its own platform-issued token for an Entra token against a service principal configured to trust that issuer — zero stored secrets for cross-cloud automation ("configure federated credentials" is the tell). And user accounts as service accounts fail two ways at once: they're subject to human policies (MFA, password expiry break the job at midnight) and they're exempt from human accountability (who is svc-report7?).
Licensing note: securing workload identities with Conditional Access and ID Protection risk (2.3.3's risky workload identities) requires Microsoft Entra Workload ID Premium — stems asking to "apply Conditional Access to service principals" are flagging that add-on.
⚠️ Exam Trap: "A script running on an on-premises server must call Microsoft Graph without stored secrets" cannot be a managed identity (not Azure) — the modern answer is a service principal with workload identity federation or certificate credential, never a user account with "MFA excluded."
Reflection Question: Rank the four identity options for a nightly Azure Function that reads a storage account — and explain what specifically becomes impossible to leak at each step up your ranking.
