Your audit-log retention rule duplicates a control your nightly benchmark run already checks - which one survives?
answer
- same number, different positions
- one refuses, one reports
- compare coverage sets, not rule text
- gate cannot see out-of-band change
- keep the superset, record the decision
basics
~20 sUsually both survive, because they are not the same control. The gate rule is preventive and stops a non-compliant change before it lands; the nightly benchmark is detective and reports live systems afterwards. Neither covers the other's blind spot.
solid answer
~50 sThe two checks read the same standard but occupy different positions. The gate rule is preventive: it sees a proposed change on its way in, and only if that change goes through the gate. The benchmark run is detective: it sees whatever is live and reachable, including everything created outside the pipeline, but only on its schedule and only as a report. So I would not treat them as duplicates to be deduplicated; I would put the engine's firing counts next to the benchmark's pass/fail results and read the four combinations. Never fires plus all-pass means the control is satisfied everywhere and the preventive rule is a retirement candidate. Never fires plus benchmark failures means the rule is not matching what the benchmark inspects - that is a scope bug, not a redundancy. If I do retire one, the survivor has to be the one whose coverage contains the other's.
go deeper
Know the difference between a check that refuses a change before it happens and a check that reports on systems after the fact, and that having both is normal rather than wasteful.
Explain the coverage sets precisely: what a gate cannot see, what a scheduled scan cannot prevent, and why identical wording in two checks does not make them redundant.
Demonstrate the side-by-side read of firing counts against scan results, and show that you treat 'quiet rule plus failing scan' as a scope bug rather than a reason to delete either.
Own how many encodings of one requirement the organisation maintains, who is authoritative when they disagree, and what you accept losing when you decide a control lives in a default instead of a gate.
## They are not the same control An audit-log retention requirement can be enforced in two very different positions, and the fact that both quote the same number does not make them duplicates. - The **gate rule** is **preventive**. It evaluates a proposed change - a plan, a manifest, a config file - before it takes effect, and it can refuse. Its coverage is exactly *changes that pass through the gate and match its selector*. - The **benchmark run** is **detective**. It inspects live systems on a schedule and reports which controls pass and which fail. Its coverage is *whatever it can reach at the moment it runs*, and its output is a finding, not a refusal. Getting the direction right matters, because the two failure modes are opposites. The preventive check cannot see anything that never went through it: a resource created by hand, a change applied with credentials that bypass the pipeline, or configuration that drifts after apply. The detective check sees all of that, but always after the fact, and it never stops the change - it only tells you the state you are already in. ## Read the two signals side by side Put the engine's firing counts for the retention rule next to the benchmark's pass/fail for the corresponding control. There are four cases and each has a different action: | Rule firing | Benchmark result | What it means | What to do | |---|---|---|---| | Never fires | All pass | The control is satisfied everywhere it is checked | Genuine retirement candidate for the preventive rule | | Fires regularly | All pass | The rule is stopping violations before they become findings | Keep both; this is the system working | | Never fires | Failures present | The rule is not matching the things the benchmark inspects | Scope bug in the rule - fix it, do not delete it | | Fires regularly | Failures present | Violations are landing anyway | Something reaches production without passing the gate | The third and fourth rows are the ones that make this comparison worth doing at all. A rule with zero denials looks healthy until you notice the benchmark is reporting failures for exactly the control that rule was supposed to prevent - which means either the rule's selector misses the real resources, or the resources are not created through the gated path. ## When retiring one is defensible Retire the redundant check only when its coverage is a subset of the survivor's **and** you can accept losing its distinctive property. - Retiring the **preventive** rule costs you the fast, specific feedback at the moment of change - the developer learns from a scheduled report tomorrow instead of a refusal now - and it costs you prevention: the non-compliant state exists for up to one scan interval. - Retiring the **detective** check costs you all coverage of anything that did not go through the gate. That is usually the harder loss, because out-of-band change is exactly the case a gate cannot see. In practice the preventive rule is the more retirable of the two, and only when something upstream now guarantees the value - a base template or provisioning path that everything is built from. Then the honest description is not 'we removed a control', it is 'the control moved from the gate into the default, and the benchmark still verifies it'. ## What duplication actually costs If you keep both - the usual answer - the cost is not evaluation time, it is drift between them. Two encodings of one standard means two places to update when the number changes, two message texts that can disagree, and two owners who each think the other is authoritative. So: name one of them the authoritative expression of the requirement, derive the other from the same recorded source, and make the retention number a value both read rather than a literal typed twice. Also decide which one produces the evidence you will be asked for later, so a reviewer is not handed two artefacts with different verdicts and no tiebreak. ## The mistake to avoid The tempting move is to count both checks as one line of coverage and delete whichever is cheaper to remove - typically the benchmark control, because the gate rule is the one the team wrote. That inverts the risk: you keep the check that can only see changes made properly, and drop the one that would have caught the change made improperly. Deduplicate the *reporting* when both fire on the same defect. Do not deduplicate the *positions*.
- The rule never fires and the benchmark reports failures for the same control. What is your first hypothesis?That the rule is not matching the resources the benchmark inspects. Either its selector is scoped to a subset - a kind, a path, a label - that misses them, or those resources were never created through the gated path. Both are coverage bugs. I would confirm by feeding the engine one of the failing resources as an input and seeing whether the rule matches it at all.
- If you keep both checks, how do you stop them drifting apart?Make the requirement a single recorded value that both encodings read, rather than a literal typed in two places, and put both under the same owner and the same review. Name one as authoritative for evidence, so a reviewer handed disagreeing verdicts knows which one answers the question.
saying these in an interview costs you the question
- Calls the two checks duplicates because they cite the same number
- Deletes the detective check and keeps only the gate
- Assumes a gate can see resources created outside the pipeline
- Treats a scheduled report as prevention
- Counts both checks as one line of coverage without comparing scope