A pre-change policy gate has been green all quarter, yet a sweep of live resources finds violations — why?
answer
- the gate judges proposals, not the estate
- some resources never produce a proposal
- console clicks, vendor credentials, managed sub-resources
- measure coverage, not just verdicts
basics
~10 sA pre-change gate only judges changes routed through it. Resources created by hand in a console, by a third-party integration, or by a platform component never reach the gate and so never fail it.
solid answer
~50 sThe green record is honest — it just measures something narrower than people read into it. A gate adjudicates proposals that pass through it, so its verdict covers the gated path, not the estate. Three families of resource escape it routinely: things created directly through a console or CLI by a human with standing permissions; things created by a vendor or third-party integration holding its own credentials; and sub-resources provisioned by a managed service or platform controller on your behalf, which nobody ever wrote down. A detective sweep reads the estate as it is, so it sees all of them. The right response is not to distrust the gate but to measure its coverage — what fraction of resources of this type can be matched to a change that actually went through it — and to treat the unmatched remainder as detective-only territory.
go deeper
Know that a gate only ever sees changes that pass through it, and be able to name one way a resource comes into existence without touching the pipeline — a console click during an incident is the easy example.
Be ready to enumerate the ungated creation paths and to explain why the gate cannot be extended to cover them. Expect to be pushed on how you would tell a missed proposal from a wrong verdict.
Show how you would measure coverage rather than argue about it: reconcile live resources against gated changes using provenance tags or the provider's activity log, and report the unmatched fraction as the risk.
Own the trade between shrinking ungated creation paths — which costs teams and vendors autonomy — and living with detective-only coverage, and be able to justify where you spend that capital based on remediation cost.
## The green record is true and narrower than it sounds A pre-change gate answers exactly one question: *of the proposals presented to me, how many violated the rule?* A quarter of green means no proposal that reached the gate broke the rule. It says nothing whatsoever about resources that never produced a proposal. Confusing "the gate is green" with "the estate conforms" is the single most common reasoning error in this area, and a detective sweep over live state is what exposes it. ## Where the ungated resources come from **Human out-of-band creation.** Someone with standing permissions clicks through a console or runs a CLI command. This is not always misbehaviour: it is what happens during an incident at 2am, during an evaluation of a new service, or when someone needs a scratch environment quickly. The resource is real, it is in the same account, and no proposal ever existed for a gate to read. **Third-party and vendor integrations.** A monitoring vendor, a data platform, a CI provider or a backup product is given credentials into your environment and creates resources with them. It has no idea your gate exists and would not route through it if it did. This category is easy to miss because nobody on your team performed the action. **Platform-provisioned sub-resources.** A managed service creates the storage, queue or replica it needs to do its job. The parent resource may have gone through the gate perfectly; its children did not appear in the proposal, because the proposal described what you asked for, not everything the provider would build. There is a fourth, duller source: resources that predate the gate. They are usually the largest bucket the first time a sweep runs, and they are the one category everybody thinks of first. ## Why the gate cannot simply be extended to cover them A gate is *event-driven on a specific channel*. It exists at a place a change flows through — a pull request, a pipeline stage, an admission request, an API call path. Its coverage is exactly the set of changes that traverse that place. You can add gates at more places, and you can shrink the ungated paths by narrowing who and what holds standing create permissions, but you cannot make a gate see a creation that did not pass through it. That is a structural property, not a configuration mistake. ## What to do with the answer Stop treating the gate result as a coverage metric and measure coverage directly. The practical form is a reconciliation: enumerate the live resources of the type the rule concerns, and try to match each one to a change that went through the gate. Common matching handles are an ownership or provenance tag applied by the gated path, a creation record in the provider's own activity log naming the identity that made the call, or an inventory entry produced by the pipeline. Anything unmatched is, by definition, outside the gate's reach. That number is the real risk statement, and it drives two different decisions: - **Shrink the ungated set** where it is worth the friction: remove or scope down standing create permissions for the resource type, give the vendor integration a role that cannot create it, or route the platform component's provisioning through the same path. Every one of these costs somebody autonomy, so it is a negotiation, not a switch. - **Accept detective coverage** for the remainder, and size the sweep's response to what remediation costs. Where the violated property is fixed at creation — encryption at rest on a managed data store being the canonical case — after-the-fact remediation means build a new store, migrate, cut over and destroy. That cost is the argument for spending political capital on shrinking the ungated set rather than for running the sweep more often. ## The interview trap Candidates often answer this with "someone must have bypassed the gate", which frames it as misconduct and stops the analysis. Bypass is one path among several, and often the least common. The strong answer distinguishes *creation paths that never reach the gate* from *a gate that reached the wrong verdict*, then says how you would tell which one you are looking at — the provider's activity log will name the identity and the API call that created the resource, and that identity tells you immediately whether it was a person, a vendor's role or a platform service.
- How would you measure what fraction of the estate the gate actually covers?Reconcile live resources against changes that went through the gate. Match on a provenance or ownership tag stamped by the gated path, or on the identity recorded in the provider's activity log for the creating API call. Anything unmatched was never adjudicated. That percentage, not the gate's pass rate, is the honest coverage number.
- The offending store was created by a vendor integration's role. What is your remedy?Either route that provisioning through the gated path, or scope the role so it cannot create that resource type at all and have it request one through the normal flow. If neither is negotiable, accept it as permanently detective-only territory and document that decision with the exposure it implies.
- Does adding a second gate at a different point fix this?Only for changes that traverse the new point. A second gate broadens coverage where two flows exist, but a creation made directly against the provider API still passes through neither. Placement adds coverage; it never converts an ungated creation path into a gated one.
saying these in an interview costs you the question
- Concludes someone must have deliberately bypassed the gate
- Reads a green gate record as estate-wide conformance
- Proposes running the gate more often as the fix
- Forgets that managed services provision sub-resources you never declared
- Assumes vendor integrations route through your pipeline