A departing contractor held the key to one encrypted credentials file — what must you do that a store would not?

middlemust knowfreq 58%

answer

Nothing in a file to revoke
They kept the key and the ciphertext
Re-keying is not replacing
Entries times consumers
One grant withdrawn instead

basics

~20 s

Re-key and replace everything. One file-wide key means the departure exposes every entry, so each value is replaced, the file re-encrypted under a new key and every consumer redeployed. A store withdraws that one identity's grant instead.

solid answer

~40 s

The file has no per-holder object, so there is nothing to revoke. The contractor holds a copy of the key and can decrypt any copy of the ciphertext they kept, which means every entry the file held while they had the key must be treated as theirs. The work is therefore: replace all forty values on their own systems, re-encrypt the file under a new key, get that new key to everything that decrypts at deploy time, and redeploy all twelve services. Re-encrypting alone protects only the container — the values themselves stay live until they are replaced. In a store you withdraw the grants held by that one identity; other holders are untouched, and the replacement list shrinks to the three names that identity could reach.

code

pseudocode · 16 lines

pseudocode

// one encrypted file: the key opens every entry
onDeparture(contractor):
    for each entry in encryptedFile:          // all 40 entries
        newValue = mintOn(entry.owningSystem)
        entry.value = newValue                 // this is what ends their access
    fileKey = generateKey()
    reEncrypt(encryptedFile, fileKey)          // re-protects the container only
    distribute(fileKey, everyDeployTarget)
    redeploy(allTwelveServices)

// a store: access is a grant over a branch of names
onDeparture(contractor):
    revokeGrants(identity = contractor)        // their next read is refused
    for each name in grantedTo(contractor):   // 3 names, not 40
        replaceOn(name.owningSystem)
    // other holders untouched, no redeploy

go deeper

for a junior

Remember that a departing key holder keeps whatever they already decrypted. Removing their access to the repository does not take those values back.

for a middle

Explain why there is nothing to revoke: the file has one key and no per-holder grant, so the only lever is replacing every value and re-keying the container.

for a senior

Walk the real cost across the estate — forty replacements, a key redistribution and twelve redeploys — and note that this cost is identical for routine and emergency departures, which is why it is quietly skipped.

for a principal

Argue the standard: any control whose cost is the same for a routine event and an emergency will be deferred, so design so that withdrawing one holder is cheap enough to be ordinary.

Why there is nothing to revoke

Revocation needs a thing to revoke: a grant, an identity, a handle the system knows about. An encrypted file has none of these. It has a key, held by whoever was given it, and the key opens everything. When a holder leaves, the system holds no record that they ever had it and no mechanism that would stop them using it. Two facts follow, and they set all the work:

They may have kept a copy of the ciphertext. A repository is copied by design, so "removing their access" stops them getting future copies and does nothing about the one on their disk.
They may have read every entry. Decryption is all-or-nothing and unobserved, so you cannot narrow the list; the honest assumption is the whole file.

The work a departure forces, under the file

Take the concrete estate: twelve services, one file holding forty entries, decrypted at deploy time.

Replace all forty values on the systems that accept them. This is the step that actually ends the contractor's access, and it is the expensive one: forty credential changes across forty owning systems, each with its own consumers.
Re-encrypt the file under a new key. This protects the container going forward. On its own it protects nothing that was inside it — the old ciphertext plus the old key still opens the old values, and those values are what the downstream systems accept.
Distribute the new key to everything that decrypts at deploy time, and to every remaining person who needs it.
Redeploy all twelve services so each one picks up the replaced values.

The cost is entries times consumers, and it is identical whether the departure is a planned end-of-engagement or a live exposure. That symmetry is the practical problem: a cost that large, incurred for routine events, gets deferred, and the deferral is invisible because nothing fails.

The same departure, under a store

The contractor authenticated to the store as an identity, and that identity held rules granting read over some branch of the name space. The departure is handled by withdrawing those grants. What follows from that:

Every other holder keeps working. Nothing is re-keyed, nothing is redeployed, and no other consumer is touched.
The replacement list is bounded by what that identity could reach — three names here, not forty. If you want it bounded by what they did reach, that is what the store's record of reads gives you, with the caveat that a shared identity makes any read unattributable.
The withdrawal is instant and checkable: the next read by that identity is refused, and you can see that it was.

Step	One encrypted file	A secret store
Stop their access	No mechanism exists	Withdraw that identity's grants
Values to replace	All 40, by assumption	The 3 they were granted
Other holders	Need the new key	Unaffected
Consumers to redeploy	All 12	None, for the withdrawal itself

Two directions people state backwards

Rotation is not revocation. Rotating puts a new value in place; revoking makes the old one stop working. A team that writes new values into the file and never changes them on the downstream systems has rotated nothing that matters: the contractor's copies still authenticate. Say which of the two you are doing, every time.

Re-keying the file is not replacing its values. Changing the key the file is encrypted under re-protects the container against someone holding old ciphertext and the old key. It leaves every credential inside it exactly as valid as it was.

Which order, and what it costs

When the same person's access must end, you choose between two orders and you should be able to name the cost you accepted:

Replace first, then withdraw. Consumers move onto new values while the old ones still work, so nothing breaks. You accept a window in which the departed holder's copies are still good.
Withdraw first, then replace. Use ends immediately. You accept that anything still reading the old value fails until the replacement lands.

An ordinary end of engagement takes the first order. A suspicion that the credentials are being used inverts it — and the fact that the encrypted file makes the fast order ruinously expensive (re-key, redistribute, redeploy, all at once, under pressure) is itself an argument for the store.

## Why there is nothing to revoke Revocation needs a thing to revoke: a grant, an identity, a handle the system knows about. An encrypted file has none of these. It has a **key**, held by whoever was given it, and the key opens everything. When a holder leaves, the system holds no record that they ever had it and no mechanism that would stop them using it. Two facts follow, and they set all the work: - They may have kept a copy of the ciphertext. A repository is copied by design, so "removing their access" stops them getting *future* copies and does nothing about the one on their disk. - They may have read every entry. Decryption is all-or-nothing and unobserved, so you cannot narrow the list; the honest assumption is the whole file. ## The work a departure forces, under the file Take the concrete estate: **twelve services, one file holding forty entries, decrypted at deploy time**. 1. **Replace all forty values on the systems that accept them.** This is the step that actually ends the contractor's access, and it is the expensive one: forty credential changes across forty owning systems, each with its own consumers. 2. **Re-encrypt the file under a new key.** This protects the container going forward. On its own it protects nothing that was inside it — the old ciphertext plus the old key still opens the old values, and those values are what the downstream systems accept. 3. **Distribute the new key** to everything that decrypts at deploy time, and to every remaining person who needs it. 4. **Redeploy all twelve services** so each one picks up the replaced values. The cost is entries times consumers, and it is identical whether the departure is a planned end-of-engagement or a live exposure. That symmetry is the practical problem: a cost that large, incurred for routine events, gets deferred, and the deferral is invisible because nothing fails. ## The same departure, under a store The contractor authenticated to the store as an identity, and that identity held rules granting read over some branch of the name space. The departure is handled by **withdrawing those grants**. What follows from that: - Every other holder keeps working. Nothing is re-keyed, nothing is redeployed, and no other consumer is touched. - The replacement list is bounded by what that identity could reach — three names here, not forty. If you want it bounded by what they *did* reach, that is what the store's record of reads gives you, with the caveat that a shared identity makes any read unattributable. - The withdrawal is instant and checkable: the next read by that identity is refused, and you can see that it was. | Step | One encrypted file | A secret store | |---|---|---| | Stop their access | No mechanism exists | Withdraw that identity's grants | | Values to replace | All 40, by assumption | The 3 they were granted | | Other holders | Need the new key | Unaffected | | Consumers to redeploy | All 12 | None, for the withdrawal itself | ## Two directions people state backwards **Rotation is not revocation.** Rotating puts a new value in place; revoking makes the old one stop working. A team that writes new values into the file and never changes them on the downstream systems has rotated nothing that matters: the contractor's copies still authenticate. Say which of the two you are doing, every time. **Re-keying the file is not replacing its values.** Changing the key the file is encrypted under re-protects the container against someone holding old ciphertext *and the old key*. It leaves every credential inside it exactly as valid as it was. ## Which order, and what it costs When the same person's access must end, you choose between two orders and you should be able to name the cost you accepted: - **Replace first, then withdraw.** Consumers move onto new values while the old ones still work, so nothing breaks. You accept a window in which the departed holder's copies are still good. - **Withdraw first, then replace.** Use ends immediately. You accept that anything still reading the old value fails until the replacement lands. An ordinary end of engagement takes the first order. A suspicion that the credentials are being used inverts it — and the fact that the encrypted file makes the fast order ruinously expensive (re-key, redistribute, redeploy, all at once, under pressure) is itself an argument for the store.

Is re-encrypting the file under a new key enough on its own?
No. The contractor already read the plaintext, so they hold the values themselves, not just a way to open the file. A new file key stops someone opening an old copy of the ciphertext with the old key; it does not make a single downstream system refuse a credential they already have. Only replacing each value on its owning system does that.
What decides whether you replace the values first or cut the grant first?
Whether you are ending access or stopping use. A planned departure replaces first, so consumers move across without an outage, accepting a short window where the old copies still work. A suspicion of active misuse inverts it: withdraw first and accept that anything still on the old value fails until the replacement lands.
The contractor only ever used two credentials. Why replace forty?
Because with a file you cannot show that. Decryption is unobserved, so "only used two" is their account, not evidence. A store's record of reads is what would let you narrow the list honestly — and even then only if the identity was theirs alone and the record covers the whole engagement.

A shared front-door key: when one holder leaves you change the lock and cut a new key for everyone. A badge reader lets you cancel one badge and leave every other badge working.

saying these in an interview costs you the question

Says removing repository access ends the contractor's reach
Thinks re-encrypting the file invalidates the values inside
Rotates values in the file but not on the owning systems
Assumes only the entries they used need replacing
Treats a routine departure as cheaper than an emergency here

A departing contractor held the key to one encrypted credentials file — what must you do that a store would not?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why there is nothing to revoke

The work a departure forces, under the file

The same departure, under a store

Two directions people state backwards

Which order, and what it costs

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

Why there is nothing to revoke

The work a departure forces, under the file

The same departure, under a store

Two directions people state backwards

Which order, and what it costs

answer

go deeper