When should a Checkov exemption be an inline skip comment rather than a config-file skip-check or skip-path?

## Three levers, three blast radii A scanner gives you more than one way to stop a finding, and they are not interchangeable. Ranked from narrowest to widest: | Mechanism | Scope | Visible where the violation is? | Dies when? | |---|---|---|---| | Inline `#checkov:skip=ID:reason` | one block, one check | yes — it is at the line | the resource is deleted | | `skip-check: [ID]` in config / `--skip-check` | that check, across the whole scan | no | someone edits the config | | `skip-path: [pattern]` in config / `--skip-path` | every check, across matching paths | no | someone edits the config | The first column is what most people compare. The second column is what actually decides most reviews. ## Why visibility dominates An inline annotation is a piece of code. It arrives in a pull request, sits next to the thing it excuses, and is read by whoever reviews that file. Six months later, an engineer opening the resource sees immediately that a control was disabled here and why someone thought that was fine. A `skip-check` entry has none of that. The Terraform looks clean. The scan is green. Nothing at the violating resource hints that a control was ever meant to apply. Worse, the exemption is *prospective*: it does not just excuse today's violation, it pre-approves every future one. A team disables a check once for a legacy resource, and two years later the same class of violation ships in new code with nobody noticing — because the gate is not looking. ## When the config file is right anyway There are two honest uses. **The rule genuinely does not apply to this scan.** If the check encodes a control that the organisation has consciously decided not to enforce for this class of repository, disabling it once in configuration is more truthful than a hundred inline skips repeating the same reason. The test is whether you would be comfortable writing the justification once, in a place a reviewer will find it — the config file should carry a comment saying why, because the mechanism itself records nothing. **The path is not deployed infrastructure.** A Terraform module ships an `examples/` directory and a set of test fixtures whose entire purpose is to be scanned by the module's own tests, or to demonstrate a minimal configuration. That code is never applied to a real account. Excluding it with `skip-path` is correct: the alternative is decorating fixtures with skip comments that then become the copy-paste source for skips in real code. The hazard with `skip-path` is that the patterns are matched as regular expressions against paths. A pattern written loosely enough to catch `modules/foo/examples/` can also catch a directory called `examples-prod` or, worse, swallow a whole `modules/` tree. Because an excluded path produces no finding **and** no skip record, the mistake is invisible in the output — you cannot spot it by reading the report, only by reading the pattern. ## The pattern to be suspicious of The common anti-pattern is a `skip-check` list that grew one id at a time, each added by whoever was blocked that afternoon, none of them carrying a reason because the file has no field for one. That list is a de facto rewrite of the policy, made by nobody in particular. If a check is being disabled everywhere, that is a decision that deserves an owner and a written rationale — not a line in a YAML list. One related distinction worth keeping clean: making the whole run non-blocking (Checkov's `--soft-fail`) is **not** a suppression. Nothing is exempted; every finding is still reported, the run just stops failing. It changes what the gate does with the answer, not what the answer is. ## How to answer this in an interview Say the ranking, then say the test: exemption as close to the exempted thing as possible; the config file only for "not this rule, ever, here" or "not real infrastructure". Then name the failure mode of each — a skip comment copy-pasted onward, and a config skip that silently pre-approves everything that comes later.