Your organization wants to automate Power Platform Pipelines deployments using a service account that is not tied to any individual employee's identity, ensuring deployments continue even when team members leave. Which identity type should be used for the pipeline service account?

Service principals are Azure Active Directory identities designed for automated, non-human workloads. Unlike user accounts, service principals don't have personal email inboxes, don't require MFA prompts when using certificate-based or client secret authentication, don't leave the organization, and are managed independently of any individual's employment status.

For Power Platform Pipelines automation, you register an Azure AD app registration, which creates an associated service principal, generate a client secret or certificate, and grant the service principal appropriate Power Platform roles — typically the 'Deployment Pipeline Administrator' role or environment-specific Maker/Admin roles depending on the deployment scope.

Automated pipeline triggers from Azure DevOps, GitHub Actions, or Power Automate authenticate using the service principal's credentials to initiate deployments.

The shared mailbox account that multiple team members can access is an email tool, not an identity solution. Using a shared mailbox as an identity is a security anti-pattern: no individual accountability, shared credentials, no proper RBAC integration.

The guest user account from a third-party identity provider introduces cross-tenant complexity and dependency on the third party's identity infrastructure. It isn't appropriate for automated pipeline operations.

The pipeline system administrator's personal Microsoft account ties automation to a human account. When that person changes roles or leaves, the automation breaks and may require emergency remediation.

Exam principle: automated operations = service principal identity. This applies across all Microsoft automation scenarios, not just Power Platform.