How would you design and roll out a policy blocking :latest image tags cluster-wide, without breaking every existing deployment on day one?

Deploy the policy first in "audit" or "dry-run" mode (most policy engines, including Gatekeeper and Kyverno, support a mode that reports violations without actually blocking them), giving visibility into exactly which existing workloads would be affected — fix those identified workloads first, then switch the policy to actual enforcement mode only once the violation count is at (or near) zero, rather than enabling hard enforcement immediately and breaking everything using :latest on day one.

The rollout risk isn't the policy's correctness — it's the gap between "what the policy requires" and "what's already running." Closing that gap safely means measuring it first, not enforcing blind and discovering the gap via a production outage.

• New workloads using :latest should eventually be blocked from being created.
• Existing workloads already using :latest must not be suddenly broken by the policy's introduction.
• The rollout needs visibility into actual impact before enforcement begins, not a blind cutover.

Start in audit/dry-run mode, not immediate enforcement: Gatekeeper's enforcementAction: dryrun (or Kyverno's validationFailureAction: audit) makes the policy evaluate every matching request and record violations, without actually rejecting anything — this gives real, concrete visibility into which existing resources currently violate the intended policy, which is essential information you don't otherwise have before deciding it's safe to enforce.

Use the audit results to build a concrete remediation list: the policy engine's own reporting (Gatekeeper's constraint status showing violating resources, Kyverno's PolicyReport objects) gives an actual, queryable list of exactly which Deployments/workloads currently use :latest — this turns "we think a few things might break" into a specific, actionable list to work through.

Fix the identified violations before flipping to enforcement: working through the audit-identified list — pinning each affected Deployment to a specific, real version tag — closes the gap between current state and the policy's requirement, ideally coordinated with the owning teams rather than done unilaterally, since they may have context on why a specific deployment still uses :latest.

Switch to actual enforcement only once violations are at or near zero: enforcementAction: deny (Gatekeeper) or validationFailureAction: Enforce (Kyverno) actually blocks new violating requests — flipping this switch after the existing violations have been addressed means the transition to enforcement doesn't break anything that was already running, and only affects genuinely new attempts to violate the policy going forward.

Consider a narrower initial scope before going cluster-wide: for a large cluster with many teams, rolling the policy out to one namespace or one team first (via namespaceSelector), validating the audit-then-enforce process works smoothly there, before expanding cluster-wide, reduces the risk of a rollout-process mistake affecting everyone simultaneously.

The audit-then-enforce rollout takes real calendar time — you can't jump straight to the desired enforced end-state, and during the audit period, the anti-pattern the policy is meant to prevent is still technically possible for new workloads too (since enforcement isn't active yet). This is the necessary cost of a safe rollout for a policy affecting existing production workloads; for a genuinely new cluster with no existing violating workloads at all, skipping straight to enforcement mode is reasonable, since there's nothing existing to break.

• Start any new cluster-wide policy in audit/dry-run mode, which reports violations without blocking them, to get real visibility into impact before enforcing.
• Use the policy engine's own violation reporting to build a concrete remediation list, rather than guessing what might break.
• Only switch to actual enforcement once existing violations are addressed — this is what avoids breaking already-running workloads on day one.
• For a large, multi-team cluster, consider a narrower initial rollout scope before expanding cluster-wide, to validate the process itself first.

• OPA Gatekeeper: Audit
• Kyverno: Background Scans