9.3 Service Principals Fundamentals

Service principals on the SC-300 map

When a workload cannot use a managed identity—or when you are modeling a multi-tenant application, CI/CD pipeline, or daemon that needs Graph/application permissions—you work with service principals. Domain 3 expects you to know what they are, how they relate to app registrations and enterprise applications, how they authenticate, and how to keep them secure.

This section is fundamentals. The next chapter of this guide deepens enterprise applications and app registrations (permissions, consent, app roles). Here, build a precise mental model and the security habits that keep workload identities from becoming silent Tier-0 risks.

/practice/azure-sc-300Practice questions with detailed explanations

Application object versus service principal

Microsoft Entra uses a two-layer application model:

When you register an app in App registrations, Entra creates the application object in your tenant and usually a service principal in the same tenant. When a multi-tenant app is consented into a customer tenant, that customer gets their own service principal (enterprise app) without owning the app registration.

Managed identities are a special case: Azure creates and manages a service principal for you without you building a full customer-facing app registration experience.

Exam phrasing tips:

• “Grant the app access in this tenant” → think service principal / enterprise application assignments and permissions.
• “Define redirect URIs, expose an API, configure platform auth” → app registration.
• “Who signed in non-interactively at 02:00?” → service principal sign-in logs.

Enterprise applications and the SP you administer

In the Microsoft Entra admin center, Enterprise applications is where identity admins commonly:

• Find the service principal for a SaaS app or custom app.
• Assign users and groups (for apps that use user assignment required).
• Configure SSO properties for gallery/SAML apps (deeper next chapter).
• Review permissions granted (delegated and application).
• Set owners for operational accountability.
• Disable sign-in for an app instance in the tenant when needed.

For workload scenarios (daemon, pipeline), you often care less about user SSO and more about:

1. Credentials on the app registration (secret, cert, federated credential).
2. Application permissions (app roles on Graph or your API) versus delegated permissions.
3. Azure RBAC assignments to the service principal on subscriptions and resources.
4. Owners and access reviews of those privileged machine identities.

Credentials: secrets, certificates, federation

Service principals authenticate with credentials configured on the application object (and presented by the instance):

Why certificates beat secrets in exam answers: secrets are easy to paste into repos, pipelines, and tickets; certificates bind to key material that can live in Key Vault or a secure agent store with clearer rotation. Federation goes further by eliminating a stored Azure credential in GitHub secrets for deployment identities.

Operational rules:

• Track expiry; expired credentials cause sudden production outages.
• Prefer two certificates during rotation (overlap) so you never hard-cut.
• Restrict who can add credentials (app owners, Application Administrator, Cloud Application Administrator—understand privileged roles from Domain 1).
• Never embed secrets in mobile apps or public SPA code; public clients use different auth patterns (user-interactive, PKCE)—daemons are confidential clients.

Ownership and lifecycle

Treat service principals as non-human identities with a full lifecycle:

1. Create — app registration + SP, or consent to a multi-tenant app, or Azure creates MI SP.
2. Configure — permissions, roles, credentials, owners.
3. Authorize — admin consent for application permissions; Azure RBAC for Azure resources; app role assignments.
4. Operate — rotate credentials, monitor sign-ins, respond to Identity Protection risky workload signals where licensed/features apply.
5. Review — access reviews for highly privileged SPs; owner recertification.
6. Retire — remove credentials, delete role assignments, disable enterprise app sign-in, delete app registration when appropriate.

Owners on app registrations and enterprise applications create accountability. An app with no owner and a client secret that never expires is a classic audit finding.

Relationship to app registrations (preview of next chapter)

You do not need full app-registration mastery yet, but you must not confuse the layers:

• App registration — developer/identity-admin definition: Application (client) ID, directory (tenant) ID, platforms, certificates & secrets, API permissions list, expose an API, app roles, token configuration, optional claims.
• Service principal — the running instance in a tenant that actually receives consent and uses assigned access.
• Enterprise application blade — admin-centric view of that SP plus SSO and assignment features for many SaaS patterns.

Daemon pattern at SC-300 level:

1. Register application (public client false—confidential client).
2. Create certificate or federated credential (or short-lived secret if forced).
3. Add application permissions (for example Mail.Read application—if truly required—or better, narrower custom API roles).
4. Grant admin consent in the tenant.
5. Run client credentials flow from the secure host.
6. Call the API with the access token.

User-delegated patterns use authorization code flow and delegated permissions—different from pure workload daemons. Conditional Access can still apply to workload identities in modern “secure workload identities” designs; know that identity protection for workload identities is an evolving control area (linked from Domain 2 risky workloads topics).

Workload identity security basics

Secure workload identities with the same Zero Trust instincts you use for privileged users—verify explicitly, least privilege, assume breach:

Risky workload identities (Identity Protection capabilities, where available) extend risk detection beyond human users—pair that awareness with the Identity Protection chapter content for complete Domain 2/3 linkage.

Comparison recap: MI versus SP versus user

Exam traps

• Calling the app registration the thing you assign to a subscription IAM role—you assign the service principal object.
• Believing a client secret is “more secure” than a certificate because it is simpler.
• Using delegated permissions for a pure daemon with no user (will fail or be the wrong model).
• Leaving Application.ReadWrite.All-style permissions on a build agent SP “for convenience.”
• Forgetting that deleting an app registration impacts every credential and SP relationship for that app definition.

Closing Domain 3 entry skills

/study-guides/azure-sc-300Free exam prep with practice questions & AI tutor