In GitOps, how are the Desired State declarations pulled from the source?

GitOps follows a “pull-based” reconciliation model. One or more agents (e.g., Flux, Argo CD) run inside or near the target system, periodically polling the declared configuration stored in the Git repository. When a difference between the live system and the repository is detected, the agent automatically reconciles the system to match the desired state. No human-initiated CLI/API call or external webhook push is required once the agent is running; the agent alone performs the fetch and apply cycles.

A. “Sending a request” implies an ad-hoc, user-initiated pull; GitOps relies on an always-running agent, not sporadic manual requests.
B. CLI/API calls are manual or scripted pushes; GitOps purposely removes this human step in favor of autonomous agents.
D. Webhooks represent a push model that notifies the cluster; GitOps mandates a pull model driven from within the cluster, so manual webhook triggers are unnecessary.

1. GitOps Working Group, “GitOps Principles,” Principle 4: Continuous Reconciliation – “Software agents… continuously observe and pull desired state from the source.” (v1.0, CNCF/LF, 2021).

2. Weaveworks, “GitOps – Operations by Pull Request,” p. 4: “An operator in the cluster periodically polls Git and automatically applies changes.” (Whitepaper, 2019).

3. Flux v2 Documentation, Intro → How Flux Works, para 2: “Flux runs as a daemon inside Kubernetes and… automatically pulls the config from Git.” (https://fluxcd.io/docs).

4. Argo CD Documentation, “Key Features,” sec. Continuous Delivery: “A Kubernetes controller continuously monitors repositories and… synchronizes the cluster state.” (https://argo-cd.readthedocs.io).