A county wants developers to deploy into a sandbox account but must prevent creation of IAM users that attach AdministratorAccess. Which multi-account control best enforces that guardrail?
Select an answer to reveal the explanation.
Short Explanation
A polite reminder in Slack is not a lock on the sandbox door. SCPs and permission boundaries sit above what developers can grant themselves, so AdministratorAccess IAM users never get born. Logging off or handing out management-account root makes the problem worse.
Full Explanation
Preventing sandbox developers from creating IAM users that attach AdministratorAccess requires preventive controls above the developers' own IAM permissions. AWS Organizations Service Control Policies can deny creation of users or attachment of overly broad managed policies at the account or OU level, while IAM permissions boundaries cap the maximum permissions a delegated admin can grant to identities they create. Together they ensure that even if a developer can call iam:CreateUser, they cannot mint an unrestricted AdministratorAccess principal. That is the multi-account guardrail pattern SAA-C03 expects for sandbox containment.
Asking developers in chat to avoid AdministratorAccess and reviewing weekly screenshots is detective theater after the fact and is not enforceable. Disabling CloudTrail in the sandbox removes the audit trail needed to investigate privilege escalation and contradicts security baselines. Giving every developer the organization management account root credentials collapses the entire multi-account model and exposes billing, SCPs, and every member account.
Exam caveat: SCPs alone may deny AttachUserPolicy for AdministratorAccess or deny CreateUser broadly—combine with a permissions boundary ARN that developers must apply when they create roles, or else legitimate least-privilege role creation can break. SCPs do not affect the management account like members. Operational check: as a sandbox developer role, attempt to create a user with AdministratorAccess and confirm denial; create a bounded role with only S3 sandbox prefix access and confirm it works; inspect CloudTrail for explicit AccessDenied on the blocked IAM calls.