A reporting service holds its own pasted copy of the shared credential in its configuration — what does that break on replacement day?
answer
- no read, no record, no reach
- the store is not a distributor
- breaks at withdrawal, not at write
- the failure lands late
- re-pasting restores the blind spot
basics
~20 sThree things: the census cannot see it, because it never reads the store; writing a new value does not reach it; and it keeps working until the old value stops being accepted downstream, then fails late.
solid answer
~50 sA copy held outside the store is invisible, unreachable and delayed. Invisible, because a census built from read records is built from reads, and this consumer performs none. Unreachable, because a replacement writes the new value where the store keeps it, and nothing propagates to a value someone pasted elsewhere. Delayed, because nothing breaks at the moment of the change — the copy works until the **old value is withdrawn at the system that accepts it**, and then it fails on its next call, which for a nightly job can be hours later and for a periodic one weeks later. That delay is what makes it expensive: the failure lands outside the change window and is rarely attributed to the replacement. Fixing it by pasting in the new value restores service and leaves it invisible for the next round.
go deeper
Remember that a value copied out of the store lives on its own: changing what the store holds does not change the copy.
Explain the three consequences — invisible to a census, unreachable by the write, and failing only when the old value is withdrawn downstream — and why the last one is delayed.
Plan for it: ask owners the question the records cannot answer, sequence the withdrawal so a late failure is survivable, and insist the durable fix is conversion rather than a fresh paste.
Treat it as a standard question rather than an incident: decide what your estate requires of a consumer before it may hold a credential at all, and what you do about the ones that cannot comply.
## The shape of the problem Somewhere in most estates there is a consumer that does not participate in the store at all. Somebody, once, copied the value out and put it where their service reads its settings. From the store's point of view that consumer does not exist: it has no grant, it makes no reads, and it contributes nothing to any census. From the credential's point of view it is a fully-fledged holder, authenticating downstream exactly like everything else. On the day of a replacement this produces three separate failures, and they land at three different moments. ## Failure one: it is invisible to the plan A consumer census is built from evidence of reads. This one generates none, so no window is long enough and no grouping is clever enough to surface it. It is found by one of two routes: an owner remembers, or it breaks. Interviewers care about this because it is the reason a census is never treated as complete — the population that reads nothing is exactly the population the records cannot describe. ## Failure two: the new value never reaches it A replacement normally means: mint a new value, write it to the store, let consumers pick it up. That sequence assumes the consumer fetches. This one does not. Writing the new value changes nothing for it whatsoever — not on the next read, because there is no next read; not on restart, because it will re-read the same pasted copy it has always had. This is worth stating precisely, because it is the step people skip in their heads: **the store is not a distribution mechanism for values that were copied out of it.** It serves what it is asked for. ## Failure three: the breakage is delayed and misattributed Here is the sequence, with the moment each thing happens: 1. The new value is minted and written to the store — this consumer is unaffected. 2. Known consumers take the new value — this consumer is unaffected. 3. The **old value is withdrawn at the downstream system** — this consumer is now broken, but not yet failing. 4. The consumer makes its next call — *now* it fails. Step 4 is the part that hurts. For a service handling continuous traffic, step 3 and step 4 are seconds apart and the change owner sees it. For a nightly job, it is hours. For a periodic one, it can be weeks, long after the change record is closed, and the on-call engineer who picks it up has no reason to connect an authentication failure to a change that finished successfully a fortnight ago. ## The direction people get backwards **Deleting is not withdrawing.** Removing the value from the store does nothing to this copy at all — the copy keeps authenticating, because the system that accepts the credential does not consult the store before answering. Withdrawal is an action against that downstream system, and it is the only step that reaches an out-of-store copy. Similarly, removing a grant is irrelevant here: there is no grant. | Action taken | Effect on a store-reading consumer | Effect on a pasted copy | |---|---|---| | Write a new value to the store | Picked up on next read or restart | None | | Delete the value from the store | Next read fails | None | | Remove the identity's read right | Next read is refused | None | | Withdraw the old value downstream | Already moved, unaffected | Fails on its next call | ## What to do about it, in order - **Before the replacement**, ask each owner one question the records cannot answer: does anything here hold this value without fetching it? The answers are how out-of-store copies become known. - **Convert rather than re-paste.** The durable fix is to make that consumer fetch from the store, so that it registers next time and takes future values automatically. Pasting in the new value restores service and rebuilds exactly the same blind spot. - **Sequence for it anyway.** Because you will not find them all, withdraw the old value in a way that gives you a signal and a way back — and expect the late failure from a consumer with a long duty cycle. ## Why an interviewer asks it The question looks trivial and is not: it tests whether a candidate understands where a value actually lives after it leaves the store, and whether they know which of the four actions above is the one that touches a copy. Weak answers say "we would update the store and it would pick it up", which is precisely the assumption the scenario removes. Strong answers separate the moment of the change from the moment of the failure, and say plainly that the only lever that reaches the copy is withdrawal at the downstream system.
- The team offers to paste the new value in during the change window — is that enough?It keeps the service up, and it leaves you exactly where you started: still invisible to the next census, still requiring a human at every future replacement, still liable to be missed by whoever runs that one. Accept it as the tactical step if the window is tight, and record converting the consumer to fetch from the store as the actual remediation, with an owner.
- How would you discover copies like this before the replacement rather than during it?By asking, primarily: each owner is asked whether anything holds the value without fetching it, and each downstream account's own settings are checked for a credential someone entered by hand. Expect the list to be incomplete, which is why the withdrawal step is sequenced with a way back rather than treated as the end of a completed change.
saying these in an interview costs you the question
- Assumes writing the new value into the store reaches every holder
- Expects the failure at the moment the store is updated
- Believes deleting the stored value disables copies already taken
- Fixes it by pasting the new value in and closing the change
- Thinks a census would have found a consumer that never reads