What is 'drift' in Argo CD, and what are the different ways an Application can respond to it?

Argo CD's core reconciliation loop continuously compares the live manifests in the cluster against what's rendered from the target Git revision, and any difference is drift — this could come from someone running kubectl edit directly against a resource, another controller mutating a field Argo CD also manages, or simply Git having moved forward since the last sync.

By default (manual sync), Argo CD only reports drift as an 'OutOfSync' status in the UI/CLI and does nothing further until an operator explicitly runs argocd app sync. With automated sync policy enabled, Argo CD will automatically apply a sync whenever it detects the live state differs from Git — but note this only triggers when Argo CD's own reconciliation notices drift on its polling interval, not instantaneously. Adding selfHeal: true to the automated sync policy makes Argo CD actively revert manual changes back to the Git-defined state as soon as it detects them, treating any out-of-band kubectl edit as something to be corrected rather than tolerated — this is what makes Git genuinely the single source of truth rather than just a convenient deployment starting point.

A common gotcha: without selfHeal, a well-meaning but manual kubectl scale during an incident will silently persist until the next sync (which might reset it, surprising the responder), and with selfHeal it might get reverted almost immediately, which is exactly the desired GitOps behavior but can confuse an engineer who doesn't realize self-healing is enabled and expects their manual fix to stick.