In GitOps, what is the app-of-apps (root application) composition pattern, and what does it change about how a new component reaches a cluster?

## The problem it solves A GitOps controller reconciles *registered units* — each one binds a source (repo, revision, path) to a destination (cluster, namespace). A cluster running a real platform has a lot of them: ingress controller, cert manager, monitoring stack, log shipper, policy engine, secret operator, plus every product team's services. Registering thirty of those objects by hand on every cluster is exactly the manual, drifting work GitOps exists to remove — and it is invisible to review, because those objects live only in the cluster. **App-of-apps** closes the loop: make the registrations themselves declarative. You register one *root* unit whose rendered manifests are more units. The controller reconciles the root, which creates children, and each child reconciles its own component. ```text root (points at platform/apps/) ├─ ingress -> platform/ingress/ ├─ monitoring-> platform/monitoring/ ├─ policy -> platform/policy/ └─ team-a -> teams/a/prod/ ``` Nothing about the nesting is special to the controller: a child definition is just another manifest, so it obeys the same reconcile, drift and prune semantics as a Deployment would. ## What actually changes **The inventory becomes a file.** "What does this cluster run?" is answered by reading one directory in Git rather than querying the cluster. Onboarding is a pull request that adds a child; offboarding is deleting that child, which — with pruning enabled — removes the component's objects too. **Bootstrap collapses to one handle.** The bootstrap step registers exactly one thing. Everything else arrives transitively, which is what makes rebuilding a cluster or standing up cluster number fifty tractable. **Granularity survives.** This is why the pattern beats "put all the manifests in one big unit". Each child keeps its own source path, its own revision, its own sync status and its own health — so one team's broken chart shows up as one unhealthy child instead of failing the whole cluster's sync, and a component can be pinned to a different revision from its neighbours. **Ownership boundaries get a place to live.** Because children are generated from a path you control, a platform team can own the root and the platform children while product teams own only the paths their own children point at. ## Costs and sharp edges **Indirection.** Debugging is now two hops: is the child missing because the root did not render it, or because the child's own source is broken? Newcomers regularly look at the workload namespace and cannot find who created it. **Cascading deletion.** The root's children are ordinary managed objects. Delete or mis-render the root with pruning on and every child — and transitively every workload — is a candidate for removal. This is the pattern's most famous outage: a templating mistake renders an empty child list, and the controller obediently converges the cluster to empty. Mitigations are ordinary ones: protect the root's path, keep deletion behaviour conservative on the root, and require the rendered output to be reviewed rather than the template alone. **No ordering.** Nesting gives composition, not sequencing. All children become live at roughly the same time; if one component needs another to exist first, that has to be expressed explicitly rather than assumed from the tree. **Deep nesting stops paying.** Root → children is clear. Root → children → grandchildren for organisational reasons mostly adds hops; most teams keep it two levels and use a per-cluster root instead of deeper trees. ## Hand-written children vs generated children App-of-apps says nothing about *where the child manifests come from*. Two variants exist: children written out as files (explicit, greppable, one file per component — fine up to a few dozen), and children produced by a generator from an inventory (one template plus a list — the only sane option once the same set repeats across many clusters or tenants). The two combine: hand-written children for the handful of one-off platform pieces, generated children for the repeating fleet. ## Interview framing The crisp answer is: *app-of-apps makes the registration list itself a reconciled artifact*. Everything else — reviewable inventory, one bootstrap handle, offboarding by deletion — follows from that sentence, and so does the main risk, because a list that the controller manages is a list the controller can also empty.