GitOps Basics and Workflows: CNPA practice questions

Day to day, a GitOps workflow looks like ordinary collaboration on a repository, with the deployment step taken over by an agent. A developer or a pipeline proposes a change to the desired state, for example a new image tag or a higher replica count, as a pull request against the configuration repository. Reviewers and automated checks look at the diff. Once it is merged, the agent in the cluster notices the new revision, renders the manifests and applies them. Nobody runs kubectl against production, and the merged commit records who changed what and why.

The vocabulary differs slightly between tools, so it pays to know both. In Argo CD an Application is a custom resource for a group of Kubernetes resources defined by a manifest. The target state is what the files in Git describe and the live state is what is actually deployed. Sync status says whether the two match, a sync is the process of moving the application to its target state, a refresh compares the latest code in Git with the live state, and health reports whether the application is running correctly and can serve requests. Manifests can come from Kustomize, Helm, Jsonnet or plain YAML directories.

In Flux, a Source such as a GitRepository or OCIRepository checks its origin on a defined interval and produces a new artifact when a newer matching revision appears. A Kustomization applies that artifact to the cluster. Its reconciliation runs every five minutes by default, configurable with .spec.interval, and changes made with kubectl edit, patch or delete are promptly reverted; the only ways around that are to suspend reconciliation or push the change to Git. Flux installs itself the same way through a bootstrap, after which it manages its own components from the repository.

Drift handling is configurable and a frequent exam theme. Argo CD's automated sync, as a safety mechanism, does not delete resources that disappear from Git unless pruning is enabled, and it does not react to changes made directly in the live cluster unless self-healing is enabled. With selfHeal on, a manual edit is synced back to what Git says. Rollback follows the same path as any change: revert the commit, or point the application at an earlier revision, and let the agent reconcile.

Common misconceptions are that GitOps rules out emergency fixes (they go through a fast commit, or a deliberate and visible suspension of reconciliation), that an agent applying from Git makes review optional (review is where much of the safety comes from), and that plain-text secrets can live in the repository. Secrets need a secret store, such as the External Secrets project listed in the CNCF Platforms White Paper, or encryption before they are committed.

Expect associate-level questions that describe a manual change in the cluster and ask what happens next, ask which component detects drift, or ask what a pull request represents in a GitOps workflow.