A platform has a policy check that warns when a service lacks resource limits, readiness probes or an owner label. 140 of 200 services fail at least one check. The security team asks for it to become blocking next week. What happens if you do, and what would you do instead?

What happens if you switch it on

Nothing breaks for running services, and everything breaks for changes to them. Admission policy evaluates on write, so the 140 failing services keep serving traffic and become undeployable. The first consequence is not a wave of compliance, it is a wave of blocked deploys, including the hotfix somebody needs at 02:00, and an urgent demand for a bypass.

The second consequence is the one that lasts. A bypass created under pressure becomes permanent, and within a month the policy is a thing 140 services are exempt from, which is worse than a warning because it now carries the appearance of control.

The sequence that works

1. Make the current state visible per team, not as a global number. "Your six services, three of which fail, here is the exact YAML to add" converts a policy into a task.
2. Apply the gate to new objects only. Anything created from today must pass; existing objects are grandfathered. This stops the population growing while you work on it, and costs nobody a blocked deploy.
3. Fix what the platform can fix centrally. Defaults for resource limits can be injected; owner labels can often be derived from the service catalogue. Anything the platform can set itself should never have been a policy violation — it should be a default.
4. Set expiring exemptions, dated and owned, for the genuinely hard remainder. An exemption without an expiry date is a permanent waiver with extra paperwork.
5. Flip to blocking for everything when the remaining count is small enough that the affected teams can be named in a meeting.

Where the pressure comes from, and how to answer it

The security team's request is reasonable and their deadline is usually driven by an audit date rather than by risk. The answer that lands is a dated plan with a burn-down chart, not a refusal and not a yes that produces a bypass. What they need is evidence the number goes to zero; what they asked for is a switch.

What this costs

The staged path takes weeks instead of a day, and during those weeks the risk the policy addresses is still present for existing services. State that plainly rather than hiding it: if any of the 140 present a serious live risk, they are an incident to be fixed now, separately, and not an argument about enforcement mechanics.

When this staged approach is wrong

When the check catches something that is actively dangerous — a container running as root with host mounts, a publicly exposed service without authentication — the calculus reverses. Blocked deploys are cheaper than the exposure, and the right move is to block now and apologise in the channel. The distinction is between hygiene, which is staged, and exposure, which is not.