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. Correct
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.