A retail enterprise with 40 existing AWS accounts wants standardized baselines, required guardrails, and a custom rule blocking non-approved Regions. New acquisitions must enroll with networking baselines automatically. Which Control Tower strategy deploys mandatory, optional, and custom controls across new and existing environments?

Enrolling existing and newly acquired accounts in the Control Tower landing zone brings them under common governance, while native mandatory and optional controls provide standardized baselines. The non-approved Region requirement calls for a customer-defined preventive service control policy (SCP), and Customizations for AWS Control Tower (CfCT) is the listed method for deploying that custom policy. An IAM permissions boundary fails by enforcement scope: it limits IAM principals within an account, rather than denying API actions across the organization regardless of identity. An AWS Config rule fails by control type: it detects and reports noncompliant resources after creation, rather than proactively blocking launches in unapproved Regions. Organization CloudFormation StackSets can distribute templates, but lack Control Tower enrollment hooks, so they do not provide the same automatic application of customizations to future acquisitions as CfCT. For exams, distinguish preventive SCPs from detective Config rules, and CfCT landing-zone customizations from general multi-account StackSets deployments. As a practical check, verify account enrollment in the Control Tower dashboard, confirm the SCP is attached to the governed organizational unit, validate the CfCT pipeline, test a launch in a denied Region, and vend a test account to confirm networking baselines are applied automatically.