GitOps keeps the desired state of the system in git and runs an agent inside the target environment that continuously pulls that state and reconciles reality against it. A push based deploy has CI hold credentials to the cluster and apply changes from outside. The pull model means CI never needs production credentials, drift gets corrected automatically, and git history is an accurate audit log of what is deployed.
Why interviewers ask this
This tests whether you can distinguish a genuine architectural difference from a branding exercise. The interviewer looks for the credential direction and continuous reconciliation as the real differences, not just storing YAML in git. Good candidates also raise the hard parts: promoting between environments, handling secrets in a public facing repository, and what happens when someone changes something manually.
How to structure your answer
- Define GitOps by the reconciliation loop, not by using git.
- Contrast credential direction: pull versus push.
- Explain drift correction and auditability as the practical wins.
- Name the hard parts: promotion, secrets, and emergency changes.
Example answer
The defining bit is not that the manifests live in git, it is that an agent inside the cluster watches the repository and continuously reconciles the running state to match. Push based means my CI job holds a kubeconfig with write access and applies from outside, so those credentials exist in the CI system, and once it applies it stops caring. With the pull model, CI only ever writes to a repository. Nothing outside needs cluster credentials, which narrows the attack surface a lot. And because reconciliation is a loop, not an event, if somebody edits a deployment by hand at two in the morning, it gets reverted and I can see the drift. The awkward parts are real though. Promotion between environments becomes a pull request that changes an image tag in an overlay, which feels slower until you appreciate that it is also the audit record. Secrets need encryption against a key management service, since the repository itself is not a safe place. And you need a documented break glass path for when reconciliation is the thing standing between you and fixing an outage.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you promote a change from staging to production in this model?
- How do you handle a rollback when the repository is the source of truth?
- What is your break glass procedure during an incident?
Related devops engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions