This chapter covers IAM Permission Boundaries, a critical advanced feature for delegating permission management while maintaining security guardrails. On the SAA-C03 exam, permission boundaries appear in roughly 5-10% of questions related to Secure Architectures, often as a distractor or correct answer in scenarios involving delegated administration or cross-account access. Understanding how permission boundaries interact with identity-based policies and resource-based policies is essential for designing secure, scalable AWS environments.
Jump to a section
Imagine a large office complex with many departments. Each department has its own area, and employees have badges that grant access to specific rooms. The company wants to allow managers to assign badges to their team members, but they must ensure no employee can ever enter the executive floor or the server room—even if a manager makes a mistake or acts maliciously. To enforce this, the company installs a security guard at every entrance. The guard carries a master list (the permission boundary) that defines the maximum access any badge can have. When an employee tries to enter a room, the guard checks two things: the badge's permissions and the master list. The guard denies access if either check fails. Even if a manager grants a badge full access to the entire building, the guard's master list overrides it, preventing entry to the executive floor and server room. This way, the guard acts as an ultimate limit, ensuring no one can exceed certain privileges, regardless of what their badge says. In AWS IAM, permission boundaries work exactly like this guard—they define the maximum permissions that an IAM entity (user or role) can have, and any policy attached to that entity cannot grant permissions beyond the boundary.
What Are IAM Permission Boundaries?
IAM permission boundaries are an advanced feature that allows you to set the maximum permissions that an identity-based policy can grant to an IAM entity (user or role). They do not grant permissions by themselves; instead, they act as a guardrail that limits the effective permissions of the entity. The effective permissions of a user or role are the intersection of the permission boundary and the identity-based policies attached to that entity. If a permission boundary is set, any action not allowed by the boundary is denied, even if the identity-based policy explicitly allows it.
Why Permission Boundaries Exist
Permission boundaries exist to solve a key problem in AWS IAM: how to delegate permission management to teams or developers without giving them full administrative control. For example, you might want to allow a development lead to create and manage IAM roles for their team, but you want to ensure that no role can ever have access to production databases or billing information. Without permission boundaries, if you grant someone the ability to create roles, they could theoretically create a role with full administrator access. Permission boundaries let you define a set of maximum permissions that any role created by that lead can have, preventing privilege escalation.
How Permission Boundaries Work Internally
When a user or role makes an API call, AWS evaluates the following policies in order: 1. Identity-based policies (attached to the user or role) 2. Resource-based policies (if applicable) 3. IAM permission boundary (if set) 4. Organizations service control policies (SCPs) 5. Session policies (when using role chaining or STS)
The effective permission is the union of all allow statements from these policies, intersected with the permission boundary and SCPs. Specifically, the permission boundary acts as a filter: any action that is not allowed by the boundary is denied, regardless of what the identity-based policy says. If no permission boundary is set, the identity-based policy's full scope is considered (subject to SCPs and resource-based policies).
Key Components and Values
Permission boundary policy: A JSON policy document that defines the maximum permissions. It can be a managed policy (AWS or customer managed) or an inline policy.
Entity types: Permission boundaries can be applied to IAM users and IAM roles. They cannot be applied to groups.
Effective permissions: The intersection of the identity-based policy and the permission boundary. For example, if the identity-based policy allows ec2:* but the permission boundary only allows ec2:Describe*, the effective permission is ec2:Describe*.
Default: No permission boundary is set by default. If none is set, the identity-based policy's full scope applies (subject to other policies).
Cross-account access: Permission boundaries do not affect resource-based policies. If a role has a permission boundary, it can still access resources in another account if the resource-based policy allows it, as long as the action is allowed by the boundary.
Configuration and Verification
You can set a permission boundary when creating a user or role, or later by editing the entity. To set a permission boundary via AWS CLI:
aws iam create-role --role-name MyRole --assume-role-policy-document file://trust-policy.json --permissions-boundary arn:aws:iam::aws:policy/AWSLambdaExecuteTo verify the effective permissions, use the IAM policy simulator or the aws iam simulate-principal-policy command:
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/MyRole --action-names ec2:RunInstancesInteraction with Related Technologies
Service Control Policies (SCPs): SCPs are similar but applied at the AWS Organizations level to all accounts. Permission boundaries are applied per entity. SCPs and permission boundaries both limit permissions; the effective permission is the intersection of all policies including SCPs and boundaries.
Session Policies: When you assume a role using STS, you can pass a session policy that further limits permissions. The session policy is intersected with the role's permission boundary and identity-based policies.
Resource-based policies: These are not affected by permission boundaries. If a resource-based policy allows an action, the principal can perform that action even if their permission boundary denies it, provided the action is not also denied by an identity-based policy or SCP. However, the permission boundary still applies to the principal's own identity-based permissions.
Exam-Relevant Details
Permission boundaries are often used in delegated administration scenarios. For example, you can create a role that allows a developer to create other roles, but attach a permission boundary to those roles to limit their maximum permissions.
Common exam scenario: An admin wants to allow a team to manage their own IAM roles but prevent them from giving those roles access to sensitive services like IAM or S3 with full access. The correct solution is to attach a permission boundary to the roles created by the team.
Trap: A question might describe a scenario where a user has a policy that allows iam:CreateRole and iam:AttachRolePolicy. Without a permission boundary, the user could create a role with administrator access. The correct answer is to use a permission boundary to limit the maximum permissions of any role created by that user.
Numbers: There is a limit of one permission boundary per user or role. The boundary policy document size limit is the same as other IAM policies (6144 characters for managed policies, 10240 characters for inline policies).
Define the permission boundary policy
Create a JSON policy document that specifies the maximum permissions allowed. This policy can be a managed policy (AWS managed or customer managed) or an inline policy. The policy must include the actions, resources, and conditions that define the boundary. For example, to allow only EC2 and S3 read-only access, you would write a policy with `ec2:Describe*` and `s3:Get*` actions. This policy does not grant permissions itself; it only sets a limit.
Attach the boundary to an IAM entity
When creating or modifying an IAM user or role, you can specify the permission boundary by providing the ARN of the boundary policy. For a role, you do this during creation with the `--permissions-boundary` parameter in the AWS CLI, or in the console under the 'Permissions boundary' section. For a user, you can set it in the 'Permissions' tab. Once attached, the boundary is enforced immediately.
Attach identity-based policies to the entity
After setting the permission boundary, you can attach identity-based policies (managed or inline) to the user or role. These policies define the specific permissions the entity should have, but they cannot exceed the boundary. For example, if the boundary allows only `ec2:Describe*`, attaching a policy that allows `ec2:RunInstances` will not grant that action because the boundary denies it.
Evaluate effective permissions
When the entity makes an API call, AWS evaluates the identity-based policy and the permission boundary. The effective permission is the intersection: only actions that are allowed by both policies are granted. If the identity-based policy allows an action that the boundary denies, the action is denied. AWS also evaluates SCPs and session policies if applicable, further narrowing the effective permissions.
Test and verify with the IAM policy simulator
Use the IAM policy simulator to test the effective permissions of the entity. Provide the user or role ARN and the actions you want to test. The simulator will show whether each action is allowed or denied, taking into account the permission boundary. This is a critical step to ensure the boundary is correctly configured and that the entity does not have unintended access.
Enterprise Scenario 1: Delegated Role Creation in a Multi-Account Environment
A large enterprise uses AWS Organizations with hundreds of accounts. The central security team wants to allow each application team to create and manage their own IAM roles within their respective accounts, but they must ensure that no role can ever have access to the organization's master account or to sensitive services like IAM, S3 with full access, or Lambda with admin privileges. The security team creates a customer managed policy called MaxPermissionsBoundary that allows only specific services and actions (e.g., ec2:Describe*, s3:GetObject, dynamodb:Query). They then create a role called RoleCreator in each account with permissions to create roles (iam:CreateRole, iam:AttachRolePolicy) but attach a condition that requires the created roles to have the MaxPermissionsBoundary policy as their permission boundary. This is done using a condition in the identity-based policy: "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/MaxPermissionsBoundary" } }. Any role created by RoleCreator will automatically have the boundary attached, preventing privilege escalation. In production, this setup scales to thousands of roles, and the security team audits regularly to ensure no role has been modified to remove the boundary.
Enterprise Scenario 2: Cross-Account Access with Limited Scope
A company has a centralized logging account that needs to assume roles in member accounts to collect logs. The security team wants to ensure that the logging role can only access CloudWatch Logs and S3 buckets with a specific prefix, even if the role's identity-based policy is broader. They create a permission boundary policy that allows only logs:CreateLogGroup, logs:PutLogEvents, and s3:PutObject with a condition on the bucket ARN. When the logging role is created in each account, the boundary is attached. Even if someone accidentally attaches a broader policy like AdministratorAccess to that role, the boundary will prevent any actions outside the allowed list. This provides a safety net against misconfiguration. Common pitfalls include forgetting to update the boundary when new services are added, or using a boundary that is too restrictive, causing the logging to fail silently.
Performance and Scale Considerations
Permission boundaries themselves do not impact performance; they are evaluated during authorization, which adds minimal latency (typically <10ms). However, managing many custom boundary policies can become complex. Use AWS managed policies where possible (e.g., AWSLambdaExecute) to reduce overhead. Also, be aware of the policy size limits: 6144 characters for managed policies, 10240 for inline. If your boundary policy is large, consider splitting into multiple policies? No, only one boundary per entity, so you must fit all limits into a single policy.
SAA-C03 Exam Focus on IAM Permission Boundaries
The SAA-C03 exam tests permission boundaries primarily in the context of Secure Architectures (Domain 1) and Design for Security and Compliance (Objective 1.1). Questions typically present a scenario where an administrator needs to delegate permission management while maintaining guardrails. The correct answer often involves using a permission boundary, while common wrong answers include using service control policies (SCPs), resource-based policies, or simply attaching a restrictive identity-based policy.
Common Wrong Answers and Why Candidates Choose Them
Using SCPs instead of permission boundaries: Candidates often confuse the two because both limit permissions. However, SCPs apply at the account or OU level, not to individual users/roles. If the scenario involves delegating role creation to a user within an account, SCPs are not the right answer because they affect all principals in the account, not just the roles created by that user. The exam tests this distinction: SCPs are for organization-wide guardrails, permission boundaries are for per-entity limits.
Attaching a restrictive identity-based policy directly to the role: Some candidates think that simply giving the developer a policy that allows creating roles but with limited permissions is enough. However, the developer could still attach a broader policy to the role they create, bypassing the restriction. Permission boundaries prevent this by imposing a hard limit that cannot be exceeded.
Using resource-based policies: Resource-based policies are attached to resources (like S3 buckets) and control who can access that resource. They do not limit what actions a principal can perform on other resources. Permission boundaries are about the principal's maximum permissions, not about who can access a specific resource.
Specific Numbers and Terms That Appear on the Exam
Maximum of one permission boundary per user or role.
Permission boundaries do not grant permissions; they only limit them.
Effective permissions = intersection of identity-based policy and permission boundary.
Permission boundaries can be applied to IAM users and roles, not groups.
Use the `iam:PermissionsBoundary` condition key in policies to enforce that a role must have a specific boundary.
Edge Cases and Exceptions
Resource-based policies can override permission boundaries? No, but they are evaluated separately. If a resource-based policy allows an action, the principal can perform that action even if their permission boundary denies it? Actually, no. The permission boundary still applies to the principal's own actions. For example, if a role has a permission boundary that denies s3:PutObject, but an S3 bucket policy allows the role to put objects, the request will be denied because the boundary denies it. However, if the action is not covered by the boundary (i.e., the boundary does not explicitly deny it), the resource-based policy can allow it. The key is that the boundary must allow the action for the resource-based policy to take effect. This is a common exam trap.
Session policies: When assuming a role, you can pass a session policy that further restricts permissions. The session policy is intersected with the role's permission boundary and identity-based policy. This allows temporary narrowing of permissions.
How to Eliminate Wrong Answers
If the scenario involves delegating permission management (e.g., allowing a user to create roles for others), look for permission boundary.
If the scenario involves organization-wide limits across multiple accounts, think SCP.
If the scenario involves controlling access to a specific resource (e.g., an S3 bucket), think resource-based policy.
If the scenario is about limiting what a specific user/role can do without delegation, think identity-based policy or permission boundary if there is a need to enforce a hard limit that cannot be changed by the user.
Permission boundaries set the maximum permissions an IAM user or role can have; they do not grant permissions.
Only one permission boundary can be attached per user or role.
Effective permissions are the intersection of the identity-based policy and the permission boundary.
Permission boundaries can be applied to IAM users and roles, but not to groups.
Use the condition key `iam:PermissionsBoundary` in policies to enforce that roles created by a user must have a specific boundary.
Permission boundaries are often used in delegated administration scenarios to prevent privilege escalation.
Resource-based policies are not overridden by permission boundaries; the boundary still applies to the principal's actions.
These come up on the exam all the time. Here's how to tell them apart.
Permission Boundaries
Applied to individual IAM users or roles.
Do not grant permissions; only limit them.
Managed within a single AWS account.
Can be used to delegate permission management safely.
Effective permissions = intersection of identity-based policy and boundary.
Service Control Policies (SCPs)
Applied to AWS accounts or organizational units (OUs).
Do not grant permissions; only limit them.
Managed at the AWS Organizations level.
Used for organization-wide guardrails across multiple accounts.
Effective permissions = intersection of all policies including SCPs.
Mistake
Permission boundaries grant permissions to a user or role.
Correct
Permission boundaries do not grant permissions; they only set a limit on the maximum permissions that identity-based policies can grant. The entity still needs an identity-based policy that allows actions within the boundary to actually perform those actions.
Mistake
Permission boundaries can be applied to IAM groups.
Correct
Permission boundaries can only be applied to IAM users and roles, not to groups. If you want to apply a boundary to all members of a group, you must apply it to each user individually or use a role with the boundary.
Mistake
A permission boundary overrides a resource-based policy, allowing the resource-based policy to grant access even if the boundary denies it.
Correct
The permission boundary is evaluated for the principal's own actions. If the boundary denies an action, the principal cannot perform that action, even if a resource-based policy allows it. The resource-based policy does not override the boundary.
Mistake
Service control policies (SCPs) and permission boundaries are interchangeable.
Correct
SCPs apply at the AWS Organizations level to all accounts in an OU, while permission boundaries apply to individual IAM users or roles within an account. They are complementary but not interchangeable. SCPs are for organization-wide guardrails, permission boundaries for per-entity limits.
Mistake
You can attach multiple permission boundaries to a single user or role.
Correct
Each IAM user or role can have only one permission boundary. If you need to combine multiple limits, you must create a single policy that includes all the restrictions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A permission boundary is applied to an individual IAM user or role within an account, setting the maximum permissions that identity-based policies can grant. An SCP is applied to an AWS account or organizational unit (OU) at the AWS Organizations level, setting the maximum permissions for all principals in that account or OU. Both limit permissions, but they operate at different scopes: permission boundaries per entity, SCPs per account/OU. They can be used together; the effective permission is the intersection of all applicable policies.
No, a permission boundary does not grant any permissions. It only defines the maximum permissions that an identity-based policy can grant. The entity still needs an identity-based policy (e.g., a managed or inline policy) that explicitly allows actions within the boundary. Without an identity-based policy, the entity has no permissions, even with a boundary set.
Resource-based policies are attached to resources (e.g., S3 buckets, SQS queues) and specify who can access that resource. When a principal makes a request, AWS evaluates both the principal's permissions (identity-based policy and permission boundary) and the resource-based policy. The request is allowed only if both the principal's permissions and the resource-based policy allow the action. The permission boundary still applies to the principal's own permissions, so if the boundary denies an action, the request is denied even if the resource-based policy allows it.
Yes, you can change or remove a permission boundary from a user or role at any time. To change it, you attach a different boundary policy. To remove it, you set the permission boundary to 'None'. However, note that removing a boundary may increase the entity's effective permissions if its identity-based policies are broad. Always test changes using the IAM policy simulator.
Permission boundaries do not use explicit deny; they only define allowed actions. The effective permission is the intersection of what is allowed by both policies. If the identity-based policy allows an action that is not allowed by the boundary, the action is denied. If the identity-based policy denies an action (explicit deny), that deny overrides any allow from the boundary or identity-based policy. AWS evaluates explicit denies first.
Yes, permission boundaries can be applied to cross-account roles. When a role in Account A has a permission boundary, it limits what that role can do within Account A and when accessing other accounts. However, when the role accesses resources in another account, the resource-based policy in that account may allow actions that the boundary would otherwise deny? Actually, the boundary still applies: the role's effective permissions are limited by the boundary, so it cannot perform actions the boundary denies, regardless of resource-based policies.
You can use a condition in the user's IAM policy that requires the `iam:PermissionsBoundary` condition key to match a specific boundary ARN. For example, when calling `iam:CreateRole`, the user must include the `--permissions-boundary` parameter with the required ARN. The condition would be: `"Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/MyBoundary" } }`. This ensures the user cannot create a role without the boundary.
You've just covered IAM Permission Boundaries — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?