This chapter covers IAM permission boundaries, an advanced IAM feature that sets the maximum permissions an IAM user or role can have. It is part of the Security Compliance domain, which makes up approximately 25% of the CLF-C02 exam. Understanding permission boundaries is critical for questions about delegating permission management and enforcing privilege limits. You will learn how boundaries differ from service control policies (SCPs) and how they solve the problem of preventing privilege escalation when users manage their own IAM policies.
Jump to a section
Imagine you are the general manager of a large hotel. You have housekeeping staff who need to enter guest rooms to clean them. You want to give each housekeeper a master key that opens every room, but you also want to ensure they cannot access the hotel's main safe or the manager's office. An IAM permission boundary is like a security seal on each staff member's key card that says, "This key can open any door, but it can never open the safe or the office, no matter what." Even if a housekeeper somehow gets a new key card that says "open safe," the seal on their card prevents that. Similarly, in AWS, a permission boundary is a managed policy that sets the maximum permissions an IAM entity (user or role) can have. Even if you attach a more permissive policy directly to the user, the boundary acts as a cap, preventing any action beyond the boundary. This is different from a service control policy (SCP), which is like a hotel-wide rule that applies to all keys. The boundary is per-person, ensuring that even if someone is accidentally given too many permissions, they cannot exceed the boundary. This mechanism allows delegation of permissions management without giving away full administrative control.
What Is a Permission Boundary and What Problem Does It Solve?
An IAM permission boundary is a managed policy that defines the maximum permissions that an identity-based policy can grant to an IAM entity (user or role). When you set a permission boundary, the effective permissions of that entity are the intersection of the identity-based policy and the boundary. In other words, the entity can only perform actions that are allowed by both the identity-based policy AND the boundary. If either denies an action, the action is denied.
The problem permission boundaries solve is the challenge of delegating IAM policy management to users or roles without giving them full administrative control. For example, you might want developers to create and attach policies to their own roles, but you need to ensure they cannot escalate their privileges beyond a certain level (e.g., cannot create IAM users or modify S3 bucket policies). Without a boundary, a developer could attach a policy that grants themselves admin access. With a boundary, you can cap their permissions so that even if they attach a permissive policy, they cannot exceed the boundary.
How Permission Boundaries Work – The Mechanism
Permission boundaries work at the IAM entity level. They are not inherited by child entities (e.g., a role created by a user with a boundary does not automatically get the user's boundary). You must explicitly set a boundary on each entity.
The evaluation logic for effective permissions is: 1. If there is an explicit deny in any policy (identity-based, resource-based, boundary, or SCP), the action is denied. 2. If there is an explicit allow in the identity-based policy AND the boundary allows it (or no boundary is set), the action is allowed. 3. If the identity-based policy allows an action but the boundary does not, the action is denied. 4. If there is no identity-based policy allowing the action, it is denied by default (implicit deny).
Thus, the boundary acts as a filter: it can only reduce permissions, never increase them. You cannot use a boundary to grant permissions; it only restricts.
Key Tiers, Configurations, and Pricing
Permission boundaries are a feature of AWS Identity and Access Management (IAM). They are free of charge. There is no limit on the number of permission boundaries you can create, but each IAM user or role can have only one permission boundary at a time. The boundary itself is a managed policy (either AWS managed or customer managed). You can use the same boundary for multiple entities.
To set a permission boundary, you need the iam:PutRolePermissionsBoundary or iam:PutUserPermissionsBoundary permission. Typically, only administrators set boundaries. When creating a role via the AWS Management Console, you can optionally select a permissions boundary in the "Set permissions boundary" step. For users, you set it during creation or later in the user's summary page.
Comparison to On-Premises or Competing Approaches
In on-premises environments, you might use Active Directory group policies or Unix file permissions to restrict users. However, those are often static and require manual management. IAM permission boundaries provide a cloud-native way to enforce maximum permissions dynamically. Compared to AWS Organizations service control policies (SCPs), which apply to all accounts in an OU, permission boundaries apply to individual IAM entities within a single account. SCPs are like a global cap for an entire account, while boundaries are per-entity caps inside that account. They work together: an entity's effective permissions are the intersection of identity-based policy, boundary, and SCP (and any resource-based policies).
Another approach is to simply not delegate permission management and have a central admin attach policies. But that creates a bottleneck. Boundaries allow secure delegation.
When to Use Permission Boundaries vs Alternatives
Use permission boundaries when:
You want to allow developers or teams to create and manage their own IAM roles and policies, but you need to prevent them from granting themselves excessive permissions (e.g., IAM admin, S3 bucket deletion).
You are using AWS Organizations and want to add an extra layer of restriction within an account beyond SCPs.
You need to enforce a consistent maximum permission level for certain types of roles (e.g., all EC2 roles can only access S3 and DynamoDB).
Do NOT use permission boundaries when:
You want to restrict all principals in an account – use SCPs instead.
You want to grant permissions – boundaries only restrict.
You need to enforce restrictions on service-linked roles – boundaries are not supported for service-linked roles.
Important Limits and Defaults
Each IAM user or role can have only one permission boundary.
Permission boundaries are not supported for service-linked roles.
The boundary policy must be a managed policy (AWS managed or customer managed). You cannot use an inline policy as a boundary.
The maximum size of a permissions boundary policy is 6,144 characters (same as other managed policies).
You can set a permission boundary on a role when creating it or later; for users, you can set it at creation or later.
When you delete a permission boundary policy, all entities that had that boundary lose their boundary restriction. This can cause privilege escalation if those entities have permissive identity-based policies. AWS warns before deletion.
Example CLI Commands
To set a permission boundary on an existing role:
aws iam put-role-permissions-boundary --role-name MyRole --permissions-boundary arn:aws:iam::123456789012:policy/MyBoundaryTo set a permission boundary on a new user:
aws iam create-user --user-name NewUser --permissions-boundary arn:aws:iam::123456789012:policy/MyBoundaryExample CloudFormation Snippet
Resources:
MyRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: ec2.amazonaws.com
Action: sts:AssumeRole
Policies:
- PolicyName: MyInlinePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: s3:GetObject
Resource: '*'
PermissionsBoundary: arn:aws:iam::123456789012:policy/MyBoundaryIn this example, even though the inline policy allows s3:GetObject on all resources, the boundary may restrict it further (e.g., to only a specific bucket).
Create a Managed Policy
First, you create a customer managed policy that defines the maximum permissions you want to allow. For example, you might create a policy that allows all EC2 actions but denies IAM actions. This policy will serve as the permission boundary. You can create it via the IAM console, CLI, or CloudFormation. The policy must be a managed policy (not inline). AWS managed policies can also be used as boundaries, but custom boundaries are more common for precise control. The policy document follows standard IAM policy syntax, with Effect, Action, Resource, and optional Condition elements. Remember that the boundary can only restrict, so you typically use Allow statements to define what is permitted, and Deny statements are unnecessary because anything not allowed is implicitly denied.
Attach Boundary to a User or Role
Next, you attach the boundary to an IAM user or role. In the AWS Management Console, when creating or editing a user, you can select the permissions boundary under the 'Set permissions boundary' section. For a role, it is in the 'Permissions boundary' step of the role creation wizard. You can also use the CLI commands `put-user-permissions-boundary` or `put-role-permissions-boundary`. Once attached, the boundary takes effect immediately. The entity's existing identity-based policies are still in place, but now the effective permissions are limited to the intersection of those policies and the boundary. AWS evaluates the boundary during every request.
Attach Identity-Based Policies
After the boundary is set, an administrator or the user themselves (if allowed) can attach identity-based policies (managed or inline) to the user or role. These policies define what the entity wants to allow. However, because the boundary is in place, any action that is allowed by the identity-based policy but not by the boundary will be denied. For example, if the identity-based policy allows `iam:CreateUser` but the boundary does not, the action is denied. The user might see an 'AccessDenied' error even though their policy appears to allow it. This is the core mechanism: the boundary acts as a safety net, preventing privilege escalation even if the identity-based policy is overly permissive.
Test Effective Permissions
To verify that the boundary is working correctly, you can use the IAM policy simulator. Simulate the actions that the entity should and should not be able to perform. The simulator shows the effective permissions after considering the identity-based policy and the boundary. Alternatively, you can test by attempting actions as the entity. For example, if you set a boundary that denies all IAM actions, try to list IAM users – it should fail. If you try to launch an EC2 instance (if allowed by both policies), it should succeed. This step is crucial to ensure the boundary does not inadvertently block legitimate actions. Remember that the boundary does not grant permissions; it only restricts. So the entity also needs an identity-based policy that allows the desired actions.
Monitor and Audit Boundary Usage
Finally, monitor how boundaries are used in your account. AWS CloudTrail logs all API calls, including `PutRolePermissionsBoundary` and `PutUserPermissionsBoundary`. You can track who set boundaries and on which entities. AWS Config can be used to check if entities have a specific boundary attached, helping enforce compliance. Also, be aware that if you delete a boundary policy, the boundary is removed from all entities that used it. AWS will warn you, but you should audit regularly to ensure no entity has lost its boundary unexpectedly. This could lead to privilege escalation if the entity has permissive identity-based policies. Use tools like IAM Access Analyzer to identify unintended access.
Scenario 1: Delegating IAM Management to a DevOps Team
A large enterprise has a central cloud team that manages the AWS account. They want to allow the DevOps team to create and manage their own IAM roles for their applications, but they cannot allow the DevOps team to grant themselves full administrative access. The central team creates a permission boundary policy that allows all EC2, S3, DynamoDB, and Lambda actions, but denies all IAM actions (except iam:PassRole with conditions). They attach this boundary to a role that the DevOps team can assume. The DevOps team then creates roles for their apps and attaches policies as needed. However, no matter what policy they attach, the boundary prevents them from creating IAM users or modifying IAM roles. This allows the central team to safely delegate IAM management without risking privilege escalation. Cost: no additional cost for using boundaries. Misconfiguration: if the central team accidentally does not set a boundary, the DevOps team could escalate privileges. Also, if the boundary is too restrictive, it might block legitimate actions needed by the apps.
Scenario 2: Multi-Tenant SaaS Application
A SaaS provider runs a multi-tenant application on AWS. Each customer's workload runs in a separate AWS account. The provider uses AWS Organizations and SCPs to restrict all accounts. However, within each account, the provider wants to allow customers to create their own IAM roles for their users. To prevent customers from accidentally giving themselves too many permissions, the provider sets a permission boundary on the IAM role that the customer uses to manage their account (e.g., a role assumed via AWS SSO). The boundary limits actions to only those necessary for the customer's specific service (e.g., only EC2 and RDS in a specific region). This ensures that even if the customer attaches a policy that allows everything, they cannot exceed the boundary. Misconfiguration: if the boundary is not updated when new services are added, the customer may be unable to use new features, leading to support tickets.
Scenario 3: Developer Sandbox Accounts
A company gives each developer a personal AWS account for experimentation. To prevent developers from incurring high costs or using prohibited services, the company uses permission boundaries on the IAM users that developers log in with. The boundary allows only low-cost services (e.g., t2.micro EC2, S3 standard, Lambda free tier) and denies any action that could modify IAM or billing. This allows developers freedom within safe limits. Without boundaries, a developer could accidentally launch expensive instances or delete critical resources. Misconfiguration: if the boundary is too restrictive, it hinders learning; if too permissive, it defeats the purpose. Regular reviews are needed.
Exactly What CLF-C02 Tests on This Objective
The CLF-C02 exam tests your understanding of permission boundaries as a tool for delegating permission management and enforcing privilege limits. You should know:
The definition: a permission boundary sets the maximum permissions an IAM entity can have.
How effective permissions are determined: intersection of identity-based policy and boundary.
Use cases: delegating IAM management, preventing privilege escalation.
Difference from SCPs: SCPs apply to all IAM entities in an account (via Organizations), boundaries apply to specific entities within an account.
That boundaries can only restrict, never grant.
That each user/role can have only one boundary.
That boundaries are not supported for service-linked roles.
Common Wrong Answers and Why Candidates Choose Them
'Permission boundaries grant permissions.' Candidates often think that setting a boundary gives the entity those permissions. In reality, boundaries only restrict; you still need an identity-based policy to allow actions.
'Permission boundaries are the same as service control policies.' They are similar but not the same. SCPs apply at the account level; boundaries apply to individual IAM entities. The exam may ask which one would be used to restrict a specific role within an account.
'You can use an inline policy as a permission boundary.' No, only managed policies can be used as boundaries. Candidates might confuse inline policies with managed ones.
'Permission boundaries are inherited by child roles.' Boundaries are not inherited. Each role must have its own boundary set explicitly.
Specific Terms and Values That Appear Verbatim
'Permissions boundary' (not 'permission boundary' – note the 's')
'Maximum permissions'
'Intersection'
'Service control policy (SCP)'
'Identity-based policy'
'Managed policy'
'Service-linked role' (boundaries not supported)
The ARN format for a boundary policy: arn:aws:iam::account-id:policy/policy-name
Tricky Distinctions
The exam often asks you to choose between using a permission boundary, an SCP, or a resource-based policy. Key distinction: if you need to restrict a specific IAM user or role within an account, use a permission boundary. If you need to restrict all principals in an account (or OU), use an SCP. Resource-based policies are attached to resources (like S3 buckets) and control access to that resource, not to the principal.
Decision Rule for Multiple-Choice Questions
When you see a question about limiting what a developer can do when managing their own IAM roles, ask: 'Is the restriction per-entity or per-account?' If per-entity, the answer is permission boundary. If per-account, the answer is SCP. Also, if the question mentions 'maximum permissions' or 'cap', it's likely a boundary. If it mentions 'delegating administration', it's probably a boundary. Remember that boundaries are always about setting a ceiling, not granting access.
Permission boundaries set the maximum permissions an IAM user or role can have; effective permissions are the intersection of identity-based policy and boundary.
Only managed policies (AWS managed or customer managed) can be used as permission boundaries; inline policies are not allowed.
Each IAM user or role can have only one permission boundary at a time.
Permission boundaries are not supported for service-linked roles.
Deleting a permission boundary policy removes the boundary from all entities using it, potentially causing privilege escalation.
Permission boundaries differ from SCPs: boundaries apply per entity within an account, SCPs apply to all entities in an account/OU.
Use permission boundaries when you want to delegate IAM policy management while preventing privilege escalation.
These come up on the exam all the time. Here's how to tell them apart.
Permission Boundary
Applies to individual IAM users or roles within an account
Set at the IAM entity level
Can only restrict, never grant
Each entity can have only one boundary
Used to delegate permission management safely
Service Control Policy (SCP)
Applies to all IAM users and roles in an AWS account (or OU)
Set at the AWS Organizations level
Can only restrict, never grant
Each account can have multiple SCPs (effective permissions are intersection)
Used to enforce compliance across accounts
Mistake
Permission boundaries grant permissions to the entity.
Correct
Permission boundaries only restrict permissions; they never grant. To allow an action, you must also have an identity-based policy that allows it. The boundary acts as a cap, not a grant.
Mistake
Permission boundaries are the same as service control policies (SCPs).
Correct
SCPs apply to all IAM entities in an AWS account (or OU) and are set at the AWS Organizations level. Permission boundaries apply to individual IAM users or roles within a single account. They can be used together.
Mistake
You can use an inline policy as a permission boundary.
Correct
Only managed policies (AWS managed or customer managed) can be used as permission boundaries. Inline policies are not allowed.
Mistake
Permission boundaries are inherited by roles created by a user with a boundary.
Correct
Permission boundaries are not inherited. Each IAM user or role must have its own boundary explicitly attached. A role created by a user with a boundary does not automatically get that boundary.
Mistake
Deleting a permission boundary policy has no effect on entities that used it.
Correct
When you delete a managed policy that is used as a permission boundary, the boundary is removed from all entities that had it attached. This can lead to privilege escalation if those entities have permissive identity-based policies.
A permission boundary is attached to a specific IAM user or role within an account and limits that entity's maximum permissions. A service control policy (SCP) is attached to an AWS account (or OU) and applies to all IAM users and roles in that account (except the management account). Both restrict permissions, but at different scopes. For the exam, remember: boundaries are per-entity; SCPs are per-account. They can work together: an entity's effective permissions are the intersection of identity-based policy, boundary, and SCP.
No. A permission boundary only restricts permissions. It defines the maximum allowed actions. To actually allow an action, you must also have an identity-based policy (managed or inline) that allows it. If the identity-based policy allows an action that the boundary does not, the action is denied. If the identity-based policy does not allow an action, it is denied regardless of the boundary.
Each IAM user or role can have exactly one permission boundary at a time. You can change it, but you cannot attach multiple boundaries. If you need to combine restrictions, you must create a single managed policy that includes all restrictions.
Yes. You can use any managed policy (AWS managed or customer managed) as a permission boundary. However, AWS managed policies are often too broad for boundaries. It is common to create a custom customer managed policy that precisely defines the maximum permissions you want to allow.
When you delete a managed policy that is used as a permission boundary, the boundary is removed from all IAM users and roles that had it attached. After deletion, those entities no longer have a boundary, so their effective permissions are determined solely by their identity-based policies (and any SCPs). This could lead to privilege escalation if the identity-based policies are permissive. AWS warns you before deletion.
Permission boundaries affect only identity-based policies (policies attached to the IAM user or role). They do not affect resource-based policies (e.g., S3 bucket policies). However, when a principal accesses a resource, the effective permissions are evaluated considering both the principal's identity-based policy (with boundary) and the resource-based policy. If either denies, the action is denied.
No. Service-linked roles are predefined by AWS services and cannot have permission boundaries. The exam may test this as a fact: permission boundaries are not supported for service-linked roles.
You've just covered IAM Permission Boundaries — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?