In Argo CD, what does an AppProject constrain, and what does the built-in project named default permit out of the box?

## What an AppProject actually is Argo CD has two custom resources that matter for tenancy. An **Application** says "take the manifests at this path in this Git repository and make them exist in this cluster and namespace". An **AppProject** says "here is the set of Applications a particular team owns, and here are the limits on what any of them may reference". Every Application belongs to exactly one project, named in `spec.project`. If the field is left empty, the Application lands in the built-in project called `default`. The project is therefore not a folder or a UI grouping — it is evaluated on every sync, and an Application that asks for something its project does not permit is refused. ## The fences a project sets An AppProject fences three independent axes. **Where manifests may come from.** `sourceRepos` is a list of repository URLs (globs allowed) that Applications in this project may set as `spec.source.repoURL`. Point a team's project at the team's repositories and an Application in that project cannot silently pull manifests from somewhere else. **Where manifests may go.** `destinations` is a list of `{server or name, namespace}` pairs. `server` is the cluster API URL as Argo CD registered it, `name` is the friendly cluster name, and `namespace` is the target namespace. A project scoped to one cluster and one namespace prefix is how you stop a team from deploying into `kube-system` or into another team's cluster. **What kinds may be created.** Four lists control resource kinds, split by scope: ```yaml apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: team-a namespace: argocd spec: sourceRepos: - https://github.com/acme/team-a-manifests.git destinations: - name: prod-eu namespace: team-a-* clusterResourceWhitelist: [] # no cluster-scoped kinds at all namespaceResourceBlacklist: - group: '' kind: ResourceQuota - group: networking.k8s.io kind: NetworkPolicy ``` `clusterResourceWhitelist` and `clusterResourceBlacklist` govern cluster-scoped kinds; `namespaceResourceWhitelist` and `namespaceResourceBlacklist` govern namespaced kinds. A project that names no cluster-scoped kinds in its whitelist permits none of them, which is the sane default for an application team. ## The default project Installing Argo CD creates one AppProject called `default`, and it is intentionally permissive so that a first-time install works with no configuration: any source repo, any destination cluster and namespace, and any resource kind. That is fine for a single-team playground and wrong for a shared instance. Two habits follow from it: create a real project per tenant before onboarding anyone, and tighten or delete the `default` project's wildcards so nothing quietly falls back into it. ## What a violation looks like Project enforcement shows up in two places. When you create or edit an Application through the API, server or CLI, a source repo or destination outside the project is rejected outright. When the violation is inside the manifests — the repository contains a kind the project forbids — the Application syncs partially or not at all and surfaces a condition on the Application saying the resource is not permitted in its project. Reading that condition text is the fast path to diagnosing "why did my sync skip this object": it usually names the exact group and kind that the project does not allow. ## Why interviewers ask it The question separates people who have used Argo CD from people who have operated it for more than one team. Argo CD holds credentials to every cluster it manages, so an instance with everything in `default` is effectively a shared administrative account for the whole fleet. The AppProject is the object that turns it back into a multi-tenant control plane, and the answer an interviewer wants names the three axes — repos, destinations, kinds — and admits that the shipped `default` project fences none of them.