How GitOps controllers detect drift and sync

WHAT THIS TESTS Whether you understand that GitOps controllers continuously compare two states and converge them, and that drift can originate from either side.

A GOOD ANSWER COVERS The controller maintains two pictures: the desired state, produced by rendering the manifests, Helm chart, or kustomization from the Git repo at a given revision, and the live state, read from the Kubernetes API server. On an interval and on webhook events it diffs them object by object and field by field, normalizing for server-managed fields. If they differ, the application is marked OutOfSync. Crucially, drift is detected regardless of source: a new Git commit changes desired state, while a manual kubectl edit or a controller mutating a field changes live state; either triggers an OutOfSync status. A sync operation applies the rendered desired manifests to the cluster to make live match desired. It can run automatically or manually, supports ordering via sync waves, runs pre- and post-sync hooks, and with prune enabled deletes objects that no longer exist in Git. Self-heal can re-sync automatically when live drifts.

COMMON WRONG ANSWERS Saying drift is only noticed when someone commits to Git, ignoring manual-edit drift, or describing sync as a blind reapply with no diff, ordering, or pruning.

LIKELY FOLLOW-UPS What is self-heal versus manual sync? How do sync waves order resources? What does prune do and why is it risky?

ONE CONCRETE EXAMPLE Git says a Deployment has 3 replicas. An operator manually scales it to 8 with kubectl. Argo CD's next reconciliation renders the Git manifest, diffs it, finds replicas 8 versus 3, and marks the app OutOfSync. With self-heal on, it syncs, reapplying the manifest and returning replicas to 3, then reports Synced and Healthy.