How would you use GitOps to manage Kubernetes cluster lifecycles?

WHAT THIS TESTS: Whether you understand that GitOps applies to infrastructure lifecycle, not just workloads. The interviewer wants to see if you can separate the control plane that does the GitOps work from the clusters being managed, and if you know how to make cluster creation, upgrades, and teardown fully declarative and auditable through a Git repository.

A GOOD ANSWER COVERS: Four things in order. First, the hub and spoke pattern: a persistent management cluster runs Flux and Cluster API providers, while workload clusters are ephemeral. Second, the Git source of truth holds Cluster API objects like Cluster, MachineDeployment, and KubeadmControlPlane templates, plus any infrastructure-specific custom resources. Third, the reconciliation flow: Flux detects a commit, applies the manifests to the management cluster, and Cluster API controllers provision or mutate the target clusters. Fourth, upgrade mechanics: changing a Kubernetes version field in Git triggers a rolling update through MachineDeployment or control plane templates, and day-two addons are delivered via HelmRelease or Kustomization resources scoped to each workload cluster.

COMMON WRONG ANSWERS: Candidates often answer as if the question were about application deployment, describing Helm charts and namespace-scoped resources while ignoring Cluster API entirely. Another red flag is proposing that CI pipelines run Terraform or kubectl apply directly against a cloud provider; this is push-based infrastructure management, not GitOps. Suggesting that the GitOps agent runs inside the cluster it is trying to provision is also a bootstrap error that shows weak systems design.

LIKELY FOLLOW-UPS: How do you handle secrets like cloud provider credentials or node bootstrap tokens in a GitOps cluster lifecycle workflow? How would you roll back a failed Kubernetes minor version upgrade across a fleet of clusters? What is your strategy for managing cluster addons like CNI or CSI drivers that must exist before workloads schedule? How do you enforce policy or drift detection when infrastructure engineers can still change resources via the cloud console?

ONE CONCRETE EXAMPLE: Imagine a platform team operating fifty workload clusters on AWS. They maintain a management cluster running Flux and the Cluster API AWS provider. Their Git repository contains a Kustomization per environment, each referencing a Cluster API Cluster object with machine templates using AMI IDs and instance types. When the team commits a change to the Kubernetes version field from 1.28.0 to 1.29.0, Flux reconciles the management cluster within two minutes. Cluster API creates new nodes with the updated AMI, cordons old nodes, and drains workloads until the control plane and all node pools are rolled. Addon updates, such as a new CNI Helm chart version, are applied by a separate Flux HelmRelease object targeting each workload cluster through a KubeConfig secret stored on the management cluster.

Source: fluxcd.io