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. A definition-only response fails at this level because the interviewer is probing whether you have run a growing fleet, not whether you read the docs page.
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. The ownership boundary is made of directories and projects rather than tickets.
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.
Governance is where strong candidates separate. The follow-up hiding behind this pattern 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.
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.