KCNA - Cloud Native Application Delivery (16% of the exam) - Section 3.1
Explain GitOps and how it differs from a push-based deployment pipeline.
Git as the single source of truth, continuous reconciliation of cluster state against the repository, and the pull-based agent model implemented by Argo CD and Flux. Also the auditability and rollback properties that follow from it.
GitOps principlesArgo CDFluxpull versus push deploymentdeclarative configuration in Git
A platform team currently deploys by having their CI server run kubectl apply against the cluster using stored admin credentials after each merge. They want to adopt a pull-based GitOps model instead. Which change best characterises that shift?
AThe CI server keeps applying manifests to the cluster, but each commit is now cryptographically signed before it is pushed.
BDevelopers run kubectl apply from their own laptops after each merge instead of relying on the shared CI server.
CThe CI pipeline builds the container image and pushes it to the registry automatically on every merge to the main branch.
DAn in-cluster agent continuously pulls the desired state from the Git repository and reconciles the live cluster to match it.check_circle Correct
Pull-based GitOps uses an in-cluster agent that reconciles the cluster against Git, unlike a push pipeline that applies changes from outside. The essence of GitOps is a reconciliation loop running inside the cluster that treats Git as the source of truth and continuously converges live state toward the declared state, rather than an external system pushing changes in.
Why A is wrong: Signing commits is a sound supply-chain practice and feels GitOps-flavoured, but the CI server still pushes changes into the cluster, so the delivery model is unchanged.
Why B is wrong: Moving where the command runs is tempting because it decentralises deployment, but it is still an imperative push of state into the cluster, not a pull-based reconciliation.
Why C is wrong: Automated image builds are part of continuous integration and often sit alongside GitOps, but building and pushing an image is not the deployment model and does not describe pull-based delivery.
Why D is correct: Pull-based GitOps places a reconciliation agent inside the cluster that watches Git and converges the live state towards the declared state, which is the defining shift away from push.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
Run kubectl rollout undo on each affected Deployment directly against the live cluster to restore the earlier revision.
errorWhy it is wrong: This can revert a Deployment quickly, but the change lives outside Git, so the agent will treat it as drift and reconcile the broken state straight back.
The external CI system encrypts the stored cluster credentials at rest, so a breach of that system cannot expose them.
errorWhy it is wrong: Encryption at rest is good hygiene and sounds reassuring, but the CI system still holds and uses the credentials, so the external exposure the team objected to remains.
The deployment is triggered by developers manually running apply commands from their laptops instead of by the CI system.
errorWhy it is wrong: This is tempting because both involve people committing code, but pull-based GitOps removes manual apply steps entirely; the change does not move the trigger to laptops, it moves it to an in-cluster agent.