Bootstrapping Argo CD and Letting It Manage Itself
Argo CD manages your apps. Who manages Argo CD? Walk me through how you would bootstrap it from a fresh cluster and where its own config lives in your repo.
Argo CD manages your apps. Who manages Argo CD? Walk me through how you would bootstrap it from a fresh cluster and where its own config lives in your repo.
Argo CD has a chicken-and-egg problem on day one. The cluster has nothing in it, so kubectl is the only tool that can install the first thing. After that, you want Argo CD to manage itself the same way it manages everything else. The flow I use: 1. One bootstrap kubectl apply puts Argo CD into the cluster. I use the upstream install manifest pinned to a version, not latest. That gets you the namespace, the CRDs, the controller, the repo server, the API server. 2. Once Argo CD is up, I apply one Application CR by hand. This Application points at a directory in the manifests repo, something like argocd/bootstrap. That directory contains another Application that points at Argo CD's own Helm chart or Kustomize overlay. So Argo CD starts syncing itself. 3. The same bootstrap directory contains AppProjects, repository credentials (as sealed secrets or external secrets), and a parent Application that points at argocd/applications, which holds every other Application CR for the cluster. After that initial kubectl apply, you never touch Argo CD with kubectl again. Bumping the Argo CD version is a Git commit changing the chart version or image tag in argocd/bootstrap. Adding a new app to the cluster is a Git commit dropping a new Application YAML into argocd/applications. Repo layout I keep for this: argocd/ bootstrap/ # Argo CD itself, plus the root app-of-apps kustomization.yaml values.yaml # Helm values for the argo-cd chart root-app.yaml # the parent Application that points at applications/ projects/ # AppProjects: per-team or per-environment applications/ # one Application YAML per workload or per env One gotcha. Argo CD syncing itself can lock you out if a bad change rolls in. If the controller fails to start because of a config change you just merged, no controller means no reconcile, which means no rollback through Git. Keep the bootstrap Application on manual sync, or at minimum keep a tested rollback commit ready. Some teams keep a separate management cluster running its own Argo CD that watches the workload clusters' Argo CDs, so a broken self-managed instance can still be repaired through GitOps.
Most junior candidates can install Argo CD. Fewer can explain how it ends up managing itself, and even fewer have thought about what happens when self-management goes wrong. This question separates someone who has watched a tutorial from someone who has set up Argo CD in a real environment. Listen for the bootstrap kubectl apply being acknowledged as a one-time thing, a clear repo location for Argo CD's own config, and any awareness of the self-lockout risk.
One-time bootstrap commands
Root Application that bootstraps the rest
Argo CD managing its own install via Helm
- Installing Argo CD with kubectl, then continuing to use kubectl for every config change instead of having it manage itself
- Putting Argo CD's own Application on the same auto-sync settings as workloads, then getting locked out when a bad chart bump crashes the controller
- Forgetting about the repository credentials problem and hard-coding tokens into Git on day one
- What happens if you merge a bad change to the Argo CD chart values and the controller crashloops? How do you recover?
- Would you put Argo CD on auto-sync for itself? Why or why not?
- How do you handle Argo CD version upgrades across many clusters?
- Where do the credentials that Argo CD uses to read your private manifests repo come from? They cannot be in the same repo in plaintext.
More GitOps interview questions
Also worth your time on this topic
Argo CD Multi-Environment Repository Structure Checklist
How to organize your Git repositories when running Argo CD across dev, staging, and production. Covers folder layout, app-of-apps, ApplicationSets, secrets, RBAC, and promotion flow.
60-90 minutes
Structuring a Git Repo for Argo CD Multi-Environment Deployments
How would you structure a Git repo for Argo CD when you have dev, staging, and prod environments?
junior
GitOps with Argo CD: Structuring Your Repository for Multi-Environment Deployments
A practical guide to laying out your Git repository for Argo CD across dev, staging, and production. See real folder structures, Kustomize and Helm patterns, and the pitfalls that bite teams in production.