What is GitOps, and how does managing infrastructure declaratively through git actually work?

#The core idea: git is the desired state, not just a history of it

GitOps is an operating model where the desired state of your infrastructure and applications is declared entirely in git — Kubernetes? manifests, Helm? charts, Kustomize overlays, Terraform HCL — and a piece of automation running inside the target environment continuously compares that declared state against what's actually running, and reconciles any difference. The commit isn't a record of what happened; it's the instruction for what should exist.

This is a meaningful architectural shift from traditional CI/CD, and interviewers ask about it because the shift changes where authority and credentials live, not just which YAML files you edit.

#Push-based CI/CD vs. pull-based GitOps

In a traditional push pipeline, your CI system (GitHub Actions, Jenkins, GitLab CI) builds an artifact and then runs kubectl apply or helm upgrade directly against the cluster, using credentials stored as CI secrets. The CI system reaches into the cluster.

In GitOps, that direction reverses. An operator running inside the cluster — ArgoCD or Flux? are the two dominant choices — watches a git repository and pulls changes into the cluster itself. Nothing external ever needs a cluster-admin kubeconfig; the only thing that needs write access to the cluster is the reconciler already running inside it. This single reversal is the security argument for GitOps: it collapses the number of systems that can mutate production to one, and that one system's only input is an auditable git commit.

#The reconciliation loop

The operator runs a continuous loop: read desired state from git, read actual state from the cluster's API server, diff them, and act. If a developer bumps an image tag in the manifest repo, the operator applies the change. If someone runs kubectl edit directly against a running Deployment and manually changes a replica count, the reconciler notices the drift on its next pass and reverts it back to whatever git says — self-healing infrastructure, whether the "damage" was a mistake or an intentional shortcut.

Most teams split this into two repositories: an application repo (source code, Dockerfile, CI config) and a separate manifest repo (the Kubernetes YAML/Helm/Kustomize describing what should run). CI's only write access to the manifest repo is opening a pull request — often automatically bumping an image tag — which a human or an automated policy merges, and only then does the operator see and apply the change. This keeps "build" and "deploy" as separately auditable, separately permissioned events.

#Why teams adopt it

• Auditability by construction. Every infrastructure change is a git commit with an author, a timestamp, and — if PRs are required — a reviewer. git log on the manifest repo is your deployment history.
• Trivial, reliable rollback. Reverting a bad deploy is git revert, not remembering the exact prior Helm values or manually reconstructing a previous state.
• Reduced blast radius for credentials. No CI runner, laptop, or external script needs a production kubeconfig. Compromising CI no longer means compromising the cluster directly.
• Self-healing against drift. Manual, undocumented changes get silently reverted rather than accumulating as untracked "snowflake" state that nobody can reproduce.
• Consistency across environments. The same reconciliation model and repo structure (e.g., Kustomize base + per-environment overlays) scales from one cluster to a fleet, often via an "app-of-apps" pattern where one root ArgoCD Application manages many child Applications.

#What it costs you

GitOps isn't free of trade-offs. Secrets can't be committed to git in plaintext, so teams need Sealed Secrets, SOPS-encrypted files, or an External Secrets Operator pulling from a vault at reconcile time — an extra piece of infrastructure that has to be set up correctly or secrets management becomes the weak link. Reconciliation isn't instant; there's a sync interval (or a webhook-triggered sync) between "commit merged" and "change applied," which matters for anyone expecting push-and-forget speed. And the self-healing behavior itself can surprise an engineer who kubectl edits something during an incident expecting it to stick, only to watch the operator quietly revert it minutes later — a real operational gotcha worth knowing about before you hit it live.