A holding company with 60 AWS accounts in five subsidiaries needs centralized billing, separate guardrails per subsidiary, and automated provisioning of new accounts with baselines. The landing zone must scale without email juggling. Which Organizations deployment meets these governance goals?

The correct design works because a single organization enables consolidated billing, nested OUs allow distinct SCPs for per-subsidiary guardrails with clear inheritance, and Control Tower automates account vending with identity, logging, and compliance baselines that scale without manual email handling. The manual-console provisioning approach retains billing centralization and OU separation but breaks the automation requirement because direct creation bypasses landing-zone baselines, lifecycle workflows, and guardrail enrollment, causing drift and operational overhead as accounts increase. The single-OU Control Tower approach retains billing centralization and automation but breaks isolation because one OU forces identical policies on all subsidiaries, preventing tailored SCPs, delegated administration, and differentiated detective controls. The separate-organization-per-subsidiary approach retains local isolation and automation but breaks centralized governance because multiple management roots fragment billing, SCP hierarchy, and audit visibility, requiring complex aggregation and cross-organization trust. As an exam caveat, separate the roles of consolidated billing for cost, Organizations and SCPs for policy control, and Control Tower for automated landing-zone baselines, since stems often test which layer is missing. As a practical check, verify consolidated billing in the management account, distinct SCP attachments per subsidiary OU, and that new accounts are vended only via Control Tower with enrolled guardrails and centralized CloudTrail and Config logging.