skip to content

Before an estate can decide which credentials to replace, it needs an inventory, so what does one row of it have to carry?

level: middleimportance: must knowfreq 52%

answer

  1. a list you can act on
  2. location, class, age, owner
  3. one name, not a team
  4. the row may say no store
  5. consumers are traced, not stored

basics

~20 s

A usable row names the credential, the system it authenticates to, its class, where the value of record is held, a single accountable owner by name, when it last changed, and the copies known to rest outside the store.

solid answer

~40 s

Seven fields make a row actionable. **What it is** and **what it authenticates to**, so you know what breaks if it stops working. **Its class** — shared password, bearer token, signing key, data encryption key — because the class decides what possession of it buys an attacker. **Where the value of record is held**, which is legitimately allowed to say *no store, it lives in the settings repository*, because the untracked values are the ones the inventory exists to surface. **An owner**, meaning one named person accountable for it, not the team that reads it. **When it last changed**, which is usually the most embarrassing column. And **the copies known to rest outside the store**. The owner field is the one that turns the row from a report into work someone will actually do.

code

pseudocode · 12 lines
pseudocode
inventoryRow:
  name            = "nightly report reader"
  authenticatesTo = "reporting datastore, production"
  class           = SHARED_PASSWORD      # or BEARER_TOKEN, SIGNING_KEY, DATA_KEY
  valueOfRecord   = "none - lives in the deployment settings repository"
  owner           = "one named person, accountable for changing it"
  lastChanged     = "unknown"            # honest beats blank
  knownCopies     = [ "settings repository history",
                      "incident runbook page",
                      "two engineer laptops" ]
  # deliberately absent: the live readers of this value.
  # that list goes stale in a week and is traced fresh at replacement time.

go deeper

for a junior

Know that an inventory is a list of rows and that each row names a credential, where it lives, what accepts it, and a person responsible. The list is what makes any later cleanup possible.

for a middle

Explain why each field is there and what the row cannot be used for without it, especially why the owner has to be one named person and why the value of record may legitimately be a repository rather than a store.

for a senior

Argue the boundary: why a durable consumers column is a trap, and why an incomplete inventory published this month beats a complete one promised next quarter.

for a principal

Decide who maintains the rows and what the inventory must be able to prove — and set the standard the rest of the estate is asked to meet, knowing the owner field is a decision you are imposing on people.

## Why the inventory comes before the store An estate with no inventory cannot answer the questions every later decision depends on: which credentials exist, which one would take a service down if it stopped working, who is accountable for any of them. Buying or standing up a secret store does not answer those questions — it gives you a good home for the values you already know about, and says nothing about the ones you do not. So the inventory is the first deliverable, and it is built by reading and interviewing rather than by tooling. ## The fields that make a row actionable 1. **Name and purpose.** A human-readable identity for the credential — what it is for, in the words the team that depends on it would use. 2. **What it authenticates to.** The system that accepts it, and in which environment. This is the field that says what stops working if the value is withdrawn, and it is what makes the row rankable against others. 3. **Class.** Shared password, bearer token, signing key, or data encryption key. Possession of each buys an attacker something different, so the class is what separates a row worth a week from a row worth an hour. 4. **Value of record.** Where the authoritative copy lives today. Crucially, this field is allowed to say *there is no store; the value lives in a configuration repository, and three people have it*. A row that is only permitted to point at a store quietly excludes exactly the population the inventory was built to find. 5. **Owner.** One named person accountable for the value: who decides it may be changed or withdrawn. Not the team, not a distribution list, not *platform*. 6. **Last changed.** A date, or an honest `unknown`. Age is a proxy for how many holders have accumulated and how many people have left since. 7. **Known copies.** The resting places you are aware of, with the standing assumption that unknown copies exist. A row reading `known copies: unknown, assumed non-zero` is more useful than a blank, because it is a claim someone can challenge. ## Owner is the load-bearing field Every other field describes the credential. The owner field describes who will act on it, and without it the row is a report rather than work. A row with a location, a class and an age but no name attached produces a list that everyone reads and nobody acts on, because the first question raised by any proposed change — *may we change this?* — has no addressee. Ownership is also the field that cannot be derived. Location can be found by looking, class by inspection, age from the system that accepts the credential. Ownership has to be **conferred by a decision**, usually by a lead, and often onto someone who did not create the value and does not want it. ## What the inventory deliberately does not try to establish | Question | Answered by the inventory? | Where it belongs | |---|---|---| | Which values exist and where they rest | Yes | This row | | Who is accountable for a given value | Yes | The owner field | | Which processes actually read it at run time | No | Traced separately, immediately before a replacement | | Whether a value has leaked publicly | No | A detection exercise with its own mechanisms | | Which value gets replaced first, and when | No | A separate decision taken over these rows | The third row is the important boundary. It is tempting to add a *consumers* column, and it is tempting because that column is what a replacement actually needs. But a static list of consumers is stale the week after it is written, and the exercise that produces a trustworthy one is done fresh against live evidence at the moment of replacement. The inventory's job is to tell you the credential exists and who owns it; the owner's job, at replacement time, is to find out who is still reading it. ## Building it honestly The first version is built by interview and by reading: ask each team what they need to start their services, read the configuration repositories they deploy from, read the runbooks they follow during an incident, and ask the longest-serving person which values predate everyone. Every one of those sources is partial. What makes the inventory worth having is not completeness — it will never be complete — but that it converts an unbounded, unnamed population into a finite list of rows with names against them, which is the only shape a decision can be taken over.

  • Why is a team name not good enough in the owner field?
    Because a team cannot be asked a question and cannot accept a consequence. When a value needs to change, someone has to weigh the outage risk and say yes; a team name routes that to nobody, and in practice the row sits untouched for another year. One name can be wrong and reassigned, which is still strictly better.
  • The team insists a credential's row cannot be written because nobody knows what reads it. Is the row blocked?
    No. The row records that the value exists, what accepts it, where it rests and who owns it. Finding the live readers is a separate exercise the owner runs immediately before replacing the value, against fresh evidence. Blocking the row on it is how estates end up with no inventory at all.
  • What does a row with lastChanged set to unknown actually tell you?
    That the value is old enough that nobody present remembers changing it, which is a reasonable proxy for a large, unnamed holder population and for departures since. It is a rankable signal in its own right, and much more useful than leaving the column blank and hoping someone fills it in.

saying these in an interview costs you the question

  • Puts a team or a distribution list in the owner field.
  • Drops any value that is not already in a store, so untracked ones stay invisible.
  • Adds a consumers column and treats it as durable.
  • Leaves fields blank rather than recording an honest unknown.
  • Waits for completeness before publishing the first version.
  • Treats the inventory as a document rather than as the input to a decision.