A holding company with 60 AWS accounts must block S3 public access and unapproved Regions even when account owners grant access, including attempts by root. Developers still need flexibility within allowed guardrails. Which policy enforcement design correctly applies SCPs with RCPs for preventive governance?

The correct design works because SCPs set preventive identity-side guardrails that limit Regions and actions for all member-account principals including member-account root, while RCPs set preventive resource-side guardrails on S3 that apply regardless of access granted by identity policies, so denying unapproved Regions with SCPs and limiting S3 to trusted identities and networks with RCPs blocks public access even when granted yet allows development within boundaries. The IAM boundaries design fails the root requirement because identity policies and permission boundaries are not evaluated for root, so root can still grant or obtain S3 public access that only SCPs and RCPs would constrain. The Config monitoring design fails the preventive requirement because Config rules with alerts and remediation are detective controls that permit the violating bucket policy to take effect until rollback, allowing exposure rather than blocking it upfront. The deny-all cross-account RCP design fails the flexibility requirement because blocking every external S3 access without exception for trusted partners and networks prevents legitimate sharing and forces workarounds. For exams, remember SCPs restrict what principals can do, RCPs restrict what can be done to resources, neither grants access, and management-account root sits outside SCPs. As a practical check, pilot both policies in a sandbox OU, test S3 policy changes and Region launches as administrator, and confirm with Access Analyzer and CloudTrail that only trusted paths succeed.