CardNet segregates PCI DSS workloads into a dedicated Organizational Unit (OU). They need preventative restrictions (for example, no Internet Gateways in PCI accounts, approved Regions only) and ongoing control mapping to PCI best practices with centralized visibility. What is the MOST appropriate approach?

The correct approach leverages AWS Organizations, Service Control Policies (SCPs), and AWS Config conformance packs for robust PCI DSS compliance. Placing PCI accounts in a dedicated OU allows for granular control via SCPs, which can proactively deny actions like CreateInternetGateway or restrict resource deployment to approved Regions, directly addressing the need for preventative restrictions. Deploying the AWS Config "Operational Best Practices for PCI DSS" conformance pack organization-wide to that OU provides continuous auditing and control mapping against PCI best practices, offering centralized visibility into compliance posture. Incorrect options: AWS Security Hub provides findings but doesn't prevent actions; it's a detective control, not preventative. AWS Control Tower offers guardrails, but it alone does not cover all specific PCI DSS preventative and detective controls without customization, especially for highly specific requirements like denying internet gateways. Keeping PCI and non-PCI workloads in a single account complicates scope, increases blast radius, and makes enforcing PCI compliance much harder, even with IAM permission boundaries. Dedicated accounts and OUs are a best practice for segregation.