Managed identities vs service principals
A service principal is the identity an application has inside a Microsoft Entra tenant; a managed identity is a special kind of service principal whose credentials Azure creates, holds and rotates for you. The decision rule for exams: if the code runs on an Azure resource that supports managed identities, use a managed identity; if it runs outside Azure and has to authenticate with no stored secret, use workload identity federation; only when neither is possible use a service principal with a certificate or secret.
Four questions that pick the identity
Work through these in order. The first “yes” is the answer.
| Question | If yes, use | Why |
|---|---|---|
| Does the code run on an Azure resource that can have a managed identity (VM, App Service, Function, AKS, Container Apps and similar)? | Managed identity | There is no secret to store, rotate or leak. Microsoft says the credentials are not even accessible to you. |
| Does the code run outside Azure (GitHub-hosted runner, on-premises Kubernetes, another cloud) and the external system can issue tokens? | Federated credential on an app registration or user-assigned managed identity | The external token is exchanged for an Entra token. Nothing secret is stored. |
| Does the code run outside Azure with no token issuer to trust? | Service principal with a certificate (or secret) | The workload must hold a credential, so you own rotation and expiry. |
| Does the app serve other tenants or need delegated user permissions? | App registration (and so a service principal in each tenant) | Multitenant apps and consent flows need an application object. |
Two sentences carry most of the weight. A managed identity works only for Azure resources (plus servers onboarded to Azure Arc, which get a system-assigned one), so it can never be the answer for a GitHub-hosted runner or a plain on-premises server. A service principal is not the “old” option: managed identities and app registrations both end up as service principals in the tenant.
How the objects relate
An app registration creates an application object in the app’s home tenant, a blueprint that holds redirect URIs, API permissions and credentials. A service principal is the instance of that app in one tenant; it is what receives role assignments and consent. Registering an app in the portal creates both. The Enterprise applications page lists service principals; App registrations lists application objects.
Managed identities are a separate kind of service principal. Microsoft documents three types: application, managed identity and legacy. A managed identity service principal has no application object behind it and cannot be edited directly. That is why a managed identity never has a client secret you could set.
There are two flavours of managed identity:
| Property | System-assigned | User-assigned |
|---|---|---|
| Created | Together with the Azure resource | As a standalone Azure resource |
| Lifecycle | Deleted automatically when the resource is deleted | Independent; must be deleted explicitly |
| Sharing | One resource only | Many resources |
| Role assignments in advance | Not possible (the identity does not exist before the resource) | Possible |
Microsoft’s best-practice guidance leans towards user-assigned identities in more scenarios, for example when many resources need the same access, or when resources are created and deleted so quickly that creating system-assigned identities can hit Entra rate limits. Exam wording still follows the classic split: “one resource, identity deleted with it” is system-assigned, “shared” or “must outlive the resource” is user-assigned.
Worked example
A team runs a web API on Azure App Service. It reads secrets from Key Vault, writes files to a storage account, and the same code runs in a staging slot and a production app.
- Enable a managed identity on the App Service. In Entra a service principal appears with the app’s name.
- Grant that identity a data role on the vault (for example Key Vault Secrets User) and on the storage account (Storage Blob Data Contributor). This is an Azure RBAC assignment, covered in Azure RBAC vs Entra roles.
- In code, use the Azure Identity library.
DefaultAzureCredentialtries the managed identity in Azure and falls back to the developer’s sign-in locally; for production Microsoft recommends a deterministic credential such asManagedIdentityCredential. No connection string with a key is needed.
Now the same team builds a GitHub Actions deployment. Hosted runners are not Azure resources, so a managed identity cannot be “on” the runner. The team creates a user-assigned managed identity (or an app registration), gives it Contributor on the target resource group, and adds a federated credential that trusts tokens from their GitHub repository and environment. The workflow logs in with OpenID Connect and gets a short-lived token. No secret exists in the repository. The protocol background is in SSO, SAML and OAuth explained.
Which exams test this
| Exam | How it appears | Covered on this site |
|---|---|---|
| SC-300 | Plan and implement workload identities: pick the right identity (managed identity, service principal, user account, managed service account), create managed identities and assign them to Azure resources, plus app registrations and enterprise applications | Workload identities |
| AZ-400 | Develop a security and compliance plan: choose between service principals and system- or user-assigned managed identities, and use secretless authentication (workload identity federation with OpenID Connect) in GitHub Actions and Azure Pipelines | Security and compliance |
| SC-500 | Manage identity, access, and governance: configure managed identities for Azure resources and identities for applications (enterprise applications and app registrations) | Identity, access and governance |
| SC-900 | Capabilities of Microsoft Entra: describe identity types, including workload identities; concept level only | Microsoft Entra explained |
| AI-103 | Plan and manage an Azure AI solution: secure AI systems with managed identity, keyless credentials and role policies | Plan and manage |
| AI-300 | Design and implement a GenAIOps infrastructure: identity and access for Foundry with managed identities and RBAC | GenAIOps infrastructure |
| DP-750 | Secure and govern Unity Catalog objects: authenticate data access with service principals and resource access with managed identities | Unity Catalog security |
| DP-800 | Secure, optimize, and deploy database solutions: secure model endpoints, including with a managed identity; a single objective | Secure, optimize and deploy |
| AZ-305 | Minor and indirect: design authentication and authorization solutions (recommend an authentication solution, authorize access to Azure resources, manage secrets); managed identities are not named in the outline | Identity, governance and monitoring |
| AI-200 | Minor and indirect: implement secure Azure solutions by retrieving secrets from Azure Key Vault; managed identities are not named, but they are the usual way the app authenticates to the vault | Secure, monitor, troubleshoot |
| AB-900 | Minor: core security features of Microsoft 365 include understanding app registrations and enterprise applications (the service principal side); managed identities are not named | Microsoft 365 core features |
How questions are built around it
The scenario states a constraint about secrets, and the options mix identities that differ in where they can run and who owns the credential. Constraint words:
- “No credentials stored” / “no secret rotation”: managed identity or federation, never a client secret.
- “Runs outside Azure”, “GitHub-hosted runner”, “on-premises”: a managed identity is impossible, so federation (or a certificate-based service principal).
- “Shared by several resources”, “must survive deletion of the VM”: user-assigned.
- “Created and deleted with the resource”: system-assigned.
- “Multitenant”, “admin consent”, “redirect URI”: app registration.
Common wrong answers: a system-assigned identity for five VMs (it cannot be shared), a client secret in Key Vault (still a secret to rotate), a user account with a password used as a service account, and a managed identity on a runner outside Azure. A subtler trap: Conditional Access policies scoped to users do not apply to service principals. Policies for workload identities (a Workload ID Premium feature) cover single-tenant service principals registered in the tenant, but not managed identities, and Microsoft notes that managed identities are not in scope for ID Protection risk detection either, a point picked up in Entra ID Protection explained.
Practice questions
Question 1. Six virtual machines in different resource groups must read blobs from one storage account. Administrators want one set of role assignments to maintain, and the identity must remain if any single VM is deleted. What should you use?
- A. Six system-assigned managed identities
- B. One user-assigned managed identity attached to all six VMs
- C. A service principal with a client secret stored in each VM
- D. A guest user account with a long password
Show answer
Answer: B
A user-assigned managed identity is a standalone resource that can be attached to several VMs, keeps its role assignments when a VM is deleted, and avoids secrets. Six system-assigned identities would mean six separate role assignments and each disappears with its VM. A service principal with a client secret introduces a credential to store and rotate. A guest user account is meant for external people, not workloads.
Question 2. A Jenkins server in an on-premises datacenter, not connected to Azure Arc, must deploy to Azure. The security policy forbids long-lived secrets, and the Jenkins platform can issue OpenID Connect tokens. What should you configure?
- A. A system-assigned managed identity on the Jenkins server
- B. An app registration with a client secret that expires in 24 months
- C. An app registration with a federated credential that trusts the Jenkins token issuer
- D. An app registration with a password uploaded to the Jenkins credential store
Show answer
Answer: C
Workload identity federation lets an app registration or user-assigned managed identity trust tokens from an external identity provider, so Jenkins exchanges its token for a short-lived Entra token with no stored secret. A managed identity cannot be enabled on a server outside Azure that is not Arc-enabled, so a system-assigned identity is not possible. A client secret and an uploaded password are both stored credentials, which the policy forbids.
Go deeper
- What are managed identities for Azure resources? (Microsoft Learn)
- Application and service principal objects in Microsoft Entra ID (Microsoft Learn)
- Workload identity federation (Microsoft Learn)
- Related guides: Conditional Access explained for policies on workload identities, CI/CD explained for pipeline context, and how to study for certification exams.