AWS organizations documentation change
Summary
Fixed typos: 'behaviour' to 'behavior' and 'permits' to 'permit'.
Security assessment
Language/spelling corrections without security impact. No changes to policy evaluation logic.
Diff
diff --git a/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md b/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md index ba0ed7ef4..828f54f35 100644 --- a//organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md +++ b//organizations/latest/userguide/orgs_manage_policies_scps_evaluation.md @@ -159 +159 @@ This scenario demonstrates that a deny policy at the root-level affects all acco -This scenario demonstrates how SCPs with explicit service allow lists function when applied at root level within an AWS Organizations. At the organization root level, two custom "Service Allow" SCPs are attached that explicitly permits access to a limited set of AWS services — SCP_1 allows IAM and Amazon EC2, SCP_2 allows Amazon S3 and Amazon CloudWatch. At the organizational unit (OU) level, the default FullAWSAccess policy remains attached. However, due intersection behaviour, accounts A and B under these OUs can only access the services explicitly permitted by the root-level SCP. The more restrictive root policy takes precedence, effectively limiting access to only IAM, EC2, S3, and CloudWatch services, regardless of the broader permissions granted at lower organizational levels. +This scenario demonstrates how SCPs with explicit service allow lists function when applied at root level within an AWS Organizations. At the organization root level, two custom "Service Allow" SCPs are attached that explicitly permits access to a limited set of AWS services — SCP_1 allows IAM and Amazon EC2, SCP_2 allows Amazon S3 and Amazon CloudWatch. At the organizational unit (OU) level, the default FullAWSAccess policy remains attached. However, due to intersection behavior, accounts A and B under these OUs can only access the services explicitly permitted by the root-level SCP. The more restrictive root policy takes precedence, effectively limiting access to only IAM, EC2, S3, and CloudWatch services, regardless of the broader permissions granted at lower organizational levels.