Your team keeps its existing CI pipeline but adopts an in-cluster GitOps agent for Kubernetes deploys. Which responsibilities move to the agent, and what does the CI pipeline lose?
answer
- CI builds, CD reconciles
- the boundary is a commit
- green pipeline means intent recorded
- no exit code from a control loop
- verification moves out of the deploy job
basics
~20 sApplying manifests and keeping the cluster converged move to the agent; CI keeps building, testing, scanning, publishing the artifact and recording the desired state. The pipeline loses synchronous deploy feedback — its job finishes before the change is actually running.
solid answer
~50 sThe split is usually described as "CI builds, CD reconciles". CI still owns everything up to and including a published, immutable artifact: compile, test, scan, push the image, then record the new desired state in the configuration repository. From that commit onward the in-cluster agent owns applying the manifests and keeping the cluster matching them. What the pipeline gives up is the deploy step's return value: the job goes green when the push succeeds, not when pods are healthy, so post-deploy smoke tests, deploy-time gating and ordered multi-service releases can no longer live in the same job. Teams recover this by having the agent report status outward — notifications, metrics, or a pipeline step that waits on the agent's reported health — and by moving verification into a separate job triggered after the sync rather than inline.
code
bash · 10 lines# CI's final deployment-related step after the split: record intent, not act
set -euo pipefail
IMAGE="registry.example.com/web:${GIT_SHA}"
docker push "$IMAGE"
git clone --depth 1 [email protected]:org/config.git cfg
cd cfg
sed -i "s|^ image: .*| image: ${IMAGE}|" env/staging/web.yaml
git commit -am "staging: web ${GIT_SHA}"
git push # returns success immediately - nothing is deployed yetgo deeper
Know the shape of the split: your pipeline builds and tests the image and then records the new version in a config repository, and something inside the cluster does the actual deploy.
Be able to list what moves and what stays, and explain why the pipeline's green tick now means the intent was recorded rather than the software is running. Say where smoke tests go instead.
Show you have handled the fallout: alerting on the agent's sync state rather than the pipeline, re-homing post-deploy verification, and dealing with migrations and cross-service ordering that no longer have a job graph to rely on.
Judge whether the hybrid is worth it for your organisation — if teams rebuild a synchronous deploy-and-verify pipeline on top of the agent, you now operate two control planes for one outcome and should say so.
## The hybrid split most teams actually run Adopting pull-based delivery rarely means throwing away the CI system. The common end state is a hybrid: continuous integration stays where it is, and only the deployment act moves into the cluster. Being able to draw that line cleanly is the point of this question. **Stays in CI:** - compiling, unit and integration tests, linting, static analysis - building the container image and pushing it to a registry - vulnerability and licence scanning of the artifact - signing or attesting the artifact - writing the new desired state (typically the image reference) into the configuration repository **Moves to the agent:** - reading the declared state from Git or an OCI artifact - applying it to the cluster's API server - keeping the cluster converged with it afterwards, without a pipeline run - reporting whether the applied state is actually healthy The boundary is a commit. Everything before it is a pipeline that has run to completion; everything after it is a control loop with no run boundary at all. ## What the pipeline loses ### The deploy step's return value A push-based deploy job is synchronous: `kubectl rollout status` blocks, and the job's exit code tells you whether the new version is serving. After the switch, the last deployment-related step is `git push`, which succeeds in milliseconds regardless of what happens in the cluster. The pipeline's green tick now means "the intent was recorded", not "the software is running". Teams that miss this ship a pipeline that reports success while the agent is failing to apply the manifest. ### Post-deploy verification in the same job Smoke tests, contract checks against the deployed environment, or a synthetic transaction used to run in the step after the deploy, sharing its context and its credentials. They now need a trigger that fires *after* the agent has synced and the workload is healthy — a notification from the agent, a scheduled check, or an explicit wait step. ### Deploy-time orchestration A pipeline could sequence "migrate the database, then deploy service A, then service B". A reconciler applies what it finds and orders things by its own dependency rules, not by your job graph. Cross-service ordering has to be expressed declaratively (dependencies between components, health gating) or kept in a pipeline for the specific cases that need it. ### Deploy-time secret injection An imperative deploy could read a secret from the CI secret store and pass it in at apply time. The agent applies what is in the repository, so secrets must reach the cluster another way — encrypted in the repo and decrypted in-cluster, or fetched by an in-cluster operator from an external store. ## Getting feedback back The usual patterns, in increasing order of coupling: 1. **Fire and forget.** The pipeline ends at the commit; the agent's own UI, alerts and notifications are the deploy feedback channel. Simplest, and adequate for many teams. 2. **Notify outward.** The agent sends a webhook or chat message on successful and failed syncs, and alerts fire on "declared state not achieved for N minutes". 3. **Wait in the pipeline.** A final job polls the agent's reported status (or the workload's own health endpoint) until the new revision is live or a timeout expires, then runs smoke tests. This restores a synchronous feel at the cost of a pipeline job that outlives the sync interval and can time out for reasons unrelated to the change. Option 3 is worth calling out carefully in an interview: it is legitimate, but if you find yourself rebuilding a full synchronous deploy-and-verify pipeline on top of the agent, question whether the pull model is buying you enough to justify the second control plane. ## The judgment being tested An interviewer wants to hear that you understand a reconciler is not a remote-control deploy button. It has no run, no exit code, and no notion of your pipeline's ordering. The migration is not "replace one step"; it is moving from a request/response model to an eventually-consistent one, and every practice that assumed a synchronous answer has to be re-homed.
- How would you stop the pipeline from reporting success while the agent is silently failing to apply the manifest?Do not rely on the pipeline for that signal at all. Alert on the agent's own state — declared revision not reached, or sync failing — with a time threshold, so a stuck apply pages someone regardless of which pipeline produced it. If a specific release must be verified inline, add a job that waits on the agent's reported health for that revision and fails on timeout.
- Where do database migrations fit once deploys are reconciled rather than pushed?They are the classic case for keeping some imperative orchestration. Either run the migration in CI before the config commit, so the new schema exists when the agent rolls the workload, or model it as a job in the manifests with ordering and health gating. What you cannot do is assume the reconciler will honour a sequence you never declared.
saying these in an interview costs you the question
- Assuming the pipeline still knows when the deploy finished
- Keeping smoke tests in the job that pushes the commit
- Expecting the reconciler to honour the pipeline's job ordering
- Injecting deploy-time secrets from the CI secret store as before
- Treating the agent as a remote kubectl with a return code