Inheritance of SCPs

[ch34]

Hi,

my topic is about this question:

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:

….

In the screen you are showing:

you are saying that the SCP “FullAWSAccess” has been inherited.

According to the docu there is no inheritance for allow statements:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps

My understanding:

deny statements are inherited, I can’t change this anymore

allow statements are not inherited, I have to add them at every level.

Can you please approve my understanding?

[Nikee-TutorialsDojo]

Hello ch34,

Thank you for your question regarding Service Control Policies (SCPs) in AWS Organizations.

To clarify, SCPs define the maximum set of permissions an AWS account can have, but they do not grant permissions by themselves. Instead, they act as a boundary that IAM policies must stay within. You’re correct in stating that explicit deny statements in SCPs are consistently enforced and effectively inherited — they apply across all levels and cannot be overridden. As for allow statements, it’s important to note that they are not “inherited” in the same sense as IAM policies. However, SCPs attached at higher levels (such as the root or an Organizational Unit) still apply to all accounts beneath them, unless overridden or restricted by another SCP. This is why the AWS Management Console may show an SCP like FullAWSAccess as “inherited.” It simply means that the account is subject to that SCP by its position in the organizational hierarchy, not that the SCP is automatically copied or re-attached at each level.

So, while you don’t need to attach an allow SCP like FullAWSAccess at every level manually, all SCPs attached at the root, OU, or account level are evaluated together to determine the effective permission boundary. As long as there’s no deny in place and the IAM policies permit the action, the allow SCP will still be effective.

I hope this clears up the confusion, and I appreciate your thoughtful question. Please feel free to reach out if you have further concerns or want to discuss this in more detail.

Best regards,
Nikee @ Tutorials Dojo

[ch34]

Hi Nikee,

thank’s for your reply and I’m sorry for my late answer. Too busy with preparation for the exam :-/

To be honest I don’t agree with you.

As stated in the link documentation AWS writes:

“AWS Organizations attaches an AWS managed SCP named FullAWSAccess<awsui-icon name=”external”></awsui-icon> to every root, OU and account when it’s created“

The FullAWSAccess is really attached to each OU/Account. It’s not just a matter of showing it in the console in my opinion. In my AWS Organizations I can see that the SCP is attached not just inherited to my OUs/Accounts.

Besides on the webpage you can see some examples.

The last line in the very last table confuses me.

On root level there is a “Deny S3 access”.

So whatever is defined below this level doesn’t matter anymore because S3 is denied and nothing else has been explicitly allowed on root level.

So below root no OU/Account should be able to do anything.

But at the very last line in this example is stated that “Resultant policies at Production OU, Account E and Account F” have “no S3 access” (the very last line in the last table). In my opinion it should be “No service access”.

(I’m assuming: “no S3 access” means: every service can be accessed except S3, the wording is not good at the example from AWS)

What do you think about this example?

[Nikee-TutorialsDojo]

Hi ch34,

Thank you once again for your follow-up, and no worries at all about the delay — exam preparation takes priority, and we totally understand!

To address your main point, yes, you are correct that AWS explicitly states the FullAWSAccess
SCP is attached to the root, OUs, and accounts when they are created. This is clearly documented in the AWS Organizations User Guide: “AWS Organizations attaches an AWS managed SCP named FullAWSAccess to every root, OU, and account when it’s created.” This means it is not just “inherited” visually in the console, but actually attached to each entity. You are right to distinguish between inheritance and attachment here, and I appreciate the clarification.

Regarding the evaluation of SCPs, AWS Organizations uses a whitelisting model. This means that to allow an action, it must be explicitly permitted by SCPs at every level of the hierarchy, from the root to the OU to the individual account. On the other hand, Deny statements are consistently enforced and cannot be overridden, regardless of where they are placed in the hierarchy. So, if any level does not allow for a specific action, that action will be blocked, even if allowed in other levels. This is documented under the SCP evaluation strategy here: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps.

As for the example in the AWS documentation showing a root-level “Deny S3 access” SCP, I agree with your interpretation. If the root SCP denies access to S3 and no other SCPs at the OU or account level explicitly allow any services, then the effective result should logically be no access to any service, not just S3. The table entry stating “No S3 access” may assume that another SCP, such as FullAWSAccess, is still attached at the lower levels, which would permit other services except S3. However, this assumption is not clearly stated, and I can see how the wording could be misleading or confusing.

In summary, your understanding is sound: allow statements in SCPs must be present at all levels to be effective, while deny statements are inherited and enforced universally. The FullAWSAccess policy is indeed attached at each level by default, not merely inherited. And yes, if only a deny policy exists at the root without any corresponding allow policies at the lower levels, then no service actions should be allowed, not just S3. I appreciate your detailed analysis; this kind of deep dive makes AWS learning challenging and rewarding. Best of luck on your certification exam — and feel free to reach out anytime with more questions.

Best regards,
Nikee @ Tutorials Dojo