Explain GitOps and how an agent knows when to apply changes

WHAT THIS TESTS: This question probes whether you see GitOps as a paradigm rather than a tool. The interviewer wants to know if you understand the difference between push-based CI/CD and pull-based reconciliation, and whether you can articulate why Git serves as the single source of truth for declarative infrastructure. Senior candidates should demonstrate that they grasp immutable desired state, drift detection, and self-healing clusters.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, define the core principle: Git is the single source of truth for the desired state of the system, and all infrastructure is declared in version-controlled files. Second, explain the mechanism: the GitOps agent runs inside the cluster and continuously polls the Git repository at a set interval, or optionally receives webhook events, to notice new commits. Third, describe the reconciliation loop: the agent compares the desired state stored in Git against the actual live state of the cluster by querying the Kubernetes API. Fourth, state the action: when the agent detects drift or new desired state, it applies changes to converge the cluster toward the Git-defined state, and it can also prune resources that were removed from Git.

COMMON WRONG ANSWERS: A common wrong answer is saying the CI server pushes changes to the cluster after a build. That describes traditional CI/CD, not GitOps. Another red flag is claiming the agent relies solely on human approval or manual sync for every change; while sync windows or manual gates exist, the fundamental model is automated reconciliation. Some candidates also conflate GitOps with simply storing YAML in Git and running kubectl apply from a laptop, missing the continuous loop entirely.

LIKELY FOLLOW-UPS: Interviewers often follow up by asking how you would handle secrets in GitOps, since plain text secrets should not live in Git. They may ask about disaster recovery and whether you can rebuild a cluster from Git alone. Another common tangent is comparing polling versus webhooks for change detection, or asking how you would manage multiple environments and promotion strategies without breaking the GitOps model.

ONE CONCRETE EXAMPLE: Imagine a team uses Argo CD to manage a microservices fleet. A developer merges a pull request that changes a Deployment replica count from three to five in the main branch. Argo CD polls the repository every three minutes, detects the new commit, reads the updated manifest, compares it against the live Deployment object in the cluster, sees a mismatch in the replicas field, and patches the Deployment to five replicas. If a manual operator later scales the Deployment to seven via kubectl, Argo CD will detect that drift on its next poll and scale it back to five, demonstrating self-healing.