You withdrew a generated database account, yet a worker still reads rows — what survived the withdrawal?

seniorshould knowfreq 45%

answer

the gate does not empty the room
authenticated at open, not per statement
a pool holds what it opened
a lease is not a session
look for success after the cutoff

basics

~20 s

An already-open connection survived. Most systems authenticate when a connection opens and do not re-check per statement, so work under that account continues until something closes it. Fetched copies and store-side sessions survive the same way.

solid answer

~40 s

Three things routinely outlive a withdrawal. A connection opened before it: authentication happens at open time and most systems do not re-check afterwards, so the worker keeps reading until something closes that connection. A copy already fetched — in a process's memory, in a rendered file on the host, inside a connection pool — which fails only at its next attempt to authenticate, possibly days away. And the caller's own session at the store, a different object with its own end, which is why an operator sometimes finds the consumer can still fetch values. So withdrawal has two parts: remove the account, then terminate what is already established under it, and confirm from the accepting system's records that no successful use appears after your cutoff.

Three things routinely outlive a withdrawal. A **connection opened before it**: authentication happens at open time and most systems do not re-check afterwards, so the worker keeps reading until something closes that connection. A **copy already fetched** — in a process's memory, in a rendered file on the host, inside a connection pool — which fails only at its next attempt to authenticate, possibly days away. And the caller's **own session at the store**, a different object with its own end, which is why an operator sometimes finds the consumer can still fetch values. So withdrawal has two parts: remove the account, then terminate what is already established under it, and confirm from the accepting system's records that no successful use appears after your cutoff.

code

pseudocode · 15 lines

pseudocode

confirmWithdrawn(cred, observationWindow):
    system = downstream[cred.systemId]

    system.removeAccount(cred.accountName)               # gates the NEXT authentication only

    for each c in system.listEstablished(cred.accountName):
        system.terminate(c.id)                           # an open connection re-checks nothing

    cutoff = now
    wait(observationWindow)

    stillEstablished = system.listEstablished(cred.accountName)
    usedSinceCutoff  = system.accessRecords(cred.accountName, after = cutoff, outcome = "success")

    return stillEstablished is empty and usedSinceCutoff is empty   # anything else is a survivor

go deeper

for a junior

Recall that removing an account governs the next authentication attempt, not activity that is already under way inside the system.

for a middle

Explain why a pooled connection keeps working: the credential was checked when the connection opened and is generally not consulted again afterwards.

for a senior

Demonstrate the full act — remove, terminate what is established, then look for successful use after a stated cutoff over a window you chose deliberately.

for a principal

Decide what the estate accepts where a downstream system cannot list established sessions, and how much shorter credentials there have to be to make that tolerable.

What a withdrawal actually interrupts

Dropping or disabling a downstream account changes one thing: what happens the next time something tries to authenticate as that account. It is a gate on the door, and it has no reach over anyone already inside. Everything that failed to cross that gate after the withdrawal is genuinely stopped; everything that crossed it earlier and is still running is untouched.

That is why a withdrawal that looks successful is routinely followed by a report that the consumer is still working. Nothing has gone wrong with the withdrawal. What is wrong is the expectation that it is retroactive.

The three survivors

Survivor	Why it survives	What actually ends it	How you confirm
A connection opened before the withdrawal	It authenticated at open time; most systems do not re-check per statement	An operator terminating it, the process reconnecting, or the system's own idle or maximum-age limit	List what is currently established under that account name; expect it empty
A copy already fetched and held	It is a value in a process, a pool, or a rendered file — nothing notifies it	Its next attempt to authenticate, whenever that is	Watch for successful use under that name after your cutoff
The caller's own session at the store	A session bounds access to the store; it is a different object from the credential the store issued	Ending that session, or its own bound expiring	Check the store's live sessions for that caller separately

The third is worth stating carefully, because the two objects are easy to conflate. A lease bounds a credential the store issued to a downstream system. A session bounds the caller's own access to the store. Withdrawing the first does not touch the second, and a caller whose session is intact may simply request a fresh credential — which is why suspending the requesting identity belongs in the sequence at all.

Why an open connection is almost always the answer

Most systems that accept a long-lived connection check the credential once, when the connection is established, and treat the resulting connection as the authenticated thing from then on. Some re-authenticate on a schedule or when a policy changes; behaviour genuinely differs, and the honest answer names the class rather than asserting one behaviour for all of them. But the default assumption should be that an established connection is not revisited.

A pool sharpens this. A worker that opened twenty connections at 06:00 and runs until 22:00 holds them the whole time. Withdraw the account at 09:00 and nothing observable happens for thirteen hours — no error, no alert, no failed authentication to trigger on — and then the process restarts overnight and finally fails at the moment nobody is watching. The absence of failures is not evidence of success here. A credential that still works produces successful requests, and success is what you have to look for.

Confirming instead of assuming

Remove the account in the accepting system.
Terminate what is established. List current connections or sessions under that account name and end each one. This is the step people skip, and it is the entire difference between a gate and a withdrawal.
Choose an observation window and query the accepting system's access records for successful use under that name after your cutoff moment. An hour, a day — pick a number that matches how often that consumer works, and say which you picked.
Re-list at the end of the window. If the established list is empty and the access records are silent, you can state the credential is out of use. If either is not, you have found a survivor, not a reporting error.

The claim you are actually making

"Revoked" should mean: the account no longer authenticates, nothing established under it remains, and nothing succeeded under it after a stated time. Each clause is checkable, and each corresponds to one of the survivors. An estate that cannot check the second and third clauses on a given system does not have a withdrawal there; it has a withdrawal plus an assumption, and the useful discipline is to write down which one was assumed rather than to let the ticket say revoked and mean something weaker.

## What a withdrawal actually interrupts Dropping or disabling a downstream account changes one thing: what happens the **next** time something tries to authenticate as that account. It is a gate on the door, and it has no reach over anyone already inside. Everything that failed to cross that gate after the withdrawal is genuinely stopped; everything that crossed it earlier and is still running is untouched. That is why a withdrawal that looks successful is routinely followed by a report that the consumer is still working. Nothing has gone wrong with the withdrawal. What is wrong is the expectation that it is retroactive. ## The three survivors | Survivor | Why it survives | What actually ends it | How you confirm | |---|---|---|---| | A connection opened before the withdrawal | It authenticated at open time; most systems do not re-check per statement | An operator terminating it, the process reconnecting, or the system's own idle or maximum-age limit | List what is currently established under that account name; expect it empty | | A copy already fetched and held | It is a value in a process, a pool, or a rendered file — nothing notifies it | Its next attempt to authenticate, whenever that is | Watch for successful use under that name after your cutoff | | The caller's own session at the store | A session bounds access **to** the store; it is a different object from the credential the store **issued** | Ending that session, or its own bound expiring | Check the store's live sessions for that caller separately | The third is worth stating carefully, because the two objects are easy to conflate. A **lease** bounds a credential the store issued to a downstream system. A **session** bounds the caller's own access to the store. Withdrawing the first does not touch the second, and a caller whose session is intact may simply request a fresh credential — which is why suspending the requesting identity belongs in the sequence at all. ## Why an open connection is almost always the answer Most systems that accept a long-lived connection check the credential once, when the connection is established, and treat the resulting connection as the authenticated thing from then on. Some re-authenticate on a schedule or when a policy changes; behaviour genuinely differs, and the honest answer names the class rather than asserting one behaviour for all of them. But the default assumption should be that an established connection is not revisited. A pool sharpens this. A worker that opened twenty connections at 06:00 and runs until 22:00 holds them the whole time. Withdraw the account at 09:00 and nothing observable happens for thirteen hours — no error, no alert, no failed authentication to trigger on — and then the process restarts overnight and finally fails at the moment nobody is watching. The absence of failures is not evidence of success here. A credential that still works produces **successful** requests, and success is what you have to look for. ## Confirming instead of assuming 1. **Remove the account** in the accepting system. 2. **Terminate what is established.** List current connections or sessions under that account name and end each one. This is the step people skip, and it is the entire difference between a gate and a withdrawal. 3. **Choose an observation window** and query the accepting system's access records for successful use under that name after your cutoff moment. An hour, a day — pick a number that matches how often that consumer works, and say which you picked. 4. **Re-list at the end of the window.** If the established list is empty and the access records are silent, you can state the credential is out of use. If either is not, you have found a survivor, not a reporting error. ## The claim you are actually making "Revoked" should mean: the account no longer authenticates, nothing established under it remains, and nothing succeeded under it after a stated time. Each clause is checkable, and each corresponds to one of the survivors. An estate that cannot check the second and third clauses on a given system does not have a withdrawal there; it has a withdrawal plus an assumption, and the useful discipline is to write down which one was assumed rather than to let the ticket say revoked and mean something weaker.

Why is watching for failed authentications the wrong signal after a withdrawal?
Because a credential that survived produces successes, not failures. Everything the withdrawal genuinely stopped is silent, and everything it missed looks exactly like normal traffic. The signal that discriminates is a successful authentication under that account name after the moment you withdrew it — which means the accepting system has to record successes, not just refusals.
The downstream system cannot list what is currently established under an account name. What do you do?
Bound the exposure instead of proving it. Issue much shorter-lived credentials there so any survivor dies on its own inside a known time, and state in the withdrawal record that termination was assumed rather than confirmed. If the system can restart or cycle its connections cheaply, doing that is a blunt substitute for a targeted terminate.

Cancelling a building pass stops the next person at the door. It does not walk anyone already inside back out — somebody has to go and do that, and then check the floors.

saying these in an interview costs you the question

Believes dropping an account terminates its existing connections
Expects a fetched copy to be notified that it was withdrawn
Confuses the caller's session at the store with the credential it issued
Takes the absence of authentication failures as proof of withdrawal
Declares a credential out of use without an observation window
Assumes every system re-checks a credential on every statement

You withdrew a generated database account, yet a worker still reads rows — what survived the withdrawal?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What a withdrawal actually interrupts

The three survivors

Why an open connection is almost always the answer

Confirming instead of assuming

The claim you are actually making

▾common follow-ups2 questions

▾analogy~10 s

▾red flags6 flags

What a withdrawal actually interrupts

The three survivors

Why an open connection is almost always the answer

Confirming instead of assuming

The claim you are actually making

answer

go deeper