A fintech with 60 AWS accounts must ensure no S3 bucket is ever public and any unencrypted RDS instance is auto-remediated before audit. Platform engineers use CDK and CloudFormation for deployments and need guardrails that block bad templates early while fixing existing drift continuously. What governance design works?

The correct design combines shift-left prevention with continuous correction because CloudFormation Hooks inspect CDK-synthesized templates before resources provision and fail deployments missing S3 Block Public Access or RDS encrypted storage, while Config managed rules detect drift from console or API changes across all 60 accounts and invoke Systems Manager Automation for immediate repair, satisfying both block early and auto-remediate before audit. An organization-wide Config plus auto-remediation design corrects drift reliably but is purely reactive, allowing noncompliant stacks to deploy before detection, which violates the pre-deployment blocking requirement and leaves audit exposure. A Service Control Policy plus Hooks design provides prevention by denying public S3 and unencrypted RDS APIs and failing bad templates, yet deny statements do not repair resources that are already noncompliant, so existing drift persists and the continuous auto-remediation requirement is missed. A Hooks plus Config detection with manual ticketing design provides prevention and visibility but substitutes human triage for automated correction, so remediation latency depends on ticket handling and fails the auto-remediated mandate. Exam caveat is to separate evaluation point from outcome: Hooks evaluate pre-provision, SCPs evaluate at API authorization, Config evaluates post-provision, and only pre-provision plus post-provision with automation covers both mandates. Practical check is to confirm Hook DENY in CloudFormation events, Config aggregator compliance across member accounts, and successful block and auto-fix of test violations.