Service principal (app identity)
What it is
A service principal is the identity Entra ID gives to an application or service (as opposed to a human user). It’s “who the app is” when it authenticates to Azure resources. A managed identity is an automatically managed service principal.
Why it exists
Apps and automation need to authenticate and be authorized without human credentials. A service principal carries its own identity and secret/certificate, so CI/CD (Pipelines/github-actions), scripts, and services can access resources via RBAC.
Key ideas
- Forms — (1) Application registration + its service principal, (2) managed identity (system-assigned or user-assigned) — the administrative-friendly kind, (3) a legacy service principal.
- Credentials — client secret, certificate, or federated credentials.
- Managed identities — Azure automatically creates/rotates credentials; ideal for VMs, Functions, and App Service to reach Key Vault/Azure SQL without storing secrets.
- Scoped via RBAC assignments just like users.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity-platform/app-objects-and-service-principals
Exam notes
- Managed identities are the recommended way to give Azure workloads access to Azure resources.
- System-assigned (tied to one resource) vs user-assigned (shared across resources) — know the difference.
- Service principals need the right role (e.g. Contributor, or a custom role) — least privilege.
Related
entraid · rbac · user-account · azure-pipelines
📘 Source: Microsoft Learn — Service Principal