Reply To: Fundamental Error in Question on SCP Allow Inheritance

[Jayid]

Hi @JR, let me post the entire question here for clarity:

A multinational bank has recently set up AWS Organizations to manage its several AWS accounts from their various business units. The Senior Solutions Architect attached the SCP below to an Organizational Unit (OU) to define the services that its member accounts can use:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": ["EC2:*", "S3:*"],
        "Resource": "*"
    }]
}

In one of the member accounts under that OU, an IAM user tried to create a new S3 bucket but was getting a permission denied error.

Which of the following options is the most likely cause of this issue?

A. The IAM user in the member account does not have IAM policies that explicitly grant EC2 or S3 service actions.

B. All accounts within the OU does not automatically inherit the policy attached to them. You still have to manually attach the SCP to the individual AWS accounts of the OU.

C. An IAM policy that allows the use of S3 and EC2 services should be the one attached in the OU instead of an SCP.

D. You should use the root user of the account to be able to create the new S3 bucket.

No where in the question explicitly states that the account itself has FullAWSAccess attached. If the account itself does not have the FullAWSAccess directly attached and it’s only inherited from the parent OU, we can not rule out option B as an incorrect answer. I’d once again quote the doc:

For a permission to be allowed for a specific
account, there must be an explicit Allow statement at every level from the root through each OU in the direct path
to the account (including the target account itself). This is why when you enable SCPs,
AWS Organizations attaches an AWS managed SCP policy named FullAWSAccess<awsui-icon name=”external”></awsui-icon> which allows all services and actions.

You mentioned “Account A – No SCP explicitly mentioned (inherits from OU)”

The doc itself explicitly states that inherited SCPs are not enough to grant permissions, we also need to directly attach it to every entity. Which is why I encountered an AccessDenied error when I tried creating a bucket despite inheriting FullAWSAccess from both Root and Sandbox OU and my IAM user having AdministratorAccess managed policy attached to it.

Regarding “The key point is that SCP evaluation works as an intersection across all
levels. Even if FullAWSAccess exists at the account level by default,
the OU-level SCP still defines the maximum allowed actions.” – to that I’d say that the SCP I configured at the account level was more restrictive that what’s configured at the OU level. In my explanation above, both Root and Sandbox had FullAWSAccess and the account had a custom SCP attached that only allowed ec2:*, the account level SCP is the most restrictive of all the SCPs and that would dictate the final permission.

The point I’m trying to make is that the question needs to clarify that the SCPs at the account level has not been modified, otherwise both options A and B can be correct answers. Hope that explains the issue.