What is the 'single source of truth' principle in GitOps?

In GitOps, the Git repository is the system state. Every resource that should exist in the cluster — deployments, services, config maps, RBAC rules, network policies — is represented as a committed file. The repository is not a backup or documentation artifact; it is the authoritative record, and the cluster is just the materialised form of what Git contains.

Practical implications of this principle:

• No out-of-band changes: Running kubectl apply -f directly, editing a ConfigMap in the Kubernetes dashboard, or scaling a deployment manually all create "drift" — a gap between what Git says and what the cluster is doing. A GitOps operator will detect and revert those changes on its next reconciliation cycle.
• All changes via pull request: A developer who wants to change a replica count opens a PR, gets it reviewed and approved, and merges it. The operator then applies the change automatically. There is no separate "deployment approval" step because the PR is the approval.
• History as an audit log: git log shows exactly who changed what, when, and why. This satisfies SOC 2, PCI-DSS, and similar compliance requirements without building a separate audit system.
• Reproducibility: Because the entire desired state is in Git, spinning up a new environment is a matter of pointing a GitOps operator at the same repository and branch. There are no snowflake servers.

The single-source-of-truth principle breaks down if teams maintain parallel state (e.g., Helm releases applied manually alongside Argo CD-managed ones). Discipline about eliminating all write paths to the cluster other than the operator is essential.