You revoke the key protecting a multi-year log archive - which copies of that data go dark, and which do not?

## What revocation is Revoking a key means disabling or destroying it so that the `unwrap` operation fails. No unwrap, no data key; no data key, no plaintext. Everything else about the system is unchanged: the ciphertext still occupies storage, the objects still appear in listings, the access policy still admits the same callers, and the bill is the same the next morning. This is why **revocation is not deletion** - it changes readability, not existence. The interview value of the question is that engineers reliably overestimate its reach. Revocation covers exactly one thing: ciphertext that still depends on that key. ## What goes dark - **Live objects in the store.** Immediately in principle, and in practice once cached data keys expire - services cache an unwrapped data key for a bounded interval, and that window is the lag on any revocation promise. - **Backups and snapshots the service took at the storage layer.** These normally hold the same ciphertext and need the same key, so they go with it. That is the outcome you want for a destruction obligation and a nasty surprise if you were relying on them for recovery. - **Replication targets, sometimes.** Replication copies ciphertext faithfully within a failure domain. Across regions, designs differ: some re-wrap the data key under a region-local key so that the copy has its own key lineage, and some do not. Do not assert that every replica goes dark - check the design you actually have. ## What does not - **Anything decrypted and copied out.** A plaintext export, a copy loaded into an analytics system, a file on a laptop, a tenant's own download. These were protected at the destination the moment they left, and your key has no purchase on them. - **Derived data.** Aggregates, indexes and reports a pipeline produced from the plaintext are independent artefacts under whatever protection that system applies. - **Metadata.** Object names, sizes, timestamps, tags and the listing itself are typically stored in the clear so the service can operate. An archive whose file names encode customer identifiers leaks after revocation exactly as much as before. - **The data, if the key comes back.** A pending-deletion window that is still reversible, a backup of the key, or an escrow copy held for break-glass all mean readability can be restored. A destruction claim that ignores these is not a claim. | Copy | Still needs that key? | Outcome of revocation | |---|---|---| | Live objects in the store | Yes | Unreadable once cached data keys expire | | Service-taken backup or snapshot | Yes, normally | Unreadable, including for your own recovery | | Cross-region replica | Depends on design | May be re-wrapped locally and survive | | Plaintext export into another system | No | Fully readable, unaffected | | Object names, sizes, timestamps | No | Still listed and still readable | ## Blast radius is set by key scope, not by the act The single most consequential decision here is made long before the revocation: **what the key covers**. One key for an entire archive means one switch that takes out every tenant in it. A key per customer means the switch matches the obligation - which is exactly why an archive under a contract permitting a customer to order its records destroyed should be keyed per customer from the first write. Retrofitting that scope means rewriting the data under new keys, priced by volume and by the store's write path. ## Revocation against the alternatives A destruction obligation has three candidate mechanisms, and they are not equivalent: 1. **Deleting the objects.** Honest but hard to prove, because you must chase every replica, every backup within its retention, and every version the store kept. 2. **Denying access.** Fast, and worth nothing as evidence - it is reversible by whoever can edit the policy, and the bytes remain plaintext-recoverable. 3. **Destroying the key** - often called crypto-shredding. Provable only if three things hold: every copy of the data is under that key, the key's destruction is genuinely irreversible, and no usable copy of the key exists in escrow or in a still-reversible deletion window. A strong answer states those three conditions rather than asserting that shredding works. The failures are almost never cryptographic - they are an export nobody tracked, a shared key whose scope was never narrowed, or a break-glass copy someone kept for exactly the emergency this was supposed to create.