3.4.1.3. Permission Management Delegation by Using IAM Permissions Boundaries

3.4.1.3. Permission Management Delegation by Using IAM Permissions Boundaries

Permissions boundaries solve: how do you let developers create IAM roles without letting them escalate privileges?

Without boundaries: Developer with iam:CreateRole + iam:AttachRolePolicy creates a role with AdministratorAccess — effectively self-granting admin.

With boundaries: Effective permissions = Identity Policy ∩ Permissions Boundary. Even with AdministratorAccess attached, the role can only do what the boundary allows.

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": ["s3:*", "dynamodb:*", "lambda:*", "logs:*"], "Resource": "*"},
    {"Effect": "Deny", "Action": ["iam:*", "organizations:*"], "Resource": "*"}
  ]
}

Enforcing boundaries on role creation:

{
  "Sid": "EnforceBoundary",
  "Effect": "Allow",
  "Action": ["iam:CreateRole", "iam:AttachRolePolicy"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary"
    }
  }
}

Developers can only create roles with the DevBoundary attached — they can't create unbounded roles.

Exam Trap: Boundaries limit but never grant permissions. A boundary allowing s3:* doesn't give the role S3 access — the identity policy must also allow it. This is the most misunderstood IAM concept on the exam.