Question #586
A company with several AWS accounts is using AWS Organizations and service control policies (SCPs). An administrator created the following SCP and has attached it to an organizational unit (OU) that contains AWS account 2222-2222-2222:json<br>{<br> "Version": "2012-10-17",<br> "Statement": [<br> {<br> "Sid": "AllowsAllActions",<br> "Effect": "Allow",<br> "Action": "*",<br> "Resource": "*"<br> },<br> {<br> "Sid": "DenyConfig",<br> "Effect": "Deny",<br> "Action": "config:*",<br> "Resource": "*"<br> }<br> ]<br>}<br>
Developers working in account 2222-2222-2222 complain that they cannot create Amazon S3 buckets. How should the administrator address this problem?
Add s3:CreateBucket with \"Allow\" effect to the SCP.
Remove the account from the OU, and attach the SCP directly to account 2222-2222-2222.
Instruct the developers to add Amazon S3 permissions to their IAM entities.
Remove the SCP from account 2222-2222-2222.
Explanation
The SCP attached to the OU allows all actions (*) except AWS Config (Deny). However, SCPs only define the maximum permissions for accounts; they do not grant permissions. IAM policies must explicitly allow specific actions. Since the developers cannot create S3 buckets, their IAM entities (users/roles) lack the s3:CreateBucket permission.
Why other options are incorrect:
- A: The SCP already allows all actions except Config. Adding an explicit Allow for S3 is redundant.
- B: Moving the SCP to the account directly doesn't resolve the issue, as the SCP's effect remains the same.
- D: Removing the SCP would remove the AWS Config denial but doesn't address the missing IAM permissions.
Key Points:
1. SCPs set permissions boundaries but do not grant access.
2. IAM policies must explicitly allow actions even if SCPs permit them.
3. Deny policies in SCPs override Allow policies if conflicting.
Answer
The correct answer is: C