Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 57 discussion

SCP doesn’t grant permission

C is correct SCP policy allow everything except cloudtrail. SCP is boundary but it does not give allow to IAM users. You have to configure allow for every IAM

IAM permissions do not override SCPs. Even if developers have IAM policies allowing s3:CreateBucket, an SCP restriction will still block it unless explicitly allowed.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Sid": "DenyCloudTrail", "Effect": "Deny", "Action": "cloudtrail:*", "Resource": "*" }, { "Sid": "AllowS3CreateBucket", "Effect": "Allow", "Action": "s3:CreateBucket", "Resource": "*" } ] }

B. Register a block of customer-owned public IP addresses in the AWS account. Create Elastic IP addresses from the address block and assign them to the NAT gateways in the VPC.

C, SCP is just a distractor, the users need direct permissions

The problem described does not originate from the Service Control Policy (SCP) itself based on the SCP content provided. The SCP allows all actions ("Action": "") except for actions related to AWS CloudTrail ("Action": "CloudTrail:"), which are explicitly denied. Therefore, the inability for developers to create Amazon S3 buckets is not due to this SCP, as the SCP does not restrict S3 actions. Given the situation, the correct way to address the developers’ inability to create Amazon S3 buckets would be: * C. Instruct the developers to add Amazon S3 permissions to their IAM entities. Option C is the correct action because the issue likely stems from the IAM permissions (or lack thereof) assigned to the developers’ IAM entities (users, groups, or roles). IAM permissions are required to perform actions within AWS accounts, such as creating S3 buckets. If developers lack the necessary IAM permissions, they would not be able to create S3 buckets regardless of the SCP settings.

The SCP in the scenario is allowing any actions with the exception of cloudtrail. Thus, the SCP is not preventing user to create S3 bucket. If the user cannot create a bucket, then the user IAM user/role is missing permissions to create S3 bucket.

Answer C.

it's a C

C is correct

I just wanted to add my vote to the mix to hopefully drown out the wrong votes. Its definitely C. SCP is only a guardrail, it doesn't actually grant access. So the users would need to be given s3 access separately. And to address the wrong answer, A isn't correct because creating an s3 bucket is not a cloudtrail action. Being denied cloudtrail wouldn't deny s3 actions.

C is the answer. SCP DONT grant permissions. They just set boundaries on what account is capable of giving access to all users. For example, we applied a SCP on an OU that has account A. This SCP has S3fullAWSaccess. This does NOT mean that any IAM user can perform any S3 action. You still need to explicitly define IAM permissions for user to perform action on S3. This is called whitelisting. Another example, You wrote an SCP that DENIES S3 access and applied it to an OU that has account B. Now Lets say ROOT user of Account B (who got admin previleges) tries to create S3 bucket, they get DENIED error as SCP has already set a bounday saying NOONE in this OU can access S3

Need to deal with iam policy auth now

I am not sure the given situation is possible. When I tested, member (1111-1111-1111) could create bucket without any policy which can be attached or detached by the oneself.

Are developers allowed to modify their IAM entities in the situation of option C? If so, I am not sure this is the best practice.

C is correct