Fundamental Error in Question on SCP Allow Inheritance

[PeterMescher]

“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.

An “incorrect” answer is: “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.” is incorrect because an SCP attached to an OU is automatically inherited by all accounts within that same OU.

This answer option is, in fact, a correct (and frankly, the most-likely) one. Only deny statements are inherited. Allow statements must be explicit at every level of the OU.

For a permission to be allowed for a specific account, there must be an explicit Allow statementAllow statement at every level from the root through each OU in the direct path to the account (including the target account itself).

So, attaching the SCP to the OU itself is insufficient.

• This discussion was modified 6 months, 1 week ago by  PeterMescher.

[Jayid]

Glad to see I’m not the only one who found the explanation inadequate for this question. The question does not provide enough details to definitively say the IAM policy is the root cause. If the SCP directly attached to the account does not allow adequate permissions, then the SCP would be the root cause of the error.

[JR-TutorialsDojo]

Hello PeterMescher and Jayid,

Thanks for sharing your thoughts on this item.

In AWS Organizations, SCPs act as permission guardrails, not permission grants. While it’s true that for an action to be allowed, there must be an explicit Allow at every level, this requirement applies within the SCP hierarchy itself, not as a need to manually attach SCPs to each account.

When an SCP is attached to an OU, it is automatically inherited by all member accounts. There is no requirement to reattach the same SCP at the account level for it to take effect.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html

Also, the statement that “only deny statements are inherited” is incorrect. Both Allow and Deny statements are inherited, but:

• Deny blocks actions explicitly
• Allow defines the maximum possible permissions (still requiring IAM permissions)

In this scenario, the SCP already allows S3:* and EC2:* at the OU level. Therefore, the SCP is not restricting the action. The failure must come from the IAM side, where no explicit permission was granted.

Let me know if this helps.

Regards,
JR @ Tutorials Dojo

[Jayid]

@JR, I’d kindly ask you to replicate this behavior. Let’s consider this example scenario.

Root
|
|----- Sandbox --> Account A

On Root, we have FullAWSAccess SCP attached

On Sanudbox OU, we have FullAWSAccess SCP attached (Plus the one inherited from Root)

On Account A, apply the following SCP and detach the FullAWSAccess SCP:

{
    "Statement": [{
        "Sid": "Statement1",
        "Effect": "Allow",
        "Action": [
            "ec2:*"
        ],
        "Resource": "*"
    }]
}

Log into account A with a user that has AdministratorAccess managed policy attached and then try creating a bucket. Bucket fails to create with:

User: arn:aws:sts::****:assumed-role/AWSReservedSSO_AWSAdministratorAccess_39b69685aec01e2d/*** is not authorized to perform: s3:CreateBucket on resource: "arn:aws:s3:::test-****" because no service control policy allows the s3:CreateBucket action

• This reply was modified 4 months, 2 weeks ago by  Jayid.

[JR-TutorialsDojo]

Hello Jayid,

Thank you for the follow-up.

Please note that the scenario explicitly states that the Senior Solutions Architect attached the following SCP to the Sandbox OU to define the services that its member accounts can use:

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

Given this, it is reasonable to interpret that the OU is being intentionally scoped down to only EC2 and S3 actions. In practice, this typically implies that the default AWS Organizations Service Control Policy at the OU level has been replaced or overridden to enforce that boundary.

So the effective structure would look like:

• Root – FullAWSAccess
• Sandbox OU – Allow ec2:*, s3:*
• Account A – No SCP explicitly mentioned (inherits from OU)

Regarding your question: “Based on your logic, we should be able to create the bucket because the account is already inheriting the FullAWSAccess SCP from Root and Sandbox OU. However, the account itself does not have the FullAWSAccess SCP attached.”

• By default, when SCPs are enabled in AWS Organizations, AWS attaches the managed FullAWSAccess policy to the root, OUs, and accounts, ensuring no restrictions unless explicitly modified (this was mentioned in the documentation you provided). Since there is no indication in the given scenario that an SCP was modified at the account level, the account simply inherits the OU policy and the default FullAWSAccess policy.
• 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.

For example, if s3:* is removed from the OU-level SCP, then even with:

• FullAWSAccess at the account level, and
• AdministratorAccess on the IAM user

…the account would still be unable to perform S3 actions, since the OU no longer permits it.

This reinforces that in the given scenario, the OU-level SCP (ec2:*, s3:*) is not restricting S3. Therefore, if an S3 action fails, the cause would more likely be on the IAM side rather than SCP.

Please try to simulate the exact scenario described here and let me know if this aligns with your findings.

Regards,
JR @ Tutorials Dojo

[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.

[JR-TutorialsDojo]

Hello Jayid,

As mentioned, by default, when SCPs are enabled in AWS Organizations, AWS attaches the managed FullAWSAccess policy to the root, OUs, and accounts, ensuring no restrictions unless explicitly modified. Since there is no indication in the given scenario that an SCP was modified at the account level, the account simply inherits the OU policy and the default FullAWSAccess policy.

We don’t need to specify in the question that the SCP at the account level has not been modified because, since the question only mentions modifications at the OU level, we can assume that no modifications have been made at the account level. Therefore, we can reasonably conclude that the default FullAWSAccess policy remains attached.

For this one: 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. – I’m referring to this structure:

• Root – FullAWSAccess
• Sandbox OU – Allow ec2:*, s3:*
• Account A – No SCP explicitly mentioned (inherits from OU)

Take note that there are questions in the actual AWS exam that are difficult, tricky, and ambiguous. You have to be prepared to look for specific keywords or key phrases in order to find the most suitable answer. This is the style that we are trying to mimic in our practice tests. Some of the questions do not explicitly show the obvious keywords or phrases that will easily point to the answer.

We will improve the explanation to avoid confusion, and the changes should be reflected on the portal soon.

Regards,
JR @ Tutorials Dojo

[Jayid]

Based on your logic, we should be able to create the bucket because the account is already inheriting the FullAWSAccess SCP from Root and Sandbox OU. However, the account itself does not have the FullAWSAccess SCP attached. So going back to the documentation:

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).

The question does not explicitly say anything about the SCPs attached to the account level. So we can’t rule out misconfigured SCP as a potential issue.

• This reply was modified 4 months, 2 weeks ago by  Jayid.