An enterprise wants automated policy enforcement. Where should policies be evaluated, and what makes the approach fail?

Where policies should be evaluated

At more than one point, for different reasons:

1. In the developer's environment, giving feedback in seconds while the context is fresh. Cheapest place to fail.

2. In the pipeline, blocking the change before it merges. Clear ownership — the failing build belongs to the person making the change.

3. At the control plane, as admission control, so a change cannot be applied by any path — including a console action that bypassed the pipeline. This is the layer that makes the policy an actual control rather than a convention.

4. Continuously against running state, catching what was applied before the policy existed and anything that drifted.

Pipeline-only enforcement is bypassed by anyone with console access; control-plane-only enforcement gives feedback hours after the engineer moved on. Both are needed.

What makes the approach fail

• Policies written by a central team about work they do not do, producing rules that block legitimate cases and are resented.
• No exception path, so a genuine need forces the policy to be disabled entirely rather than waived narrowly. Exceptions need an owner, a scope and an expiry, since permanent exceptions become the architecture.
• Unclear failure messages. A rejected deployment saying "policy violation" without naming the policy, the reason and the remedy is a support request.
• Policies applied to low-consequence actions, generating friction that erodes trust in the whole framework.
• Policy as code with no tests. Policies are code; an untested policy blocking production is an outage caused by governance.

The scope that works

Preventive for the small set of severe, irreversible actions — public data exposure, unencrypted storage, unapproved regions, missing attribution, destructive migrations. Detective for the rest.

Prevention scales with automation; detection scales with headcount — which is the whole argument for placing the boundary carefully rather than enforcing everything.