A policy rule has not denied a single change in twelve months - is it safe to delete?
answer
- zero denials, two opposite causes
- count evaluations, not just denials
- did anything ever match the rule?
- no result is not a violation
- prove it with a known-bad input
basics
~20 sNot yet. Zero denials is ambiguous: it can mean nothing in scope violated the rule, or that the rule never matched anything at all. Compare how often it was evaluated with how often it denied before deciding.
solid answer
~50 sZero denials has two completely different causes that look identical in the same counter. Either the rule is working and everything now complies - often because a platform default satisfies it - or the rule is dead: its selector no longer matches anything, the field it reads moved, or a guard condition leaves it with no result on every input. So the first thing I look at is not the denial count but the evaluation and match counts. A rule that matched thousands of changes and denied none is genuinely quiet, and is a real retirement candidate once I know what else still covers that control. A rule that matched nothing is broken, and deleting it quietly converts a broken control into no control while the dashboard still looks green. I confirm either way by feeding it a deliberately violating input and checking it still denies.
go deeper
Be ready to say that a rule which never denied anything might be working or might be broken, and that you would check whether it still matches any input before touching it.
Explain the stages between an input arriving and a denial appearing, and which counter distinguishes them. Know that a rule whose condition yields no result produces nothing rather than a denial.
Show how you would instrument the engine so quiet rules are diagnosable, and how you decide between fixing a dead selector, retiring a rule whose control moved upstream, and keeping a rare-event guardrail.
Own the standing question of whether a growing rule set still reflects real risk, including the argument that unverified coverage is worse than acknowledged gaps, and who is accountable when a control is removed.
## What a firing count actually measures Every enforcement engine can tell you how many times a rule said no. That number is the most-quoted and least-informative statistic in policy operations, because it is the last step of a chain: an input arrives, the gate evaluates the policy set, some rules match the input, of those some evaluate to a violation, and of those some produce a denial the caller sees. A zero at the end of that chain tells you nothing about where the chain stopped. ## Three firing profiles, and what each says about the rule Read enforcement telemetry as a statement about **the rule**, not about the estate: - **Never fires.** Either the estate complies, or the rule is not looking at anything. These are indistinguishable in a denial count and trivially distinguishable in a match count. - **Fires on every change.** The rule is not a guardrail, it is a wall. Either the standard it encodes was never adopted, or the rule encodes a stricter reading than the standard actually requires. A rule that everything fails is usually wrong about the world rather than right about everyone. - **Always excepted.** Every match ends in a bypass rather than a fix. The rule is describing something the organisation has decided, in practice, not to do - which is a statement about the rule's fit, and it needs a decision rather than another quarter of the same result. Only the first of those is a retirement question. The other two are authoring questions. ## Why a rule goes quiet without anyone noticing Common causes, in rough order of frequency: 1. **The selector stopped matching.** The rule is scoped to a resource kind, a namespace label, a path prefix or a file pattern that no longer describes where the relevant changes live. 2. **The field moved.** The rule reads an attribute at a path that a schema change relocated or renamed. The lookup now yields nothing, the rule body has no result, and - importantly - **no result is not a violation**. In most policy languages a rule whose body cannot be satisfied simply produces nothing; it does not fall through to deny. 3. **A guard swallowed everything.** An early condition intended to skip a narrow set of inputs is written so broadly that it skips all of them. 4. **The control moved upstream.** A platform default, a base template or a provisioning module now sets the compliant value everywhere, so nothing non-compliant ever reaches the gate. This is the genuinely good outcome. ## The instrumentation that makes the question answerable If you can only see denials, you cannot answer this question and you never will be able to. Emit, per rule and per evaluation: how many inputs the rule was considered for, how many it matched, how many it found in violation, and how many of those violations reached the caller as a block. The gap between *matched* and *violated* is the healthy silence; the gap between *considered* and *matched* is where dead rules hide. ## Confirming it directly Telemetry tells you what happened; a fixture tells you what would happen. Keep, for each rule, at least one input that must be denied and one that must be allowed, and run them as tests on every policy-set change. If the must-deny fixture still denies, the rule is alive and the silence is real compliance. If it does not, you have found a dead rule, and the counters were never going to tell you. ## The decision, once you know which case you are in - **Alive and quiet because the control moved upstream.** This is the strongest retirement case, but retirement is still a decision with an owner: name what now guarantees the value, and confirm that thing is itself protected. A default that anyone can change is not a control. - **Alive and quiet because nothing in scope has ever tried.** Keep it. A rule that has never fired against a rare, high-consequence mistake is doing exactly what a guardrail does; you do not remove a railing because nobody has fallen. - **Dead.** Fix the selector or the field path. Deleting a dead rule is defensible only after you know it was dead, because deleting it and deleting a working rule produce the same diff and very different risk. ## The cost of keeping a rule that never fires Rules are not free just because they are quiet. Each one costs evaluation time on every request, occupies a line in the set that a future author must read and decide about, and - worst - contributes to a sense of coverage that nobody has verified. A policy set that has only ever grown is a policy set nobody trusts to be accurate, which is how organisations end up with hundreds of rules and no confidence in any of them. That is the argument for a standing review, not for reflexive deletion.
- What single piece of telemetry would you add so this question is answerable next time?Per-rule counters that separate the stages: how many inputs the rule was considered for, how many it matched, and how many it found in violation. Denials alone cannot distinguish a compliant estate from a rule whose selector matches nothing. Once matched-but-not-violated is visible, healthy silence and dead silence stop looking the same.
- The rule matched thousands of changes and denied none. Does that alone justify deleting it?No. It justifies asking why. Usually something upstream - a base template, a provisioning module, a platform default - now sets the compliant value, so violations never reach the gate. Retire the rule only if that upstream guarantee is itself protected against change. If anyone can edit the default, the rule is the thing keeping it honest.
- A colleague says a rule that never fires proves the estate is clean. What is wrong with that?It confuses a property of the rule with a property of the estate. The rule only sees inputs that reach the gate and match its selector; resources created outside that path, or under a field name the rule no longer reads, are invisible to it. Silence is evidence only once you have shown the rule is still looking.
saying these in an interview costs you the question
- Treats zero denials as proof the estate is compliant
- Deletes the rule without checking it still matches anything
- Reads denial count and evaluation count as the same signal
- Assumes a rule with no result falls through to deny
- Keeps every rule forever because deleting one feels risky