A platform team lets project administrators create IAM roles for workloads in their own AWS accounts, but every role must stay inside a fixed security baseline. The organization also wants to block all member accounts from using AWS Regions outside us-east-1 and us-west-2. Which three controls should be used? Select three.
Trap 1: Grant AdministratorAccess to the project administrators and rely on…
Granting AdministratorAccess gives project administrators unrestricted control over every IAM resource and action, including the ability to modify or delete the very policies and boundaries that enforce the security baseline. This is a direct violation of least privilege and turns delegated administrators into root-equivalent principals, so any audit that happens later is purely reactive and cannot prevent the initial over-privileged role from being created and abused. Audits may detect noncompliance after the fact, but they offer no guarantee that the damage—such as credential theft or resource deletion—has not already occurred.
Trap 2: Use an AWS Config rule alone to stop role creation if the…
AWS Config rules are inherently detective, not preventive: they evaluate the configuration of existing resources and report noncompliance, but they cannot intercept or block an API call such as CreateRole at the moment it is made. An over-permissioned role could be created and used before the Config rule even runs its periodic evaluation, leaving a window for privilege escalation or data exfiltration that no later alert can undo. To actually stop the creation, you need a preventive control like an IAM policy condition, a service control policy, or a permissions boundary required at creation time.
- A
Attach a permissions boundary to each role created through the delegation process.
A permissions boundary caps the maximum permissions a created role can ever receive, even if an administrator later attaches broader policies. This is the right mechanism for a fixed security baseline on delegated role creation.
- B
Require iam:PermissionsBoundary in the role creation policy so every new role must include the approved boundary.
The role creation policy must include a condition such as "StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/ApprovedBoundary"} to make the boundary mandatory. Without this explicit requirement, a delegated administrator could create a role without any boundary and then attach overly permissive policies, exceeding the approved maximum. This IAM-level enforcement closes that loophole by denying the CreateRole action whenever the condition fails, guaranteeing that every role is born with the intended security baseline.
- C
Use an SCP to deny actions in all AWS Regions except us-east-1 and us-west-2.
An SCP attached to the organization root or to the member account OU can deny all actions when the requested Region is not in the allowed set, using a condition like "StringNotEquals": {"aws:RequestedRegion": ["us-east-1", "us-west-2"]}. Because SCPs are evaluated before any IAM policy and cannot be bypassed even by the account root user, they provide a hard organizational guardrail that keeps workloads confined to approved Regions. This complements IAM-level controls by addressing a different dimension: not who can create roles, but where any resource or action can be performed.
- D
Grant AdministratorAccess to the project administrators and rely on later audits for enforcement.
Why it fails: Granting AdministratorAccess gives project administrators unrestricted control over every IAM resource and action, including the ability to modify or delete the very policies and boundaries that enforce the security baseline. This is a direct violation of least privilege and turns delegated administrators into root-equivalent principals, so any audit that happens later is purely reactive and cannot prevent the initial over-privileged role from being created and abused. Audits may detect noncompliance after the fact, but they offer no guarantee that the damage—such as credential theft or resource deletion—has not already occurred.
- E
Use an AWS Config rule alone to stop role creation if the permissions are too broad.
Why it fails: AWS Config rules are inherently detective, not preventive: they evaluate the configuration of existing resources and report noncompliance, but they cannot intercept or block an API call such as CreateRole at the moment it is made. An over-permissioned role could be created and used before the Config rule even runs its periodic evaluation, leaving a window for privilege escalation or data exfiltration that no later alert can undo. To actually stop the creation, you need a preventive control like an IAM policy condition, a service control policy, or a permissions boundary required at creation time.