A finance department insists on separate AWS accounts so the parks department cannot read tax databases. Why is account isolation an appropriate access-control choice?

Separate AWS accounts for finance and parks create a strong blast-radius and access boundary that does not rely solely on perfect IAM policies inside one shared account. By default, principals in the parks account cannot read tax databases in the finance account unless explicit cross-account grants exist. That default deny across account IDs is why municipal architects isolate regulated or sensitive workloads even when IAM groups could theoretically separate teams in one account. Misconfigured wildcards in a shared account can expose everything; misconfiguration across accounts usually requires an intentional trust.

Claiming IAM in a single shared account always provides stronger isolation than separate accounts reverses industry and AWS guidance—accounts are the hard boundary. Saying separate accounts only matter for billing ignores security isolation, SCPs, and blast-radius design. Asserting parks can still use the finance root user whenever accounts are separated misunderstands ownership: each account has its own root, and parks should not receive finance root credentials.

Exam caveat: account isolation is not complete until you control cross-account roles, resource policies, and Organizations sharing features (RAM, etc.). Central logging still aggregates evidence without merging workload permissions. Operational check: from a parks role, attempt to read the finance tax table or secret and confirm AccessDenied; document any intentional cross-account roles with least privilege; verify SCPs reinforce that parks cannot create unconstrained assume-role trusts into finance.