- Tutorials Dojo

JR-TutorialsDojo

Administrator
May 4, 2026 at 12:05 pm
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

JR-TutorialsDojo