Which policy violations can no pre-change check ever catch, however you place the gate?
answer
- no change means no event to evaluate
- the resource sat still, the world moved
- expiry dates and later disclosures
- the rule tightened, the resource did not
- needs an evaluation started by a clock
basics
~20 sViolations where nothing changed. A gate fires on a proposed change, so a resource that becomes non-conforming while sitting still — a certificate passing its expiry, a vulnerability disclosed later — produces no event at all.
solid answer
~50 sConformance is a function of the resource *and* the world, and the world moves without your changing anything. A certificate that was valid at deploy time crosses its expiry date. A container image that passed every check is later the subject of a newly disclosed vulnerability. A standard tightens, so a resource that satisfied the rule as written now does not. A key ages past its rotation limit. None of these involve a proposal, a merge, a plan or an admission request, so there is no event for a gate anywhere in the pipeline to fire on — the failure is in time, not in a change. Only an evaluation that re-runs over existing state on its own initiative catches this class, which is why detective coverage is not merely a backstop for gate gaps but the only control that exists for this category.
go deeper
Know that a gate only fires when something is proposed, and be able to give one example of a violation that appears without anybody changing anything — a certificate reaching its expiry date is the clearest.
Be ready to name the category and two or three families within it, and to explain why adding gates at more points cannot help when there is no change anywhere to intercept.
Show that you classify each rule by whether its truth can change while the resource sits still, and that time-dependent rules get a re-evaluating control by design rather than being bolted on after an incident.
Be able to argue why a conformance claim decays for one class of rule and not another, and what that means for the assurances you are prepared to make about the estate between evaluations.
## A gate is an event-driven evaluation Every pre-change control shares one shape: something is proposed, the control evaluates the proposal, and a verdict comes back. Change the placement — editor, pull request, build, promotion, admission, the provider's own API — and that shape does not change. **No proposal, no evaluation.** That makes an entire class of violation permanently invisible to gates, regardless of how many you deploy or how well you write them: violations where the resource did not change at all, and the *world around it* did. ## The category, with concrete cases **Time passing.** A TLS certificate that was comfortably valid when the service was deployed reaches its expiry date. Nothing was edited. There was no merge, no deployment, no admission request on the day it expired. The same shape covers a credential or signing key aging past a rotation limit, a support or end-of-life date arriving for a runtime version, and a temporary exception whose expiry has come and gone. **New knowledge about an unchanged artifact.** A container image is scanned at build time and admitted clean. Weeks later a vulnerability is disclosed in a library it contains. The image bytes are identical; the digest is identical; the only thing that changed is what the world knows about it. A gate that re-evaluates only on the next deployment will not notice, and if that workload is not redeployed for months, nothing notices. **The rule moved, not the resource.** A standard tightens — an allowed algorithm is dropped, a minimum version is raised, an allow-list of approved options shrinks. Resources that satisfied the previous rule are non-conforming under the new one without anyone touching them. **A dependency outside the resource changed.** The resource references something — an external endpoint, a shared network boundary, a parent scope — and that thing was altered by someone else. The resource's own definition is byte-identical. ## Why placing the gate better does not help It is tempting to answer "move the check earlier" or "add a check at another point". Both are answers to a *coverage* problem: a change happened somewhere the gate was not. This is a different problem. Here there is no change anywhere, so there is no place to stand that would see one. The evaluation has to be initiated by something other than the change — a schedule, a clock, an external feed of new advisories, a re-evaluation triggered when the rule itself is edited. A subtle half-measure worth naming: the gate *will* catch these on the next change, whenever it comes. That produces two bad effects. First, the delay is unbounded and inversely related to risk — the least-touched systems, which are usually the oldest and least well maintained, wait the longest. Second, the violation surfaces to whoever happens to be making an unrelated change, who has no context and did not cause it, which is one of the surest ways to make teams resent a policy programme. ## What this implies for control design For each rule, ask whether its truth can change while the resource sits still. - If it cannot — a property fixed at creation, such as whether a managed data store was created with encryption at rest — the rule is fully expressible at a gate, and detective coverage exists only to catch resources that never passed one. - If it can, the rule needs a re-evaluating control by construction, and the gate version is at best the first of two homes. The exposure window is then governed by how promptly the re-evaluation runs after the world moves, which for a newly disclosed vulnerability means after the advisory lands, not after the next deploy. The second category is also where "we are compliant" quietly rots into a claim about a past moment. A pass is a statement about the instant it was evaluated. For a create-time property that statement stays true indefinitely; for a time-dependent one it starts decaying the moment it is made, and the only thing that keeps it honest is something re-asking the question. ## The strong interview answer Name the category first — *violations that arrive with no change* — then give two concrete cases from different families (expiry and newly disclosed vulnerabilities are the cleanest pair), then say why placement cannot fix it, then close on the design consequence: rules whose truth is time-dependent are detective by necessity, not by preference.
- Doesn't the gate catch these the next time the workload is deployed?Eventually, and that is the worst property of relying on it. The delay is unbounded and longest for the least-touched systems, which are usually the most neglected ones. It also surfaces the violation to whoever made an unrelated change, who neither caused it nor has the context to fix it.
- How does this change the way you write a rule?Ask whether the rule's truth can change while the resource is untouched. A create-time property such as whether a store was created encrypted stays settled once evaluated. A time-dependent property needs a control that re-evaluates on its own schedule, so the gate version is at best half the deployment.
- A vulnerability is disclosed against an image already running in production. Which control notices?Only one that re-evaluates the deployed inventory against the current advisory data. The image is byte-identical to the one that passed at build, so nothing about the artifact changed and no gate has an event to fire on. The trigger is the new advisory, not a change of yours.
A gate checks the milk when you put it in the trolley. Nothing re-checks the carton in the fridge as the date on it passes — only opening the fridge on purpose does that.
saying these in an interview costs you the question
- Answers by moving the check earlier in the pipeline
- Claims a gate catches everything if placed correctly
- Confuses this with someone modifying the resource later
- Treats a past pass as a standing statement of conformance
- Relies on the next deployment to re-evaluate old workloads