skip to content

Your census of a shared credential's consumers comes from the store's read records — which real holders will that list miss?

level: seniorimportance: must knowfreq 54%

answer

  1. evidence of reads, not holders
  2. window shorter than the cadence
  3. read once, held ever since
  4. one identity, many machines
  5. copies outside never read at all

basics

~20 s

Read records are evidence of reads, not a register of holders. They miss anything whose cadence exceeds the observation window, anything that read once and still holds the value, machines hiding behind one shared identity, and copies living outside the store.

solid answer

~50 s

The store's records are the best starting point available, and they systematically under-count. Four blind spots matter. A job whose cadence is longer than your window — a quarterly extract against a forty-day look-back — simply has not read yet. A long-running process that read at start-up months ago holds the value and will not read again until it restarts. A fleet reading under one identity appears as a single line, so you learn that something reads, not how many things must move. And a copy that lives outside the store never reads it, so nothing records it. There is an over-count too: an identity that still reads out of habit but no longer uses the value. Treat the output as a list of leads with an owner attached to each, and assume a residual you have not seen.

code

pseudocode · 18 lines
pseudocode
window = 40 days          # covers a monthly cadence (31 days) with slack
census = empty map

for record in store.readRecords(credential: "warehouse-read-only", since: now - window):
    entry = census.getOrCreate(record.identity)
    entry.lastReadAt = max(entry.lastReadAt, record.at)
    entry.sourceAddresses.add(record.from)
    entry.readCount = entry.readCount + 1

for entry in census:
    entry.owner = teamThatDeploysIdentity(entry.identity)   # asked, not recorded
    entry.holderCount = "unknown"                           # one identity may front many

# not visible to the loop above, and added by hand:
#   quarterly extract   -> cadence 92 days, longer than the window
#   long-running worker -> read once at start-up, holds the value since
#   worker fleet        -> 30 processes sharing one reading identity
#   pasted copy         -> lives outside the store, never reads it

go deeper

for a junior

Know that the store can record who fetched a value and when, and that this record is where a search for consumers begins.

for a middle

Explain why the record under-counts: cadences longer than the window, start-up-only reads, shared identities, and copies that never fetch at all.

for a senior

Show the working — name the window you chose and why, push each identity back to an owner, and carry the residual unknown into how you sequence the change.

for a principal

Decide what the estate must require so that this census is cheap next time, and what level of residual uncertainty you are willing to fund coordination around.

## What a read record actually is A store that serves credentials generally records that a value was served: which identity asked, when, from where, and which value. That is a genuinely useful artefact, and for a credential nobody can describe from memory it is usually the only evidence that exists. The mistake is upgrading it in your head from **evidence of reads** to a **register of holders**. It is the first and never the second, and the gap between them is where a replacement goes wrong. ## The four blind spots **1. A cadence longer than the observation window.** You watch for forty days — enough to cover a monthly job, which can leave a thirty-one day gap, with nine days of slack. A quarterly extract can go ninety-two days between reads and produces nothing at all in that window. The fix is arithmetic, not cleverness: the window must exceed the longest cadence you believe exists, and you should assume a cadence you do not know about — an annual close, a disaster-recovery exercise, a seasonal report. **2. A holder that read once and kept the value.** Many processes fetch at start-up and hold the value for the life of the process. If that process last restarted nine months ago, it has been a holder every day since and has generated exactly one record, outside any sane window. It reappears in the records only when it next restarts — which may be *after* your change, which is exactly when it fails. **3. A fleet behind one identity.** Thirty workers authenticating as the same identity produce one line in your census. You learn that something reads on that identity, not that thirty processes must each take the new value. The count you need — how many holders must move before the old value can be withdrawn — is the thing the record is least able to give you. **4. A copy that never reads the store.** A value pasted into a team's own configuration, typed into a downstream system by a person, or carried in someone's notes has no read to record. It is invisible by construction, and no amount of widening the window finds it. These are found by asking owners, or by breaking them. One variant deserves its own line: where a single component reads the value and distributes it onward, the record names that component, and the things actually holding the value are behind it. ## The over-count, which is smaller but real Not everything that reads is a consumer. A health check, a configuration reconciler, or a deployment step may fetch the value on a schedule without anything downstream ever using it. Those inflate the census and waste coordination effort. They are cheap to resolve — ask the owner what it does with the value — and much less dangerous than the under-count. ## How to use the census honestly | The census says | What that licenses | What it does not license | |---|---|---| | This identity read yesterday | Coordinate a move with its owner | Assuming it is one process | | No read from this identity in the window | Deprioritise it | Concluding nothing holds the value | | Reads from three source addresses | Suspect at least three holders | Believing there are only three | | No record anywhere for this credential | Suspect every copy is outside the store | Concluding it is unused | The practical procedure is: 1. Choose a window longer than the longest cadence anyone can name, and say what you assumed. 2. Group reads by identity, then push each identity back to a team, and ask that team how many processes run as it. 3. Ask each owner one question the records cannot answer: does anything hold this value without fetching it? 4. Carry the residual explicitly — "we believe there are holders we have not seen" — into how the change is sequenced, rather than pretending the list is complete. ## The direction that must not be reversed A complete-looking census tempts people into a flag day. The census is a starting point for a staged change and never a certificate that nothing else holds the value; that certificate, where it exists at all, comes from watching the old value stop being used before it is withdrawn. Note also that the records tell you about reads *from the store*, not about use of the credential *at the downstream system* — those are different observation points, and a holder that fetched long ago is busy at the second while silent at the first. ## Why an interviewer asks it This question separates people who have run a replacement from people who have read about one. The weak answer is "pull the access records, that is your list". The strong answer accepts the records gratefully, names the specific populations they cannot see, states the window assumption out loud, and plans for the holders that will surface only when the old value stops working.

  • How long an observation window would you choose, and how do you justify it?
    Longer than the longest cadence anyone can name, plus slack — forty days covers a monthly job's thirty-one day gap, and misses a quarterly one entirely, so a quarter-plus window is the honest minimum where finance or compliance-style periodic jobs exist. State the assumption in the plan, because the window is the single number that decides which consumers the census can see at all.
  • The records show one identity reading from twelve source addresses — what have you learned?
    That at least twelve holders exist behind that identity, not that exactly twelve do. Addresses can be shared, re-used or hidden behind an intermediary, and a holder that read once from a machine since replaced contributes none. It is a floor on the count, useful for sizing the coordination effort and useless as a completion signal.
  • Which consumers will the census never find, however long you watch?
    Anything holding a copy that does not fetch from the store: a value pasted into a team's own configuration, typed into a downstream system by a person, or passed along in a message. No read exists to record. Those surface by asking owners, or by failing when the old value is finally withdrawn — which is an argument for sequencing rather than a flag day.

A visitors' book at the front desk tells you who signed in this month. It does not list the people who took a key years ago and let themselves in ever since.

saying these in an interview costs you the question

  • Calls the read records a complete list of holders
  • Picks an observation window shorter than a known job's cadence
  • Reads one identity as exactly one running process
  • Forgets processes that fetch once at start-up
  • Expects a copy outside the store to appear in read records
  • Treats every reading identity as an actual user of the value