A review asks whether a retired credential's earlier values are truly gone — what does deleting the entry leave behind?
answer
- delete and destroy are not one operation
- reversible until the window closes
- destruction covers the live store
- earlier copies keep their own clocks
- the closing proof is downstream refusal
basics
~20 sDeletion is reversible in many stores: the entry stops answering reads while the value is still held and can be brought back during a recovery window. Destruction is the separate, irreversible step, and even that covers only the live store.
solid answer
~40 sTwo different operations often wear the same word. A **reversible deletion** hides the entry — reads stop answering — while the value is still held and can be recovered until a window closes. **Destruction** makes it unrecoverable in the live store. Designs differ in which of the two the delete operation means, whether a recovery window exists, and how long it runs, so the honest first answer is "I would check which one this store performed." Then there are the copies destruction does not reach: anything taken before it, and anything a consumer already fetched. Each ages out on its own clock. That is why absence is not really provable, and the evidence that closes the review is different: the credential itself no longer authenticates anywhere, so any surviving copy is worthless.
go deeper
Recall that removing a secret from a store may be reversible for a period, and that an irreversible destruction is usually a separate operation.
Explain the difference between an entry that stops answering reads and a value that no longer exists, and why the first says nothing about the second.
In front of a review, establish which operation actually ran, enumerate the copies it did not reach, and lead with the evidence that the credential no longer authenticates.
Decide what the estate must be able to demonstrate about retired values, and accept the cost: shorter recovery windows mean fewer undos and a cleaner answer to that question.
## Two operations wearing one word Ask what "we deleted it" meant and you get one of two very different states. - **Reversible deletion.** The entry stops answering reads. The value is still held. Within a recovery window — however long the store or the name is configured for — it can be brought back intact. The entry looks gone from the outside and is not gone. - **Destruction.** The value is made unrecoverable in the live store. There is no undo, which is exactly the property that makes it useful and exactly the property that makes people nervous about performing it. Designs genuinely differ here: in whether the ordinary delete means the first or the second, in whether a recovery window exists at all, in how long it runs, and in whether a name can be configured to skip it. None of that is a fact about secret stores in general, so the first move in front of a review is to establish which operation was actually performed, not to recall which one you believe is standard. ## What a reversible deletion is good for, and what it costs It exists because mistaken deletion is common and a genuinely destroyed credential with no other copy can take a system down. The window buys an undo. What it costs is precise and worth stating plainly: - The value is still present for the length of the window, not merely the record of it. - A recovery is an ordinary operation, so whoever can recover the entry can bring the value back into service. - "It is not in the store" is true of reads and false of the contents, which is the gap a careless answer falls into. ## What destruction covers | Copy | Does destruction in the live store reach it? | What actually ends it | |---|---|---| | The live store's own data | Yes — that is what the operation does | the destroy itself | | A read-only follower of that store | Yes, as the change replicates | the same operation, once it propagates | | A copy taken before the destroy and kept elsewhere | No | that copy's own retention, however it is governed | | A value a consumer already fetched | No | the consumer's own lifetime, restart or refresh | | The account the credential belongs to | No | changing or removing the credential there | The last row is the one that matters most and gets mentioned least. Destroying a value in the store is a statement about the store. It is not a statement about the system that accepts the credential, which will go on honouring any surviving copy until the credential is withdrawn there. ## What you can actually prove Absence is not directly provable: you cannot demonstrate that no copy exists anywhere. What you can put in front of a review is a chain that makes surviving copies irrelevant. 1. **Which operation was performed, and when.** A destruction with a timestamp, distinguished from a deletion that merely started a recovery window — and, if a window was used, evidence that it has since closed. 2. **Which copies existed and what governs each.** Followers, whatever copies were taken before the destroy, and anything already fetched by a consumer. Naming them is the honest part of the answer; each has its own clock. 3. **That the credential no longer authenticates.** The account was changed or removed, tested, and the test recorded. This is the step that converts "we believe every copy is gone" into "a copy would not do anyone any good." A candidate who offers only the first item has answered a smaller question than the one asked. A candidate who leads with the third has understood what the review is really trying to establish. ## The order to do it in When a value is being retired for cause rather than housekeeping, withdrawal comes first or close to first: stop the credential being accepted, then destroy the stored copies, then record both. Destroying first feels decisive and buys nothing, because the copies already handed out are unaffected — and if the destruction turns out to have been a mistake, there is no version to roll forward from. ## The trap in the word "retired" "Retired" describes a version the store will no longer serve. It says nothing about whether the value is still held, and nothing about whether the credential still works. Three states, three separate questions: served or not, held or not, accepted or not. A review asking whether the old values are gone is asking about the second and the third, and an answer about the first is a different answer to a different question.
- What single piece of evidence best answers "is the old value gone?"That the credential no longer works — the account it belonged to was changed or removed, and the check was recorded. A destruction record with a timestamp supports the claim about the store, but only downstream refusal makes every remaining copy worthless, which is what the question is really after.
- Why have a recovery window at all if it weakens the deletion?Because mistaken deletes are common and an irrecoverable one can take a system down. The window buys an undo and costs a period in which the value is still held. Where a name's blast radius makes that trade wrong, destroy explicitly rather than waiting the window out.
- A consumer fetched the value an hour before it was destroyed — what state is it in?It is holding a working credential that no longer exists in the store. Nothing about the destruction reaches it, and the store cannot tell it to forget. It stops mattering when the process restarts or refreshes, or when the credential is withdrawn at the system that accepts it — whichever comes first.
A document dropped into a bin that is emptied on a schedule is not a shredded document: until the bin is emptied, anyone who can reach it reads exactly what you meant to throw away.
saying these in an interview costs you the question
- Treats delete and destroy as the same operation
- Says a deleted value is unrecoverable the moment it disappears
- Claims destruction reaches copies taken before it ran
- Offers the absence of the entry as proof the value is gone
- Forgets the credential still authenticates until withdrawn