Why does a secret store treat an engineer signing in at a terminal differently from a service re-authenticating at restart?
answer
- who is standing there
- one path has nobody present
- presence decides what may be asked
- cheap expiry against an outage
- individual name against service name
basics
~20 sA person is present, can answer a prompt, and acts under a name the organisation already knows. A service authenticates with nobody watching, at any hour, so nothing in its path may wait for a human, and its name belongs to no individual.
solid answer
~50 sBoth arrive at the same door, but only one of them has somebody standing behind it. A person can be asked for something extra — a second factor, a confirmation — and can be given a short-lived credential, because redoing it costs them a few seconds. A service restarting at 3am after a node was replaced has nobody to prompt: any step that waits for a human response converts a routine restart into an outage at the worst possible hour. The difference then propagates. The person's identity has an owner and an ending — someone administers it and removes it when they leave. The workload's identity has neither unless somebody deliberately gives it one. Treating the two as "a login" is how people end up on machine identities and jobs end up on personal accounts.
go deeper
Recall the one fact everything else hangs off: a person is present and a restarting service is not. Be able to name two consequences without prompting.
Explain why presence decides what the path may ask for and what lifetime is affordable, and describe what goes wrong in each direction when the two callers are collapsed onto one identity.
Show you have operated it: name the failure a job on a personal login produces months later, and what the record looks like afterwards. Say what you would check first in an estate you inherited.
Frame it as a standard other teams follow: which caller classes exist at all in your estate, who owns each one, and what you are willing to pay in convenience to keep the two paths from merging.
## Two callers at the same door A secret store has one job at the door: decide whether the caller is who it claims to be, before any value is released. Two very different kinds of caller arrive there. - A **person** — an engineer at a terminal, awake, able to be prompted, able to type, holding a name that already exists in the organisation's system of record for people. - A **workload** — a service, a nightly reconciliation job, a worker coming back after its node was replaced — running with nobody present and nothing to type. The store can be built to accept both. What it cannot do is pretend they are the same caller, because everything downstream of the check — how long the access lasts, whose name is on the record, and what eventually ends it — follows from which one it was. ## What presence buys the human path Because somebody is standing there, the path may ask things of them: 1. **An interactive step is possible.** A second factor, a confirmation, a re-prompt — each one costs the person seconds and buys real assurance that the credential is not being used by somebody who merely copied it. 2. **A short lifetime is affordable.** This is the point most candidates miss: a short-lived credential is cheap for a person precisely because redoing it is cheap. Expiry is an inconvenience, not an incident. 3. **The identity already has a lifecycle.** Somebody creates the account when the person joins and removes it when they leave, and that routine exists whether or not the secret store was thought about. 4. **The record names an individual.** When a reviewer later asks who could have read a value, there is a person to name. ## What unattendedness forces on the workload path Remove the human and each of those inverts: - **No step may wait for a response.** Anything that needs a human to act turns a restart into an outage, and it will be the restart nobody planned. - **The path must work again, unchanged, on the next restart** — and the one after that, indefinitely, without anyone touching it. - **Whatever it presents must be obtainable without a person.** How that first credential comes to exist is a hard problem in its own right; the point here is only that the answer cannot involve somebody typing. - **The name on the record is a service.** A service does not have a manager, does not leave, and does not answer questions. ## The comparison, compressed | | Person at a terminal | Workload restarting | |---|---|---| | Who is present | someone who can be prompted | nobody | | When it happens | on demand, during a working session | at any hour, on the machine's schedule | | Affordable lifetime | minutes to a shift; redoing it is cheap | must succeed on every restart, forever | | Name on the record | an individual who can be found | a service, which no one person answers for | | What ends it | the person leaves and an existing routine removes them | nothing, unless somebody owns the identity | | Cost of a failed check | one person retries | the workload does not come up | ## Collapsing the two, in both directions Teams collapse the distinction for good short-term reasons, and it fails in a shape you can predict: - **A job running on an engineer's personal login.** It works beautifully until that person's account changes, is removed, or has its credential replaced — then a batch job fails for a reason nobody connects to a leaver form. Worse, every action the job takes is recorded against somebody who was asleep. - **A person authenticating as the workload.** The record then names the service, and the person quietly inherits everything the service may reach. That is a mirror-image failure, and it deserves its own treatment. - **One account shared by several people.** Neither a personal identity nor a machine one: it authenticates correctly and attributes to nobody. ## What a strong answer says It does not say "machines are less trusted than people" — a workload identity can be verified at least as strongly as a person's, and often more consistently. The real difference is **presence**, and the three things presence decides: whether the path may ask for anything interactive, whether a short lifetime is cheap or expensive, and whether there is a human name on the other end of the record. Everything else — approvals, ownership, what happens at departure — is downstream of those three.
- A nightly reconciliation job authenticates with an engineer's personal login. What breaks first?The job, the next time that person's account is touched — a credential replacement, a role change, or their departure. None of those are done by someone who knows a batch job depends on them. A second, quieter failure arrives earlier: every read the job performs is recorded against a person who did nothing, so the record stops meaning what it appears to mean.
- Does the store itself need to know which class a caller belongs to?It needs to distinguish them in practice, because the two paths differ in what may be asked and in what lifetime is affordable. Whether that appears as two separate mechanisms or one mechanism with different settings is a design choice. What is not a choice is the record: it must make clear whether a person or a process was calling, since nothing later can reconstruct it.
- Is a workload identity inherently weaker than a person's?No. A workload's identity can be verified as strongly as a person's, and it is often more consistent, because a machine presents the same proof every time and never reuses a password from elsewhere. What it lacks is not strength but presence and ownership: nobody is there to be asked for more, and nobody automatically answers for it.
A night-shift door that a guard opens by checking a face works fine until the shift with no guard on it; the lock that covers that shift cannot be one that asks a question.
saying these in an interview costs you the question
- Says both are just logins, so one path can serve both.
- Claims the service can be prompted for something extra at restart.
- Assumes a short-lived credential is equally cheap for both callers.
- Thinks a job on a personal account is fine if the account is scoped.
- Believes machine identities are inherently less trustworthy than people.