A contractor who knew a shared admin credential rolls off — why does disabling their accounts not end their access?
answer
- two things to take away, not one
- account removal versus value withdrawal
- the accepting system never heard of the store
- a read copy cannot be recalled
- replace, move holders, then refuse the old
basics
~20 sDisabling an account closes one path to the value; it does not withdraw the value. A shared credential the person already read is a copy nobody can recall, so it must be replaced and the old value refused.
solid answer
~50 sTwo different things can be taken away when someone leaves, and teams usually do only the first. Removing their account in the secret store, or the grant that let them read, stops them fetching the value *again*. It does nothing about the value they already fetched, because the system that accepts that credential has never heard of the store and will keep honouring it. A shared static value lives entirely in that second category once a human has read it: there is no copy to delete, only notes, a saved file, a terminal history or a memory. So departure is a replacement trigger — mint a new value, move every holder to it, and then make the accepting system refuse the old one. Replacement alone is not enough; the withdrawal is what ends the contractor's access.
go deeper
Recall the split: removing someone's account stops future reads, while the value they already read still works. A shared password must be changed when a holder leaves.
Explain where withdrawal actually happens — at the system that accepts the credential, not in the store — and why deleting the stored value does not reach it.
Show how you scope it: which values the person could read, what read records prove and do not prove, and what order you replace and withdraw in without an outage.
Argue the structural fix: shared static values make every departure an estate-wide event, so the question is what it costs to move to per-consumer credentials before the next one.
## Two withdrawals, and teams do only one When a person with access leaves, there are two distinct things you can take away. - **The path to the value.** Their account in the secret store, their entry in whatever directory the store trusts, their membership of the group a read rule names. Removing it stops them *fetching the value again*. - **The value itself.** The credential they already fetched and can still present to the system that accepts it — a database account, an administrative interface, a partner endpoint. Nothing about the account removal reaches that system. It was never told who was allowed to hold the value, only what the value is. Offboarding checklists are almost always written against the first list, because it is the list a joiner/leaver process can see. The second is the one that decides whether the contractor can still get in on Monday. ## Why a shared static value makes departure a trigger A **static credential** is typed or generated once and handed to whoever needs it; a **generated credential** is minted by the store per consumer at the moment it is needed. The distinction decides what a departure costs you: | What the person held | What removing their access achieves | What still has to happen | |---|---|---| | A shared static value they read | Stops further reads from the store | Replace the value and refuse the old one at the accepting system | | Their own credential the store generated for them | Revokes that one credential | Nothing else moves; other consumers keep their own values | | A value they copied into a personal file or notes | Nothing at all | Same replacement, and the copy is why you cannot skip it | The defining property is simple and unfixable: **a human who read a value holds a copy that no system can take back**. There is no record to delete, no session to kill, no device to wipe. Every other containment move in this area depends on reaching the thing that holds the copy. Here nothing does. ## Rotation and revocation point in opposite directions Say which one you mean, because they are not the same action: - **Replacement** puts a *new* value in place so consumers have something to move to. - **Withdrawal** makes the *old* value stop authenticating at the system that accepts it. A replacement that never withdraws the old value has changed nothing for the leaver — both values now work, and theirs is one of them. Equally, deleting the value from the store is neither: the store stops serving it, while the accepting system carries on honouring the copy already in circulation. **Deleting is not withdrawing.** ## Scoping it without guessing 1. **List what they could read** — the rules and group memberships that granted them anything, not just what you remember them using. 2. **Narrow with read records** where the store keeps them, remembering that those prove only the reads that went *through* the store; a value handed over in a chat message leaves no entry. 3. **Rank by blast radius** — how far one value reaches decides what is replaced today and what can wait for the next change window. 4. **Carry it out in order** — new value in place, every holder moved across, then the old value refused. 5. **Record the declaration and the completion**, so the question "was this actually done?" has an answer later. ## Where designs differ Stores differ in what they can do for you here. Some can mint a fresh downstream account per consumer, which turns a departure into a single revocation with no coordination. Others only hold the value you gave them, in which case a departure is a full replacement across every holder. Some keep read records rich enough to enumerate what one identity touched; others keep very little. Do not assume the estate you are describing has the first of each — say what the mechanism requires and then what you would check. ## What an interviewer is listening for The weak answer stops at "we disable their accounts and revoke their access". The good answer separates the path from the copy in one sentence, names the accepting system as the place withdrawal happens, and says out loud that a shared value is what makes this expensive — which is also the argument for issuing per-consumer credentials before the next person leaves.
- The contractor insists they never wrote the value down. Does that change what you do?No. The decision cannot rest on an assertion nobody can check, and memory is a copy like any other. What their statement is worth is scope: it helps establish which values they saw and when, which sets how much has to move. Replace anyway, and prefer per-consumer generated credentials so the next departure is one revocation.
- How would you make the next departure cheaper rather than repeating this?Stop sharing one static value across many holders. Where the store can mint a credential per consumer, a leaver's own credential is revoked and nothing else moves. Where it cannot, at least keep an inventory of who holds what, so scoping the trigger is a lookup and not an archaeology exercise.
- The value is only readable by an on-call group the contractor was in. Is that enough scoping?It is the starting list, not the answer. Group membership tells you who could have read the value; read records tell you who did, for reads that went through the store. Neither covers a copy passed hand to hand, which is why the default for a shared value is to replace it.
A departing key-holder can hand back the office key, and that ends what the key opens. They cannot hand back the door code they memorised — the only way to close that is a new code on the door.
saying these in an interview costs you the question
- Says disabling the account ends access to the credential
- Treats deleting the value from the store as a withdrawal
- Puts a new value in place and never refuses the old one
- Accepts a promise that the value was not kept
- Assumes read records capture copies passed outside the store
- Calls replacement and revocation the same action