Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson explains IAM permissions boundaries, an advanced AWS Identity and Access Management feature used to control the maximum permissions an IAM user or role can receive.
For the AWS Certified Solutions Architect – Professional SAP-C02 exam, permissions boundaries are important because they often appear in scenarios involving:
- Delegated IAM administration
- Preventing privilege escalation
- Multi-team AWS account governance
- Developer self-service permissions
- Limiting what roles or users can create
- Designing secure access controls at scale
A permissions boundary does not grant permissions by itself. Instead, it acts as a guardrail that limits what an identity-based policy can allow.
Key Concepts
What Is an IAM Permissions Boundary?
A permissions boundary is an IAM policy that defines the maximum permissions an IAM user or role can have.
It is applied to an IAM entity such as:
- IAM user
- IAM role
A permissions boundary works together with identity-based policies. The effective permissions are the overlap between:
- What the identity-based policy allows
- What the permissions boundary allows
If an action is allowed by the identity policy but not allowed by the permissions boundary, the action is not permitted.
Think of it as:
Identity policy = what the user or role is trying to allow
Permissions boundary = the maximum ceiling they are allowed to reach
Permissions Boundaries Do Not Grant Access
This is one of the most important exam points.
A permissions boundary does not provide permissions on its own. It only limits permissions that are granted elsewhere.
For example, assume a user has the following identity-based policy permissions:
- Amazon S3 full access
- Amazon CloudWatch full access
- Amazon EC2 full access
- IAM full access
But the permissions boundary only allows:
- Amazon S3
- Amazon CloudWatch
- Amazon EC2
The user can perform actions in S3, CloudWatch, and EC2 if their identity policy allows them. However, they cannot perform IAM actions because IAM is outside the permissions boundary.
Even though the identity-based policy allows IAM, the boundary blocks it.
Effective Permissions: Policy Intersection
The final permissions are based on the intersection of the identity-based policy and the permissions boundary.
| Policy Type | Allows IAM? | Allows EC2? | Allows S3? | Allows CloudWatch? |
|---|---|---|---|---|
| Identity-Based Policy | Yes | Yes | Yes | Yes |
| Permissions Boundary | No | Yes | Yes | Yes |
| Effective Permissions | No | Yes | Yes | Yes |
The key rule is:
The action must be allowed by both the identity-based policy and the permissions boundary.
If either side does not allow it, the user or role cannot perform the action.
Why Permissions Boundaries Matter
Permissions boundaries are useful when you need to delegate IAM administration without allowing users to exceed approved limits.
Common use cases include:
- Allowing developers to create roles for applications
- Allowing teams to manage their own IAM users or roles
- Preventing junior administrators from granting themselves excessive permissions
- Enforcing organization-wide permission limits
- Supporting self-service cloud operations while maintaining security control
This becomes especially important in large AWS environments where centralized cloud teams need to allow some autonomy without giving away full administrative control.
Privilege Escalation Risk Without Permissions Boundaries
A common security problem occurs when a user has permissions to manage IAM but is not supposed to have access to other AWS services.
For example, a user may have IAM full access so they can create and manage users, groups, policies, or roles. However, they do not have direct permissions to launch EC2 instances, create VPCs, or use other AWS services.
Without guardrails, that user could create a new IAM user or role and attach the AWS managed AdministratorAccess policy to it. Then they could sign in or assume that identity and gain broader permissions than they were originally assigned.
That is a classic privilege escalation scenario.
The user did not initially have full AWS administrator access, but because they could manage IAM freely, they created another identity that did.
How Permissions Boundaries Prevent Privilege Escalation
Permissions boundaries can prevent this by ensuring that IAM users or roles created by delegated administrators cannot exceed an approved permission ceiling.
For example, a user may still be allowed to create IAM users or roles, but any created identity must have a permissions boundary attached. That boundary limits the maximum permissions available to the new identity.
This means the delegated administrator can still perform their job, but they cannot create a more powerful user or role and use it to bypass their own limitations.
In practical terms:
- The IAM administrator can create users.
- The IAM administrator can attach policies.
- But the created user or role is still capped by the boundary.
- The created identity cannot exceed the approved maximum permission set.
Permissions Boundaries vs Identity-Based Policies
Permissions boundaries and identity-based policies work together, but they have different jobs.
| Feature | Purpose |
|---|---|
| Identity-Based Policy | Grants permissions to an IAM user, group, or role |
| Permissions Boundary | Limits the maximum permissions an IAM user or role can have |
| Effective Permissions | The permissions allowed by both the identity policy and boundary |
A permissions boundary is not a replacement for IAM policies. It is a control layer that prevents IAM permissions from expanding beyond a defined limit.
Permissions Boundaries vs Service Control Policies
Permissions boundaries are sometimes confused with Service Control Policies, or SCPs.
Both can act as permission guardrails, but they operate at different levels.
| Control Type | Scope | Applies To | Main Purpose |
|---|---|---|---|
| Permissions Boundary | IAM user or role | Specific IAM identities | Limit maximum permissions for an identity |
| SCP | AWS Organizations account or OU | All identities in member accounts | Limit maximum permissions available in accounts |
| Identity-Based Policy | IAM identity | User, group, or role | Grant permissions |
For the SAP-C02 exam, remember:
- SCPs control what is possible in an AWS account or OU.
- Permissions boundaries control what a specific IAM user or role can receive.
- Identity-based policies grant permissions.
- All applicable policy types must allow the action for access to succeed.
Common Use Cases for Permissions Boundaries
Delegated IAM Administration
A central cloud team may want to allow application teams to create their own IAM roles. However, the central team does not want those application teams to create administrator roles.
A permissions boundary solves this by allowing role creation only when the new role includes an approved boundary.
Developer Self-Service
Developers may need to create roles for Lambda functions, EC2 instances, ECS tasks, or application deployments.
Instead of requiring the platform team to create every role manually, developers can be given controlled self-service access. The permissions boundary ensures that any role they create stays within approved limits.
Preventing AdministratorAccess Abuse
If a user can attach policies but the created identity is required to have a boundary, attaching AdministratorAccess does not automatically result in unrestricted administrator privileges.
The boundary still limits what the identity can actually do.
Multi-Team Governance
In larger AWS environments, multiple teams may need limited administrative capabilities. Permissions boundaries help enforce consistent guardrails without blocking teams from doing their work.
This is especially useful in organizations that use separate AWS accounts for workloads, environments, or business units.
Exam-Relevant Takeaways
For the SAP-C02 exam, remember these points:
- A permissions boundary defines the maximum permissions for an IAM user or role.
- A permissions boundary does not grant permissions.
- Effective permissions are the intersection of the identity-based policy and the permissions boundary.
- If the identity policy allows an action but the boundary does not, the action is denied.
- Permissions boundaries are useful for preventing privilege escalation.
- They are commonly used when delegating IAM administration.
- They apply to IAM users and IAM roles.
- They are different from SCPs, which apply at the AWS Organizations account or OU level.
- A user with IAM permissions can be dangerous if they can create users, roles, or attach policies without boundaries.
- Permissions boundaries can allow self-service while still enforcing centralized governance.
Architecture Decision Guide
| Scenario | Best AWS Choice | Why |
|---|---|---|
| You need to limit what a specific IAM role can ever do | Permissions boundary | It sets the maximum permissions for that role |
| You need to restrict all identities in an AWS account | Service Control Policy | SCPs apply at the AWS Organizations account or OU level |
| You need to grant a user permissions to use S3 | Identity-based IAM policy | Identity policies grant permissions directly |
| You want developers to create IAM roles but not administrator roles | Permissions boundary with IAM role creation controls | Developers can self-service, but created roles cannot exceed the boundary |
| You want to prevent a user with IAM access from creating a more powerful identity | Permissions boundary | The new identity can be forced to stay within an approved permission ceiling |
| You want to block an AWS service across multiple accounts | SCP | Better suited for organization-wide account restrictions |
| You want to control what a Lambda execution role can access | IAM role policy, optionally with a permissions boundary | The role policy grants access; the boundary can enforce maximum limits |
Common Exam Traps
Trap 1: Thinking Permissions Boundaries Grant Permissions
A permissions boundary does not grant access. It only limits access.
If a boundary allows S3 but the identity policy does not allow S3, the user still cannot access S3.
Trap 2: Confusing Permissions Boundaries with SCPs
Permissions boundaries are attached to IAM users or roles.
SCPs are attached to AWS Organizations roots, organizational units, or accounts.
If the scenario is about limiting a specific IAM identity, think permissions boundary. If the scenario is about limiting an entire account or OU, think SCP.
Trap 3: Assuming IAM Full Access Is Always Safe
IAM full access can be dangerous because it may allow a user to create new users or roles with broader permissions.
A user with only IAM access may still escalate privileges if they can create identities and attach powerful policies.
Trap 4: Ignoring the Created Identity
In privilege escalation scenarios, the attacker may not directly use their own identity to perform unauthorized actions. Instead, they create another identity with stronger permissions and use that identity.
Permissions boundaries help prevent that path.
Trap 5: Forgetting the Policy Intersection Model
For an action to be allowed, it must be allowed by the relevant policies and not explicitly denied.
With permissions boundaries, the identity policy and boundary must both allow the action.
Real-World Engineer Notes
In a real AWS environment, permissions boundaries are valuable when you want to balance security governance with team autonomy.
For example, an application team may need to create IAM roles for Lambda, EC2, ECS, or CI/CD pipelines. If every IAM role request has to go through a central cloud team, delivery slows down. But if developers can create any role they want, the environment becomes risky.
A practical design is to create a standardized permissions boundary and require all developer-created roles to use it. Then you can allow developers to create and manage roles while preventing them from creating administrator-level access.
Operationally, this requires careful IAM policy design. You may need controls that:
- Allow users to create roles only if a required permissions boundary is attached
- Prevent users from removing or changing the permissions boundary
- Prevent users from attaching policies that exceed approved access
- Monitor IAM changes with AWS CloudTrail
- Alert on attempts to create roles without boundaries
- Regularly review IAM policies for privilege escalation paths
In enterprise environments, permissions boundaries are usually part of a larger governance model that may include:
- AWS Organizations
- SCPs
- IAM Identity Center
- CloudTrail
- AWS Config
- IAM Access Analyzer
- Centralized logging
- Change control
- Infrastructure as Code guardrails
Permissions boundaries are not a complete security strategy by themselves, but they are a strong control for delegated IAM management.
Quick Reference Summary
Permissions boundaries define the maximum permissions an IAM user or role can have. They do not grant permissions directly. Effective permissions are the overlap between the identity-based policy and the permissions boundary.
They are especially useful for preventing privilege escalation. If a user has IAM permissions, they may be able to create another identity with greater permissions unless boundaries are enforced. By requiring a permissions boundary, AWS can ensure that created users or roles cannot exceed an approved permission ceiling.
For the SAP-C02 exam, associate permissions boundaries with delegated IAM administration, privilege escalation prevention, and maximum-permission guardrails for users and roles.
Flashcards
Q: What is an IAM permissions boundary?
A: A policy that defines the maximum permissions an IAM user or role can have.
Q: Does a permissions boundary grant permissions by itself?
A: No. It only limits permissions granted by identity-based policies.
Q: How are effective permissions calculated when a permissions boundary is used?
A: Effective permissions are the intersection of the identity-based policy and the permissions boundary.
Q: If an identity policy allows IAM actions but the permissions boundary does not, can the user perform IAM actions?
A: No. The action must be allowed by both the identity policy and the permissions boundary.
Q: What AWS security risk can permissions boundaries help prevent?
A: Privilege escalation.
Q: What is a common privilege escalation path involving IAM permissions?
A: A user with IAM access creates another user or role with broader permissions, such as administrator access, and then uses that identity.
Q: What IAM entities can have permissions boundaries?
A: IAM users and IAM roles.
Q: How is a permissions boundary different from an SCP?
A: A permissions boundary limits a specific IAM user or role, while an SCP limits permissions available within an AWS Organizations account or OU.
Q: Why might an organization use permissions boundaries for developers?
A: To let developers create roles or users while preventing them from exceeding approved permissions.
Q: Can attaching AdministratorAccess bypass a permissions boundary?
A: No. The permissions boundary still limits the maximum effective permissions.
Q: In an exam scenario, when should you think of permissions boundaries?
A: When a user or team needs delegated IAM administration but must be prevented from creating identities with excessive permissions.
Q: If a boundary allows EC2 but the identity policy does not allow EC2, can the user use EC2?
A: No. The identity policy must also allow EC2.
Practice Questions
Question 1:
A developer has an identity-based policy that allows full access to Amazon S3, Amazon EC2, Amazon CloudWatch, and IAM. The developer also has a permissions boundary that allows only Amazon S3, Amazon EC2, and Amazon CloudWatch. What can the developer do?
A. Use IAM because the identity-based policy allows IAM
B. Use only the services allowed by both the identity policy and permissions boundary
C. Use all AWS services because the identity policy includes full control
D. Use IAM only if MFA is enabled
Correct Answer:
B. Use only the services allowed by both the identity policy and permissions boundary
Explanation:
The permissions boundary limits the maximum permissions. Even though the identity-based policy allows IAM, the boundary does not, so IAM actions are not allowed.
Question 2:
A user has IAM full access but no permissions to launch EC2 instances. The user creates a new IAM user and attaches the AdministratorAccess policy to that new user. The original user then signs in as the new user and launches EC2 instances. What security issue does this represent?
A. Cross-account access
B. Privilege escalation
C. Resource-based policy inheritance
D. Federation failure
Correct Answer:
B. Privilege escalation
Explanation:
The user created another identity with more permissions than they originally had. This is a privilege escalation path.
Question 3:
A company wants developers to create IAM roles for their applications, but the security team must ensure developers cannot create roles with permissions beyond an approved maximum. What should the solutions architect recommend?
A. Give developers the AWS managed AdministratorAccess policy
B. Use permissions boundaries on developer-created roles
C. Use S3 bucket policies to restrict IAM role creation
D. Disable IAM role creation in all workload accounts
Correct Answer:
B. Use permissions boundaries on developer-created roles
Explanation:
Permissions boundaries are designed to cap the maximum permissions of IAM users or roles. They are commonly used for delegated IAM administration.
Question 4:
Which statement about permissions boundaries is correct?
A. They grant permissions to IAM groups
B. They apply only to AWS Organizations OUs
C. They define the maximum permissions for IAM users and roles
D. They replace the need for identity-based policies
Correct Answer:
C. They define the maximum permissions for IAM users and roles
Explanation:
Permissions boundaries apply to IAM users and roles and define the maximum permissions those identities can have. They do not grant permissions or replace identity-based policies.
Question 5:
A solutions architect is designing governance for a multi-account AWS environment. The company wants to restrict all identities in a specific AWS account from using certain AWS services. Which control is most appropriate?
A. Permissions boundary
B. Service Control Policy
C. IAM access key
D. Resource tag
Correct Answer:
B. Service Control Policy
Explanation:
Permissions boundaries limit specific IAM users or roles. SCPs are used with AWS Organizations to limit the maximum available permissions across accounts or OUs.