How do you architect self-service GitOps with central policy enforcement?

WHAT THIS TESTS: This question evaluates whether you understand the tension between developer autonomy and platform governance in Kubernetes. The interviewer wants to see if you can separate the delivery mechanism from the enforcement boundary, and if you know how to use policy-as-code to make security guardrails self-service rather than bureaucratic.

A GOOD ANSWER COVERS: First, tenancy isolation for the GitOps layer itself, such as namespace-scoped Argo CD AppProjects or Flux RBAC, so each team can manage its own repositories and destinations without seeing another tenant's workloads. Second, an admission control strategy using OPA Gatekeeper or Kyverno to enforce deny policies at the API server, for example rejecting pods with privileged security contexts or services of type LoadBalancer in namespaces that are not explicitly allowlisted. Third, a centralized policy repository managed by the platform team that is continuously reconciled to the cluster, ensuring teams cannot override or disable constraints. Fourth, a clear separation between the source of truth for application manifests, which lives in team-owned repos, and the source of truth for cluster policy, which lives in a repo with restricted merge permissions. Fifth, optional but valuable, a pre-flight check in CI that surfaces policy violations early using the same constraint templates that run in the cluster, reducing feedback loops.

COMMON WRONG ANSWERS: Proposing that the platform team manually reviews every pull request or ticket to enforce policy, which creates a bottleneck and contradicts the self-service goal. Suggesting CI-only checks without admission control, which leaves the cluster vulnerable to kubectl apply or compromised credentials. Recommending a single shared GitOps instance with cluster-admin access for all teams, which violates least privilege and makes lateral movement trivial. Proposing network policies as the primary enforcement for public load balancers, which is a mitigation but not a prevention strategy since the resource still gets created.

LIKELY FOLLOW-UPS: How do you handle policy exceptions for a specific team during an incident? How do you prevent a tenant from consuming all cluster resources or creating thousands of objects in a GitOps loop? What is your strategy for secret management when teams need to inject credentials through GitOps? How do you audit drift if a user bypasses GitOps and modifies resources directly with kubectl?

ONE CONCRETE EXAMPLE: Imagine a cluster with fifty application teams. Each team has an Argo CD AppProject scoped to their three namespaces. The platform team maintains a Kyverno policy in a central repo that mutates and validates every incoming service, rejecting any service of type LoadBalancer unless it carries an approved annotation. When a team commits a privileged container to their application repo, Argo CD syncs the manifest, but the Kyverno admission webhook blocks the pod creation and surfaces the violation in the GitOps UI. The team fixes the manifest without ever opening a ticket to the platform team, and the platform team retains audit logs of every denied request through Kubernetes audit events.