What is the basic principle of GitOps?

WHAT THIS TESTS Whether you understand that GitOps is declarative and reconciliation-driven, not just storing YAML in Git and running kubectl from a pipeline.

A GOOD ANSWER COVERS GitOps means the desired state of your infrastructure and applications is described declaratively and stored in a Git repository, and an automated agent continuously makes the live system match that declared state. Git is the single source of truth: nothing is changed by hand in the cluster; you change the repo, and the controller applies it. This matters because Git gives you a complete, reviewable, auditable history of every change, pull-request-based approval, instant rollback by reverting a commit, and a clear answer to what should be running. The reconciliation loop also detects and corrects drift, so manual changes or failures are pulled back to the declared state automatically. Pull-based agents like Argo CD or Flux run inside the cluster and watch the repo, which also improves security because the cluster pulls rather than exposing credentials to an external pusher.

COMMON WRONG ANSWERS Labeling any pipeline that runs kubectl apply from CI as GitOps, forgetting the continuous reconciliation, or omitting why Git authority matters (audit, rollback, drift correction).

LIKELY FOLLOW-UPS How does pull-based differ from push-based delivery? How does drift get corrected? How do you roll back?

ONE CONCRETE EXAMPLE You bump an image tag in a Git manifest and open a pull request. After review and merge, Argo CD detects the new desired state and updates the Deployment. Later, someone manually edits the Deployment in the cluster; the controller sees the divergence from Git and reverts it, keeping reality equal to what the repo says.