A regional bank with 40 existing AWS accounts in Organizations wants a governed landing zone with preventive controls, centralized logging, and enrollment of current workloads without recreation plus a custom check for approved regions. Which Control Tower approach meets all landing zone enrollment and control requirements?
Select an answer to reveal the explanation.
Short Explanation
You nailed the core landing zone move here: enrollment plus controls matters most. Control Tower is your landing zone autopilot for existing accounts and layered controls. Customizations for AWS Control Tower (CfCT) handles that extra Region rule cleanly.
Full Explanation
Control Tower provisions a landing zone with Account Factory, centralized log and audit accounts, and baseline preventive, detective and proactive controls that continuously govern enrolled accounts, and existing Organizations accounts can be enrolled rather than recreated while retaining workloads. Optional controls extend the baseline for use cases like data residency and Customizations for AWS Control Tower (CfCT) deploys customer-authored CloudFormation templates and SCPs, such as an allowed-Region restriction, alongside managed controls. Building only with Organizations SCPs plus StackSets misses the landing zone lifecycle, centralized logging and control drift management that Control Tower automates. Using Config aggregator with conformance packs provides assessment and remediation but does not create Account Factory provisioning, enrollment workflow or preventive guardrails. Using Identity Center plus GuardDuty centralizes access and threat detection but lacks preventive enrollment, baseline guardrails and CfCT custom control deployment. Exam caveat is to distinguish enrollment of existing accounts from migration and to associate custom SCP and template deployments with CfCT, and practical check is to verify enrolled account status and enabled controls in Control Tower console before adding workloads.