A healthcare company manages 28 member accounts across three Regions from an Organizations management account. It must deploy standard audit S3 buckets, IAM roles, and Config rules everywhere, auto-apply baselines to new accounts in an OU, and let the security tooling account manage deployments without using management credentials. Versioned templates are required. Which multi-account multi-Region infrastructure deployment design using StackSets delivers this baseline?

The correct design succeeds because service-managed StackSets integrates natively with Organizations to target an OU across multiple Regions, automatically creating and removing stack instances for audit buckets, roles, and Config rules in current and future accounts, while delegation lets the security tooling account operate without management credentials and versioned templates ensure auditable, repeatable baselines. The management-account design fails on administration model because keeping execution in the management account violates least privilege and the explicit requirement to avoid management credentials, even though OU targeting and scale otherwise work. The design without auto-deployment fails on lifecycle automation because it provisions only existing OU members and requires manual action for each new account, breaking continuous enforcement for OU growth. The primary-Region-only design fails on deployment scope because stack instances materialize only in selected StackSets Regions, so replication cannot substitute for real IAM and Config resources instantiated everywhere required. An exam caveat is that service-managed with delegated administrator plus auto-deployment signals OU-based new-account automation, while self-managed signals explicit account lists and custom IAM roles. A practical check is to confirm in the delegated administrator console that auto-deployment is enabled, the OU is targeted, all three Regions are selected, and the template source is versioned, then add a test account to validate automatic creation.