What a Permission Boundary Limits

A permission boundary is an advanced IAM feature that sets the maximum permissions a user or role can ever have. It does not grant anything by itself; it caps what identity-based policies can effectively allow. Permission boundaries are a favorite exam topic because they enable safe delegation of permission management.

An identity-based policy grants permissions; a permission boundary limits them. The effective permissions are the intersection of the two: an action is allowed only if both the identity policy and the boundary permit it. A boundary can shrink but never widen what the identity policy grants.

Suppose a user's identity policy allows full S3 and EC2 access, but their permission boundary allows only S3. The user can do only S3 actions, because the boundary caps them. Remove the boundary and the EC2 permissions become effective again. The boundary quietly enforces a maximum.

This boundary policy permits only S3 and CloudWatch actions. No matter what the identity policy says, the user can never exceed these services.

The main use case is safe delegation. You want developers to create their own IAM roles, but you fear they will grant excessive permissions. By requiring that every role they create carries a permission boundary, you guarantee those roles can never exceed the boundary, no matter how broad the attached policy is.

Both boundaries and SCPs cap permissions, but they differ in scope. A permission boundary applies to a single user or role and is set within IAM. An SCP applies to entire accounts in an organization. The exam tests choosing the right tool: per-identity uses a boundary, account-wide uses an SCP.

In the evaluation flow, an explicit Deny still wins over everything, including boundaries. Otherwise, the boundary acts as a cap: the action needs an Allow in both the identity policy and the boundary. Resource-based policies can grant access independently of the boundary in some cases, a nuance worth remembering.

A frequent misconception is that adding an action to a boundary grants it. It does not. If the identity policy lacks the permission, the boundary allowing it has no effect. The identity policy must grant, and the boundary must also permit, for the action to succeed.

A nuance the exam tests: permission boundaries limit what a principal's identity-based policies can do, but they do not limit access granted to that principal by a resource-based policy in some cases. So a boundary capping a role to S3 may still let the role be granted SQS access through a queue policy. Design with this gap in mind.

To enforce that delegated principals always attach a boundary, you write a permission policy with a condition requiring iam:PermissionsBoundary to equal a specific boundary ARN on any role they create. This prevents a developer from creating roles without the guardrail, closing the delegation loophole.

A permission boundary caps the maximum permissions of a single user or role: effective access is the intersection of the boundary and the identity policy. It never grants on its own. Its key purpose is safe delegation of IAM role creation, enforced by requiring the boundary via the iam:PermissionsBoundary condition.

Test permission-boundary logic.

A permission boundary sets the maximum permissions of a single user or role; effective access is the intersection of the boundary and the identity policy. It never grants on its own and an explicit deny still wins. Its primary purpose is safe delegation, enforced via the iam:PermissionsBoundary condition.