AWS IAM Permissions Boundaries – SAP-C02 Study Guide

Purpose of This Lesson

AWS Identity and Access Management (IAM) permissions boundaries provide a control layer that limits the maximum permissions an IAM user or role can receive through identity-based policies. They are especially useful in delegated administration scenarios, where developers or administrators need to create or manage IAM entities without being able to grant unlimited access.

A permissions boundary is not a permissions grant. It defines the upper limit of permissions that the attached user or role can exercise.

Key Concepts

Effective permissions are an intersection

For an IAM user or role, permissions granted through identity-based policies are limited by the attached permissions boundary:

Effective permissions = Identity-based permissions ∩ Permissions boundary

For example:

• An identity policy grants full access to Amazon S3, Amazon CloudWatch, Amazon EC2, and IAM.
• The permissions boundary allows only Amazon S3, CloudWatch, and EC2 actions.
• The principal can use the allowed S3, CloudWatch, and EC2 actions that are present in both policies.
• IAM permissions are unavailable because IAM actions are not included in the boundary.

A permissions boundary cannot grant an action that the identity-based policy does not grant.

Permissions boundaries apply to users and roles

A boundary can be attached to:

• IAM users
• IAM roles

It is an AWS-managed or customer-managed policy used as a limit on the principal’s identity-based permissions. A principal can have an identity policy that appears broad, but its usable permissions cannot exceed the boundary.

Explicit denies still override allows

Permissions boundaries do not replace the normal IAM evaluation model. An explicit Deny in an applicable policy overrides an Allow, including permissions granted through the intersection of an identity policy and boundary.

Other controls can further restrict access, including:

• Service control policies (SCPs)
• Resource-based policies
• Session policies
• VPC endpoint policies
• Identity policies

Delegated IAM administration

Permissions boundaries are valuable when one team must create IAM users or roles for applications and developers, but security teams must retain control over the maximum access those entities can receive.

A typical design is:

1. A security team creates and controls a boundary policy.
2. A delegated administrator receives permission to create users or roles.
3. IAM policies require newly created entities to use the approved boundary.
4. The delegated administrator can attach identity policies, but the boundary prevents access beyond the approved maximum.

The boundary policy itself must be protected. A user who can modify, replace, or remove the boundary may be able to bypass the intended restriction.

Privilege escalation scenario

Suppose a user has permission to manage IAM but not to launch EC2 instances or access other AWS services. Without additional controls, that user might:

1. Create another IAM user or role.
2. Attach AdministratorAccess or another broad policy.
3. Assume or use the newly created principal.
4. Perform actions that the original user could not perform directly.

This is a privilege-escalation path. Permissions boundaries can mitigate it when the created user or role is required to have a boundary that limits its maximum permissions.

The important implementation detail is that the boundary must actually be attached to the newly created principal. A boundary on the original administrator does not automatically propagate to every user or role that administrator creates.

Exam-Relevant Takeaways

• A permissions boundary sets the maximum permissions for an IAM user or role.
• It does not grant permissions by itself.
• Effective permissions require an Allow in the identity policy and permission within the boundary.
• A boundary cannot override an explicit Deny.
• Boundaries are useful for safely delegating IAM administration.
• A boundary attached to one principal does not automatically attach to principals created by that principal.
• Use IAM conditions and governance controls to require an approved boundary on created users and roles.
• Protect the boundary policy and restrict permissions such as iam:PutUserPermissionsBoundary, iam:PutRolePermissionsBoundary, iam:DeleteUserPermissionsBoundary, and iam:DeleteRolePermissionsBoundary.
• Permissions boundaries do not replace SCPs. SCPs provide organization-level maximum permissions, while boundaries constrain individual users and roles.
• To prevent privilege escalation, evaluate not only what actions a user can perform directly, but also whether the user can create or modify principals, attach policies, pass roles, or alter boundaries.

Architecture Decision Guide

Requirement	Suitable control	Why
Limit the maximum access of a specific IAM user or role	Permissions boundary	Constrains identity-based permissions for that principal
Restrict all accounts in an AWS Organization	Service control policy	Applies organization-level guardrails to accounts and principals
Delegate IAM user or role creation safely	Permissions boundary plus IAM conditions	Allows administration while constraining the permissions of created entities
Prevent a team from changing the approved guardrail	Resource permissions and policy protection	The boundary is ineffective if the team can edit or remove it
Restrict access to a specific S3 bucket	S3 bucket policy, identity policy, or both	Resource-level access control is more appropriate than a general boundary alone
Limit temporary credentials issued by a session	Session policy	Further restricts permissions for a specific role session
Prevent a role from being passed to an untrusted service or principal	iam:PassRole policy conditions	Controls role delegation, a common privilege-escalation path

Common Exam Traps

• A boundary grants access: It does not. The identity policy must also allow the action.
• A boundary overrides an explicit deny: It does not. Explicit denies remain authoritative.
• A boundary on the creator protects all created users: It does not automatically propagate. Each created user or role needs its own boundary.
• Attaching AdministratorAccess bypasses the boundary: It does not, provided the boundary remains attached and does not allow those permissions.
• Permissions boundaries apply to IAM groups: They do not attach directly to groups. They apply to IAM users and roles.
• Removing the boundary is harmless: A principal with permission to remove or replace its boundary may be able to escalate privileges.
• IAM full access means unrestricted AWS access: iam:* grants broad IAM administration, but it does not directly grant access to services such as EC2 or S3. However, it may enable privilege escalation if principal-management actions are not constrained.
• Permissions boundaries replace SCPs: They operate at different scopes and are often used together.

Real-World Engineer Notes

• Use a centrally managed customer-managed policy as the boundary so security teams can update the guardrail consistently.
• Grant delegated administrators only the IAM actions they need. Carefully review permissions to create policies, attach policies, pass roles, and manage boundaries.
• Require the approved boundary during creation with IAM policy conditions such as iam:PermissionsBoundary.
• Prevent administrators from creating unrestricted roles that trusted services can assume.
• Monitor CloudTrail for boundary creation, replacement, deletion, policy attachment, role assumption, and iam:PassRole activity.
• Treat permissions boundaries as a preventive control, not a complete security model. Combine them with least privilege, SCPs, identity policies, resource policies, and monitoring.
• Test the effective permissions of both the delegated administrator and the principals they can create. Privilege-escalation analysis must include indirect paths.

Quick Reference Summary

• Purpose: Limit the maximum permissions available to an IAM user or role.
• Formula: Identity-based permissions intersected with the permissions boundary.
• Boundary alone: Grants nothing.
• Explicit deny: Always wins.
• Primary use case: Safe delegation of IAM administration.
• Privilege-escalation defense: Require boundaries on users and roles created by delegated administrators.
• Critical limitation: Boundaries do not automatically propagate and can be bypassed if unauthorized users can modify or remove them.
• Complementary controls: SCPs, session policies, resource policies, least privilege, CloudTrail, and iam:PassRole restrictions.

Flashcards

1. Q: What is an IAM permissions boundary?

A: A policy that defines the maximum permissions an IAM user or role can receive through identity-based policies.

1. Q: Does a permissions boundary grant permissions?

A: No. It only limits permissions granted elsewhere.

1. Q: How are effective permissions calculated?

A: The effective permissions are the intersection of the identity-based policy permissions and the permissions allowed by the boundary, subject to other applicable policies.

1. Q: Which IAM entities can have permissions boundaries?

A: IAM users and IAM roles.

1. Q: Can a permissions boundary override an explicit deny?

A: No. An explicit deny overrides an allow.

1. Q: Do permissions boundaries automatically apply to users created by a bounded user?

A: No. The new users or roles must have boundaries attached separately.

1. Q: Why are permissions boundaries useful for delegated administration?

A: They allow administrators to create or manage IAM entities while limiting the maximum access those entities can receive.

1. Q: What happens if an identity policy allows s3:*, but the boundary allows only s3:GetObject?

A: The principal can use only the S3 actions permitted by both policies, such as s3:GetObject where resource conditions also match.

1. Q: What is a major boundary-management risk?

A: Allowing a delegated administrator to modify, delete, or replace the boundary.

1. Q: Which permission should be reviewed when a user can cause a role to act on its behalf?

A: iam:PassRole.

Practice Questions

Question 1

A company allows a development team to create IAM roles for application workloads. Developers must be able to attach policies to those roles, but they must not be able to create a role with permissions outside the security team’s approved maximum. What is the best design?

A. Attach AdministratorAccess to the developers and rely on CloudTrail alerts
B. Create a permissions boundary managed by the security team and require every developer-created role to use it
C. Use an S3 bucket policy to restrict the roles
D. Attach a permissions boundary only to the developer IAM group

Correct answer: B

Explanation: A permissions boundary limits the maximum permissions of each role. The company must also restrict boundary modification and use IAM conditions or equivalent controls to require the approved boundary. Boundaries do not attach directly to groups and are not replaced by monitoring alone.

Question 2

An IAM user has an identity policy allowing ec2:*, s3:*, and iam:*. The user’s permissions boundary allows only ec2:* and s3:*. Which result is expected?

A. The user can perform all three categories because the identity policy is broader
B. The user can perform EC2 and S3 actions allowed by both policies, but not IAM actions
C. The boundary is invalid because it does not include every identity-policy action
D. The user cannot perform any action because the policies do not match exactly

Correct answer: B

Explanation: The boundary establishes the maximum set of permissions. IAM actions excluded from the boundary are not effective, while matching EC2 and S3 permissions can be effective if no other policy denies them.

Question 3

A delegated IAM administrator can create users, attach any managed policy, and remove permissions boundaries. The administrator’s own IAM user has a restrictive boundary. The security team discovers that the administrator created an unrestricted administrator user. Why did the boundary fail to prevent the escalation?

A. Permissions boundaries do not work with IAM users
B. The administrator’s boundary should have been attached to the account root user
C. A boundary on the administrator does not automatically propagate, and the administrator could remove boundaries from created entities
D. AdministratorAccess always overrides a permissions boundary

Correct answer: C

Explanation: Boundaries are attached per user or role. The boundary on the original administrator does not automatically protect created principals. In addition, allowing boundary deletion or replacement creates a direct bypass path.

Question 4

A security architect wants to ensure that an IAM role cannot use permissions outside the organization’s account-wide restrictions, even if a role policy and permissions boundary allow them. Which additional control is most appropriate?

A. An AWS Organizations service control policy
B. An S3 access point
C. An IAM group boundary
D. An additional identity policy granting the missing actions

Correct answer: A

Explanation: An SCP provides an organization- or OU-level guardrail that limits permissions available in member accounts. It works alongside permissions boundaries and identity policies; it does not grant permissions by itself.

Question 5

An application role has an identity policy allowing access to a sensitive database service. Its permissions boundary also allows that access. However, an explicit deny in another applicable policy denies the database actions. What is the result?

A. The boundary’s allow takes precedence
B. The identity policy’s allow takes precedence
C. The explicit deny prevents the database actions
D. The role can access the database only when assumed by the account root user

Correct answer: C

Explanation: Explicit denies override allows regardless of whether the allow comes from an identity policy or is permitted by a permissions boundary.