ArgoCD makes Kubernetes drift visible. It does not decide who owns the drift, when to sync, or whether pruning is safe.

Those decisions need to be explicit before teams treat the ArgoCD UI as the deployment control plane.

Define Application Ownership

Every ArgoCD Application should have an owner who can answer:

  • which repo path declares the workload.
  • which team reviews changes.
  • which namespace and cluster are in scope.
  • whether sync is automatic or manual.
  • whether prune and self-heal are enabled.
  • what emergency live changes are allowed.
  • how live fixes get written back to Git.

If the owner is “platform,” but the application team controls the chart values, the ownership model is incomplete.

Bound The Project

Use ArgoCD AppProject boundaries to make intent visible:

  • allowed source repos.
  • allowed destination clusters and namespaces.
  • permitted cluster-scoped resources.
  • denied resource kinds.
  • deployment windows.
  • RBAC by team or environment.

The project boundary should prevent a staging application from accidentally targeting production, not just document that it should not happen.

Sync Policy Questions

Before enabling automatic sync, decide:

  • Is prune enabled?
  • Is selfHeal enabled?
  • Are sync waves or hooks required?
  • Are CRDs managed by the same application as custom resources?
  • Are StatefulSets, PVCs, or database objects involved?
  • Is there a rollback path if sync applies successfully but readiness fails?

Automatic sync is safe when the blast radius is understood. It is dangerous when it silently turns every merge into an apply across shared infrastructure.

Manual Intervention Rule

Live changes happen during incidents. The rule is not “never touch the cluster.” The rule is:

live fix -> capture evidence -> update Git -> let ArgoCD converge -> verify drift cleared

If a live fix stays outside Git, ArgoCD may revert it during self-heal, preserve it as unmanaged drift, or delete it during a future prune.

Useful Checks

During review or incident response, inspect:

argocd app get <app>
argocd app diff <app>
argocd app history <app>
argocd app manifests <app>
kubectl -n argocd logs deploy/argocd-application-controller

Look for the declared revision, sync status, health status, comparison errors, hook failures, and resources that are orphaned or pruned.

Failure Model

The common failure is ambiguous ownership:

ArgoCD shows OutOfSync -> app team patches live object
-> self-heal reverts patch -> platform disables sync
-> Git no longer represents production

The operating rule: ArgoCD owns reconciliation, but teams still own review, timing, exceptions, and recovery evidence.