SAP-C02 Practice Question 1: SCP Region and Leave Org Guardrails
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 1 · question 1 of 10
A financial services company runs 40 AWS accounts in a single organization in AWS Organizations with all features enabled. A recent audit produced two mandatory, non-negotiable controls:
1. Account administrators in member accounts must not be able to remove their account from the organization. 2. Workloads must only create resources in eu-west-1 and eu-central-1, while global services such as IAM, AWS Organizations, Amazon CloudFront, and Amazon Route 53 must keep working.
Each member account has its own local administrators who can create IAM roles and users at will. The controls must be preventive, must survive an account administrator editing local IAM policies, and must apply automatically to accounts added later. Which approach meets these requirements with the least ongoing operational effort?
Show answer and explanation
Answer:
Service control policies are the only preventive guardrail in AWS Organizations that a member account administrator cannot override. An SCP sets the maximum available permissions for every principal in the affected accounts, including the account root user, so a locally created admin role still cannot escape it. Attaching the SCP to the organization root means every account, including accounts created or invited later, inherits it with no per-account work. Both controls in the stem are documented SCP examples: a Deny on organizations:LeaveOrganization, and a Deny with NotAction listing the global services plus a StringNotEquals condition on aws:RequestedRegion. The NotAction form is required because global service API calls are made against a single Region endpoint (usually us-east-1) and a naive Region deny would break IAM, CloudFront, and Route 53. Note that SCPs do not restrict the management account, which is why production workloads should not run there.
Option A fails on durability and effort. A permissions boundary is an IAM policy inside the member account, so the local administrator who can create roles can also detach or rewrite the boundary. It also has to be attached to every principal individually, forever.
Option C only governs identities that come through IAM Identity Center. Roles created locally in the account, EC2 instance profiles, and service-linked roles bypass permission sets entirely, so the control is not preventive across the account.
Option D is detective and reactive, not preventive. AWS Config reports on resources after they are created and cannot stop LeaveOrganization at all, and building deletion automation on top of it adds significant operational burden for a weaker control.
Reference: Example service control policies