Question 40
Application DeliveryIn the "pull-based" GitOps model, where does the initiative for updating the cluster state originate?
Correct answer: C
Explanation
In a pull-based GitOps model, the cluster does not wait for external pushes; the in-cluster operator initiates reconciliation by pulling desired state from Git. This matches the definition of pull-based control, where "the GitOps operator running inside the cluster pulls changes from the Git repository" and applies them to the cluster.
Why each option is right or wrong
A. The CI server pushes changes directly to the Kubernetes API server.
B. The developer manually runs kubectl apply from their workstation.
C. The GitOps operator running inside the cluster pulls changes from the Git repository.
In a pull-based GitOps architecture, the reconciliation loop is initiated by the in-cluster controller, not by an external deployment system. The operator continuously compares the live cluster state with the desired state stored in Git and then fetches the repository contents to apply any drift corrections; the defining feature is that the cluster-side agent originates the update cycle.
D. An external webhook triggers the update based on Git commits.
E. The Git repository pushes changes directly to the cluster nodes.