Learn the vocabulary of a GitOps tool that keeps a cluster's live state matched to Git.
0 / 5 completed
1 / 5
At standup, a dev mentions a GitOps continuous delivery tool that continuously compares a cluster's live state against what's declared in Git and shows any difference directly in a dashboard. What is this tool doing?
Continuous, visible application-state synchronization, the core function a tool like Argo CD provides, continuously compares a cluster's live state against what's declared in Git and surfaces any difference directly in a dashboard. A one-time manual deployment script offers no ongoing visibility into whether the live cluster still matches what's declared after that initial deployment. This continuous comparison is what gives a team confidence the cluster genuinely reflects its intended, declared state at any given moment.
2 / 5
During a design review, the team wants a new version declared in Git to require an explicit, manual approval click in the dashboard before it's actually synced to the live cluster. Which capability supports this?
Manual sync mode requires an explicit approval click in the dashboard before a new version declared in Git is actually applied to the live cluster, giving a team a deliberate checkpoint before a change takes effect. Automatic sync mode applies every declared change immediately, which is convenient but removes that deliberate pause. This manual mode is often preferred for a production environment where a human review before deployment adds real value.
3 / 5
In a code review, a dev notices the tool is configured to automatically prune a resource from the live cluster once it's removed from the Git repository, rather than leaving it running indefinitely. What does this represent?
Automatic pruning removes a resource from the live cluster once it's deleted from the Git repository, keeping the live cluster's actual set of resources matched exactly to what's currently declared. Leaving a removed resource running indefinitely lets an orphaned, undocumented resource linger on the cluster with no corresponding entry in Git. This pruning keeps the cluster's live state a true, complete mirror of its declared Git state.
4 / 5
An incident report shows a resource deleted from the Git repository kept running on the live cluster for weeks because automatic pruning had been disabled, consuming resources with no corresponding declared configuration. What practice would prevent this?
Enabling automatic pruning removes a resource from the live cluster the moment it's deleted from Git, preventing exactly the kind of long-lived orphaned resource this incident describes. Disabling pruning permanently leaves a removed resource running with no corresponding declared configuration anywhere. This pruning setting is what keeps a cluster's live state from silently accumulating resources that no longer exist in its source of truth.
5 / 5
During a PR review, a teammate asks why the team relies on a continuous, visible synchronization tool instead of just running a deployment script once and assuming the cluster stays in that state afterward. What is the reasoning?
A cluster's live state can drift from what was originally deployed through a manual change or an orphaned, later-removed resource, and a one-time deployment script has no way to detect that after the fact. Continuous comparison against Git catches drift and prunes an orphaned resource on an ongoing basis. The tradeoff is the added infrastructure of running and maintaining a dedicated continuous delivery tool inside the cluster.