skip to content

Your team mandates fifteen-minute database credentials; which properties of the existing consumers set the floor under that number?

level: seniorimportance: should knowfreq 52%

answer

  1. the holder decides, not the policy
  2. can it go back for a value?
  3. longest holding period wins
  4. pools and boot-time readers hold longest
  5. a mandate below the floor buys exceptions

basics

~20 s

The floor is set by the longest period any holder keeps one value with no way to obtain another: a six-hour export, a pool whose connections authenticate once at open and live for days, a worker that reads at boot and holds until redeployment.

solid answer

~40 s

The binding property is not how long the work takes but whether the holder can go back for a fresh value without stopping. Three shapes dominate. A batch job that reads the credential at the start and runs six hours holds one value for six hours. A connection pool that authenticates each connection when it opens and then keeps it for days holds one value for the life of that connection. A worker that reads the value once at boot holds it until the next deployment, which may be weeks. The floor under an estate-wide number is the longest of those, and if it is fourteen days then fifteen minutes is not a setting you can turn on — it is a programme to change consumers so they can acquire a value repeatedly.

code

pseudocode · 18 lines
pseudocode
# floor = the longest period any holder keeps one value
#         with no way to obtain another while running

holders = [
  { name: "nightly-export",     holdsOneValueFor: 6h,  canReacquireWhileRunning: false },
  { name: "connection-pool",    holdsOneValueFor: 14d, canReacquireWhileRunning: false },
  { name: "request-path-service", holdsOneValueFor: 0,   canReacquireWhileRunning: true  }
]

floor = 0
for each h in holders:
    if h.canReacquireWhileRunning:
        continue                      # puts no floor under anything
    if h.holdsOneValueFor > floor:
        floor = h.holdsOneValueFor

# floor = 14d  ->  a 15-minute mandate is a change programme,
#                  not a number you can set today

go deeper

for a junior

Notice that some programs read a credential once when they start and then never look again. How long that program runs is how long it keeps that one value.

for a middle

Explain why the binding property is the ability to obtain a fresh value mid-run rather than the duration of the work, and name a holder of each shape.

for a senior

Walk the estate out loud: which holders cannot re-acquire, what each one's holding period actually is, and what the arithmetic makes the floor. Then say what work lowers it.

for a principal

Own the sequencing. Decide which classes move now, which get a named exception with a date, and what you are prepared to spend to lower the tallest floor — rather than announcing a number and inheriting an exception list.

A mandate for short-lived credentials is decided somewhere other than where it is written. The number is available to you only if nothing in the estate holds one value for longer than the number, and the thing that decides that is a property of the **holder**, not of the security argument. ## The property that binds The intuitive answer is "the length of the work", and it is nearly right but not the useful form. A service that handles a request in forty milliseconds and can obtain a fresh value whenever it likes puts no floor under anything, however busy it is. A job that runs for six hours puts a six-hour floor under the number **only because it cannot go back for another value while running**. So the property is: > the longest unbroken period a holder keeps one value with no way to obtain another. Call that the holding period. The floor under any estate-wide number is the maximum holding period across the holders you cannot change. ## Three shapes that set a floor | holder | what it does with the value | holding period | |---|---|---| | nightly export | reads it at the start, runs six hours | six hours | | connection pool | authenticates a connection when it opens, keeps it for days | the life of a connection | | worker reading once at boot | loads it into memory at start-up, never re-reads | until the next deployment | | request-path service that re-fetches | obtains a value whenever it needs one | effectively zero | The pool is the one that surprises people, and it is usually the tallest floor in the table. Nothing in a pool is written to go back for a value: a connection opened on Monday is still serving on Friday on the credential it presented when it opened. The holding period is the life of the connection, not the life of a query, and on a stable service that can be weeks. The read-once-at-start worker is the second surprise, for the same underlying reason. Its holding period is set by your deployment cadence, which is an operational fact nobody thought of as a security parameter until the mandate landed. ## Doing the arithmetic out loud Take the numbers above as the estate's actual figures: a six-hour export, a pool whose connections live up to fourteen days, and services that can re-fetch freely. The floor is fourteen days, because that is the longest holder that cannot acquire another value while it is running. Against that floor, a fifteen-minute mandate is not a shorter number — it is three separate pieces of work: 1. Change the pool so a connection is replaced rather than held, or so the pool acquires a value per connection from something that can obtain a fresh one. 2. Change the export so it acquires a value per unit of work instead of once at the start, or accept a longer number for that one holder with an owner and a date on it. 3. Change the boot-time reader so it re-reads on a schedule rather than once. Only after that does fifteen minutes describe anything real. Mandating it first produces one of two outcomes, both familiar: an exception list that swallows the consumers that mattered, or an outage on the first holder whose value lapsed underneath it. ## What the floor is not The floor is **per holder**, not per estate. Human access and the services that can already re-fetch can move to minutes today while the export keeps a longer value, which is why the number is normally set per class with the exceptions named rather than as one figure decided by the slowest consumer. Letting the worst holder set everyone's validity is the most common way a good change gets diluted into nothing. The floor is also not a statement that long-running work is unfixable. Every one of the three shapes above is fixable, and the fix is always the same shape: give the holder a way to obtain a value again without stopping the work. The mechanics of extending or re-obtaining a credential mid-flight, and what happens to work that is already under way when a value lapses, are their own subjects — here the point is narrower and it is the one that decides the argument: **until a holder can go back for a value, its holding period is your floor, and no amount of wanting fifteen minutes lowers it.**

  • The pool authenticates each connection when it opens and keeps connections for days. Why does that set a taller floor than the six-hour export?
    Because nothing in the pool ever goes back for a value. A connection opened on Monday is still serving on Friday on the credential presented when it opened, so the holding period is the life of a connection rather than the life of a query. The export at least ends after six hours; a stable pool can hold one value for weeks.
  • What has to change before a fifteen-minute number describes anything real?
    Each holder has to be able to obtain a value again without stopping: a connection replaced rather than held, a value acquired per unit of work instead of once at the start, a boot-time read replaced by a scheduled one. Until that exists, the mandate produces either an exception list or an outage, and whoever writes the exceptions is setting the real number.
  • Is the floor one number for the whole estate?
    No — it is per holder, and treating it as one figure hands the decision to the slowest consumer. Human access and services that already re-fetch can move to minutes immediately while one long-running job keeps a longer value under a named owner and a date. One estate-wide number set by the worst case is how a real improvement gets diluted to nothing.

saying these in an interview costs you the question

  • Treats fifteen minutes as a setting rather than a change programme.
  • Assumes every consumer re-reads the value it was given.
  • Measures the floor by average job duration instead of the longest holder.
  • Forgets the process that read the value once at boot weeks ago.
  • Lets the slowest consumer set the validity for every other one.