Walk me through deploying a new version using a GitOps workflow

WHAT THIS TESTS: Whether the candidate understands the fundamental GitOps principle that the Git repository serves as the single source of truth for desired state, and that the deployment pipeline is pull-based and declarative rather than push-based and imperative. The interviewer cares that you separate the concerns of continuous integration from continuous delivery and recognize that Kubernetes application definitions and configurations must be declarative and version controlled.

A GOOD ANSWER COVERS: Four things in order. First, the developer merges a pull request that updates the declarative application manifests stored in the Git repository. Second, a continuous integration process may build a new container image, run tests, and update the image reference in the version-controlled manifests, but it does not touch the cluster directly. Third, the GitOps continuous delivery tool detects that the desired state in Git has changed and compares it against the live state running in the Kubernetes cluster. Fourth, the tool automatically reconciles the cluster so that the live state matches the declarative desired state defined in version control, making the deployment automated, auditable, and easy to reason about.

COMMON WRONG ANSWERS: Three red flags stand out. One is describing a traditional push-based pipeline where CI executes kubectl apply or helm upgrade directly against the cluster, which violates the GitOps model of keeping cluster access out of the build pipeline. Another is omitting the idea of automated reconciliation or drift detection, suggesting that deployment is a one-shot manual action rather than a continuous loop. A third is failing to distinguish between the artifact build phase and the deployment phase, collapsing CI and CD into a single opaque step that lacks clarity.

LIKELY FOLLOW-UPS: The interviewer may ask how rollbacks work in a GitOps workflow, which is done by reverting the commit in Git so the previous declarative state becomes the desired state again. They may ask how you would handle secrets outside of Git, or how the controller knows when to sync if it is polling the repository versus using a webhook. They might also probe how you manage environments such as staging and production, typically by using separate Git branches or directories for declarative configurations.

ONE CONCRETE EXAMPLE: Imagine a team using Argo CD for Kubernetes continuous delivery. A developer merges a pull request that changes the image tag in a declarative Deployment manifest from version 1.2 to 1.3 in the Git repository. The GitOps controller notices the version-controlled desired state no longer matches the live cluster state. Because application deployment and lifecycle management are automated, the controller reconciles the cluster by applying the updated manifest so the live state converges to the desired state stored in Git. The entire change is auditable because the Git commit history records exactly who changed what and when.