A CI check rejects plans requesting a disallowed instance type, so why do such instances still appear in the account?
answer
- a verdict about what arrived
- which routes never reach CI
- same role, no pipeline
- path coverage versus rule correctness
basics
~20 sA CI check only sees changes that travel through CI. Anyone holding cloud credentials can create the instance from a console session or a local apply, and that route never reaches the check at all.
solid answer
~50 sA policy check in CI evaluates whatever the pipeline handed it, so a green verdict means the submitted plan satisfied the rule and nothing more. Any route to the same effect that does not pass through that pipeline is untouched: a console click, a local apply using the same role the deploy job assumes, a second repository with its own pipeline, an automation identity creating resources programmatically, or resources that predate the rule and no plan has touched since. So the question is not whether the rule is right but whether the check sits on every path to the effect. Enforcement needs three things at once: the decision point is on-path for that surface, a failing verdict actually stops the action, and no equivalent route bypasses it. Where a route cannot be closed, pair the preventive check with a detective control that evaluates live resources and attributes each creation to a principal.
go deeper
Be ready to state plainly what a passing CI check does and does not claim: the change that went through CI satisfied the rule, and nothing at all about the rest of the account.
An interviewer expects you to enumerate the other routes to the same resource — a console session, a local apply with the deploy role, a second pipeline, an automation identity, pre-existing resources — and to say why none of them touches the check.
Show that your first move is to find the calling identity in the target's change events rather than to rewrite the rule, and that you pair the preventive check with a detective control over live resources.
Own the framing that a guardrail programme is judged by path coverage across the estate, not by how many rules were written, and be able to name which routes you are deliberately leaving open and why.
### What a passing check actually claims A policy check that runs in CI evaluates a *document*: a plan rendered to JSON, a rendered manifest, a job definition — whatever the pipeline handed it. Its verdict is scoped exactly to that document. Green says: *the change submitted to this pipeline, as described, does not violate the rule.* It says nothing about the account, the cluster or the estate, because the check never looked at them. It also says nothing about changes that were never submitted. That is the whole answer to the question. Instances with a disallowed type exist because they arrived by a route the check is not on. ### Two properties that get conflated **Rule correctness** — given the input, does the rule catch the condition it is meant to catch? This is where authors spend their time, and it is the easier half. **Path coverage** — is the decision point on every route by which the condition can come to exist? This is what decides whether the rule enforces anything at all. A perfectly written rule covering one route out of four is a convention with a robot enforcing it on the polite path. Candidates who only ever tune rules never notice the other three routes. ### The routes an honest inventory turns up - A human with cloud credentials creating the instance directly in the provider console. - The same person running the apply from a laptop, very often assuming *the same role the deploy job assumes* — identical credentials, identical API calls, only the surrounding job missing. - A second repository or a second pipeline that touches the same account and was never wired to the check. - An automation identity: a controller, an autoscaler, a vendor integration, an internal support tool, each with credentials of its own. - Resources created before the rule existed. A plan-time check only evaluates what a change touches, so drifted or legacy resources are simply invisible to it. - A resource created indirectly, where the gated object is a template or a module input and the instance is a downstream effect whose shape the rule's matcher never inspected. ### Why rewriting the rule is the wrong first move The instinct on being shown a violation is to assume the rule missed a case. Sometimes it did. But when the violating resource exists and every run was green, the far likelier explanation is that no run ever saw it. The cheap discriminator is on the target's side, not the pipeline's: the provider's change events for that resource record the calling identity and the API action. If the creator is a human session or an automation identity rather than the deploy identity, this is a coverage problem and no amount of rule work will fix it. ### What enforcement actually requires Three properties, all necessary: 1. **On-path** — every mutation of the surface transits the decision point. 2. **Terminal** — a failing verdict stops the action, rather than annotating something a person can proceed past. 3. **Non-substitutable** — no route with the same effect avoids the decision point. A CI check usually has the second and lacks the first and third. That is not a defect in CI; it is what a check on a submitted document can structurally be. The mistake is reporting it upward as if it were a control over the account. ### The honest posture You will not close every route at once, and pretending otherwise is how the gate everyone believed was enforcing turns out never to have been. The workable posture is preventive on the covered path and detective everywhere else: a scheduled evaluation of live resources for the same condition, plus attribution from the provider's change events. Detection is not an admission of defeat here — it is the correct control for a route you have consciously left open, and it doubles as the way you *build* the inventory. Group a month of creation events for that resource type by calling identity; every identity that is not the deploy identity is a route you did not know you had. ### How to phrase it under interview pressure Say what the check claims, say what it cannot claim, then name three concrete routes and how you would confirm which one was used. That answer distinguishes someone who has operated a guardrail from someone who has only written one.
- Where do you look first to find out how that instance was actually created?The cloud provider's change or audit events for that resource, not the pipeline logs. They record the API action and the calling identity, which immediately tells you whether it was the deploy identity, a human console session or an automation identity — and that decides whether you are fixing a rule or closing a route.
- Would moving the same check into a pre-commit hook help here?No. It moves the same rule further up the same route, so it catches nothing new, and it adds a route the developer can skip outright by committing without the hook. It is a feedback-speed improvement, not a coverage improvement — worth doing for developer experience, worthless as an answer to this problem.
- The instance was created by an autoscaling controller, not a person. Does the rule still apply?The intent applies but the placement is wrong. A controller-created instance inherits its shape from something the pipeline did gate — a launch template or module input — so the effective gate belongs on that definition. Gating the instance itself would block a legitimate automated action and teach the team the rule is noise.
A locked gate on a fence proves that nobody walked through the gate. It proves nothing about the field if the fence has three other openings.
saying these in an interview costs you the question
- Says a green check proves the account is compliant
- Blames the rule and rewrites it before finding the route
- Assumes every change to the account goes through the pipeline
- Offers moving the same check earlier as the fix
- Cannot name a single way to create the resource outside CI