skip to content

You inherit a key manager holding a hundred keys with only names - which facts must a key register record about each one?

level: middleimportance: must knowfreq 55%

answer

  1. meaning the manager does not hold
  2. one row per key
  3. owner, purpose, protected systems, state
  4. owner is a team, not a person
  5. measured by an hour test

basics

~10 s

A key register records, per key: one owning team, what the key is for, the systems and data it protects, when it entered service, its current state, and which identities may use it.

solid answer

~50 s

The register holds the layer of meaning the manager itself does not have. A key manager knows a key exists, when it was created, which versions it holds and which callers its rules admit; it has no idea why anyone made it. So per key I want an **owning team** (never an individual), a one-line **purpose**, the **systems and stores that call it**, the **class of data** those systems hold, the **date it entered service**, its **state**, and the **identities granted use of it**. Half those fields are derivable from the manager and should never be typed by hand; owner, purpose and data class cannot be derived at all and have to be captured at creation, the one moment somebody still knows them. And the register is measured by whether someone can answer a question about a named key within the hour - not by how many rows are full.

code

json · 10 lines
json
{
  "keyId": "k-2291",
  "owner": "team-payments-platform",
  "purpose": "protects card-holder records written by the settlement service",
  "usedBy": ["settlement-service", "nightly-reconciler"],
  "dataClass": "restricted",
  "inServiceSince": "2024-03-11",
  "state": "in-service",
  "grantedTo": ["svc-settlement", "svc-reconciler", "ops-break-glass"]
}

go deeper

for a junior

Know that a key needs a recorded owner and a recorded purpose, and that the key manager's own list of key names is not an inventory.

for a middle

Explain which fields the manager can supply itself and which only a human can, and why the owner value must point at a team rather than an individual.

for a senior

Show you have kept a register true in a live estate: meaning captured at creation, state derived from the manager, and the register tested by answering a real question about a real key.

for a principal

Treat the register as the input to a decision - which keys the organisation is willing to keep paying for, what an unowned key costs, and who is accountable for the answer when an external review asks.

## What the manager knows and what it does not A key manager, whatever its shape, can always tell you that a key exists, when it was created, which versions it holds and which callers its own rules will accept. It cannot tell you why anyone created it, which team answers for it, what stops working if it is denied, or how bad it would be if the material escaped. Those facts are not derivable from key material. They were true in the head of whoever ran the creation step, and they leave when that person does. A **key register** is the artefact that holds them: one row per key, maintained so that questions asked *key-first* have answers. "Here is a key - what is it for, who owns it, what does it protect?" The manager's own list of keys answers a different question, "what exists", and being able to answer that is not an inventory. ## The fields that earn their place | field | the question it answers | where it comes from | |---|---|---| | `keyId` | which key this row is about | the manager | | `owner` | who answers for it and approves its retirement | set at creation | | `purpose` | why it was created | its creator | | `usedBy` | what stops working if it is denied | creator, kept current by the owner | | `dataClass` | how bad an exposure would be | the owner of the system holding that data | | `inServiceSince` | how far back its ciphertext could reach | the manager | | `state` | whether it may be used today | the manager | | `grantedTo` | which identities the manager will accept a call from | the manager's own rules | Two properties of that list matter more than its exact contents. - **Half the fields are derivable and half are not.** Existence, creation time, state and the grant list come out of the manager and should never be maintained by hand - a hand-typed copy is wrong the first time anyone changes anything. Owner, purpose and data class cannot be derived at all, which is why they must be captured at creation rather than reconstructed later. - **The register records what a key protects, not how it protects it.** How one key protects another, and what changing a key version does to stored ciphertext, are separate subjects with their own answers. This row only has to name the systems and stores whose data would be unreadable, or whose signatures would be unproduceable, without this key. ## Ownership is a duty, not a name The field most often filled in wrongly is the owner, because it gets an individual's name. An individual is a contact, not an owner, and contacts evaporate. The owner value has to name something that: 1. still exists after a reorganisation, and can be checked against an independent list of teams; 2. can be reached without knowing any particular person's name; 3. carries a real duty - answering what the key protects, approving its retirement, and paying for its replacement. If nobody can be made to do those three things for a given key, that key is unowned however the field reads. That is the honest state of most inherited registers: rows filled, duty unassigned. ## What the register is measured by Not completeness. A hundred fully populated rows are worth nothing if the answers in them are six months stale. The measure is an **hour test**: pick a key at random and see whether someone can say what it protects, who owns it and what breaks if it is denied, within the hour and without a search party. A team that measures completeness gets completeness; a team that runs the hour test gets a register that survives contact with an external review. ## What this register deliberately does not answer Four adjacent questions belong to other artefacts, and conflating them is how a register grows until nobody maintains it: - **Who actually read a value, and when.** That is the access record the store keeps, with its own retention story. - **Every copy of a credential living outside any store.** That is a different and much larger inventory problem. - **Which consumers still hold an old credential before it is withdrawn.** That enumeration belongs to replacement work. - **What to do once a key is believed exposed.** The ordering of re-protection is its own subject; the register is the *input* that work consumes, which is exactly why it has to exist before the day it is needed.

  • Why is an individual engineer's name a poor value for the owner field?
    Because ownership is a duty - answering what the key protects, approving retirement, funding replacement - and an individual cannot be held to it after they change team or leave. A team identifier survives both, and can be checked against an independent list of teams, so a dissolved owner is detectable rather than silently wrong.
  • Which fields should the manager supply automatically rather than a human?
    Existence, creation date, current state, version count and the set of identities the manager's rules admit. All of those change without anyone editing a document, so a hand-maintained copy is wrong almost immediately. Purpose, owner and the class of data protected cannot be derived and must be captured when the key is created.

saying these in an interview costs you the question

  • The manager's list of key names is the inventory
  • Naming one engineer as the key's owner
  • Recording algorithm and version count but not what the key protects
  • Treating a fully populated register as proof it is true
  • Assuming tight access control makes an inventory unnecessary