Many product teams at your company need self-service on AWS. How would you decide between giving each team its own AWS account governed by organization-level policies and keeping teams together in shared accounts governed by permissions boundaries?

## Frame the question as "what am I isolating?" The two mechanisms answer different questions, and the interview answer that lands separates them before choosing. An account is an **isolation** unit. A permissions boundary is a **delegation** unit. Asking "account or boundary?" as though they were substitutes is the trap; asking "what must be isolated, and who must be unable to lift the control?" produces a defensible design. ## What only a separate account gives you - **Blast radius.** Resources in different accounts do not see each other by default. A misconfigured policy inside one account cannot expose another account's data unless someone deliberately builds the cross-account path. - **Service quotas.** Quotas are largely per-account per-Region. One team's batch job exhausting a quota is contained rather than shared. - **Billing attribution.** Cost rolls up per account for free, without depending on tagging discipline. - **A control the team cannot remove.** Organization-level policies applied to an account are administered from the management account. Even a team member holding IAM admin in their own account cannot lift them. A permissions boundary in a shared account can be detached by anyone with the IAM write permissions to do so. - **A clean radius for incident response.** Compromise of a credential is scoped to what that account holds. ## What that costs - **Bootstrap and lifecycle.** Every account needs baseline setup: logging, network, roles, guardrails, vending. This has to be automated or it becomes a queue. - **Cross-account plumbing.** Anything shared — a data lake, a shared VPC, an artifact store, a central log archive — now needs cross-account access, which means both sides must permit it and someone must own that surface. - **Cognitive load.** Engineers switch accounts, roles and profiles constantly, and "which account is this in?" becomes a real operational question. - **Ceilings on count.** Account sprawl is manageable with automation but is not free; it needs naming, ownership and decommissioning conventions. ## What a permissions boundary gives you that an account does not Separating accounts does not, by itself, stop the people inside an account from granting themselves more than they should. If a team holds IAM write permissions in their own account — and they usually must, to self-serve roles for their workloads — they can create an administrator unless something caps what they create. That is precisely the boundary's job: bound whatever identity policies they author, so the ceiling is reviewed once instead of every policy being reviewed forever. Boundaries are also finer-grained than an account. You can give the CI role a different ceiling from the developer role and from the workload role in the same account, without any of the plumbing that separating them into accounts would demand. ## The layering that most organizations converge on 1. **Accounts as the isolation unit** — per team and per environment, at minimum production separated from everything else, because production is the isolation that matters most. 2. **Organization-level policies as the un-liftable guardrails** — the small set of rules that must hold no matter who is admin in the account: allowed Regions, protection of the audit trail, prohibition of the handful of account-level settings that would break the model. 3. **Permissions boundaries inside each account for delegation** — so the team can create their own roles without creating an administrator, and the platform team reviews one ceiling rather than a stream of policies. Each layer answers a distinct threat: the boundary defends against a mistake by a delegated engineer; the organization policy defends against the guardrail being lifted; the account defends against everything else in the account. ## When shared accounts genuinely win Do not treat account-per-team as automatic. Shared accounts are defensible when teams are small and numerous, when workloads share heavily (many services on one cluster, one VPC), when cross-account plumbing would dominate the actual engineering, or when the organization lacks the automation to vend and maintain accounts — an unmaintained account is worse than a well-governed shared one. In that world, boundaries plus disciplined resource-level policies and tagging carry the load, and you accept that isolation is soft. ## How to present the decision A strong answer names the failure each option leaves open and says which one you are willing to accept. "Shared accounts with boundaries, accepting that quota exhaustion and lateral resource access are possible, because we have twelve teams sharing one platform and no account automation yet — with production split out, and a plan to vend accounts once the tooling exists" is a much better answer than a categorical preference. The maturity signal is sequencing: what you would do first, and what triggers the move.