GitOps Terminology: CGOA practice questions

GitOps terminology is the vocabulary the rest of the CGOA material builds on, worth 20% of the curriculum. The curriculum lists nine terms: continuous, declarative description, desired state, state drift, state reconciliation, GitOps managed software system, state store, feedback loop and rollback. The OpenGitOps glossary defines most of them precisely, and the exact wording matters because several terms sound alike.

Desired state is the aggregate of all configuration data that is sufficient to recreate the system, so that instances built from it are indistinguishable. It typically excludes persistent application data such as database contents, but often includes credentials and the configuration of recovery tooling. A declarative description is a configuration that describes that operating state without specifying the procedures to reach it, which separates what you want from how it gets done.

The state store is a system for storing immutable versions of desired state declarations. It should provide access control and auditing on changes to the desired state. Git is the canonical example and the origin of the name, but the glossary is explicit that any system meeting these criteria may be used.

Drift is the situation where a system's actual state has moved, or is in the process of moving, away from the desired state. Common causes are a manual edit to a live resource or an external system changing something the agent manages. Reconciliation is the process of ensuring the actual state matches the desired state. Unlike a traditional pipeline that only acts when a job runs, GitOps triggers reconciliation whenever there is divergence, whether the cause is a new version in the store or drift.

Continuous carries its usual industry meaning: reconciliation keeps happening, but it does not have to be instantaneous. Pull, in the same glossary, means agents must be able to access the desired state from the store at any time, not only when there is an intentional change.

A GitOps managed software system has three parts: one or more runtime environments with the resources under management, management agents within each runtime, and policies controlling access to and management of repositories, deployments and runtimes. Feedback comes from control theory: it is how previous attempts to apply the desired state have affected the actual state. OpenGitOps assumes a closed loop, where feedback can lead to actions such as adding resources, rolling back or alerting a human operator.

Rollback follows from the store being versioned. Returning to a previous version of the desired state, for example by reverting a commit, lets the agent reconcile the system back to that version instead of someone undoing changes by hand.