Why does a policy rule's test suite need near-miss allow cases, not just deny cases?

## What a near-miss case is A policy rule draws a boundary through the space of possible changes. A **near-miss test case** is an input that sits as close to that boundary as you can get while still being on the allowed side — or, symmetrically, an input that differs from an allowed one by exactly the field the rule cares about. It is the case where a slightly-wrong rule and a correct rule disagree. Make it concrete with a rule that says: an instance may only be created with an approved family, and only in an approved region. Approved families are the general-purpose `m` family; approved regions are `eu-west-1` and `eu-central-1`. The obvious deny case is an unapproved family in an unapproved region — it is wrong on both axes, and almost any rule you write will refuse it. The near misses are the interesting ones: - approved family, approved region — must be allowed; - approved family, unapproved region — must be denied, **because of the region**; - unapproved family, approved region — must be denied, **because of the family**; - approved family and region, but the resource comes from a shared module rather than being declared directly — must still be allowed; - an approved resource sitting in a change that also creates ten unrelated resources — must still be allowed. ## Why deny-only suites give false confidence A test suite made only of deny cases tests one direction of the rule. It answers "can this rule say no?" A rule that denies **everything** passes every one of those cases. So does a rule whose condition is subtly too broad — one that matches on the region field being present rather than on its value, say, or one that checks the family list with a typo so that no family is ever approved. The direction that is not tested is the one that actually costs you something. A rule that fails to block a bad change costs you a misconfiguration you would probably have caught elsewhere. A rule that blocks a good change costs you the gate itself: the team on the other side raises a ticket, gets an exception, and the next time someone proposes a rule the answer is no. In policy work the allow cases are the ones that protect the programme, and they are the ones authors skip, because writing them feels like testing that nothing happens. ## Where the cases come from The strongest allow cases are not invented. They are captured from changes that have already been reviewed and merged — for this rule, the plan documents from the last few dozen merged pull requests that create instances. Each one arrives with its expected verdict attached for free: a human approved it and it shipped, so the rule must not block it. That turns a guess about what "should" pass into a recorded fact about what did. Deny cases usually still have to be written by hand, because non-compliant changes rarely survive to be merged. That asymmetry is fine — the point is that the side of the boundary you are most likely to get wrong is the side where real evidence exists. ## Organising them Write the cases as a table rather than as a pile of separate tests: one row per fixture, each row naming the input, the expected outcome and the reason. A table makes the boundary visible as a shape — you can see at a glance that you have an allow row and a deny row for each axis, and that you have no row at all for the third axis you just added to the rule. It also makes the suite cheap to extend when the approved-region list changes, which it will. ## What good looks like in an interview Saying "I test both the deny and the allow path" is the baseline. What separates a good answer is naming the specific near misses for the rule in front of you, saying where the allow fixtures come from, and stating the consequence in the right direction: a rule that over-blocks is a bigger operational problem than a rule that under-blocks, because it burns the credibility you need to enforce anything at all.