This chapter covers IAM Permissions Boundaries, a critical feature for delegating permission management while maintaining security guardrails. For the DVA-C02 exam, permissions boundaries appear in roughly 5-8% of questions, often in scenarios involving cross-account access or delegating IAM administration. Understanding how boundaries interact with identity-based and resource-based policies is essential for designing secure, scalable AWS architectures. This chapter will explain the mechanism, configuration, and common exam traps.
Jump to a section
Imagine you are the owner of a large office building. You hire a general contractor to manage renovations. You give the contractor a master key that can open every door in the building. However, you are worried the contractor might misuse the key to enter restricted areas like the server room or the executive suite. To prevent this, you issue a 'building permit' that explicitly lists the floors and rooms the contractor is allowed to enter. The permit is attached to the contractor's badge. Even though the master key can unlock any door, the security guard at each door checks the permit before allowing entry. If the permit does not list the room, access is denied, even if the key works. In AWS, the master key is the permissions policy attached to an IAM role. The building permit is the permissions boundary. The security guard is the IAM service's evaluation logic. The boundary limits the maximum permissions the role can have, regardless of what the attached policies say. This ensures that even if a developer attaches a policy granting full admin access, the boundary restricts it to only the allowed services and actions.
What is an IAM Permissions Boundary?
An IAM permissions boundary is an advanced AWS feature that sets the maximum permissions that an identity-based policy can grant to an IAM entity (user or role). It acts as a guardrail: the effective permissions of the entity are the intersection of the permissions boundary and the identity-based policies. If a policy grants an action that is not allowed by the boundary, that action is denied. The boundary itself is a managed policy (AWS or customer managed) that defines the maximum allowed actions.
Permissions boundaries do not grant permissions on their own. They only limit what can be granted. This is a crucial distinction: a boundary with Effect: Allow on s3:PutObject does NOT give the entity the ability to put objects unless an identity-based policy also allows it. The boundary simply says, "Even if you have a policy that allows S3 write, you cannot exceed this set."
Why Permissions Boundaries Exist
Permissions boundaries solve a specific problem: how to allow developers or junior admins to create and manage IAM roles without giving them full administrative privileges. Without boundaries, a user with iam:CreateRole and iam:AttachRolePolicy could create a role with any permissions, effectively escalating their own privileges. For example, they could create a role with administrator access and then assume that role. Permissions boundaries prevent this by restricting the permissions that any role they create can have.
How It Works Internally
When IAM evaluates a request for a user or role that has a permissions boundary, it performs a multi-step evaluation:
Deny evaluation: Check if there is an explicit deny in any applicable policy (identity-based, resource-based, boundary, or service control policy). If an explicit deny exists, the request is denied immediately.
Boundary check: If the entity has a permissions boundary, IAM checks whether the requested action is allowed by the boundary. If the action is not allowed by the boundary, the request is denied (even if an identity-based policy allows it).
Allow evaluation: If the action passes the boundary check, IAM then checks the identity-based policies. If an identity-based policy allows the action, the request is allowed. If no policy allows it, the request is denied.
This means the effective permissions are the intersection of the identity-based policy and the permissions boundary. In mathematical terms: EffectivePermissions = IdentityPolicy ∩ BoundaryPolicy.
Key Components and Defaults
Permissions boundary policy: A managed policy (AWS managed or customer managed). It must be attached to the user or role. For roles, the boundary can be specified at creation time or updated later. For users, it can be attached at any time.
Maximum permissions: The boundary defines the maximum set of actions and resources. The entity cannot exceed this set, regardless of what identity-based policies are attached.
No effect on resource-based policies: Permissions boundaries only apply when the entity is the principal making a request. They do not limit what the entity can do when its ARN is the resource in a resource-based policy (e.g., an S3 bucket policy granting access to a role). In that case, the resource-based policy grants permissions directly to the principal, bypassing the boundary.
Service control policies (SCPs): SCPs are similar but operate at the AWS Organizations level. Permissions boundaries are entity-level. Both can apply simultaneously; the most restrictive applies.
Configuration and Verification
Creating a permissions boundary policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"dynamodb:GetItem",
"dynamodb:PutItem"
],
"Resource": "*"
}
]
}Attaching a boundary to a role (using AWS CLI):
aws iam create-role --role-name MyLimitedRole --assume-role-policy-document file://trust-policy.json --permissions-boundary arn:aws:iam::123456789012:policy/MyBoundaryPolicyAttaching a boundary to an existing user:
aws iam put-user-permissions-boundary --user-name MyUser --permissions-boundary arn:aws:iam::123456789012:policy/MyBoundaryPolicyVerifying effective permissions:
Use the IAM policy simulator to see the intersection. The simulator shows which actions are allowed after applying all policies including the boundary.
Interaction with Related Technologies
Identity-based policies: The boundary limits these. Without a boundary, identity-based policies grant full permissions. With a boundary, the effective set is the intersection.
Resource-based policies: Not affected by boundaries. For example, if an S3 bucket policy grants s3:PutObject to a role, the role can write to the bucket even if its boundary does not include s3:PutObject. This is a common exam trap.
AWS Organizations SCPs: SCPs set maximum permissions for all accounts in an OU. Boundaries are per entity. Both can restrict permissions; the effective permission is the intersection of all applicable policies.
IAM roles for EC2: When an EC2 instance assumes a role with a boundary, the instance's permissions are limited by the boundary. This is a common pattern for delegating instance management.
Common Exam Scenarios
Delegating role creation: A user has iam:CreateRole and iam:AttachRolePolicy but with a permissions boundary that only allows S3 read access. The user can create roles, but any role they create can only have S3 read permissions, even if they attach a full admin policy.
Cross-account access: When a role in Account A is assumed by a user from Account B, the boundary of the role in Account A applies. The boundary limits what the role can do in Account A, but does not limit what the user can do in Account B (where the user's own policies apply).
Boundary vs. resource-based policy: A Lambda function with a boundary that does not allow logs:CreateLogGroup can still write to CloudWatch Logs if the log group's resource-based policy grants logs:CreateLogGroup to the Lambda function's execution role. This is a high-yield exam point.
Edge Cases and Exceptions
PassRole permission: To attach a permissions boundary to a role, the user must have iam:PassRole permission on the boundary policy ARN. Without it, the operation fails.
Boundary on service-linked roles: Service-linked roles cannot have permissions boundaries. They are predefined by AWS.
Boundary on root user: The root user cannot have a permissions boundary. Root has full access.
Maximum number of boundaries: A user or role can have only one permissions boundary attached at a time.
Boundary on users: When a user has a boundary, all actions the user takes (including using the AWS Management Console) are limited by the boundary.
Best Practices
Use AWS managed policies like AdministratorAccess as boundaries? No, that would allow everything. Instead, create custom boundaries that restrict to the specific services needed.
Always test boundaries with the IAM policy simulator before deploying.
For delegated administration, combine boundaries with service control policies for defense in depth.
Remember that boundaries do not grant permissions; they only limit. Always attach identity-based policies that grant the desired permissions within the boundary.
Define the maximum permissions
Create a managed IAM policy that lists the maximum allowed actions and resources. This policy will serve as the permissions boundary. It must be a customer managed or AWS managed policy. The policy uses the standard IAM policy language. For example, a boundary that allows only S3 read and write operations on a specific bucket. This policy does not grant permissions by itself; it only sets an upper limit. When creating this policy, ensure you include all necessary actions for the intended use case, but no more. Remember that the boundary applies to all identity-based policies attached to the entity.
Attach boundary to IAM entity
Attach the boundary policy to the IAM user or role. For a new role, specify the `--permissions-boundary` parameter during creation. For an existing user, use `put-user-permissions-boundary`. For an existing role, use `put-role-permissions-boundary`. The entity can have only one boundary at a time. If you attach a new boundary, it replaces the old one. The boundary is applied immediately; there is no propagation delay. Once attached, the entity's effective permissions are the intersection of its identity-based policies and the boundary.
Attach identity-based policies
Attach the usual identity-based policies (managed or inline) that grant the desired permissions. These policies can grant permissions that are a subset of the boundary. If a policy grants an action not in the boundary, that action is denied. For example, if the boundary allows only S3 GetObject, and the identity-based policy allows S3 PutObject, the PutObject action is denied. The entity's effective permissions are the intersection. This step is where the developer or administrator defines the actual permissions, but they are constrained by the boundary.
Test with IAM policy simulator
Use the IAM policy simulator to verify that the effective permissions are as expected. The simulator evaluates all applicable policies (identity-based, boundary, resource-based, SCPs) and shows the result for each action. This is crucial for catching misconfigurations. For example, you can simulate a request to list all S3 buckets. If the boundary does not allow `s3:ListAllMyBuckets`, the simulator will show 'denied'. The simulator also shows which policy caused the denial. This helps in debugging.
Monitor and audit with CloudTrail
Enable AWS CloudTrail to log all IAM actions, including changes to permissions boundaries. CloudTrail records events such as `PutRolePermissionsBoundary` and `PutUserPermissionsBoundary`. This allows you to audit who attached which boundary to which entity. Additionally, you can use IAM Access Analyzer to identify resources that are shared with external entities, but note that Access Analyzer does not specifically analyze boundaries. For ongoing compliance, use AWS Config rules to check that all roles have a specific boundary attached.
Enterprise Scenario 1: Delegating IAM Administration to Developers
A large enterprise wants to allow its development teams to create and manage IAM roles for their applications, but without giving them full administrative power. Without permissions boundaries, a developer with iam:CreateRole could create a role with administrator access and then assume that role, effectively bypassing all restrictions. To solve this, the security team creates a permissions boundary policy that restricts roles to specific services (e.g., EC2, S3, DynamoDB) and denies access to IAM, Organizations, and other security-sensitive services. This boundary is attached to all roles created by developers. The developers are given permissions to create roles only if they specify this specific boundary policy ARN (using the iam:PassRole permission on the boundary). This ensures that no matter what policies the developer attaches, the role can never exceed the boundary. In production, this is configured using a combination of IAM policies and service control policies at the AWS Organizations level. The security team also uses AWS Config to monitor that all roles have the required boundary attached. A common mistake is forgetting to restrict iam:PassRole to the boundary ARN, which would allow developers to create roles without a boundary. This leads to privilege escalation.
Enterprise Scenario 2: Multi-Account Access with Boundaries
A company uses AWS Organizations with multiple accounts. A central security account manages IAM roles that are assumed by users in other accounts. To limit what these roles can do, each role has a permissions boundary that restricts actions to the minimum required. For example, a role used for read-only access to production accounts has a boundary that allows only Read access for specific services. This prevents the role from accidentally or maliciously modifying resources. The boundary is combined with an SCP at the OU level that denies all actions outside a whitelist. The effective permissions are the intersection of the identity-based policy, the boundary, and the SCP. In this setup, the boundary acts as a second layer of defense. A frequent misconfiguration is setting the boundary too permissive (e.g., allowing all EC2 actions when only read is needed). This can lead to unintended modifications. Performance is not a concern because boundaries are evaluated in milliseconds.
Scenario 3: Cross-Account Lambda Execution
A company has a Lambda function in Account A that needs to access a DynamoDB table in Account B. The Lambda execution role in Account A has a permissions boundary that allows only DynamoDB read actions. The DynamoDB table in Account B has a resource-based policy that grants dynamodb:GetItem to the Lambda role's ARN. The Lambda function can read from the table, even though the boundary does not include dynamodb:GetItem. This is because resource-based policies grant permissions directly to the principal, bypassing the boundary. This is a classic exam trap. In practice, many engineers assume the boundary would block this access. The correct approach is to ensure that the resource-based policy is properly scoped and that the boundary is used to limit what the role can do within its own account.
What the DVA-C02 Tests
The DVA-C02 exam tests IAM Permissions Boundaries under Domain 2: Security, Objective 2.1: Implement identity and access management. Specifically, you need to understand:
How permissions boundaries limit effective permissions (intersection model).
The difference between boundaries and identity-based policies.
That boundaries do not affect resource-based policies.
The iam:PassRole permission requirement for attaching boundaries.
Scenarios where boundaries prevent privilege escalation.
Common Wrong Answers and Why Candidates Choose Them
"Permissions boundaries grant permissions." Candidates confuse boundaries with identity-based policies. They see a boundary that allows S3 actions and think the entity has those permissions. Reality: Boundaries only set a maximum; the entity still needs an identity-based policy that allows the same actions.
"A permissions boundary on a role limits what the role can do when accessing resources in another account via a resource-based policy." This is false. Resource-based policies grant permissions directly to the principal, bypassing the boundary. Candidates often think boundaries apply universally. Exam questions often describe a cross-account scenario with a resource-based policy and ask if the boundary blocks access.
"You can attach multiple permissions boundaries to a single IAM role." AWS limits to one boundary per entity. Candidates might think multiple boundaries can be combined. Reality: Only one boundary is allowed. If you attach a new one, it replaces the old one.
"Permissions boundaries are the same as service control policies (SCPs)." While both set maximum permissions, SCPs apply at the AWS Organizations level and affect all principals in an account. Boundaries apply to individual entities. Candidates may confuse the two, especially in multi-account scenarios.
Specific Numbers and Terms
One boundary per entity: The exam may ask how many boundaries can be attached to a user or role. Answer: One.
`iam:PassRole`: This permission is required to attach a boundary to a role. The resource ARN must be the boundary policy ARN.
ARN format: arn:aws:iam::account-id:policy/policy-name.
No boundary on root user: The exam may test that root cannot have a boundary.
No boundary on service-linked roles: These are predefined and cannot have boundaries.
Edge Cases and Exceptions
Boundary on a user who then assumes a role: When a user assumes a role, the user's boundary does not apply to the role session. The role's own boundary applies.
Boundary on a role that is used by an AWS service: For example, an EC2 instance profile role with a boundary. The boundary limits what the EC2 instance can do.
Boundary with `NotAction`: You can use NotAction in a boundary to deny everything except a specific set. This is a common pattern for restrictive boundaries.
How to Eliminate Wrong Answers
If a question mentions a resource-based policy (e.g., S3 bucket policy, Lambda function policy), remember that boundaries do not limit access granted by resource-based policies.
If a question asks about granting permissions, look for the combination of identity-based policy AND boundary. A boundary alone does not grant anything.
If a question involves delegating IAM administration, look for the iam:PassRole permission on the boundary ARN.
Remember that the effective permissions are the intersection. If the boundary allows s3:GetObject and the identity-based policy allows s3:PutObject, the effective permission is neither (since PutObject is denied by the boundary).
Permissions boundaries set the maximum permissions an IAM entity can have; effective permissions = identity-based policy ∩ boundary.
Boundaries do not grant permissions; they only limit what can be granted.
A user or role can have only one permissions boundary attached at a time.
Permissions boundaries do not affect resource-based policies (e.g., S3 bucket policies, Lambda resource policies).
To attach a boundary to a role, the user must have iam:PassRole permission on the boundary policy ARN.
The root user and service-linked roles cannot have permissions boundaries.
Boundaries are evaluated after explicit denies but before identity-based allows in IAM's policy evaluation logic.
These come up on the exam all the time. Here's how to tell them apart.
Permissions Boundary
Applies to individual IAM users or roles.
Managed as an IAM policy (customer or AWS managed).
Requires explicit attachment to each entity.
Does not affect resource-based policies.
Can be used without AWS Organizations.
Service Control Policy (SCP)
Applies to all principals in an AWS account or organizational unit.
Managed as an SCP within AWS Organizations.
Applied at the OU or account level, not per entity.
Does not affect resource-based policies (same as boundary).
Requires AWS Organizations to be enabled.
Mistake
A permissions boundary grants permissions to the IAM entity.
Correct
A permissions boundary only sets a maximum limit; it does not grant any permissions on its own. The entity must also have an identity-based policy that allows the desired actions. The effective permissions are the intersection of the identity-based policy and the boundary.
Mistake
You can attach multiple permissions boundaries to a single user or role.
Correct
AWS allows only one permissions boundary per IAM user or role. If you attach a new boundary, it replaces the existing one. There is no way to combine multiple boundaries.
Mistake
A permissions boundary on a role limits access granted by resource-based policies.
Correct
Permissions boundaries apply only when the entity is the principal making a request. Resource-based policies grant permissions directly to the principal, bypassing the boundary. For example, an S3 bucket policy that grants access to a role's ARN allows the role to access the bucket even if the role's boundary does not include S3 actions.
Mistake
Permissions boundaries and service control policies (SCPs) are identical.
Correct
Both set maximum permissions, but SCPs apply at the AWS Organizations level to all principals in an account, while permissions boundaries apply to individual IAM users or roles. They can both be in effect simultaneously, and the effective permission is the most restrictive combination.
Mistake
The root user can have a permissions boundary.
Correct
The root user has full administrative access and cannot be restricted by a permissions boundary. AWS does not allow attaching a boundary to the root user.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, a permissions boundary does not grant any permissions. It only defines the maximum set of actions and resources that an identity-based policy can grant. For an entity to have permissions, it must also have an identity-based policy (managed or inline) that allows the desired actions. The effective permissions are the intersection of the identity-based policy and the boundary. For example, if a boundary allows s3:GetObject but no identity-based policy allows it, the entity cannot get objects.
Permissions boundaries do not affect resource-based policies. When a resource-based policy grants access to an IAM entity (e.g., an S3 bucket policy granting s3:GetObject to a role), the entity can perform the action even if its permissions boundary does not include that action. This is because resource-based policies grant permissions directly to the principal, bypassing the boundary. This is a common exam trap.
Both set maximum permissions, but they operate at different levels. A permissions boundary applies to an individual IAM user or role, while an SCP applies to all principals in an AWS account or organizational unit within AWS Organizations. SCPs are managed at the organization level and affect all accounts in an OU. Both can be in effect simultaneously, and the effective permission is the most restrictive combination. For example, if a boundary allows EC2:StartInstances but an SCP denies it, the action is denied.
No, AWS allows only one permissions boundary per IAM user or role. If you attempt to attach a second boundary, it will replace the existing one. There is no way to combine multiple boundaries. To achieve a similar effect, you can create a single boundary policy that includes all the necessary restrictions.
No, the root user cannot have a permissions boundary. The root user has full administrative access to the AWS account and cannot be restricted by any IAM policy, including boundaries. This is by design to ensure that the root user can always recover access if needed.
To attach a permissions boundary to a role, the user must have the iam:PassRole permission on the boundary policy ARN. This is in addition to the permissions required to create or update the role. For example, the user needs iam:CreateRole or iam:PutRolePermissionsBoundary, and iam:PassRole on the boundary policy resource.
You can use the IAM policy simulator to test the effective permissions. The simulator evaluates all applicable policies, including the identity-based policy, permissions boundary, resource-based policies, and SCPs, and shows whether each action is allowed or denied. Additionally, you can use the AWS CLI command 'aws iam get-role' or 'get-user' to see the attached boundary, but the simulator is the best tool for testing specific actions.
You've just covered IAM Permissions Boundaries — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?