When a pipeline should use a service principal, a system-assigned or a user-assigned managed identity, and the trade-offs of each.
From Ultra Transcenders AZ-400 by Tony Rough (coming November 2026)
Automation that runs without a person needs an application identity. In Microsoft Entra ID the two options are service principals and managed identities, and the choice depends mainly on where the workload runs and who manages the credential.
A service principal is the local representation of an application registration in a Microsoft Entra tenant. It can authenticate with a federated identity credential, a certificate or a client secret; certificates and secrets are yours to store and rotate. A managed identity is a special type of service principal whose credentials Azure manages: the credentials aren’t even accessible to you, and managed identities cost nothing extra.
| Property | Service principal (app registration) | System-assigned managed identity | User-assigned managed identity |
|---|---|---|---|
| Created as | App registration plus service principal object | Part of an Azure resource (VM, App Service and so on) | Standalone Azure resource |
| Lifecycle | Independent; you delete it | Deleted automatically with the parent resource | Independent; must be deleted explicitly |
| Sharing | Can be used anywhere the credential is available | One resource only | Can be assigned to many resources |
| Credential | Federated credential, certificate or client secret | Managed by Azure | Managed by Azure |
| Best fit | Workloads outside Azure, or a portable identity | A workload contained in a single resource | Several resources needing the same permissions, or pre-authorisation before resources exist |
Microsoft recommends user-assigned managed identities as the preferred managed identity type for Microsoft services, because they’re provisioned independently of compute. For a service principal, prefer workload identity federation or a certificate over a client secret.
Service principals and managed identities can be Azure DevOps members that use short-lived Microsoft Entra tokens instead of PATs. Key rules:
Common trap: Copying the object ID from the App registrations blade when adding a service principal to Azure DevOps - Azure DevOps needs the service principal’s Object ID from Enterprise applications; the application object ID won’t be found.
This note is one section of Ultra Transcenders AZ-400: Designing and Implementing Microsoft DevOps Solutions, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in November 2026, in Kindle and paperback editions.
About the book · AZ-400 terms in the glossary · All AZ-400 study notes
How trunk-based development, GitHub Flow, feature branches, release branches and forks differ, and which fits a team's release cadence.
How the two CI/CD platforms compare on hosting, YAML, integrations and licensing, and when to combine them.
Which agent or runner option fits private network access, custom software, scale and maintenance requirements.
How each release pattern limits risk, what it costs and how traffic or users move to the new version.
How @Local, @Prerelease and @Release views work, how promotion moves packages through them and who consumes each view.
The four DORA metrics, where to get the data in Azure DevOps and GitHub, and which metrics suit planning, development, testing, security, delivery and operations.
How Git LFS pointer files and storage work in Azure Repos and GitHub, the limits on each platform and what pipelines need to fetch LFS content.