A regulated bank is consolidating 40 standalone AWS accounts after an acquisition, needs delegated admin for audit, requires preventive guardrails on production OUs, and must automate future account creation with baselines. Which Organizations design should the architect deploy to centrally provision accounts with preventive guardrails?
Select an answer to reveal the explanation.
Short Explanation
You get true central control when OUs plus SCPs do the heavy lifting. Service control policies act like building-wide circuit breakers that member accounts can't override. That hierarchy scales as new accounts roll in automatically.
Full Explanation
AWS Organizations with all features enabled provides centralized account provisioning through CreateAccount, hierarchical grouping with organizational units, and preventive control with service control policies that set maximum permissions across OUs and accounts, plus delegated administrator support for services like CloudTrail and Config; designing OUs by function such as Sandbox, Dev, and Production allows tailored SCPs that block risky actions in Production while permitting experimentation elsewhere. Consolidated billing only with a single OU and IAM permission boundaries fails because boundaries delegate control to member accounts and lack organization-wide prevention. A flat structure with IAM users in members fails because it provides no OU segmentation or centralized provisioning and depends on distributed identity management. Multiple separate organizations fail because they eliminate central governance, prevent organization-wide SCPs and consolidated policy views, and multiply operational overhead. Exam caveat: SCPs do not grant permissions, they only filter what identity policies can allow, and the management account should be isolated. Practical check: verify all features is enabled, OUs reflect blast-radius boundaries, and SCPs are tested in staging before attaching to Production.