Why is a policy rule repository reviewed, tested and released like application code?
answer
- a rule is production code
- one merge, every team's build
- author, reviewer, history
- fixtures both directions before the gate
- owner entry per rule directory
basics
~20 sA rule is production code: one bad rule blocks every team's builds at once. Review, tests and CI catch it before it reaches a gate, and give each change an author, a reviewer and a history.
solid answer
~50 sRules that gate other people's changes have a wider blast radius than the code they judge. An application team's CloudFormation template affects that team; the rule requiring a minimum backup-retention window on their databases affects every team whose stacks pass that gate, the moment it merges. So the rule repository gets the same machinery as a service: version control, a change proposed as a reviewable diff, a named owner per rule directory who reviews it, a test suite of fixtures the rule must deny and fixtures it must allow, CI that runs those tests on every change, and a release step. That buys three things you cannot get from editing a rule in place: attribution (who changed it and why), reversibility (a revert is a normal change), and evidence that the rule still does what it claims before anyone's build depends on it.
go deeper
Be ready to say plainly why rules live in version control with tests: a rule decides for many teams at once, so a mistake in it is wider than a mistake in the code it checks.
Explain the mechanics you would set up: reviewable diffs, an owner entry per rule directory, a fixture suite run in CI, required metadata on each rule, and a release the gates consume.
Show judgment about review weight. An interviewer expects you to treat a loosening change differently from a new fixture, and to want an impact report against real templates before a new denying rule merges.
Own the argument that the rule repository is production infrastructure with a service owner and an on-call story, and be able to justify the cost of that machinery to a team that just wants a quick rule added.
## The asymmetry that drives everything A policy rule is a small program whose output is a verdict on somebody else's work. Suppose the rule is "managed database instances must keep at least seven days of backups". The document it judges is a CloudFormation template that lives in the application team's own repository and is reviewed by them. The rule lives somewhere else: a rule repository owned by whoever is accountable for that requirement. That separation creates an asymmetry. A mistake in the template hurts one stack. A mistake in the rule hurts every pipeline that consults it — a typo that inverts a comparison either lets every non-compliant database through, or fails every build in the estate. The blast radius of a five-line rule change is larger than that of a five-hundred-line application change, and nothing about the rule's size signals that. This is the whole reason the rule repository is run as a software project rather than as configuration somebody tweaks. ## What "run as a software project" concretely means **History and attribution.** Every rule change is a commit with an author, a message and a diff. Six months later, when a team asks why seven days and not one, the answer is recoverable. A rule edited directly in an enforcement system's console has none of this: no reason, no author, no way to revert precisely. **A named owner per rule.** The repository carries an owner entry mapping each rule directory to a team, not to an individual. It does two jobs at once. It routes *review*: a change to the database rules requires the database platform team's approval. And it routes *questions*: when that rule blocks somebody, the failure output can name the team who decided it. **A test suite.** Fixtures the rule must deny, and — just as important — fixtures it must allow. Tests are what make a rule change reviewable by someone who did not write it. **CI.** The rule repository runs its own pipeline: parse and lint the rules, run the fixture suite, check that every rule carries its required metadata (an id, an owner, a human-readable reason). Mature setups add an impact report: evaluate the proposed rule against a corpus of templates already merged across the estate and print how many would newly be denied. A reviewer seeing "this change newly denies 37 of last quarter's 600 templates" is reviewing something real. **A release.** The rules the gates consume come from a released, identifiable state of the repository rather than from whatever happened to be on the main branch thirty seconds ago. ## What review of a rule looks for Reviewing a rule is not quite reviewing application code. The reviewer is asking: - Does it deny what it claims to deny, *and allow everything else*? Over-blocking is the failure mode that destroys trust in the gate, and it never shows up in a suite full of violations. - Is the failure message something the blocked engineer can act on — the resource, the property, the required value, the owning team? - Which direction does this change move? Tightening a rule creates work for other teams and should be sequenced deliberately. **Loosening** a rule silently removes protection, and deserves the heaviest scrutiny of anything in the repository. - Does the rule say why it exists — the control or requirement it implements — so a future reader can judge whether it is still needed? That last point is why review weight should scale with the change. Adding a fixture, or fixing the wording of a message, is low-risk. Lowering a threshold from seven days to one is the change where the owner's approval alone is the weakest possible control, because the person most motivated to loosen a rule is the person proposing it. ## The alternative, and why teams regret it The common starting point is rules typed into whatever system enforces them, by whoever had access. It works until the first argument. Nobody can say when the rule changed, or who agreed to it, or whether the version running matches the one anybody reviewed. There is no test proving the rule still allows the compliant case, so the first false positive is discovered by a team at 5pm. And because nobody is named, every complaint lands on the platform team, who did not write the rule and cannot judge whether it is right. Treating the rule repository as a software project is not ceremony. It is the minimum that makes a rule defensible to the team it blocks.
- Should every change to the rule repository carry the same weight of review?No, scale it to what the change can do. Adding a fixture or rewording a message cannot change a verdict. A new denying rule creates work across the estate and should be reviewed with its impact report. Loosening a threshold removes protection quietly and is the one case where the rule owner's approval alone is too weak — require a second reviewer who is not the requester.
- A rule was edited directly in the enforcement system rather than in the repository. What has been lost?Everything that makes it defensible: no author, no reason, no reviewer, no test run proving it still allows the compliant case, and no clean revert. You also cannot answer the simplest audit question — what was this rule saying in March — because there is no history to read.
- What metadata should a rule be required to carry before CI lets it merge?A stable identifier, an owning team, a one-line statement of what it requires, the reason or requirement it implements, and the text shown when it denies. CI enforcing those fields is cheap and it is what makes a denial routable to a human later.
A rule is less like a config file and more like a shared library every team links against: nobody reviews their own change to it lightly, because the next build to break is somebody else's.
saying these in an interview costs you the question
- Rules are just configuration, so they do not need tests
- Only the security team reads the rule repo, so review is a formality
- A rule cannot break anything because it only reports
- The rule was urgent, so it was applied directly to the enforcement system
- Reviewing a rule means checking it denies the bad example