TL;DR: App-of-apps is an Application whose manifests declare other Applications from a directory, so one commit can bootstrap an entire cluster or hand a team a bounded slice of the platform. Use it for ordered bootstrap and ownership boundaries; use ApplicationSets when children are generated by a rule rather than curated by hand.
How to approach it
Define the pattern in one sentence, then spend the answer on use cases and governance. Explain who can create children, how dependencies become ready and what happens if the parent or a generator removes a child.
A strong answer
Mechanics first, briefly: the root Application points at a path containing manifests of kind Application. Argo CD creates those children, each tracking its own repository, path and project, and they render as a tree in the UI. The parent is a table of contents the platform team reviews.
Three use cases actually earn it:
Cluster bootstrap. One root app installs cert-manager, the ingress controller, monitoring, External Secrets and your policy stack, in declared sync waves. A parent wave orders child Application resources, but does not automatically wait for their workloads to become healthy. Restore an appropriate child-Application health assessment or use explicit orchestration before treating wave order as a dependency gate. Argo CD removed built-in Application health assessment in v1.8. Standing up a new region or a DR cluster becomes replaying one directory against an empty cluster. This is the strongest case and the one to lead with.
Team self-service with guardrails. Each team owns a directory of child Applications, and every child must bind to an Argo CD project that restricts source repositories, destinations and permitted resource kinds, with project RBAC controlling operations. Kubernetes ResourceQuota, LimitRange and admission policy separately enforce consumption limits. The platform team reviews exactly one PR, the one adding the child; after that the team iterates freely inside their own repo. Directory ownership routes review; enforced permissions and admission policy establish the boundary.
Environment grouping. A directory per environment, where promoting a service means a one-line PR moving its pinned digest into the staging directory, then production. Visible, reviewable, reversible.
The honest counterpoint: much of this is now better expressed as ApplicationSets, which generate Applications from lists, directories or cluster discovery. Curated children reviewed individually call for app-of-apps. A rule-generated fleet, the same service replicated across twenty clusters, calls for an ApplicationSet. Mature platforms combine them: an ApplicationSet generates per-cluster roots, and each root carries curated platform children.
The authorization question is "who can change a child Application", because a child is credentials-adjacent: it points at a repository and a destination cluster, so editing it redirects deployments. Projects, RBAC and mandatory review on the parent directory are the actual security boundary. Presenting the pattern as pure convenience misses that entirely.
Bootstrap exercise: creation order versus readiness
Imagine a fictional root Application creates a certificate controller and an application that requests a certificate. The child Application objects appear in the intended order, yet the certificate custom resource fails because its CRD or webhook is not ready. The parent successfully creating an Application does not establish that the child's workload has completed installation.
Define the readiness condition at each dependency: the CRD must be established, the webhook reachable and the certificate controller able to reconcile a test resource. If you use child health to gate parent waves, verify that health assessment is actually configured and that it reports these conditions. Rehearse a controller that never becomes ready; the dependent stage should remain blocked with a useful diagnostic.
Also review who can edit a child's project and destination. A project restriction helps only if an untrusted editor cannot choose a more privileged project. Protect the parent source and enforce allowed bindings through review and admission controls. Argo CD treats app-of-apps creation as an administrative capability. Test rejection of a child targeting a forbidden cluster before granting team self-service.
What interviewers probe next
"App-of-apps or ApplicationSet?" Curation versus generation. Hand-reviewed children with distinct settings favour the pattern; anything describable as "same thing, different parameters" favours the generator.
"A new team onboards next week. What happens?" A PR adds their directory entry plus a project binding, CI validates destinations, platform reviews, then the bootstrap pipeline creates the resources and verifies health. Existing platform capacity and approvals determine how long onboarding takes.
"The parent shows Healthy but a child is degraded. Then what?" By default the tree displays it and nothing pages anyone, so alerting belongs outside the parent: notifications on child health plus a policy that blocks promotion while a child is degraded.
Common mistakes
Reciting the manifest structure with no use case attached to it.
Nesting apps-of-apps three levels deep until nobody can trace what deployed what, which defeats the auditability that justified GitOps.
Avoiding ApplicationSets entirely, then hand-writing fifty near-identical child manifests that drift apart within a quarter.