Practice the vocabulary of treating a Git repository as a cluster's single source of truth.
0 / 5 completed
1 / 5
At standup, a dev mentions that a Git repository is the single source of truth for a cluster's desired state, with an automated controller continuously reconciling the live environment to match it. What is this practice called?
GitOps treats a Git repository as the single source of truth for a cluster's desired state, with an automated controller continuously reconciling the live environment to match whatever that repository currently declares. Manually applying a change directly to a live cluster bypasses that source of truth, risking configuration drift the next time someone applies the declared state again. This Git-as-source-of-truth model is what makes an infrastructure change fully auditable and reversible through Git's own history.
2 / 5
During a design review, the team wants a controller running inside the cluster to pull and apply a change from Git automatically, rather than an external CI pipeline pushing a change into the cluster. Which capability supports this?
A pull-based reconciliation controller runs inside the cluster itself, pulling and applying a change from Git automatically rather than depending on an external CI pipeline pushing credentials and changes into the cluster from outside. An external push-based pipeline needs broad, standing access to the cluster to apply a change. This pull-based model keeps the cluster's own credentials from ever needing to be exposed to an external system.
3 / 5
In a code review, a dev notices the reconciliation controller detects and automatically corrects a manual, out-of-band change made directly to the live cluster, reverting it back to match Git. What does this represent?
Drift detection and automatic correction identifies a manual, out-of-band change made directly to the live cluster and reverts it back to match what Git declares, keeping the cluster's actual state consistent with its documented source of truth. Allowing such a change to persist indefinitely lets the live cluster silently diverge from what's documented in Git. This drift correction is what makes Git genuinely trustworthy as the cluster's single source of truth, rather than just an outdated snapshot.
4 / 5
An incident report shows an engineer applied an emergency fix directly to the live cluster, and it was silently reverted hours later when the reconciliation controller detected the drift, resurfacing the original incident. What practice would prevent this?
Committing the emergency fix to Git immediately ensures the reconciliation controller reconciles toward the corrected state, rather than reverting the live cluster back to an outdated, already-broken declared state. Applying a fix directly to the cluster without updating Git leaves exactly this kind of reversion risk in place. This discipline of always committing a real fix to Git first is essential to working safely within a GitOps model during an incident.
5 / 5
During a PR review, a teammate asks why the team enforces Git as the cluster's single source of truth instead of allowing a direct, manual change to the live cluster when convenient. What is the reasoning?
A manual, out-of-band change applied directly to the live cluster silently drifts it away from what's documented in Git, and a GitOps controller's whole purpose is to correct exactly that kind of drift. A real, lasting fix has to go through Git to actually stick under this model. The tradeoff is the added discipline of always committing a change to Git first, even during a fast-moving incident.