In a GitOps workflow using Crossplane, how is infrastructure provisioned across multiple clusters?

The core principle of a GitOps workflow is using Git as the single source of truth for declarative infrastructure and applications. Crossplane extends Kubernetes with Custom Resource Definitions (CRDs) that represent external infrastructure (e.g., S3 buckets, RDS instances). In this model, the desired state of the infrastructure for one or more clusters is defined as YAML manifests and committed to a Git repository. Crossplane's controllers, running in a management cluster, continuously watch these resources and reconcile the actual state of the infrastructure in the cloud provider with the desired state declared in Git, creating, updating, or deleting resources automatically.

A. This describes a traditional CI/CD approach using imperative scripts (like shell or Python), which is contrary to the declarative, reconciliation-based model of GitOps.

C. This is a manual process and uses Git for documentation, not as a source of truth for automation, which fundamentally contradicts the principles of GitOps.

D. Manually applying manifests with kubectl is an imperative action. A true GitOps workflow automates this step using an agent (like Argo CD or Flux) that syncs the cluster state with Git.

1. Crossplane Official Documentation

"Introduction to Crossplane": "Crossplane is a declarative control plane... This declarative approach is a perfect fit for a GitOps style workflow where the desired state of your infrastructure is stored in a Git repository and applied to your cluster." This directly supports the concept of defining resources declaratively in Git for reconciliation. (Source: Crossplane.io Documentation

docs.crossplane.io/v1.15/)

2. Cloud Native Computing Foundation (CNCF) Blog

"How to GitOps Your Infrastructure with Crossplane and Argo CD": "The core idea of GitOps is to have a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository." This article explicitly details the workflow described in the correct answer. (Source: CNCF Blog

Nov 18

2020)

3. The GitOps Working Group

OpenGitOps Principles v1.0.0: Principle 1 states

"A system managed by GitOps must have its desired state expressed declaratively." Principle 2 adds

"Desired state is stored in a way that enforces immutability

versioning and retains a complete version history." This reinforces that declarative definitions in Git are foundational. (Source: OpenGitOps Project

opengitops.dev/principles/)