How GitOps controllers detect drift and sync
reconciliation mechanics.
the controller renders desired manifests from Git, diffs them against live cluster objects, marks OutOfSync, then a sync applies the diff to converge.
thinking it only acts on Git commits.
What's really being asked
Whether you understand that GitOps controllers continuously compare two states and converge them, and that drift can originate from either side.
The full answer
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.
The mistakes people make
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.
What usually comes next
What is self-heal versus manual sync? How do sync waves order resources? What does prune do and why is it risky?
A 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.
Interview question
An engineer manually scales a Deployment with kubectl, but no Git commit was made. Will a GitOps controller flag it?
- a.No, because manual kubectl changes are outside the controller's scope
- b.No, because drift is only detected when a new commit lands in Git
- c.Only if a webhook was configured for that namespace
- d.Yes, because it diffs live state against Git regardless of which side changedCorrect
Why? this is the answer
The controller continuously compares rendered desired state to live cluster state, so a manual change creates a diff and an OutOfSync status. It does not depend on a Git commit or a webhook to notice drift.
Just read this? Test yourself on what you have been reading.
Read the original → argo-cd.readthedocs.io
- #gitops
- #argocd
- #flux
- #reconciliation
- #drift
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on gitops — each one lists the topics its interview covers.
See open roles