IAM Permissions Boundaries and Roles solve the problem of how to give someone power without giving them unlimited power. They allow you to delegate the ability to create and manage permissions for others while still maintaining a safety net. For the SCS-C02 exam, understanding this distinction is crucial because it is the core mechanism for implementing the principle of least privilege in complex, multi-team environments.
Jump to a section
A simple way to picture IAM Permissions Boundaries, Roles, and Advanced Concepts
A stadium access pass is a physical card that grants entry to a specific venue.
Imagine you are the operations manager for a huge concert stadium. You issue a special 'All-Access' pass to your head of security. This pass lets them go anywhere: the control room, backstage, the VIP lounge, and every seating section. It is a powerful pass. Now, you realise that while the head of security needs broad access, they should never enter the vault where the night's cash is counted. You do not want to take away their All-Access pass entirely because they need it for emergencies elsewhere. So, you create a 'Zone Restriction' label that you stick to the pass. This label says, 'This pass is valid everywhere except the Cash Vault Area.' The pass still works for every other door, but when the holder tries to swipe into the vault, the system checks the zone restriction and denies entry.
In cloud security, the IAM user or role is the pass, the permissions policies are the All-Access ability, and the permissions boundary is the 'Zone Restriction' label. The boundary sets the absolute maximum permission that the entity can ever have, no matter what other policies are attached. It does not grant permission itself; it limits the scope of any granted permissions. This separation of powers allows a central security team to delegate authority to individual teams without giving them unlimited power.
To understand IAM Permissions Boundaries, we must first understand IAM (Identity and Access Management). IAM is the AWS service that lets you control who can do what with your AWS resources. It is the gatekeeper for your cloud account.
The fundamental building blocks of IAM are Policies. A policy is a document written in JSON (JavaScript Object Notation) that specifies permissions. Think of it as a set of rules. For example, a policy might state: 'Allow access to read data from the S3 bucket named MySecretBucket.'
There are two main types of policies: Identity-based policies and Resource-based policies. An Identity-based policy is attached to an IAM user, group, or role and defines what that identity can do. A Resource-based policy is attached to a resource (like an S3 bucket) and defines who can access that resource.
Now, let us discuss IAM Roles. A role is an identity within AWS that you can assume. It does not have its own permanent credentials like a username and password. Instead, it has a set of permissions that someone or something can 'assume' temporarily. For example, an EC2 instance can assume a role to get temporary credentials to access a DynamoDB table. This is much more secure than hardcoding access keys into the instance. Roles are central to the concept of delegation in AWS.
Permissions Boundaries are a more advanced concept. A Permissions Boundary is a policy that sets the maximum permissions that an identity-based policy can grant to an IAM entity (user or role). It is an upper limit. It does not grant permissions; it defines the ceiling.
Here is how they work together:
An Administrator creates a Permissions Boundary policy that says: 'Maximum permissions allowed are: read-only access to DynamoDB and full access to S3.'
They then create a new IAM role and attach this Permissions Boundary to it.
The Administrator also attaches an Identity-based policy that says: 'Allow full access to all AWS services.'
The effective permissions for that role are NOT 'full access to all AWS services'. Because the Permissions Boundary exists, the role's effective permissions are limited to what is allowed by both the Identity-based policy AND the Permissions Boundary. In this case, the Identity-based policy grants full access, but the Boundary restricts it to read-only DynamoDB and full S3. The role gets only the intersection of the two: read-only DynamoDB and full S3.
The concept replaces the need for a central admin to micromanage every single policy by allowing them to create broad policies and then apply boundaries to limit their scope. This is critical in organisations where different teams manage their own resources. A central security team can create a boundary that prevents any team from exceeding a certain privilege level, even if the team attaches a policy that says 'allow everything'.
When you use a Permissions Boundary, you must still attach an Identity-based policy. The Boundary alone does nothing. It is only a limiter. The final set of permissions is the logical intersection of the Identity-based policy and the Permissions Boundary. If the Identity-based policy allows Action X, but the Boundary does not explicitly allow Action X (or denies it), the action is denied.
Common use cases for Permissions Boundaries include:
Delegating administration to a new team: You give them full admin access to their own project's resources by attaching a broad admin policy, but you also attach a boundary that prevents them from touching resources in other projects.
Allowing developers to create roles for their applications: You let developers create roles with any policy they like, but you set a boundary that prevents those roles from ever having IAM-modifying permissions (like creating or deleting users).
Implementing service control policies (SCPs) at the account level: While SCPs are an AWS Organizations feature, Permissions Boundaries work at the resource level within a single account and are a more granular tool for similar purposes.
Why does this matter for the SCS-C02 exam? Because the exam loves to test your ability to distinguish between what a policy grants and what a boundary limits. It also tests how boundaries interact with other policies, especially Trust Policies. A Trust Policy is a resource-based policy attached to a role that defines who can assume that role. It is separate from the Permissions Boundary.
Define the Boundary Policy
Create a JSON policy document that explicitly lists the maximum actions and resources you want to allow. For example, a boundary policy might allow all EC2 actions but deny any IAM actions. This becomes your upper limit.
Create the IAM Role
In the AWS IAM console, create a new role. You will be asked to select a trust entity (e.g., an AWS service like EC2) and attach a trust policy. This is separate from the permissions boundary.
Attach the Permissions Boundary
During the role creation (or later), under the 'Permissions boundary' section, select the policy you created in Step 1. This sets the absolute ceiling for this role's permissions.
Attach an Identity-Based Policy
Attach a managed or inline policy that grants specific permissions, such as 'Allow S3 read access'. The role's effective permissions will be the intersection of this policy and the Permissions Boundary.
Test the Role
Assume the role and try to perform actions. For example, if your identity-based policy allows full admin access but the boundary only allows S3 read, any attempt to write to S3 or access other services will fail, confirming the boundary is working.
Delegate Role Creation with Boundaries
To allow other users to create roles with boundaries, grant them the iam:CreateRole and iam:PassRole permissions, and specify the boundary policy ARN in the iam:PassRole condition. This ensures they can only attach the approved boundary.
Let us walk through a realistic scenario. You work for a company called 'FinTech Corp' that has multiple teams: a DevOps team, a Data Science team, and a Security team. Each team manages its own AWS resources within a single account. The Security team wants to give the DevOps team the ability to create their own IAM roles for their applications, but the Security team wants to ensure that no DevOps engineer can accidentally give a role full admin access.
Here is what the Security team does step by step:
The Security team creates a Permissions Boundary policy named 'DevOps-Boundary'. This policy explicitly allows actions on services like EC2, S3, and Lambda, but it denies all IAM actions except for 'iam:PassRole' and 'iam:CreateRole'. It also denies actions on resources tagged with 'Project-DataScience'.
The Security team attaches this 'DevOps-Boundary' to a new IAM group called 'DevOps-Engineers' using a special setting. Actually, boundaries are attached directly to the role or user, not indirectly via a group. So the team creates a process: every time a DevOps engineer wants a new role, they must use a specific IAM role that already has the boundary attached.
A DevOps engineer needs to create a role for their application that runs on EC2. They do not have permission to create a role themselves (because the boundary denies IAM actions). So they request the Security team to create the role for them. The Security team creates the role, attaches a policy that allows the application to read from a specific S3 bucket, and attaches the 'DevOps-Boundary' as the Permissions Boundary. The Security team also attaches a Trust Policy that allows only the specific EC2 instance profile to assume the role.
The outcome: The DevOps engineer cannot modify the role's permissions because the Permissions Boundary prevents them from performing IAM actions. They are also unable to accidentally give the role access to Data Science resources because the boundary denies it. The Security team retains control over the maximum privilege level for all roles.
This is a classic example of the 'separation of duties' that the SCS-C02 exam tests. You must understand that the person who manages the Permissions Boundary is different from the person who attaches the Identity-based policy. The Boundary is the safety net.
Another common real-world scenario involves using roles for cross-account access. Suppose you want to allow a trusted third-party auditor to access your billing information. You create a role in your account that has a policy allowing read-only access to billing. You then define a Trust Policy that allows the auditor's AWS account to assume that role. In this case, you might also attach a Permissions Boundary to that role to ensure that even if someone in your account messes with the policy, the role can never write or delete billing data.
The SCS-C02 exam will test you extensively on IAM Permissions Boundaries, Roles, and their interaction. Here is exactly what you need to know. - The exam loves to give you a scenario where a developer or team is given 'full admin' access to something but is then restricted by a Permissions Boundary. The correct answer will always involve the Permissions Boundary as the limiting factor. - You will see questions that ask: 'What is the effective permission of a role when an Identity-based policy allows Action X but a Permissions Boundary does not allow Action X?' The answer is that Action X is denied. - They test the difference between a Permissions Boundary and a Service Control Policy (SCP). An SCP is used in AWS Organizations to set permissions boundaries for an entire account or organizational unit. A Permissions Boundary is used for a single IAM role or user within an account. The exam will ask which one to use in a given scenario. - The exam tests the concept of 'passing a role' (iam:PassRole). This permission is required when a user wants to assign a role to an AWS resource (like an EC2 instance). The exam will ask: 'Which permission allows a user to attach an existing role to a new EC2 instance?' The answer is iam:PassRole. - They test the interaction between Trust Policies and Permissions Boundaries. A Trust Policy defines who can assume a role. A Permissions Boundary limits what that role can do once assumed. They are independent but both must be considered. - The exam often includes a scenario where a user has multiple policies attached (an inline policy, a managed policy, and a permissions boundary). The effective permissions will be the logical intersection of all the policies that allow, minus any explicit denies.
Trap patterns to watch out for:
Trap: A question says 'a user is made an admin of an account but cannot perform some actions.' Look for a Permissions Boundary or a Service Control Policy that is limiting them.
Trap: A question says 'a role is created for an EC2 instance, but the application cannot access S3.' The issue could be that the role's Permissions Boundary does not include S3 access, even though the role's policy does.
Trap: A question says 'a developer wants to create a new IAM role with full permissions but the system denies it.' The developer probably lacks the iam:CreateRole permission or the Permissions Boundary they can apply is restrictive.
Key definitions to memorise:
Identity-based policy: Attached to a user, group, or role, grants permissions.
Resource-based policy: Attached to a resource (e.g., S3 bucket), defines who can access it.
Permissions Boundary: A policy that sets the maximum permissions for an identity.
Trust Policy: A resource-based policy attached to a role that defines who can assume it.
Effective permissions: The actual permissions after evaluating all policies, including boundaries.
iam:PassRole: The permission needed to pass a role to an AWS resource.
Service Control Policy (SCP): An AWS Organizations policy that sets permission guardrails for accounts.
The exam questions on this topic are often scenario-based. You will read a paragraph describing a business requirement, and you must select the correct combination of IAM features to implement it. For example: 'How can a security team allow developers to create roles for their apps while ensuring those roles cannot be given access to production databases?' The answer: Use a Permissions Boundary that denies access to production databases.
Finally, know that the exam will test the concept of 'intersection' versus 'union'. When you have multiple policies, the union of all permissive policies applies, but a Permissions Boundary and explicit denies create exceptions. The effective permission is the intersection of the identity-based policy's allow set and the boundaries' allow set, minus any explicit denies.
A Permissions Boundary sets the maximum permissions an IAM role or user can have, acting as a safety cap over any identity-based policies.
Effective permissions are the intersection of the identity-based policy's allow set and the Permissions Boundary's allow set, minus any explicit denies.
Permissions Boundaries do not grant permissions by themselves; they only limit what other policies can grant.
An SCP works at the AWS account or OU level, while a Permissions Boundary works at the individual IAM user or role level.
You cannot attach a Permissions Boundary to an IAM group; it must be attached directly to a user or role.
To allow a user to attach a role to an AWS resource, you need to grant the iam:PassRole permission, which can also be restricted by a Permissions Boundary.
Trust Policies and Permissions Boundaries serve different functions: Trust Policies control who can assume a role, while Boundaries control what that role can do.
These come up on the exam all the time. Here's how to tell them apart.
Permissions Boundary
Attached to an individual IAM role or user
Sets a maximum permission limit within a single AWS account
Used for fine-grained delegation of permissions within an account
Service Control Policy (SCP)
Attached to an entire AWS account or organizational unit (OU)
Sets a permission guardrail for all users and roles in that account
Used for central governance across multiple accounts in AWS Organizations
Identity-Based Policy
Attached to an IAM user, group, or role
Defines what actions the identity can perform
Grants permissions directly to the identity
Resource-Based Policy
Attached to an AWS resource (e.g., S3 bucket, SQS queue)
Defines who can access the resource and what actions they can take
Grants permissions to a principal (another AWS account or service)
Permissions Boundary
Limits what a role can do once it is assumed
Defines the maximum actions allowed
Works in conjunction with identity-based policies
Trust Policy
Defines who can assume the role
Specifies which principals (users, accounts, services) are allowed to assume the role
Works independently of the role's permissions
Inline Policy
Created and attached directly to a single IAM user, group, or role
Cannot be shared across multiple entities
When the entity is deleted, the policy is also deleted
Managed Policy
Standalone policy that can be attached to multiple entities
Reusable across users, groups, and roles
Persists even if no entities are attached to it
Mistake
A Permissions Boundary grants permissions to a user or role.
Correct
A Permissions Boundary only limits what a policy can grant. It is a safety cap, not a source of permissions. You must still attach an identity-based policy that grants permissions.
The term 'boundary' sounds like it sets the allowable area, which it does, but many beginners think it provides the permissions within that area. They expect the boundary alone to give access, but it does not.
Mistake
Attaching a Permissions Boundary to a user automatically applies the same boundary to all roles that user creates.
Correct
A Permissions Boundary is attached to a specific user or role. If a user creates a new role, the new role does not inherit the user's boundary. The user needs to explicitly attach a boundary to the new role if desired, and only if they have the iam:PassRole permission.
Beginners often think of boundaries as inheritable, like folder permissions in a file system. In IAM, each entity is independent.
Mistake
A Permissions Boundary is the same as a Service Control Policy (SCP).
Correct
An SCP applies to an entire AWS account or organizational unit (OU) within AWS Organizations. A Permissions Boundary applies to a single IAM role or user within an account. They operate at different levels.
Both concepts involve 'setting a maximum permission', so they are easily conflated. The exam tests this distinction directly.
Mistake
If a user has a Permissions Boundary that allows S3 access, they automatically have S3 access.
Correct
The Permissions Boundary only allows up to S3 access. The user also needs an identity-based policy that explicitly grants S3 access. Without that, the boundary is meaningless.
People think of boundaries as 'granting' the access within the boundary line, but technical implementation requires explicit permission due to the default-deny principle.
Mistake
You cannot attach a Permissions Boundary to an IAM group.
Correct
You cannot. Permissions Boundaries can only be attached to IAM users and roles, not to groups. If you want to apply a boundary to all members of a group, you must attach it individually to each user or require users to assume a role with the boundary.
Beginners assume groups are like containers that inherit properties, similar to Active Directory groups. IAM groups only have identity-based policies attached, not boundaries.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can attach a Permissions Boundary to an IAM user directly. This limits the maximum permissions that any policy attached to that user can grant.
Not necessarily. An SCP sets an upper limit for an entire account. A Permissions Boundary sets a more granular limit for a specific role or user within the account. They can be used independently or together.
The effective permission is the intersection. If the identity-based policy allows an action but the boundary does not, the action is denied. If the boundary allows an action but the identity-based policy does not, the action is also denied.
Yes, you can modify or replace the Permissions Boundary policy attached to an IAM role or user at any time, provided you have the required IAM permissions.
No. Permissions Boundaries are not inherited. If you attach a boundary to a role, and that role creates another role, the new role does not automatically get the same boundary.
You must grant them the iam:PassRole permission on the specific role. They also need the ec2:RunInstances permission. Optionally, you can use a Permissions Boundary to limit which roles they can pass.
You've finished IAM Permissions Boundaries, Roles, and Advanced Concepts. Continue through the SCS-C02 study guide to build a complete picture of the exam.
Done with this chapter?