App-of-Apps Pattern vs ApplicationSets
Explain the app-of-apps pattern in Argo CD. When would you pick it over ApplicationSets?
Explain the app-of-apps pattern in Argo CD. When would you pick it over ApplicationSets?
App-of-apps is a pattern, not a feature. One parent Argo CD Application points at a directory of YAML files. Those YAML files are themselves Argo CD Application CRs. Argo CD syncs the parent, which creates the children, which deploy actual workloads. It gives you one bootstrap entry point per cluster: install the parent, everything else shows up. ApplicationSet is a controller that does something similar but template-driven. You write one Application template plus a generator (Git directory, list, cluster, matrix, pull request, SCM provider) and the controller produces N Applications from it. Add a new directory under overlays, an Application appears. Open a pull request, a preview Application appears. Close it, the preview gets cleaned up. Use ApplicationSets when: 1. You ship the same app across many environments or clusters and the only difference is a parameter (path, cluster URL, namespace). 2. You want pull-request preview environments. 3. Environments come and go often enough that hand-editing Application YAML is annoying. Use app-of-apps when: 1. Each Application is genuinely different. A monitoring stack, an ingress controller, and three apps do not fit one template. 2. You want a clear, hand-reviewed list of cluster components in Git. Real setups use both. App-of-apps bootstraps the platform layer (cert-manager, ingress, monitoring, the ApplicationSet controller itself). ApplicationSets generate per-environment Applications for actual workloads. The platform is curated; the apps are templated. One gotcha to mention. Deleting an ApplicationSet by default deletes every Application it generated, and Argo CD will then delete the workloads those Applications managed. Set preserveResourcesOnDeletion: true on the ApplicationSet spec if you do not want that cascade, or use a Finalizer carefully.
This is a senior-leaning question because the answer hinges on operational experience: knowing when templating pays for itself, and what happens when you remove the template. Listen for candidates who can name a generator type other than Git directory (PullRequest, Cluster, Matrix are the interesting ones) and who flag the deletion behavior. Bonus points for mentioning that the ApplicationSet controller is itself usually deployed via app-of-apps so it can manage everything else.
App-of-apps parent Application
ApplicationSet with Git directory generator
ApplicationSet that fans out across registered clusters
- Hand-writing one Application YAML per environment across 30 environments instead of using an ApplicationSet
- Not knowing that deleting the ApplicationSet by default cascades and deletes the generated Applications plus their workloads
- Treating ApplicationSet generators as magic and not being able to predict what Applications the template will produce for a given input
- What happens if you delete an ApplicationSet? How do you stop it from deleting prod by accident?
- Walk me through how the PullRequest generator builds preview environments and what cleans them up.
- How would you bootstrap a brand new cluster from zero with just one kubectl apply?
- When would the Matrix generator make sense, and what is the trap with it?
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.