Walk me through deploying a new version using a GitOps workflow
Separation of CI from CD and Git as the single source of truth.
Merge updates manifests; the GitOps controller compares desired state in Git to live state and reconciles.
Mixing CI with CD or recommending manual deploy.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
After CI updates the image tag in the Git repository, how is the new version deployed in a GitOps workflow?
- a.The CI pipeline pushes the update directly to the cluster using kubectl apply
- b.The cluster watches the container registry and automatically rolls out the new image tag
- c.The GitOps controller detects the manifest change and reconciles the cluster state to match GitCorrect
- d.A release engineer manually triggers a sync job to update the live deployment
Why? this is the answer
In GitOps, the GitOps controller continuously compares the declarative desired state in Git with the live cluster state and automatically reconciles differences, so the cluster converges to what is defined in version control. The distractor describing CI pushing directly with kubectl apply describes a traditional push-based pipeline, which violates the GitOps principle of keeping cluster access out of the build stage and fails to use Git as the single source of truth.
Just read this? Test yourself on what you have been reading.
Read the original → argo-cd.readthedocs.io
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on gitops — each one lists the topics its interview covers.
See open roles