Four on-call engineers share one secret-store login whose password sits in a team document — what has the estate lost?
answer
- the check passed, so what failed
- a name with four people behind it
- who replaces it, and when
- rights become a union
- no departure ends it
basics
~20 sAttribution and ownership. The store verifies the credential correctly every time, so authentication is not what failed; what is gone is any way to tie a read to one of the four, any single person responsible for replacing the value, and any departure that ends it.
solid answer
~40 sNothing at the door went wrong: the store checked a valid credential and answered. The loss is everything the identity was supposed to carry. No read can be attributed to an individual, so the record answers "the on-call team" to every question. Nobody owns the value, so replacing it is a coordination exercise across four calendars that keeps being deferred. Its rights accumulate as the union of what all four ever needed, because narrowing them would break somebody. And it has no ending: when one of the four leaves, their personal account is removed by an existing routine and the shared credential keeps working, with a copy still in their notes. A shared account is neither a person's identity nor a workload's — it has the weaknesses of both.
go deeper
Recall that a credential several people know cannot tell you which of them called. Notice that the store still answered correctly — nothing was broken at the check itself.
Explain the four losses and keep them distinct: attribution, ownership, the union of rights, and the missing ending at a departure. Be able to say why a stronger password changes none of them.
Show you have replaced one. Describe the coordination problem that keeps deferring replacement, the split between the people and the script that were both using it, and what you do about copies already held.
Decide what the organisation does when the individual path is genuinely too slow for an incident. Own the trade-off rather than issuing a rule the on-call rota will route around at 2am.
## What actually happened at the door Start by being precise about which step failed, because a weak answer blames the wrong one. The store received a credential, verified it, and released a value. That is authentication working exactly as designed. A store cannot see how many people know a password, and it is not built to. So the defect is not in the check; it is that the identity behind the check no longer corresponds to anybody. That distinction matters in an interview. Saying "the store should have rejected it" is wrong. Saying "the store answered correctly and the answer is now meaningless" is the point. ## The four things a shared account cannot do - **It cannot attribute.** Every read is by "the account", and four people could each have made it. Nothing later recovers which one, because the information was never captured — it did not exist at the moment of the call. - **It cannot be owned.** An identity with four users has no single person whose job it is to look after it. Ownership diffuses to nobody, which is different from being owned badly. - **It cannot be narrowed.** Its rights become the union of everything any of the four ever needed. Removing one of those rights breaks somebody unpredictably, so nobody removes any, and the account drifts toward being the most privileged identity in the estate. - **It cannot end.** A personal identity ends when its person leaves, through a routine that already exists. A shared one survives every departure, and each departure leaves another copy of its value outside the organisation. ## Personal identity against shared account | | One identity per person | One account shared by four | |---|---|---| | Who the record names | the individual who called | an account nobody answers for | | Who replaces the credential | the owner, alone, in minutes | four people, coordinated, eventually | | What its rights are | what that person needs | the union of what all four ever needed | | Effect of a departure | the existing leaver routine ends it | nothing changes; one more copy is out | | Where the value lives | in the person's own credential path | in a team document, and three sets of notes | ## Why it survives, despite everyone knowing better It is worth being honest about this, because interviewers are testing whether you understand the pressure rather than whether you can recite the rule: 1. **It works.** At 2am, under pressure, one known credential that always works beats four that might not. 2. **It was created for a real gap.** Usually the individual paths to that value did not exist, or granting them took a week, so somebody made one account and told the team. 3. **Replacement needs a synchronised change.** Every holder must be updated at roughly the same moment, and there is no obvious moment. So it is deferred, and the value ages for years. 4. **Nobody owns removing it.** The person who created it moved teams. The current holders inherited it and treat it as infrastructure. ## What replaces it The fix is not "rotate the shared password more often" — that improves nothing about attribution and makes the coordination problem more frequent. The direction is: - **Give every person their own identity at the store**, and grant those identities the access the shared account had. The read is then attributable by construction, and each person's access ends with them. - **If a process was using it too, split that out** into a workload identity of its own. A shared account is very often a person's account and a script's account fused together, and neither half can be fixed while they are joined. - **Where the shared credential must exist for a while**, give it a named owner and a fixed date to disappear, and record who holds it now — so the union of rights stops growing and the departure question has an answer. - **Treat the last copy problem explicitly.** Until the credential is replaced, everyone who ever held it still holds it. Replacement is the only thing that ends that, and it is a separate action from removing someone's own account. ## The trap in the question The phrase "the store authenticated every read correctly" is doing real work. A candidate who hears "shared password" and immediately talks about password strength, or about the document being the wrong place to keep it, has answered a different question. The document is bad, and a stronger password would not help: the loss is structural, and it would be identical if the four shared a strong credential kept somewhere respectable.
- Would a stronger shared credential, kept somewhere respectable, fix this?No. Strength defends against guessing, and the store already accepts the credential from all four. Every loss in the original arrangement — no attribution, no owner, a union of rights, no ending at a departure — is identical with a long random value in a proper place. The number of people behind one name is the defect, not the quality of the value or its resting place.
- The team says individual identities are too slow to grant during an incident. How do you answer?Take it seriously: that is usually true and is why the shared account exists. The fix is to make the individual path fast enough to be the natural choice at 2am, not to argue that the slow path is morally better. If it cannot be fast, say so and give the shared credential an owner and an end date, rather than pretending it is temporary.
saying these in an interview costs you the question
- Says the store should have rejected a password four people know.
- Thinks a longer shared password fixes the arrangement.
- Claims past reads can be re-attributed to individuals afterwards.
- Assumes removing a leaver's own account also ends the shared one.
- Treats the shared account as temporary years after it was made.