GitOps Principles: CGOA practice questions

OpenGitOps, a project overseen by the GitOps Working Group, publishes four principles (version 1.0.0) that define what makes a system GitOps-managed. They are the largest part of the CGOA curriculum at 30%, and each one is a requirement on the desired state or on the agents that act on it.

Declarative: a system managed by GitOps must have its desired state expressed declaratively. A declarative description states the operating state the system should be in without specifying the procedures to get there. Kubernetes manifests are the familiar example: with declarative object configuration you keep files that describe objects, and kubectl apply detects per object whether to create, patch or delete. A shell script of kubectl commands is the opposite, because it records steps rather than an end state.

Versioned and immutable: desired state is stored in a way that enforces immutability and versioning and retains a complete version history. Every change produces a new version instead of overwriting the old one, which gives an audit trail of who changed what and when, and makes rollback a matter of returning to an earlier version. Git satisfies this naturally through its commit history, but the principle is about the property, not the tool.

Pulled automatically: software agents automatically pull the desired state declarations from the source. The agent inside or alongside the runtime fetches what it needs, rather than an external pipeline pushing changes into the environment. Because the agent can fetch at any moment, it does not depend on someone announcing a change. A practical consequence is that the build system does not have to hold credentials that grant direct access to production.

Continuously reconciled: software agents continuously observe the actual system state and attempt to apply the desired state. Continuous here means the loop keeps running over time, not that every correction is instantaneous. When the observed state diverges, whether because of a new commit or because someone edited a live resource by hand, the agent works to bring it back.

The principles also tell you what GitOps is not. Manual approval gates and hand-run deployments are not among them; review can still happen, typically on the pull request that changes the desired state, but applying that state is automated. Imperative scripts, mutable configuration edited in place and push-only pipelines each break at least one principle. When judging a scenario, check each principle in turn: is the target state declared, is every version kept, does an agent fetch it automatically, and does something keep comparing and correcting.