Why should a time-boxed grant to read a stored credential expire by itself rather than be revoked after the work?
answer
- a missed revoke has no symptom
- inaction should end the right
- checked at use, not by a sweeper
- extension is a fresh decision
- the grant's clock is not the credential's
basics
~20 sBecause a revoke step is a task that fails silently: nothing breaks when a grant outlives its work, so it is skipped and accumulates. An end time makes continuation, not removal, the action somebody has to take.
solid answer
~50 sRevoking at the end depends on somebody or something doing a chore at the moment nothing is wrong — after the incident closed at four in the morning, after the requester went on leave, after the process that was going to revoke crashed. A missed revoke has no symptom, so the estate silently drifts back to standing grants and the control's whole benefit is gone. An end time inverts that: the grant ends unless somebody asks again, and asking again is a fresh decision rather than a silent slide. Two things matter mechanically. The expiry must be evaluated on the read path, not by a periodic sweeper, or the real window is the grant plus the sweep interval. And revoking early when work finishes ahead of time is still worth doing — expiry is the floor, not the ceiling.
code
pseudocode · 12 lineson read_request(caller, name):
grant = find_grant(subject = caller, covers = name)
if grant is none:
deny("no grant") # absent by default
if now() >= grant.expiresAt:
deny("grant expired") # decided here, not by the sweeper
allow()
record(caller, name, grant.id, grant.reason, grant.approvedBy)
every 10 minutes: # housekeeping only
for g in grants where now() >= g.expiresAt:
archive(g)go deeper
Recall that the grant carries its own end time, so nobody has to remember to take the access away when the work is done.
Explain why a cleanup step fails silently, and that the end time must be compared against the clock when the read is attempted rather than by a periodic job.
Demonstrate the operational reasoning: choose the shortest window, make extension a fresh approval, keep early revocation available, and know that the issued credential's validity is a separate clock.
Treat repeated extensions as evidence about where the gate belongs, and decide what the estate does when the two clocks disagree on high-value material.
## Two ways a grant can end A grant created for one piece of work can end in two ways. Somebody can **revoke** it when the work finishes, or it can carry an **end time** and stop being valid on its own. Both sound equivalent on a whiteboard. In an estate they behave nothing alike, because they fail differently. ## Why the cleanup step is the one that fails Revocation at the end of the work is a task, and it is a task with the worst possible property: **nothing visibly breaks when it is skipped.** - The investigation closed at four in the morning and the engineer went to bed. - The requester handed the work over and the new owner did not know a grant existed. - The automation that was going to revoke it failed, and nobody noticed because a failed revoke has no downstream symptom. - The work was never formally closed at all; it just stopped being urgent. Every skipped revoke leaves a right in place. None of them produces an alert, a broken build or an unhappy user. The result is the failure mode the whole design was installed to prevent: an estate that describes itself as just-in-time and is, in practice, back to standing grants — with extra ceremony at the front and no expiry at the back. An end time inverts the default. **Inaction ends the right.** Keeping access requires somebody to ask again, and asking again is a decision a second person makes with the same information as the first time. ## Where the expiry has to be evaluated This is the part candidates skip. If expired grants are removed by a job that sweeps every ten minutes, and the read path only looks up whether a grant row exists, then the effective window is *the approved duration plus up to one sweep interval* — and that gap widens to however long the sweeper is broken, which nobody will notice for the same reason nobody notices a missed revoke. The check belongs where the decision is made: on every read, compare the current time against the grant's end time and refuse if it has passed. The sweeper then becomes housekeeping — it keeps the table small and it can lag or fail without granting anybody a minute of extra access. ## Choosing the window - The default is the **shortest duration that completes the described work**, not a shift, not a day. - The approver should be able to shorten what was requested, and the shorter of the two wins. - Extension is a **fresh approval**, not a silent slide: the second decision is where a request that has quietly become routine becomes visible. - A grant that is regularly extended three times is evidence that the work behind it is not exceptional, and belongs in a conversation about whether the gate is on the right reads at all. ## The second clock, which is not this one The grant's end time bounds **the right to ask the store**. Anything the read produced has its own story: | object | what the clock bounds | what happens at the end | |---|---|---| | the grant | whether this caller may read that name | further reads are refused | | a credential issued during the window | how long the downstream system accepts it | that system stops accepting it | | a static value that was displayed | nothing; it is already copied | only replacing the value ends the exposure | These three can and do disagree. A grant expiring at 14:05 does not withdraw a credential minted at 13:30 with its own longer validity, and it certainly does not un-display a static value. Where the released credential is generated per request, binding its validity to the grant window is what keeps the two clocks aligned; where the value is static and shared, the end of the window is the moment to ask whether the value itself should now be replaced. ## Early revocation still has a job Expiry is a floor, not a ceiling. When the work finishes in ten minutes, revoking the grant immediately is strictly better than waiting out the remaining thirty-five, and an operator ending a grant early is one of the few actions worth making a single click. The argument is not *never revoke*; it is that the system must be correct when nobody revokes. ## What an interviewer is listening for The inverted default, stated in one sentence, plus the read-path detail — which is what separates somebody who has run this from somebody who has drawn it. Naming the second clock unprompted is the senior signal.
- The sweeper has been broken for two days. What access did that give anybody?None, if the read path compares the current time against the grant's end time on every request. Expired rows linger in the table and the listing looks untidy, but no read is permitted that would not have been permitted with a healthy sweeper. That is the whole point of deciding at use.
- An engineer asks to extend a grant that is about to expire. What should the system require?A fresh approval, with the same fields as the original and the extension recorded as its own decision. Silent renewal turns a window back into a standing right one extension at a time, and the repeat request is the signal that this work may not be exceptional enough to sit behind the gate.
- The grant expired but the engineer reports they can still use the credential they obtained. Is the design broken?Not necessarily — the grant bounds the right to read, while the credential carries its own validity. If they are meant to end together, the issued validity must be bound to the grant window at issue time. If the value is a static shared one, no clock helps and replacing it is the only end to the exposure.
saying these in an interview costs you the question
- Relies on the requester remembering to hand the access back
- Thinks a periodic cleanup job is where expiry gets enforced
- Believes an expired grant withdraws a credential already issued under it
- Sets the window to a working day for convenience of follow-ups
- Lets a grant be extended without a second decision
- Says expiry means early revocation is never worth doing