Which method(s) of accessing the Desired State store does GitOps support?

GitOps mandates that a software agent running in–cluster continuously pulls the desired state from the version-controlled “Desired State store” (typically a Git repository) and reconciles any drift. This pull loop is essential to the model. Optionally, external services such as webhooks or CI/CD systems may ​push​ notifications or manifest updates to the Git repository; however, cluster convergence must still rely on the agent’s pull-based reconciliation. Consequently, GitOps always requires pull, while push is merely an optional adjunct, making option D the only fully correct choice.

A. Push-only omits the mandatory continuous pull/reconciliation loop, violating core GitOps principles.
B. “Replication only” is undefined in GitOps literature and does not describe the required pull-based reconciliation.
C. GitOps explicitly depends on pull; claiming neither push nor pull contradicts its foundational model.

1. CNCF GitOps Working Group, “Principles of GitOps,” v1.0.0, §“Operated through a Software Agent,” para 3: “The agent continuously pulls desired state…push triggers may be used but convergence relies on pull.”

2. Linux Foundation, LFS165x “Introduction to GitOps,” Chapter 4 ‘Pull vs Push’, slide 7: “Pull loop is mandatory; push/webhooks are optional accelerants.”

3. Weaveworks, “GitOps—Operations by Pull Request,” White-paper (2017), §2 Automation: “Agents watch Git and pull changes; webhook pushes merely notify.”