skip to content

Your key register was accurate at hand-over and wrong six months later - which events routinely escape it?

level: seniorimportance: should knowfreq 42%

answer

  1. nobody files a form to mint a key
  2. creation is cheap, retirement is unowned
  3. reorganisations invalidate owners silently
  4. existence derived, meaning captured at creation
  5. reconcile, then assign the findings

basics

~20 s

Three events escape it: keys minted self-service in seconds, systems decommissioned without anyone retiring their keys, and owning teams dissolved in reorganisations. None of the three touches a document, so the register is stale without anybody being careless.

solid answer

~50 s

Creation is cheap and self-service - deliberately, because a team that must file a request will keep key material outside the manager instead - and nothing about that call writes a register row. Decommissioning is worse: the system goes, its key stays in service, and no one owns the task of retiring it. Reorganisations quietly invalidate the owner field on rows nobody touches. Add the one-off migration key that outlived the migration, and a second installation of the manager stood up for one project and never folded in. The fix is structural, not editorial: derive existence and state from the manager on a schedule, make owner and purpose preconditions of creating a key, hang key retirement off the decommissioning checklist, and treat every reconciliation gap as a finding with an owner and a due date.

code

pseudocode · 15 lines
pseudocode
managerKeys  = keyManager.listKeys()      // source of truth for existence
registerRows = register.listRows()

for key in managerKeys:
    row = register.findByKeyId(key.id)
    if row == null:
        report("unregistered key", key.id, key.createdAt)
    else if teamRegistry.find(row.owner) == null:
        report("owning team no longer exists", key.id, row.owner)
    else if row.usedBy is empty and row.state == "in-service":
        report("in-service key with no caller recorded", key.id)

for row in registerRows:
    if keyManager.find(row.keyId) == null and row.state != "archived":
        report("stale row - archive it", row.keyId)

go deeper

for a junior

Know that an inventory goes out of date on its own, and that creating a key is far easier than recording one.

for a middle

Explain which half of a register is derivable from the manager and which half can only be captured from a human at creation time.

for a senior

Name the three events that escape the document - minting, decommissioning, reorganisation - and describe a reconciliation loop whose findings are assigned work rather than a report.

for a principal

Weigh the friction of demanding ownership at creation against the certainty that friction pushes key material outside the manager entirely, and decide which failure you can live with.

## Three events, none of which touch the register A register goes stale without anybody being careless, because the events that change the truth are not events that touch a document. - **A key is minted.** Creating a key is one call and takes seconds, and it is meant to: a team that has to raise a request will generate key material somewhere else instead, which is a far worse outcome than an unregistered key inside the manager. But nothing about that call creates a row. - **A system is decommissioned.** The service is switched off, its hosts are reclaimed, and its key sits in the manager in service, callable, forever. Retiring a key is nobody's task on any decommissioning checklist unless somebody put it there. - **A team is reorganised.** The owner field still holds a name that no longer resolves. Nothing failed, nothing alerted, and the row still looks complete. Two more arrive on a longer cycle: the key minted for a one-off migration that finished years ago, and a second installation of the manager stood up for one project, holding its own keys that were never folded into the register. ## Why the document drifts and the manager does not The manager is a system of record for **existence**: keys are created and destroyed through it, so its list cannot lie about what is there. The register is a document, and a document tells the truth only immediately after somebody edits it. Any design that asks a human to keep a second copy of a derivable fact is a design that decays at the rate things change. So split the register by source and treat the two halves differently: - **Derived half** - which keys exist, their state, creation dates, version counts, the identities the manager's rules admit. Refresh it from the manager; never edit it. - **Human half** - owner, purpose, the systems that call the key, the class of data those systems hold. Capture it at creation and re-confirm it on a period, because nothing can derive it. ## Making it self-maintaining 1. **Reconcile on a schedule.** Walk the manager's key list against the register's rows in both directions. This is a small job and it is the only thing that will ever find an unregistered key. 2. **Make meaning a precondition of creation.** A key created without an owner and a purpose is an orphan the moment its creator moves on. Where the manager cannot enforce it, enforce it in whatever path teams actually use to create keys, and keep that path faster than doing it by hand. 3. **Put key retirement on the decommissioning checklist.** The system's own shutdown is the only moment anyone knows which keys it used. Note: retirement here means denying use, reversibly - destroying material is a separate decision with its own evidence bar. 4. **Turn findings into work.** A reconciliation report nobody is assigned is a second document that goes stale. Each finding gets an owner and a due date, or the loop is decorative. ## What reconciliation produces | finding | what it means | who resolves it | |---|---|---| | key in the manager, no row | minted outside the standard path | the identity that created it, if the manager records one | | row with no key in the manager | the key is gone | register owner: archive the row, never delete it - historical questions need it | | owner value not in the team list | the owning team dissolved | the custodian of last resort | | in-service key with no caller recorded | meaning was never captured or has lapsed | the owner named on the row | ## What this does not fix Reconciliation proves what exists and what is recorded. It cannot invent a purpose for a key whose creator has gone - that is a human investigation, and on an inherited estate it is most of the work. It also tells you nothing about whether a key is still *used*: an in-service key with a row and an owner may have had no caller for a year, and deciding that a key is dead needs different evidence and a deliberately slow procedure. Nor does it say who read any value; that record is kept elsewhere and answers a different question.

  • Which register fields can a reconciliation job fix by itself, and which can it only flag?
    It can fix everything derived: which keys exist, their state, creation dates, version counts and the identities the manager admits. It can only *flag* owner, purpose and the list of calling systems, because nothing in the manager knows them. That is why the human half has to be captured at creation rather than reconstructed by a job.
  • Why should a row be archived rather than deleted when its key is gone from the manager?
    Because questions about the past are asked in the present. If somebody asks next year what protected a set of records written three years ago, the answer lives in the row for a key that no longer exists. Archiving keeps the history and marks the row as not current; deleting destroys the only record of what that key was for.
  • Why not simply require a ticket before anyone may create a key?
    Because friction moves work rather than stopping it: a team blocked at the manager will generate key material on a host and keep it in a file, which is both unowned and uninventoried. The managed path has to stay the fastest path; the requirement to attach an owner and purpose rides along it rather than standing in front of it.

saying these in an interview costs you the question

  • An annual review keeps the register accurate
  • Nobody creates keys without telling the platform team
  • A decommissioned system's keys are harmless left in place
  • The register is a documentation problem, not a process one
  • A full set of populated rows proves the register is current