In a cloud platform's access model, what is a principal, and how do human, group and workload principals differ?

## What the platform authenticates before it authorises Every access decision a cloud platform makes has two halves. First it establishes **who is calling** — it authenticates the request and resolves it to a stable identity it issued, called the **principal**. Only then does it ask **what that principal may do**. Everything downstream hangs off the principal: the grants that are looked up, the denial message, and the line written into the audit trail of management API calls. The principal is not a person's name, a machine's address, or the team that owns the workload. It is an identifier inside the platform's own namespace. That matters because grants are written against that identifier, so two things that a human would call "the reconciliation job" — your own login when you run it by hand, and the scheduled job when it runs at night — are two different principals with two different sets of permissions. ## The three kinds you will actually name in a grant - **Human principal.** A person's login. In a mature estate these are not created locally on the platform at all; they are federated from the company directory, so a leaver disappears from the platform when HR removes them rather than when someone remembers. The principal is still a single named identity as far as the access model is concerned. - **Group.** A named container of human principals. A group is an administrative convenience: you attach grants to the group once and membership decides who gets them, so you change one membership list instead of a dozen permission documents. It is **not** a caller — it holds no credential and cannot authenticate. - **Workload principal.** The identity a running thing is: a service, a batch job, a scheduled task, a pipeline. It exists so that software has a name of its own instead of borrowing a person's. It is authenticated by a credential the platform issues to the workload rather than by a password someone types. | Kind | Can authenticate a call? | Can hold grants? | Name that appears in the audit trail | |---|---|---|---| | Human principal | Yes | Yes | The person's identity | | Group | No | Yes | Never the group — always the member who called | | Workload principal | Yes | Yes | The workload's own identity | ## Why the group row is the one that trips people Because a group holds grants, engineers start speaking about it as though it acted. It does not. When an engineer in the `platform-oncall` group deletes something, the audit record names **her**, not the group, and an investigator who searches for the group name finds nothing. The group only explains *why* she was allowed. The same asymmetry appears when a grant is attached to the resource being called rather than to the caller. Such a grant has to name the principal it applies to, and on some platforms a group is refused there outright, precisely because a group is not something that can turn up as a caller — you must name a concrete identity instead. Designs differ on this point, so the safe habit is to think of a group as a way of distributing grants to humans, not as a participant in a call. ## Why a workload gets a principal of its own Giving the nightly batch its own identity rather than letting it reuse an engineer's login buys three separate things: 1. **Attribution.** The audit trail says the job did it, not that a person who was asleep did it. 2. **Independence.** The job's access survives that engineer leaving, and the engineer leaving does not silently take production with them. 3. **A different permission set.** The job needs a narrow set of actions that is nothing like what its author needs interactively, and separate principals are the only way to express that. This is also the reason the most common cross-team failure exists at all: a write that works when you run it from your own session fails when the job runs it, because those are two principals and only one of them was granted anything. ## What an interviewer is checking They want to hear that you distinguish *who is calling* from *what is permitted*, that you know software gets an identity of its own, and that you do not describe a group as something that calls. It is a first-screen question, and the usual failure is vagueness: a candidate who says "the user" for every actor has not yet had to debug a permission problem where the actor was the surprise.