What is Configuration Drift?
Configuration drift is when the actual running state of your system diverges from the intended state defined in your source of truth. In a push-based world, drift accumulates silently. A manual kubectl patch, a Helm upgrade run from a laptop, a ConfigMap edited directly — each one moves the cluster further from what Git describes, and nobody knows until something breaks.
Detecting Drift
Because the GitOps agent inside your cluster is always comparing Git (desired state) vs. Kubernetes (actual state), it immediately knows when they diverge.
If someone manually changes a Service port from 80 to 8080 using kubectl edit service, the GitOps operator sees: "Git says port 80, cluster says port 8080. We have drift."
The agent surfaces this as a sync status — in ArgoCD's UI, the application turns yellow and shows "OutOfSync." In Flux, the Kustomization resource reports a reconciliation failure. Either way, the drift is visible and actionable immediately, not days later when a bug report arrives.
Self-Healing
In a pull-based GitOps model, the operator can be configured for auto-sync (also called self-healing). As soon as it detects the drift described above, it immediately reapplies the manifest from Git, reverting the manual change back to port 80.
This enforces Git as the absolute source of truth and eliminates "cowboy engineering" directly in production. The practical effect: if a change isn't in Git, it doesn't survive the next reconciliation loop. This forces all changes through the PR process, which means every change is reviewed, logged, and reversible.
The reconciliation loop is the heartbeat of GitOps. ArgoCD and Flux both run this loop on a configurable interval (typically every 3–5 minutes), continuously comparing desired state to actual state and correcting any differences.
A common interview scenario: "An engineer manually scales a Deployment from 3 to 10 replicas in production to handle a traffic spike. Your GitOps tool is configured with auto-sync. What happens?" The answer: the GitOps agent will revert the Deployment back to 3 replicas on the next reconciliation cycle, because Git still says 3. The correct procedure is to update the replica count in Git first, then let the agent apply it. This is a great opportunity to discuss the trade-off between GitOps purity and operational flexibility during incidents.