What does a rule requiring cost-centre and on-call fields in a service catalog entry actually check?
answer
- it never opens the source tree
- shape of one declarative file
- required keys, closed value sets
- presence is not the same as truth
basics
~20 sA required-metadata rule checks only that named fields exist in the catalog entry and hold a value from an allowed set. It proves the entry is well-formed and names an owner, not that the values are true.
solid answer
~50 sIt is a shape check over a declarative file that the service commits alongside its code - typically a `service.yaml` or catalog entry. The rule asserts that a fixed list of keys is present, and that each value comes from a closed set: a cost-centre code that finance recognises, an on-call rotation identifier that exists in the rota system, one of the defined data classifications. It reads no application code at all, so it can say nothing about what the service does or how it is built. What it buys is a nameable human owner and a small set of labels every other policy can key off - a licence rule, an evidence requirement, an incident router. Its limit is that presence is not truth: a plausible-looking wrong value passes, so validate against enumerations exported from the systems of record rather than accepting free text.
go deeper
Be ready to say exactly what the rule inspects - named keys in a declarative catalog file, and whether each value sits in an allowed set - and to name one thing it cannot possibly know.
Expect to be pushed on validation. Explain why values should be checked against enumerations exported from the rota and finance systems rather than a format pattern, and what a constrained vocabulary buys the rules downstream.
Show you have operated this. Describe how required fields decay after they are written, and what separate mechanism you would run to catch an entry that passes while pointing at a team that no longer exists.
Own the vocabulary question: who defines the closed sets, how often they are reviewed, and what it costs the organisation when every team is allowed to invent its own labels for the same thing.
## What the rule is A required-ownership-metadata rule is one of the smallest useful policies a platform team writes. Its subject is not the running service and not its source code - it is a **declarative file the repository carries about itself**, usually called something like `service.yaml`, and usually the same file that a central service catalog ingests. The rule says: this file must exist, it must contain these keys, and each key's value must come from this set. A typical required set is three fields with three different consumers: - **cost-centre** - who pays for this service's infrastructure. - **on-call rotation** - who is paged when it breaks. - **data-classification** - what kind of data it holds, which is what most downstream policy branches on. ## What "required" means precisely There are two distinct assertions hiding in the word required, and interviewers probe the gap between them: 1. **Presence** - the key exists and is non-empty. This is a schema check, and it is trivially satisfiable. 2. **Membership** - the value is one of a finite, externally-defined set. This is what makes the field worth anything. A rule that only does (1) teaches teams to type something. A rule that does (2) compares the value against a list that comes from somewhere authoritative: the finance system's cost-centre codes, the rota system's team identifiers, the security team's classification vocabulary. The difference in outcome is large and cheap to obtain. ## What it proves, and what it cannot It proves the entry is well-formed and that a value from the right vocabulary was chosen. It does **not** prove: - that the named rotation is staffed, or that anyone on it has heard of this service; - that the data classification matches the data the service actually stores; - anything at all about the code, the dependencies, the pipeline or the deployment. That last point is the leaf's whole shape: this is a metadata gate. It is fast, it never opens the source tree, and it is honest only if you describe it that way. Calling it a "service health check" or "security review" oversells it, and someone will eventually rely on that oversell. ## Why it is worth having anyway Because it is the join key. Almost every other rule in a policy estate needs to know something about the subject that cannot be derived from the artifact: is this thing customer-facing, does it hold regulated data, who do I tell when it fails a check. Without a mandatory, vocabulary-constrained entry, every one of those rules has to guess or apply itself uniformly, which means applying itself at the strictest setting everywhere and being resented for it. It is also the cheapest possible place to establish that a service has a human owner. Enforcing that at creation costs the team nothing - the scaffolder fills the fields in - while retrofitting owners onto an estate that never required them is a multi-quarter archaeology project. ## Where the value comes from matters The common weak implementation is a regular expression: the cost-centre must match `CC-[0-9]{4}`. This accepts `CC-0000` forever. The strong implementation resolves the value against the system that owns it. Where you cannot do that inside the gate, do it out of band and let the gate compare against a periodically-refreshed list; a slightly stale enumeration is still enormously better than a format check. ## Common failure to name in an interview The field decays silently. The rotation was real when it was written and the team has since been reorganised out of existence. The gate stays green because the gate only ever asked whether the value was well-formed at the moment of the change. Detecting that requires reconciliation against the rota system on a schedule - a different mechanism from the merge-time gate, and worth saying out loud so nobody mistakes a green check for a live owner.
- How do you stop a team satisfying the rule by typing a plausible but fake cost-centre?Validate against an enumeration exported from the system that owns the value - the finance cost-centre list, the rota system's team identifiers - so the rule compares against real identifiers instead of a format. A regex accepts anything well-formed, so free-text fields drift immediately and permanently.
- Why put this metadata in the repo rather than only in a central catalog?Because the gate runs where the change happens. A file in the repo travels with the change, is reviewed in the same pull request, and gives the rule a subject at the moment it has to decide. The central catalog can ingest from that file; the reverse ordering leaves the gate with nothing local to evaluate.
- A team asks why the platform, not they, should own the list of valid data classifications.Because the closed set has to be defined once by whoever owns the consequences - security, legal, finance. If teams can extend the vocabulary, you get four spellings of the same classification and no downstream rule can group services reliably. Teams choose a value; they do not invent new ones.
It is the form validation on a registration page: it can insist you typed a postcode in the right format, never that you live there.
saying these in an interview costs you the question
- Claims the check proves the listed owner is correct
- Says the rule must read the service's code
- Accepts free-text owner fields as good enough
- Assumes a green check means the rotation is staffed