skip to content

Your credential inventory was accurate the week it was built and is stale six months on, so what standing obligation, as the lead, keeps it true?

level: principalimportance: nice to knowfreq 27%

answer

  1. a snapshot of a moving estate
  2. stop the backlog growing first
  3. ride on records teams already keep
  4. ask questions, do not request ticks
  5. drill the claims, not the document

basics

~20 s

Make the row a precondition rather than a report: no credential enters production without an owned row, attach rows to the ownership records teams already maintain, and make periodic re-confirmation ask questions instead of requesting a tick.

solid answer

~50 s

An inventory decays because it is a snapshot of a process that never stopped. Three obligations, in order of leverage. First, make the row a **precondition**: a credential that has no owned row does not enter production, so new rows are true by construction — the cost is friction at creation and somebody to hold the line. Second, **attach the rows to something teams already maintain**, usually the ownership record for each service, so the inventory decays no faster than the thing it rides on rather than rotting in a separate document nobody owns. Third, **re-confirm periodically with questions, not ticks**: ask the owner to name the copies and the last change date, because a yes/no attestation gets rubber-stamped. And pick a claim the inventory must support, then drill it — an untested inventory is a document, not a control.

go deeper

for a junior

Know that an inventory goes out of date on its own, because the estate keeps changing after the list is written, and that keeping it current is somebody's explicit job.

for a middle

Explain why a periodic refresh is not maintenance, and why attaching rows to records a team already keeps decays more slowly than a standalone document.

for a senior

Design the re-confirmation so it asks questions the owner must look up rather than requesting a tick, and be able to say what each obligation leaves untouched.

for a principal

Choose the combination and defend the stopping point: new values born owned, rows riding on existing records, and a small set of testable claims drilled on a quiet week rather than a promise of perfect currency.

## Why it went stale The inventory was a snapshot. The estate it described did not stop moving: services were created, contractors joined and left, credentials were issued for one experiment and never withdrawn, teams reorganised and rows lost their owners without anyone touching the document. Decay here is the normal outcome, not a failure of diligence, and any plan that depends on people remembering to update a document will produce the same state again in six months. So the question is not how to refresh it. It is which **standing obligation** makes the inventory a by-product of work that already happens. ## The options a lead is actually choosing between | Obligation | What it buys | What it costs | What it does not touch | |---|---|---|---| | Row is a precondition for production | New rows true at creation | Friction at creation; someone must police it | Everything that already exists | | Rows attached to each service's ownership record | Decays no faster than that record | Uneven quality across teams | Credentials belonging to no service | | Periodic re-confirmation by the owner | Catches drift and lost owners | Rubber-stamping unless it asks real questions | Values nobody has a row for | | A central team maintains it | Consistency and one standard | A standing headcount; teams disbelieve a list they did not write | Its own staleness between passes | None of these is sufficient alone, and the usual mistake is choosing exactly one. The combination that survives contact with an estate is: **precondition for new values, carried on the records teams already maintain, re-confirmed on a cadence that asks questions, with a small central function that owns the standard rather than the data.** ## Make the row a precondition The highest-leverage move is the one that stops the backlog growing. A credential that is issued without an owned row is a row you will reconstruct later at ten times the cost, so the obligation is: it does not reach production without one. Be honest about the two costs. It adds friction at the exact moment somebody is trying to ship, and it only works if someone will actually hold the line when a delivery date is at stake. Note also what it does not do: it does nothing for the inherited population, which still has to be worked through separately. ## Re-confirmation has to ask a question Asking an owner to confirm their rows annually produces a wall of confirmations and no information, because confirming is the cheapest possible action and disagreeing is the expensive one. Re-confirmation earns its place only if the answer requires the owner to look: - **Name the places a copy of this value currently rests.** - **When did it last change, and what happened?** - **If this value were withdrawn tonight, what breaks?** - **Who takes this row if you leave next month?** Those produce edits. "Still accurate?" produces a tick. ## What you should not promise Do not promise that automated discovery will keep it true. Searching for credential-shaped material is a separate subject with its own mechanisms, and whatever it is worth, it cannot supply the field that matters most: ownership cannot be discovered, only conferred. A search finds candidates; a person still has to decide who is accountable for each one. An inventory whose maintenance plan is "the tooling will find them" reliably ends up with rows that have locations and no names. ## Define what true enough means, then test it Staleness is not a binary, so pick the claims the inventory has to support and make them measurable. For example: 1. For any credential named at random, a named person answers a question about it within one working day. 2. For any departure, the list of values that person could reach is producible in an afternoon. 3. For any value found somewhere it should not be, the addressee is known within an hour. Then drill them, on a quiet week, against rows picked at random. The drill is what separates an inventory from a document about an inventory, and it is the thing that tells you which of the obligations above is actually holding. It is also the answer you give when an external review asks who is accountable for a given value and how quickly you can say so: not a page, but a demonstration. The final judgement a lead owns is how much of this to buy. Perfect currency across an estate is not purchasable at any reasonable price. What is purchasable is that new values are born owned, that the rows ride on records teams already keep, and that the three claims above hold when tested — and that is a defensible place to stop.

  • Which obligation do you put in place first if you can only do one this quarter?
    The precondition on new credentials, because it stops the backlog growing and every later pass over the inherited population then works against a fixed target rather than a moving one. It is also the cheapest to state and the easiest to check, though it needs someone willing to enforce it under delivery pressure.
  • A team argues the inventory is security's job, not theirs. How do you answer?
    Concede the standard and refuse the data. A central function can own the fields, the cadence and the drills; it cannot know which values a team's services need or who on that team should be accountable. A centrally written list is also the one teams trust least, because nobody who reads it wrote it.
  • How do you know the obligations are working without waiting for an incident?
    Drill the claims on a quiet week: pick rows at random and see whether a named person answers within a day, and time how long producing a departing engineer's reachable-value list actually takes. The measurements are cheap and they fail loudly, which is the point.

saying these in an interview costs you the question

  • Plans a periodic refresh and calls that maintenance.
  • Relies on automated discovery to supply the owner field.
  • Uses a yes-or-no attestation that owners can tick without looking.
  • Keeps the inventory as a separate document nobody's work touches.
  • Assumes a central team can know who should own each value.
  • Treats perfect currency across the estate as an achievable target.