Pinecrest Energy runs a Copilot Studio agent that generates nightly compliance reports by reading data from Azure Data Lake Storage Gen2 and writing results to a SharePoint document library. The agent runs on a schedule with no user interaction. A junior developer suggests authenticating the agent's Power Automate flows using a shared service account (a licensed user in Entra ID) with delegated OAuth tokens. The architect disagrees. Which is the most compelling reason to prefer a service principal over a user-delegated token in this scenario?
Select an answer to reveal the explanation.
Short Explanation
Linking a nightly compliance agent to a user account is like building a factory that stops when one person calls in sick. You want the app identity that isn't tied to a human lifecycle, so password resets, account disablement, or license removal don't break your unattended flow.
Full Explanation
For unattended, scheduled agents, the fundamental problem with user-delegated tokens is operational fragility tied to the human account lifecycle. If the shared service account's password is rotated, the stored OAuth refresh token is invalidated and the flow breaks immediately. If the account is disabled for any reason (compliance review, offboarding error, license cost savings), all dependent flows fail. If the Microsoft 365 license is removed, the account cannot authenticate. These are real-world incidents that occur regularly in enterprise environments.
The most compelling reason to prefer a service principal is that it is not tied to a human user account, so the agent continues to function if the service account password changes, the account is disabled, or the license is removed. Service principals exist as application identities in Entra ID, independent of any individual user's lifecycle. Their credentials (client secrets or certificates) are managed separately and their continuity is not affected by HR events.
The statement that service principals support multi-factor authentication, which shared service accounts do not, is wrong. Service principals themselves do not support multi-factor authentication — they authenticate using client secrets or certificates, not interactive login flows. In fact, shared service accounts can be configured with conditional access policies. Multi-factor authentication is not the distinguishing factor here.
The statement that service principals allow the agent to request broader permissions than a licensed user account is allowed to hold in Entra ID is wrong. Service principals do not inherently allow broader permissions than users. Both service principals and users are subject to the principle of least privilege and role-based access control assignment. A service principal has only the role-based access control roles and API permissions explicitly granted to it — it does not have elevated access by default.
The statement that delegated tokens expire every 60 seconds and are impractical for scheduled flows, while service principal tokens last indefinitely, is wrong. OAuth access tokens for both service principals and delegated flows typically expire in 60 minutes (not 60 seconds), and both use refresh tokens for renewal. Token expiry is not meaningfully different between the two approaches — Power Automate handles token refresh transparently in both cases.
Exam tip: The key distinction on the exam is operational stability vs. lifecycle risk. Unattended = service principal or managed identity. Interactive/on-behalf-of = user-delegated. Never use shared user accounts for unattended production workloads.