skip to content

An external review names one key in your manager and asks which data it protects - what must the register already carry?

level: seniorimportance: should knowfreq 41%

answer

  1. asked key-first, maintained system-first
  2. record the callers, not just the purpose
  3. bounded by system and by date
  4. grants are wider than actual callers
  5. archive retired rows, never delete them

basics

~20 s

The systems and stores recorded as calling that key, the date it entered service, and the class of data those systems hold. Without the caller list the honest answer is "we do not know", and it cannot be reconstructed reliably afterwards.

solid answer

~40 s

The question arrives key-first, but estates are maintained system-first - teams know which key their service uses, and nobody keeps the reverse index. So the register has to carry it. With `usedBy`, `inServiceSince` and a data class from each of those systems' owners, you can give a truthful, bounded answer: *these two services wrote to these stores under this key from this date onward, and those stores hold this class of data.* That bound is at system and date granularity, not per record, and offering more precision than you have is worse than the bound. Note what does not substitute for the caller list: the identities the manager's rules admit tell you who **may** call the key, which is nearly always a wider set than who does, and it drifts on its own.

code

pseudocode · 13 lines
pseudocode
answerWhatItProtects(keyId):
    row = register.findByKeyId(keyId)          // includes archived rows
    if row == null:
        return "unknown - this key is not in the register"

    systems = row.usedBy                       // maintained by the key's owner
    if systems is empty:
        return "unknown - no caller was ever recorded for " + keyId

    classes = systems.map(s => systemOwner(s).dataClass)
    return systems + " wrote under " + keyId
         + " from " + row.inServiceSince + " onward, holding " + classes
         + "; earlier data sits under " + row.replaces

go deeper

for a junior

Know that a key's name is not evidence of what it protects, and that somebody has to write the callers down in advance.

for a middle

Explain why the answer is bounded by system and by date rather than per record, and why the permitted identities are a wider set than the actual callers.

for a senior

Produce the bounded statement for a named key from the register alone, including the predecessor key for older data, and say honestly where the bound came from.

for a principal

Decide what the estate must be able to answer about any key, and on what deadline, then fund the maintenance of the reverse index that makes it possible.

## The question arrives in the direction nobody maintains Every team can tell you which key their service uses. Almost nobody can tell you, given a key, which services use it - because that index is never a by-product of anything. It exists only if somebody maintains it deliberately. That asymmetry is the whole reason this question is hard, and it is why it cannot be answered by improvising on the day: at that point the only people who knew are the ones you are trying to find. ## What a truthful answer looks like An answer to "what does this key protect?" is bounded on two axes and is honest about both: - **By system** - the services and stores recorded as calling the key. Not "these records", which no register knows, but "everything these two services wrote to these two stores". - **By time** - from the date the key entered service. Anything written earlier sits under a predecessor key, which is a different row in the register and possibly a different answer. So a good answer sounds like: *"This key has been in service since March 2024. Two services call it - the settlement service and the nightly reconciler - writing to the settlement store and the reconciliation archive. Those hold card-holder records, classified restricted. Data older than that date was written under the key this one replaced."* Precision you do not have is not a favour to the reviewer; a bound you can defend is. ## The three inputs, and where each comes from 1. **The caller list** (`usedBy`), maintained by the key's owner and confirmed against the systems themselves. This is the field that decays fastest and the one the whole answer rests on. 2. **The in-service date**, derived from the manager. It is what converts "this data" into "this data since this date". 3. **The data class**, supplied by the owner of the system holding the data, not by the key's owner. Classifying data is its own discipline with its own owners; the register only carries the resulting label so that impact can be stated without a second investigation. ## What is not a substitute for the caller list | artefact | what it proves | why it is not enough | |---|---|---| | the identities the manager's rules admit | who **may** call the key | almost always wider than reality, and it drifts as grants are added and never removed | | the key's name | what somebody intended, once | names outlive purposes; a key named for a project may now serve three others | | the store's record of calls | who **did** call it | a different artefact with its own retention; it answers a different question and only reaches back as far as it was kept | The grant list is still worth reading: it is a superset, and a superset is a useful starting point when the caller field is empty. But presenting it as the answer overstates the blast radius in one direction and, where a caller uses the key through some shared identity, understates the number of systems in another. ## Retired rows are part of the answer Because the question is often historical - what protected records written four years ago - the register must keep rows for keys that no longer exist, marked as archived rather than deleted. A clean-up that removes rows for destroyed keys deletes the only record of what those keys were for, and the estate loses the ability to answer any question about its own past. ## The hour test on this exact question The practical measure of a register is: pick a key at random, and time how long it takes to produce the bounded statement above. Under an hour means the register is real. A week means you have a document, not an inventory - and the difference only ever shows up when someone is waiting for the answer. ## Where this stops This is the *readiness* half. Deciding what to do once a key is believed exposed - the order in which material is replaced, which systems are re-protected first, and what a new key version does and does not undo - is a separate subject. So is the record of who actually read a given value. The register's job is to be the input those other efforts consume, complete enough that nobody is reconstructing it under time pressure.

  • Why is the set of identities the manager will accept a call from not the same as the caller list?
    It is the set permitted, not the set active. Grants are added for a migration and never removed, so the permitted set drifts wider over time; meanwhile a shared identity can hide several distinct systems behind one entry. As a starting point it is useful and deliberately over-inclusive; as an answer it is wrong in both directions.
  • Data written four years ago predates this key. How does the register still answer for it?
    Through the archived row of the key this one replaced, and a `replaces` link between them. That chain is the only thing that turns a key-first question about the past into an answer. It is also why rows are archived rather than deleted when a key is destroyed.

saying these in an interview costs you the question

  • The key's name tells you what it protects
  • We can reconstruct the callers later if we need to
  • The list of permitted identities is the list of callers
  • Deleting rows for destroyed keys keeps the register tidy
  • Only the current key matters when asked about old data