What is GitOps? Git as the source of truth for deployments
GitOps is a way of managing infrastructure and application deployments by using a Git repository as the single source of truth — you describe the desired state in Git, and automated tooling continuously makes the live system match it. Instead of an engineer running commands against production, or a pipeline pushing changes out on every merge, an agent inside the target environment watches the repository and pulls changes in on its own. This guide covers the core idea, how the reconciliation loop actually works, how GitOps relates to the CI/CD and infrastructure-as-code practices it builds on, its benefits and honest limits, and the tools you are likely to meet.
The core idea: desired state, declared in Git
GitOps starts from the same premise as infrastructure as code — that infrastructure and configuration should be described declaratively, in version-controlled files, rather than configured by hand. Our explainer on infrastructure as code covers that foundation in more depth; GitOps is best understood as a specific, disciplined way of operating on top of it.
What GitOps adds is a strict rule about where authority lives: the Git repository is not just a record of what infrastructure should look like, it is the only source of truth. Nothing is considered “live” or “correct” unless it is reflected in the repository, and nothing should be changed by editing the live system directly.
How it works: a reconciliation loop, not a one-off push
A Git repository holds the desired state of the system — Kubernetes manifests, configuration, infrastructure definitions. An agent or operator running inside the target environment continuously compares that desired state against what is actually running, and automatically reconciles any difference, pulling changes towards the repository rather than waiting to be pushed.
Changes happen by proposing an update to the repository, typically as a pull request. That gives GitOps changes ordinary code review, a permanent audit trail of who changed what and why, and a straightforward way to undo a bad change: revert the commit, and the reconciliation loop pulls the system back to the previous known-good state on its own.
How GitOps relates to CI/CD and DevOps
GitOps is best thought of as an evolution of CI/CD and DevOps practice rather than a replacement for either — our explainers on what a CI/CD pipeline is and what DevOps means cover that broader foundation. Where it differs is the direction of deployment: a traditional pipeline typically “pushes” a change out to the target environment as its final step, whereas GitOps is usually “pull-based” — an agent already running inside the environment notices the repository has changed and pulls the update in itself.
That distinction matters operationally. A pull-based agent inside the cluster never needs deployment credentials handed to an external pipeline, which is one reason GitOps is often discussed alongside tightening deployment security as much as improving deployment speed.
Benefits and honest limits
Because every change to the live system starts as a reviewed commit, GitOps gives strong auditability, consistent, repeatable deployments, and rollback that is just as easy as any other Git revert. It also removes a common source of drift — manual, undocumented changes made directly against production that nobody remembers making.
The honest limits are worth stating plainly: GitOps needs real discipline, since any change made outside the declared process is quietly overwritten or fought by the reconciliation loop, which can surprise a team the first time it happens. It also needs tooling to run the reconciliation agent, and while GitOps is not limited to Kubernetes, it is by far the environment it fits most naturally, and most of the mature tooling assumes it.
- Benefits: auditability via pull requests, consistency between declared and running state, easy rollback by reverting a commit, fewer undocumented manual changes.
- Limits: requires disciplined process and dedicated tooling; best suited to (though not exclusive to) Kubernetes environments.
Tools you are likely to meet
Argo CD and Flux are the two GitOps tools most commonly used in practice, both built around the same reconciliation-loop model described above — watching a Git repository and continuously syncing a Kubernetes cluster to match it. This article deliberately stays at the level of what they do rather than comparing specific versions or feature sets.
Where it fits in modern cloud-native operations
GitOps has become a default pattern for operating Kubernetes at scale, and it appears in cloud operations study alongside broader deployment-automation topics. The AWS CloudOps Engineer Associate (SOA-C03) exam covers reliable, repeatable deployment practice more generally; the Kubernetes and Cloud Native Associate (KCNA) is the natural place to meet GitOps tooling directly, since it is where the pattern is most established.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.