This chapter covers the four distinct IAM policy types in AWS: identity-based policies, resource-based policies, permission boundaries, and service control policies (SCPs). Understanding the differences and how they interact is critical for the SAA-C03 exam, as questions on IAM policies appear in roughly 15-20% of exam questions under Domain 1 (Secure Architectures) and Domain 3 (Design for Security). We will explain each policy type, how AWS evaluates them, and the exact rules that determine whether a request is allowed or denied.
Jump to a section
Imagine a secure office building with multiple security layers. The building has a main entrance with a security guard (the AWS account). Employees carry badges that define their access level. There are four types of badge rules:
Identity-based policies are like the access permissions printed directly on each employee's badge. For example, 'Alice's badge says she can enter the server room.' This is attached to the person (IAM user/role).
Resource-based policies are like a sticky note on the server room door that says 'Only employees with a red badge can enter.' This is attached to the resource (the door), and it lists who can access it.
Permission boundaries are like a maximum clearance level stamped on the back of the badge. Even if Alice's badge says she can access the server room, if her permission boundary says 'Maximum clearance: Office only,' she cannot enter the server room. The boundary caps the effective permissions.
Service control policies (SCPs) are like corporate-wide rules posted at the building entrance. They say things like 'No one may enter the vault, regardless of badge permissions.' These apply to all employees in the building (all accounts in an organization) and cannot be overridden—they act as a filter.
The key mechanic: When Alice tries to enter the server room, the guard checks her badge permissions (identity policy), the door's sticky note (resource policy), the clearance level on her badge (permission boundary), and the corporate rules (SCP). Only if all allow the action does she get in. This multi-layer evaluation ensures no single policy grants unintended access.
What Are IAM Policy Types and Why Do They Exist?
AWS Identity and Access Management (IAM) policies are JSON documents that define permissions. However, not all policies are the same. AWS supports four policy types, each with a distinct purpose and evaluation behavior. The exam expects you to know when to use each type and how they combine to produce a final authorization decision.
Identity-based policies are attached to an IAM user, group, or role. They define what actions that identity can perform on which resources. These are the most common policies.
Resource-based policies are attached to a resource (like an S3 bucket, SQS queue, or KMS key). They define who can access that resource and what actions they can perform. Resource-based policies are inline policies (not managed) and are written in the same JSON format.
Permission boundaries are a special type of identity-based policy that sets the maximum permissions that an identity-based policy can grant. They do not grant permissions themselves; they only limit what the identity-based policy can allow.
Service control policies (SCPs) are used with AWS Organizations to centrally control permissions for all accounts in an organization. SCPs are not identity-based policies; they are account-level permission filters. They do not grant permissions; they define a guardrail.
The reason AWS has multiple policy types is to provide defense in depth. For example, even if an administrator grants broad permissions via an identity-based policy, a permission boundary or SCP can prevent unintended access. This layered approach is essential for enterprise security.
How AWS Evaluates Policies: The Authorization Engine
When an IAM principal (user or role) makes a request to an AWS service, the AWS authorization engine evaluates all applicable policies to determine whether to allow or deny the request. The evaluation logic follows these steps:
Collect all applicable policies — This includes:
Identity-based policies attached to the principal (user/group/role).
Resource-based policies on the target resource (if any).
Permission boundaries attached to the principal (if any).
SCPs from AWS Organizations (if the account is part of an organization).
Session policies (if the principal is using temporary credentials via role assumption).
Evaluate each policy for explicit denies — If any policy explicitly denies the action, the request is denied immediately (deny override).
Evaluate for explicit allows — If there is at least one explicit allow from an identity-based or resource-based policy, and no explicit denies, the request is allowed. However, if a permission boundary or SCP is present, the allow must also be within the boundary/SCP.
Default deny — If there is no explicit allow, the request is denied by default.
The key rule: Explicit deny always overrides an allow. Also, permission boundaries and SCPs act as filters: an allow from an identity-based policy is only effective if it is also allowed by the boundary/SCP.
Identity-Based Policies
Identity-based policies are JSON documents that you attach to IAM users, groups, or roles. They can be either AWS managed (predefined by AWS) or customer managed (you create). They can also be inline (embedded directly in the user/group/role).
Example of an identity-based policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::example-bucket/*", "arn:aws:s3:::example-bucket"]
}
]
}This policy allows the attached identity to read objects from the S3 bucket.
Key exam points:
Identity-based policies can grant permissions to the principal they are attached to.
Maximum policy size: 6,144 characters for user/group inline policies, 5,120 characters for managed policies (including the JSON itself, not the name).
A user can have up to 10 managed policies attached (both AWS and customer managed).
A group can have up to 10 managed policies attached.
Resource-Based Policies
Resource-based policies are attached directly to a resource, not to a principal. They specify which principals (AWS accounts, IAM users, or roles) can access that resource and what actions they can perform. Common services that support resource-based policies include S3 (bucket policies), SQS (queue policies), SNS (topic policies), Lambda (function policies), KMS (key policies), and Glacier (vault policies).
Example of an S3 bucket policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/Alice"
},
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::example-bucket/*"]
}
]
}This policy allows Alice (from account 123456789012) to read objects from the bucket.
Key exam points:
Resource-based policies can grant cross-account access without needing to assume a role.
The Principal element is required in resource-based policies (except for S3 bucket policies when using a bucket ACL, but ACLs are legacy).
For cross-account access, the resource-based policy must explicitly list the external account or user. Then the external account must also grant the user permissions via an identity-based policy (unless the resource-based policy grants access directly to the user).
Trust policies for IAM roles are a special type of resource-based policy attached to the role; they define who can assume the role.
Permission Boundaries
A permission boundary is an advanced feature that sets the maximum permissions that an identity-based policy can grant to an IAM user or role. The boundary itself is a managed policy that defines the maximum scope of allowed actions. The effective permissions of the user/role are the intersection of the identity-based policy and the permission boundary.
Example: Suppose a user has an identity-based policy that allows ec2:* and s3:*. But the user also has a permission boundary that only allows ec2:Describe* and s3:List*. The effective permissions are only ec2:Describe* and s3:List*.
Key exam points:
Permission boundaries are only supported for IAM users and roles, not groups.
A permission boundary does not grant permissions; it only limits what can be granted.
To allow a user to create roles with specific permissions (e.g., an admin who can create roles for developers), you attach a permission boundary to the admin's role that limits what roles they can create.
Permission boundaries are often used in conjunction with AWS Organizations to delegate role creation to child accounts.
Service Control Policies (SCPs)
SCPs are a feature of AWS Organizations. They are JSON policies that define the maximum permissions for all accounts in an organization (or a specific organizational unit). SCPs do not grant permissions; they act as a filter over the effective permissions of each account.
Example SCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["s3:DeleteBucket"],
"Resource": ["*"]
}
]
}This SCP prevents any account in the organization from deleting S3 buckets.
Key exam points:
SCPs affect all IAM users and roles in the account, including the root user (unless you explicitly allow root user actions).
SCPs do not affect service-linked roles or the AWS Organizations management account (by default).
SCPs are evaluated before identity-based and resource-based policies. If an SCP denies an action, it is denied regardless of other policies.
SCPs can be either allow lists or deny lists. By default, the FullAWSAccess SCP is attached, which allows everything. If you remove it, you must explicitly allow actions.
SCPs are not the same as IAM policies; they are account-level permission boundaries.
How Policy Types Interact: The Evaluation Flow
When a principal makes a request, the authorization engine evaluates policies in this order:
SCP — If the account is in an organization, the SCP is evaluated. If the SCP denies the action, the request is denied. If the SCP allows it (or does not mention it), evaluation continues.
Permission boundary — If the principal has a permission boundary, the requested action must be allowed by the boundary. If not, the request is denied.
Resource-based policy — If the resource has a policy, it is evaluated. If it explicitly allows the principal, that counts as an allow. If it explicitly denies, the request is denied.
Identity-based policy — If the principal has an identity-based policy that allows the action, that counts as an allow.
Session policy — If the principal is using temporary credentials (e.g., via role assumption), the session policy (passed as a parameter) is also evaluated.
Default deny — If no explicit allow is found, the request is denied.
Important nuance: If there is both an identity-based policy and a resource-based policy, only one needs to allow the action (unless both are present and one denies). This means resource-based policies can grant access to users from other accounts without requiring a role assumption.
Common Exam Scenarios
Scenario 1: Cross-account S3 access - Bucket policy (resource-based) allows access from another account. - The user in the other account must also have an identity-based policy allowing S3 actions (unless the bucket policy grants access to the user explicitly).
Scenario 2: Limiting role creation - An administrator wants to allow developers to create roles but restrict the roles to only have S3 read permissions. - Solution: Attach a permission boundary to the developer's role that limits the maximum permissions to S3 read-only. The developer can then create roles with any identity-based policy, but the effective permissions are capped by the boundary.
Scenario 3: SCP for compliance
- A company needs to prevent all accounts from disabling CloudTrail or deleting logs.
- Solution: Apply an SCP that denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, and s3:DeleteBucket on the log bucket.
Best Practices
Use identity-based policies for most day-to-day permissions.
Use resource-based policies for cross-account access and for services that support them.
Use permission boundaries to delegate role creation to trusted administrators.
Use SCPs to enforce guardrails across the entire organization.
Always follow the principle of least privilege.
Verification and Troubleshooting
To verify effective permissions, you can use the IAM Policy Simulator (https://policysim.aws.amazon.com). You can also use the AWS CLI command aws iam simulate-principal-policy for identity-based policies and aws iam simulate-custom-policy for custom policies.
Example CLI command:
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:user/Alice \
--action-names s3:GetObject s3:ListBucket \
--resource-arns arn:aws:s3:::example-bucketThis simulates the effective permissions for Alice on the specified actions and resources.
Conclusion
Understanding the four IAM policy types and their evaluation order is essential for designing secure AWS architectures. The SAA-C03 exam will test your ability to choose the correct policy type for a given scenario and to predict the outcome of policy combinations.
Define the Access Scenario
Before writing any policy, determine who (principal) needs access to what (resource) and under what conditions. For example, 'User Alice in account A needs to read objects from bucket B in account B.' This step clarifies whether you need identity-based, resource-based, or both policy types. For cross-account access, resource-based policies are often simpler than role assumption.
Write the Identity-Based Policy
Create a JSON policy document with the required actions and resources. Attach it to the IAM user, group, or role that needs the permissions. Use the AWS managed policies as a starting point, but prefer customer managed policies for least privilege. Example: an S3 read-only policy for a user. The policy must include the `Version` element (always '2012-10-17') and one or more `Statement` blocks.
Write the Resource-Based Policy
If the resource supports it, create a policy and attach it to the resource. Include the `Principal` element specifying who can access it. For cross-account access, specify the external account ID or IAM user ARN. Example: an S3 bucket policy that grants read access to Alice from another account. This policy alone can grant access without needing a role in the other account.
Attach a Permission Boundary
To limit the maximum permissions an identity-based policy can grant, create a managed policy that defines the boundary. Attach it to the IAM user or role. The boundary acts as a cap: even if the identity-based policy allows more, the boundary restricts it. This is useful when delegating role creation to others.
Apply Service Control Policies
If you are using AWS Organizations, create SCPs to enforce organization-wide guardrails. Attach the SCP to the root, an OU, or individual accounts. SCPs are evaluated before any other policies. They can deny actions across all accounts (e.g., prevent disabling CloudTrail). Remember that the management account is not affected by SCPs by default.
In a large enterprise, IAM policy types are used together to enforce security. For example, a financial services company uses AWS Organizations to manage hundreds of accounts. They apply an SCP at the root level that denies iam:CreateUser and iam:DeleteAccountAlias to prevent unauthorized user creation and account changes. This SCP applies to all accounts except the management account.
For their data science team, they have a dedicated OU with an SCP that allows only S3, SageMaker, and EC2 actions. Within that OU, each data scientist gets an IAM role with a permission boundary that limits maximum permissions to S3 read-only and SageMaker notebook creation. The boundary ensures that even if a scientist's identity-based policy grants s3:*, they cannot delete buckets. This layered approach prevents accidental data loss.
Another scenario: A SaaS company uses resource-based policies extensively. Their S3 buckets have bucket policies that grant access to specific IAM roles in customer accounts. This allows customers to read their own data without needing to assume a role. The bucket policy also includes a condition that checks the aws:SourceIp to restrict access to the customer's corporate IP range.
Common misconfigurations include:
Forgetting that SCPs do not affect the management account, leading to a false sense of security.
Attaching a permission boundary to a user but not understanding that the boundary must allow all actions the user needs, including those from attached policies.
Writing a resource-based policy without specifying the Principal correctly, resulting in unintended access.
Performance considerations: Policy evaluation is fast, but having hundreds of policies with complex conditions can add latency. AWS recommends keeping policy size under 6,144 characters and limiting the number of policies per principal.
When misconfigured, the result is usually an access denied error. The most common fix is to use the IAM Policy Simulator to test the policy combination and identify which policy is blocking the request.
The SAA-C03 exam tests IAM policy types under Domain 1 (Secure Architectures) Objective 1.1: 'Design secure access to AWS resources.' Questions often require you to identify which policy type to use for a given scenario or to determine the effective permissions when multiple policies are present.
Common wrong answers: 1. Choosing 'Use a resource-based policy' when the service does not support it (e.g., EC2 instances do not support resource-based policies). 2. Thinking permission boundaries grant permissions — they only limit. 3. Confusing SCPs with IAM policies — SCPs are organization-level, not identity-level. 4. Assuming SCPs affect the root user — they do, but the management account root is exempt (unless explicitly targeted). 5. Believing that an explicit allow in an identity-based policy is enough when a permission boundary or SCP denies the action.
Specific exam values and terms:
- Maximum policy size: 6,144 characters for inline, 5,120 for managed.
- Maximum managed policies per user/role: 10.
- SCP default: FullAWSAccess is attached by default.
- Permission boundary can only be attached to users and roles, not groups.
- Resource-based policies require a Principal element.
Edge cases: - What if a resource-based policy allows access but the identity-based policy denies? The explicit deny wins. - What if a permission boundary allows an action but the identity-based policy does not? The request is denied (no explicit allow). - What if an SCP allows everything but a permission boundary denies? The request is denied.
Strategy to eliminate wrong answers: - If the question involves cross-account access without role assumption, look for resource-based policy. - If the question is about limiting the maximum permissions a role can have, think permission boundary. - If the question is about organization-wide restrictions, think SCP. - Remember that SCPs do not grant permissions; they only filter. So if the question says 'grant' or 'allow', SCP is not the answer (unless it's an allow list SCP).
There are four IAM policy types: identity-based, resource-based, permission boundaries, and SCPs.
Permission boundaries cap the maximum permissions an identity-based policy can grant; they do not grant permissions.
SCPs are organization-level filters that affect all accounts in an OU; they do not affect the management account by default.
Explicit deny always overrides any allow, regardless of policy type.
Resource-based policies can enable cross-account access without role assumption.
The evaluation order: SCP -> Permission boundary -> Resource-based -> Identity-based -> Session policy -> Default deny.
Maximum managed policies per IAM user/role: 10.
SCPs default to FullAWSAccess; removing it requires explicit allow statements.
These come up on the exam all the time. Here's how to tell them apart.
Identity-Based Policy
Attached to IAM user, group, or role.
Grants permissions to the principal (who can do what).
Cannot grant cross-account access by itself (requires role assumption or resource-based policy).
Maximum size: 6,144 chars (inline), 5,120 chars (managed).
Example: Allow user to list S3 buckets.
Resource-Based Policy
Attached to AWS resource (e.g., S3 bucket, SQS queue).
Grants access to the resource (who can access this resource).
Can grant cross-account access directly by specifying external principal.
Maximum size varies by service (S3 bucket policy: 20 KB).
Example: Bucket policy allowing specific user from another account.
Mistake
Permission boundaries grant permissions to the user or role.
Correct
Permission boundaries do not grant permissions; they only define the maximum permissions that an identity-based policy can grant. The effective permissions are the intersection of the identity-based policy and the boundary.
Mistake
SCPs are the same as IAM policies and can be attached to IAM users.
Correct
SCPs are organization-level policies that apply to all accounts in an OU or organization. They are not attached to IAM users or roles. They act as a filter over the account's effective permissions.
Mistake
Resource-based policies can only be used with S3.
Correct
Many AWS services support resource-based policies, including SQS, SNS, Lambda, KMS, Glacier, and API Gateway. S3 is the most common, but not the only one.
Mistake
The root user in the management account is affected by SCPs.
Correct
By default, SCPs do not affect the management account's root user or IAM entities. However, you can apply SCPs to the management account if you attach them to the root OU (which includes the management account).
Mistake
Identity-based policies and resource-based policies are mutually exclusive.
Correct
They can coexist. When both are present, the authorization engine evaluates both. An allow from either is sufficient (unless the other explicitly denies).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A permission boundary is attached to an IAM user or role and limits the maximum permissions that identity-based policies can grant to that principal. An SCP is attached to an AWS organization, OU, or account and limits the maximum permissions for all principals in that account. SCPs apply to all users and roles in the account, while permission boundaries apply to a specific principal. Both act as filters, but at different scopes.
Yes, if the service supports resource-based policies (e.g., S3, SQS, SNS, Lambda). The resource-based policy must specify the external user or account as the principal. The external user must also have an identity-based policy that allows the same action (unless the resource-based policy grants access to the user explicitly). This is simpler than setting up cross-account roles.
By default, SCPs do not affect the management account. However, you can apply SCPs to the management account by attaching the SCP to the root OU (which includes the management account). This is not recommended because it can lock out the management account.
The action is denied. The permission boundary acts as a cap; even if the identity-based policy allows the action, the boundary overrides it because the boundary limits what can be allowed. The effective permissions are the intersection of the identity-based policy and the boundary.
Use the IAM Policy Simulator in the AWS Management Console or the AWS CLI command `aws iam simulate-principal-policy`. You can input the principal ARN and the actions/resources to test. This simulates the evaluation of all applicable policies including SCPs, permission boundaries, and session policies.
No. Permission boundaries can only be attached to IAM users and roles, not to groups. If you need to apply a boundary to multiple users, you must attach it to each user individually or create roles with the boundary and have users assume those roles.
The default SCP is `FullAWSAccess`, which allows all actions. When you enable SCPs, this policy is automatically attached to all accounts. To restrict permissions, you must either detach this policy (which requires you to create an allow list SCP) or attach a deny list SCP that denies specific actions.
You've just covered IAM Policy Types: Identity, Resource, Permission Boundary, SCP — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?