2.2.2.4. IAM Solutions for Multi-Account Structures (SCPs, Assuming Roles)

2.2.2.4. IAM Solutions for Multi-Account Structures (SCPs, Assuming Roles)

In multi-account environments, permissions operate at two levels: SCPs define the ceiling (maximum possible permissions), and IAM policies define what's actually granted within that ceiling.

Service Control Policies (SCPs):

• Apply to OUs or individual accounts (not the management account)
• Work as filters — they don't grant permissions, only restrict what IAM can grant
• Inheritance: effective SCP = intersection of all SCPs applied to account and parent OUs
• AWS recommends deny-list approach: start with FullAWSAccess and add explicit denies

{
  "Sid": "DenyRegionsOutsideUS",
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"]
    },
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    }
  }
}

Cross-account role assumption is the standard access pattern:

1. Account B creates a role trusting Account A
2. User/service in Account A calls sts:AssumeRole
3. Temporary credentials have the assumed role's permissions

AWS IAM Identity Center (SSO) centralizes human access. Users authenticate once and access multiple accounts via permission sets mapped to IAM roles.

Exam Trap: SCPs don't affect service-linked roles. If an SCP denies s3:*, services like CloudTrail using service-linked roles can still write to S3. This is by design — the exam tests whether you understand this exception.