An incident commander asks whether a caller's bounded session to the secret store is cut off yet — what must you check before answering?

seniormust knowfreq 61%

answer

the answer is a time, not yes
record consulted, or proof verified
a reference ends it without the value
nothing to strike out means waiting
subtract in-flight and replica lag

basics

~20 s

Check whether the store consults a session record on every call. If it does, an operator can end that session and the answer is a timestamp. If it verifies a self-contained proof instead, containment means waiting out its remaining validity.

solid answer

~50 s

The honest answer is a time, not a yes. First establish what the store does on each call. If it looks the session up in a record it owns, then an operator holding a reference to that session can end it without ever seeing the session value, and the caller is refused from its next request — so the answer is "cut off as of this timestamp". If instead the store verifies a self-contained proof against the keys of an issuer it trusts, there is no record to strike out; the caller stays accepted until the proof's validity runs out, and containment means narrowing what the store will accept or waiting. Then subtract the gap: in-flight requests already authorised, anything that verifies against a replica that has not caught up, and the caller's own retry timing. Report the worst case, and say which of those two shapes you are in.

The honest answer is a **time**, not a yes. First establish what the store does on each call. If it looks the session up in a record it owns, then an operator holding a reference to that session can end it without ever seeing the session value, and the caller is refused from its next request — so the answer is "cut off as of this timestamp". If instead the store verifies a self-contained proof against the keys of an issuer it trusts, there is no record to strike out; the caller stays accepted until the proof's validity runs out, and containment means narrowing what the store will accept or waiting. Then subtract the gap: in-flight requests already authorised, anything that verifies against a replica that has not caught up, and the caller's own retry timing. Report the worst case, and say which of those two shapes you are in.

code

pseudocode · 18 lines

pseudocode

on each call from caller:
    handle = call.sessionHandle

    if store.consultsSessionRecords:
        record = store.lookupSession(handle)
        if record == null or record.endedAt != null:
            refuse("session ended")
        if now > record.expiresAt:
            refuse("session expired")
        allow(record.rights)

    else:
        if not verifySelfContained(handle, store.acceptedIssuerKeys):
            refuse("proof not accepted")
        if now > handle.expiresAt:
            refuse("proof expired")
        allow(handle.rights)
        # no record was read, so ending one would change nothing here

go deeper

for a junior

Know that ending someone's access to a secret store is not always instant, and that the useful answer to "are they locked out?" includes a time rather than just a yes.

for a middle

Explain the two shapes: a session the store looks up in its own record and can end on demand, versus a self-contained proof it verifies without consulting anything, where the window has to run out.

for a senior

Give the commander a mechanism, a timestamp and a residual. Have rehearsed ending a session by reference and timed how long until reads are refused, and know which of your callers have no kill path at all.

for a principal

Own the promise itself. Decide what maximum containment lag the estate accepts, and accept its price: either the store is consulted on every call, or windows stay short enough that waiting is a tolerable answer.

The question behind the question

"Is that caller cut off?" is an availability-of-containment question, and the interviewer is listening for whether you can answer it with a mechanism and a number instead of a reassurance. There are exactly two shapes an answer can take, and which one you are in was decided when the session was issued.

First, keep the verbs apart. Rotation puts a new value in place. Revocation makes an existing credential stop working. Deletion removes a record and only matters if something consults that record. A rotation that never withdrew the old value left it live, and deleting a row that nothing reads changes nothing at all.

Shape one: the store consults a record

Some stores keep a record for every live session and look it up on each call. Then:

An operator can hold a reference to the session and end it, without ever having seen the session value itself. That separation is the useful part: the person doing containment does not need to be handed a working credential to take it away.
The caller is refused from the next request the store evaluates — not in flight, and not retroactively for reads that already returned.
The answer to the commander is "ended at 02:41; anything it read before then stands."

Shape two: the store verifies a self-contained proof

Other designs hand back a proof the store can verify on its own — signature, subject and an expiry inside it — and consult nothing. Then there is no record to strike out, and the levers are different:

Narrow what the store will accept. Stop honouring proofs from that issuer, or from that key, or for that subject. This is blunt: it usually hits every caller in the same class, not just the one you care about.
Wait it out. The proof stays acceptable until its own expiry, and that window is fixed; nothing you do afterwards shortens it.

Work the arithmetic out loud. A session issued twenty-one days ago under a thirty-day window leaves nine days of remaining validity. If your only lever is waiting, nine days is the containment answer, and the commander needs it in those words rather than as "we revoked it".

The gap between "revoked" and "cut off"

Even in shape one, the write and the effect are not simultaneous. Subtract:

Requests already in flight when the revocation landed. They were authorised before the check.
Anything that verified against a replica that has not yet seen the change, if reads are served from more than one place.
The caller's own timing. A consumer that reads once an hour discovers it is cut off up to an hour later — which is good for you, but it means "no failures logged yet" is not evidence that the session is still working.

You want to say	Say instead
"It's revoked."	"The revocation was written at 02:41; it applies from each caller's next request."
"We can't stop it."	"No record backs this proof, so it is accepted for nine more days unless we stop trusting the issuing key."
"We deleted the session."	"We deleted a record the store does not consult, so nothing changed."
"We rotated the credential."	"A new value is in place; the old one still works until it is withdrawn."

What you owe the commander

One sentence with three parts: the mechanism (ended by reference, or accepted until expiry), the time (a past timestamp or a future one), and the residual (what was reached before the cut-off, and what still verifies). Anything less turns into a second incident when the caller is seen reading an hour later.

The rehearsal that makes this answerable

Do not discover the shape during an incident. In a drill: issue a session, hand the reference to someone who never sees the session value, have them end it, and time the interval until reads are refused. That interval — plus the longest validity window you issue — is the number you are entitled to quote. If the drill shows there is no reference to hand over, then you know before the fact that your containment story is narrow what is accepted, or wait, and you can size the windows you issue accordingly.

One more honest caveat: cutting the caller's access to the store off says nothing about credentials it already fetched. Those are separate objects that live in the systems that accept them, and they are withdrawn there.

## The question behind the question "Is that caller cut off?" is an availability-of-containment question, and the interviewer is listening for whether you can answer it with a mechanism and a number instead of a reassurance. There are exactly two shapes an answer can take, and which one you are in was decided when the session was issued. First, keep the verbs apart. **Rotation** puts a new value in place. **Revocation** makes an existing credential stop working. **Deletion** removes a record and only matters if something consults that record. A rotation that never withdrew the old value left it live, and deleting a row that nothing reads changes nothing at all. ## Shape one: the store consults a record Some stores keep a record for every live session and look it up on each call. Then: - An operator can hold a **reference** to the session and end it, without ever having seen the session value itself. That separation is the useful part: the person doing containment does not need to be handed a working credential to take it away. - The caller is refused from the next request the store evaluates — not in flight, and not retroactively for reads that already returned. - The answer to the commander is *"ended at 02:41; anything it read before then stands."* ## Shape two: the store verifies a self-contained proof Other designs hand back a proof the store can verify on its own — signature, subject and an expiry inside it — and consult nothing. Then there is no record to strike out, and the levers are different: - **Narrow what the store will accept.** Stop honouring proofs from that issuer, or from that key, or for that subject. This is blunt: it usually hits every caller in the same class, not just the one you care about. - **Wait it out.** The proof stays acceptable until its own expiry, and that window is fixed; nothing you do afterwards shortens it. Work the arithmetic out loud. A session issued twenty-one days ago under a thirty-day window leaves **nine days** of remaining validity. If your only lever is waiting, nine days is the containment answer, and the commander needs it in those words rather than as "we revoked it". ## The gap between "revoked" and "cut off" Even in shape one, the write and the effect are not simultaneous. Subtract: 1. **Requests already in flight** when the revocation landed. They were authorised before the check. 2. **Anything that verified against a replica** that has not yet seen the change, if reads are served from more than one place. 3. **The caller's own timing.** A consumer that reads once an hour discovers it is cut off up to an hour later — which is good for you, but it means "no failures logged yet" is not evidence that the session is still working. | You want to say | Say instead | |---|---| | "It's revoked." | "The revocation was written at 02:41; it applies from each caller's next request." | | "We can't stop it." | "No record backs this proof, so it is accepted for nine more days unless we stop trusting the issuing key." | | "We deleted the session." | "We deleted a record the store does not consult, so nothing changed." | | "We rotated the credential." | "A new value is in place; the old one still works until it is withdrawn." | ## What you owe the commander One sentence with three parts: the **mechanism** (ended by reference, or accepted until expiry), the **time** (a past timestamp or a future one), and the **residual** (what was reached before the cut-off, and what still verifies). Anything less turns into a second incident when the caller is seen reading an hour later. ## The rehearsal that makes this answerable Do not discover the shape during an incident. In a drill: issue a session, hand the reference to someone who never sees the session value, have them end it, and time the interval until reads are refused. That interval — plus the longest validity window you issue — is the number you are entitled to quote. If the drill shows there is no reference to hand over, then you know before the fact that your containment story is *narrow what is accepted, or wait*, and you can size the windows you issue accordingly. One more honest caveat: cutting the caller's access to the store off says nothing about credentials it already fetched. Those are separate objects that live in the systems that accept them, and they are withdrawn there.

When the proof is self-contained and you cannot wait out the window, what is left?
Change what the store accepts at verification time: stop honouring that issuer, that signing key or that subject. Each is blunt — it refuses every caller in the same class, so you are trading a wider outage for a shorter exposure, and that is a decision to name rather than take quietly. The alternative lever is preventive: issue shorter windows so the wait is never the long pole.
Why is "the revocation is written" not the same as "the caller is cut off"?
Because the effect lands at each caller's next evaluated request. Requests already in flight were authorised before the check, a read served by a replica that has not caught up may still succeed, and a consumer that calls once an hour will not even notice for an hour. Quote the worst case across those three, not the moment of the write.
What does ending the caller's session not achieve?
It does not touch credentials the caller already fetched and holds. Those live in whatever system accepts them and stop working only when they are withdrawn there or expire. Cutting store access ends the ability to get more; it does not reach the copies already delivered.

A pass the door checks against a live list can be cancelled from the front desk, and the next person to try it is refused. A dated day-pass printed this morning is honoured by the door until the date on it passes, whatever the desk decides.

saying these in an interview costs you the question

Answers "yes, revoked" without saying what the store checks per call
Believes any session can be ended by reference in any store
Thinks deleting a record stops a self-contained proof being accepted
Confuses putting a new value in place with withdrawing the old one
Assumes revocation cuts off requests that are already in flight
Reads "no failures logged" as proof the caller is still active

An incident commander asks whether a caller's bounded session to the secret store is cut off yet — what must you check before answering?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The question behind the question

Shape one: the store consults a record

Shape two: the store verifies a self-contained proof

The gap between "revoked" and "cut off"

What you owe the commander

The rehearsal that makes this answerable

▾common follow-ups3 questions

▾analogy~20 s

▾red flags6 flags

The question behind the question

Shape one: the store consults a record

Shape two: the store verifies a self-contained proof

The gap between "revoked" and "cut off"

What you owe the commander

The rehearsal that makes this answerable

answer

go deeper