-
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
