AWS IAM Policy Evaluation Logic | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

IAM policy evaluation is one of the most important AWS security topics for the AWS Certified Solutions Architect – Professional SAP-C02 exam. Many exam questions describe a user, role, AWS Organizations SCP, permissions boundary, session policy, or resource-based policy and ask why access is allowed or denied.

The key idea is simple but extremely important:

AWS starts with deny by default, then looks for an applicable allow, unless an explicit deny exists anywhere. Some policies grant permissions, while others only set maximum permission limits.

Understanding how AWS combines these policy types is critical for designing secure multi-account environments, troubleshooting access issues, and answering scenario-based exam questions.

Key Concepts

IAM Policy Evaluation Starts with Deny by Default

AWS does not allow access unless a policy allows it.

By default, every request is treated as an implicit deny. This means that if no policy grants the requested action on the requested resource, the request is denied.

For example, if an IAM user tries to run:

s3:GetObject

against an S3 object, AWS checks whether any applicable policy allows that action against that resource. If no allow exists, the result is an implicit deny.

This default-deny model is foundational to AWS security.

Explicit Deny Always Wins

An explicit deny overrides every allow.

If any applicable policy contains an explicit deny for the requested action, AWS denies the request immediately. It does not matter if another policy allows the same action.

Explicit denies can appear in:

Identity-based policies
Resource-based policies
Permissions boundaries
Service control policies
Session policies

Example:

An IAM user has an identity-based policy allowing s3:GetObject, but the S3 bucket policy explicitly denies access unless the request comes from a specific IP range. If the request comes from outside that IP range, access is denied.

The explicit deny wins.

Request Authorization Process

When a principal makes a request to AWS, the request usually comes from one of these access methods:

AWS Management Console
AWS CLI
AWS SDK
Direct API call

AWS then goes through a policy evaluation process.

Step 1: Authentication

AWS first authenticates the principal making the request.

The principal could be:

IAM user
IAM role
Federated user
AWS service principal
Application using temporary credentials

Examples:

Access Method	Authentication Example
AWS Console	Username, password, and optional MFA
AWS CLI	Access key and secret access key
IAM Role	Temporary credentials from AWS STS
Federated Access	Identity provider-authenticated session

Authentication answers this question:

Who is making the request?

Step 2: AWS Builds the Request Context

After authentication, AWS builds a request context. This is the set of details AWS uses to evaluate the request against applicable policies.

The request context includes:

Request Context Element	Description
Principal	The user, role, federated user, or application making the request
Action	The AWS API action being requested, such as `s3:GetObject`
Resource	The AWS resource being accessed
Environment data	Source IP, user agent, MFA status, SSL usage, request time, and similar metadata
Resource data	Information related to the target resource

This is why IAM policies can use conditions such as:

Source IP address
Whether MFA was used
Whether the request used TLS
AWS region
Principal tags
Resource tags
Time of day

For example, a policy could allow access only when the request comes from a corporate public IP range.

Step 3: AWS Evaluates Applicable Policies

AWS evaluates all applicable policies to determine whether the request should be allowed or denied.

These can include:

Identity-based policies
Resource-based policies
Permissions boundaries
AWS Organizations service control policies
Session policies

AWS is not simply looking at one policy. It evaluates the combined effect of every policy type that applies to the request.

Step 4: AWS Returns Allow or Deny

The final decision is either:

Allow

or:

Deny

There is no partial authorization. The request is either authorized or rejected.

Major IAM Policy Types

Identity-Based Policies

Identity-based policies are attached to IAM identities.

They can be attached to:

IAM users
IAM groups
IAM roles

These policies define what the identity is allowed or denied to do.

Example:

An IAM role might have an identity-based policy allowing:

ec2:DescribeInstances
s3:GetObject
cloudwatch:GetMetricData

Identity-based policies are one of the most common ways to grant permissions in AWS.

Resource-Based Policies

Resource-based policies are attached directly to AWS resources.

Common examples include:

S3 bucket policies
KMS key policies
SQS queue policies
SNS topic policies
Lambda function resource policies
Secrets Manager resource policies

Resource-based policies define which principals can access the resource and what actions they can perform.

Example:

An S3 bucket policy can allow a role from another AWS account to read objects from the bucket.

Resource-based policies are especially important for cross-account access.

Permissions Boundaries

A permissions boundary sets the maximum permissions that an IAM user or role can receive from identity-based policies.

A permissions boundary does not grant permissions by itself.

It only limits what an identity-based policy can grant.

Effective permissions require both:

The identity-based policy allows the action.
The permissions boundary allows the action.

If the identity policy allows iam:CreateUser, but the permissions boundary does not allow IAM actions, then the user cannot create IAM users.

Think of a permissions boundary as a guardrail around an IAM identity.

Service Control Policies

Service control policies, or SCPs, are used with AWS Organizations.

They define the maximum permissions available to:

AWS accounts
Organizational units
The organization root

An SCP does not grant permissions. It only limits the permissions that can be used within an account.

For an action to be allowed in a member account:

The SCP hierarchy must allow the action.
The IAM policy must allow the action.
No explicit deny can apply.

SCPs are commonly used for governance in multi-account AWS environments.

Examples:

Deny access to specific AWS regions
Prevent disabling CloudTrail
Prevent leaving AWS Organizations
Deny deletion of security logging resources
Restrict access to high-risk services

Session Policies

Session policies are used when temporary credentials are issued through AWS STS.

They are commonly used with:

AssumeRole
AssumeRoleWithSAML
AssumeRoleWithWebIdentity
Federated access
Temporary role sessions

A session policy limits what the temporary session can do.

Like permissions boundaries and SCPs, a session policy does not grant permissions on its own. It further restricts the permissions available to the assumed role session.

How AWS Combines Policy Types

Identity-Based Policy + Resource-Based Policy

When both an identity-based policy and a resource-based policy apply, the effective permissions are generally based on the union of allowed permissions, unless an explicit deny exists.

This means an allow in either policy can grant access, depending on the account and resource policy scenario.

Example:

An IAM user may be allowed to read from an S3 bucket because:

The user’s identity policy allows s3:GetObject, or
The bucket policy allows that user to call s3:GetObject

However, for cross-account access, AWS often requires permissions on both sides:

The principal’s account must allow the principal to make the request.
The resource-owning account must allow access through the resource-based policy.

For the exam, remember that resource-based policies are often the correct answer for granting cross-account access to a specific AWS resource.

Identity-Based Policy + Permissions Boundary

When a permissions boundary is applied, the effective permissions are the intersection of:

What the identity-based policy allows
What the permissions boundary allows

If either side does not allow the action, the action is denied.

Identity-Based Policy	Permissions Boundary	Result
Allows `s3:GetObject`	Allows `s3:GetObject`	Allowed
Allows `s3:GetObject`	Does not allow `s3:GetObject`	Denied
Does not allow `s3:GetObject`	Allows `s3:GetObject`	Denied

The permissions boundary is a maximum permission limit, not a permission grant.

Identity-Based Policy + SCP

When an SCP applies, the effective permissions are the intersection of:

What IAM allows
What the SCP allows

The IAM policy must allow the action, and the SCP must not block it.

IAM Policy	SCP	Result
Allows `ec2:StartInstances`	Allows `ec2:StartInstances`	Allowed
Allows `ec2:StartInstances`	Does not allow `ec2:StartInstances`	Denied
Does not allow `ec2:StartInstances`	Allows `ec2:StartInstances`	Denied

SCPs are organization-level guardrails.

Identity-Based Policy + Session Policy

When a role session has a session policy, the effective permissions are the intersection of:

The role’s permissions
The session policy permissions

The session cannot exceed the role’s permissions, and the session policy can reduce what the role session can do.

This is useful when you want to issue temporary credentials with a reduced permission set.

Policy Evaluation Summary

AWS policy evaluation can be summarized like this:

Start with implicit deny.
Authenticate the principal.
Build the request context.
Check all applicable policies.
If an explicit deny exists, deny the request.
If no allow exists, deny the request.
If an allow exists, check limiting policies such as SCPs, permissions boundaries, and session policies.
If all required policy layers allow the action, allow the request.

Exam-Relevant Takeaways

For the SAP-C02 exam, focus on how different policy types interact.

The most important rule is:

Explicit deny always wins.

The second most important rule is:

SCPs, permissions boundaries, and session policies do not grant permissions. They only limit permissions.

You should also remember:

AWS denies all requests by default.
An explicit allow is required unless the root user is involved.
The root user has full permissions in the account by default, but root in a member account can still be restricted by SCPs.
SCPs do not affect users or roles in the AWS Organizations management account.
Identity-based policies attach to users, groups, and roles.
Resource-based policies attach to resources.
Permissions boundaries set the maximum permissions for IAM identities.
SCPs set the maximum permissions for AWS accounts and OUs.
Session policies restrict temporary credentials issued through AWS STS.
Resource-based policies are commonly used for cross-account access.
Permissions boundaries are commonly used when delegating IAM administration.
SCPs are commonly used for centralized governance in multi-account AWS environments.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Allow an IAM role to read objects from an S3 bucket in the same account	Identity-based policy or S3 bucket policy	Either can grant access, as long as no explicit deny or limiting policy blocks it
Grant another AWS account access to an S3 bucket	S3 bucket policy	Resource-based policies are commonly used for cross-account access
Prevent all accounts in an OU from using a specific AWS region	SCP	SCPs provide organization-level guardrails across accounts
Allow developers to create IAM roles but prevent privilege escalation	Permissions boundary	Boundaries cap the maximum permissions developers can assign
Temporarily reduce permissions when a role is assumed	Session policy	Session policies restrict temporary AWS STS credentials
Troubleshoot why a user with an allow policy is still denied	Check explicit denies, SCPs, permissions boundaries, and session policies	An allow in IAM may be overridden by other policy types
Enforce that users must use MFA before performing sensitive actions	IAM policy condition	Request context includes MFA-related condition data
Restrict access based on corporate network IP range	IAM or resource policy condition	Request context includes source IP information
Centrally prevent disabling CloudTrail in all production accounts	SCP with explicit deny	Explicit deny in an SCP blocks the action even if IAM allows it
Grant permissions directly to an application running on EC2	IAM role attached to EC2 instance profile	Avoid long-term access keys and use temporary credentials

Common Exam Traps

Trap 1: Thinking an SCP Grants Permissions

An SCP does not grant access.

Even if an SCP allows s3:*, the IAM user or role still needs an identity-based policy or applicable resource-based policy that allows the action.

SCPs define the maximum available permissions. They are guardrails, not grants.

Trap 2: Thinking a Permissions Boundary Grants Permissions

A permissions boundary does not grant permissions.

If the boundary allows ec2:*, but the identity-based policy does not allow EC2 actions, the principal still cannot use EC2.

Both the identity policy and the boundary must allow the action.

Trap 3: Ignoring Explicit Deny

If a scenario includes an explicit deny, that is usually the key detail.

An explicit deny overrides:

Identity-based allows
Resource-based allows
SCP allows
Permissions boundary allows
Session policy allows

Trap 4: Confusing Implicit Deny with Explicit Deny

An implicit deny means no policy allows the action.

An explicit deny means a policy specifically denies the action.

This distinction matters because explicit deny overrides all allows, while implicit deny can be overcome by adding an allow policy.

Trap 5: Forgetting About Request Context

AWS evaluates more than just the action and resource.

Condition keys can evaluate:

Source IP
MFA status
Principal tags
Resource tags
AWS region
TLS usage
Current time
User agent

A policy might allow an action only when the request meets specific conditions.

Trap 6: Assuming Resource-Based Policies Work Exactly Like Identity Policies

Resource-based policies are attached to resources and name the principals that can access them.

They are often used for cross-account access, but the exact evaluation depends on the service, principal type, and whether access is same-account or cross-account.

For exam purposes, know that resource-based policies are resource-side permissions and are commonly required for cross-account resource access.

Trap 7: Forgetting Session Policies During AssumeRole Scenarios

When a role is assumed with a session policy, the session policy can reduce the role’s permissions.

If the role normally allows s3:*, but the session policy only allows s3:GetObject, the temporary session is limited to s3:GetObject.

Real-World Engineer Notes

In real AWS environments, IAM policy evaluation becomes especially important during troubleshooting.

A user may say, “I have the policy attached, but I still get AccessDenied.” In that case, you need to check more than the IAM policy. You should review:

Identity-based policy attached to the user, group, or role
Resource-based policy on the target resource
SCPs inherited from the AWS Organizations root and OU structure
Permissions boundary on the IAM principal
Session policy applied during role assumption
Policy conditions such as source IP, MFA, tags, region, and TLS
Explicit denies in any applicable policy

In multi-account environments, SCPs are a common source of confusion. A team may have administrator access inside an account but still be unable to perform certain actions because an SCP blocks the action at the OU level.

Permissions boundaries are also important when delegating IAM administration. For example, you might allow a development team to create roles for their applications, but require that every role they create has a permissions boundary. This prevents them from creating a role with full administrator access.

Session policies matter heavily in federated environments. If users authenticate through SAML, OIDC, IAM Identity Center, or a custom broker, their temporary session may be more restricted than the base role.

For operations, AWS CloudTrail is usually the first place to look when troubleshooting denied API calls. CloudTrail can show the API action, principal, resource, source IP, and sometimes the authorization failure context. IAM Access Analyzer and the IAM Policy Simulator can also help validate effective permissions before making changes.

Quick Reference Summary

AWS IAM policy evaluation follows a deny-first model.

Key rules:

All requests are implicitly denied by default.
An explicit allow is required to grant access.
An explicit deny always overrides an allow.
Identity-based policies attach to users, groups, and roles.
Resource-based policies attach to resources.
Permissions boundaries limit the maximum permissions of IAM identities.
SCPs limit the maximum permissions available in AWS Organizations accounts and OUs.
Session policies limit temporary credentials from AWS STS.
SCPs, permissions boundaries, and session policies do not grant access by themselves.
Effective permissions are based on the combined result of all applicable policies.
For troubleshooting, always check for explicit denies and limiting policies.

Flashcards

Q: What is the default authorization decision in AWS IAM?
A: Deny. All requests are implicitly denied unless an applicable policy allows the action.

Q: What happens if one policy allows an action but another policy explicitly denies it?
A: The request is denied. Explicit deny always overrides allow.

Q: What is the purpose of an identity-based policy?
A: It grants or denies permissions to IAM users, groups, or roles.

Q: What is a resource-based policy?
A: A policy attached directly to a resource that specifies which principals can access that resource and what actions they can perform.

Q: Does a permissions boundary grant permissions?
A: No. It only sets the maximum permissions an IAM identity can receive from identity-based policies.

Q: Does an SCP grant permissions to users or roles?
A: No. An SCP only defines the maximum permissions available in an AWS account or OU.

Q: What two things are required when an identity-based policy and permissions boundary apply?
A: The identity-based policy must allow the action, and the permissions boundary must also allow it.

Q: What two things are required when IAM permissions and an SCP both apply?
A: IAM must allow the action, and the SCP must allow the action or at least not block it, depending on the SCP strategy.

Q: What is a session policy used for?
A: It limits the permissions of temporary credentials created through AWS STS role assumption.

Q: What is included in the AWS request context?
A: The principal, requested action, target resource, environment data such as IP address and MFA status, and resource-related data.

Q: Why might a user with an allow policy still receive AccessDenied?
A: An explicit deny, SCP, permissions boundary, session policy, resource policy condition, or missing required resource-side permission may be blocking access.

Q: What policy type is commonly used to grant cross-account access to an S3 bucket?
A: An S3 bucket policy, which is a resource-based policy.

Q: What is the difference between implicit deny and explicit deny?
A: Implicit deny means no policy allows the action. Explicit deny means a policy specifically denies the action and overrides any allows.

Q: Which policy type is best for preventing all accounts in an OU from disabling CloudTrail?
A: An SCP with an explicit deny.

Q: Which policy type is best for delegating IAM role creation while preventing privilege escalation?
A: A permissions boundary.

Practice Questions

Question 1:
A developer has an IAM policy that allows s3:DeleteObject on a production S3 bucket. The bucket policy explicitly denies s3:DeleteObject for all principals except a specific break-glass role. The developer tries to delete an object and receives AccessDenied. Why?

A. The IAM policy does not apply to S3 bucket objects
B. The bucket policy explicit deny overrides the IAM allow
C. The developer needs an SCP allowing s3:DeleteObject
D. The developer must use temporary credentials from AWS STS

Correct Answer:
B. The bucket policy explicit deny overrides the IAM allow

Explanation:
An explicit deny in any applicable policy overrides an allow. Even though the identity-based policy allows the action, the resource-based bucket policy explicitly denies it.

Question 2:
An IAM role has an identity-based policy allowing full EC2 access. The role also has a permissions boundary that only allows S3 and CloudWatch actions. What happens when the role tries to start an EC2 instance?

A. The request is allowed because the identity-based policy allows EC2
B. The request is denied because the permissions boundary does not allow EC2
C. The request is allowed because permissions boundaries only apply to users
D. The request is denied only if there is an explicit deny in the EC2 policy

Correct Answer:
B. The request is denied because the permissions boundary does not allow EC2

Explanation:
Permissions boundaries define the maximum permissions available to an IAM identity. The identity policy and permissions boundary must both allow the action.

Question 3:
A user in an AWS Organizations member account has an IAM policy allowing cloudtrail:StopLogging. An SCP attached to the account’s OU explicitly denies cloudtrail:StopLogging. What is the result?

A. The request is allowed because IAM policies override SCPs
B. The request is allowed if the user has administrator access
C. The request is denied because the SCP explicit deny overrides the IAM allow
D. The request is denied only if the root account also has the SCP attached

Correct Answer:
C. The request is denied because the SCP explicit deny overrides the IAM allow

Explanation:
SCPs define maximum permissions for member accounts. An explicit deny in an SCP overrides allows in IAM policies.

Question 4:
A company uses AWS STS AssumeRole to issue temporary credentials. The role allows read and write access to an S3 bucket, but the session policy only allows s3:GetObject. What can the temporary session do?

A. Read and write objects because the role allows both
B. Only read objects because the session policy restricts the session
C. Nothing because session policies do not work with S3
D. Full S3 access because temporary credentials bypass IAM evaluation

Correct Answer:
B. Only read objects because the session policy restricts the session

Explanation:
Session policies limit the permissions of temporary credentials. The effective permissions are the intersection of the role permissions and the session policy.

Question 5:
A solutions architect is troubleshooting an AccessDenied error. The IAM role has an allow policy for the requested action. Which policy types should the architect check next?

A. Only the AWS managed policies attached to the role
B. SCPs, permissions boundaries, session policies, resource-based policies, and explicit denies
C. Only the user’s console password policy
D. Only the VPC route table and security group configuration

Correct Answer:
B. SCPs, permissions boundaries, session policies, resource-based policies, and explicit denies

Explanation:
IAM authorization can be affected by multiple policy types. An allow in an identity-based policy does not guarantee access if another policy limits or explicitly denies the request.