AWS IAM Policy Evaluation: What Actually Happens When an API Call Is Denied?

A practical deep dive into how AWS evaluates IAM permissions, covering identity policies, resource policies, permissions boundaries, SCPs, explicit denies, and the tools engineers can use to troubleshoot AccessDenied errors without blindly adding permissions.

Olamide Kosile

Founder | Multi-Cloud Engineer | Building System and Engineers

Published Sep 1, 2026

Last modified Sep 1, 2026

One of the most frustrating experiences in AWS is having the permission you are certain you need and still receiving:

1
2
An error occurred (AccessDenied) when calling the GetObject operation:
Access Denied

You check the IAM policy.

The action is there.

The resource looks correct.

You have an Allow.

And yet AWS says No.

This is where many engineers start adding more permissions, attaching AdministratorAccess, or changing policies until the error disappears.

That is not troubleshooting.

That is guessing.

The real skill is understanding how AWS evaluates an authorization request.

AWS authorization is not simply a matter of finding an Allow statement. AWS evaluates a request in context, considering the principal, action, resource, applicable policies, policy conditions, session context, and organizational or resource-level controls.

This article goes beyond IAM policy syntax and examines what actually happens when an AWS principal makes an API request, why an explicit Deny takes precedence over an applicable Allow, how different policy types interact, and how to troubleshoot AccessDenied systematically without blindly adding permissions.

The Mental Model You Need

When an AWS principal makes an API request, AWS does not simply search for an Allow statement and stop.

The authorization decision depends on the request and the policies and controls that apply to it.

Depending on the principal, AWS service, resource, account structure, and authorization model, the evaluation can involve:

Identity-based policies
Resource-based policies
Permissions boundaries
Session policies
Service Control Policies (SCPs)
Resource Control Policies (RCPs), where supported
Policy conditions
Service-specific authorization requirements
Explicit denies

The exact evaluation behaviour depends on the AWS service and the type of principal making the request.

The most important rule is:

An applicable explicit Deny overrides an applicable Allow.

But there is another principle that is just as important:

The existence of an Allow statement does not automatically mean the request is authorized.

The statement must actually apply to the request.

A useful mental model is:

1
2
3
4
5
6
7
8
9
10
11
Principal
    +
Action
    +
Resource
    +
Request Context
    +
Applicable Policies and Controls
    ↓
Authorization Decision

For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Principal:
arn:aws:iam::123456789012:role/ApplicationRole

Action:
s3:GetObject

Resource:
arn:aws:s3:::finance-data/report.csv

Context:
Account
Region
Session
Source conditions
Encryption
Organization controls
Other applicable conditions

This is much more useful than saying:

"The role has S3 access."

The better question is:

For this principal, what action is being requested against which resource, and which authorization controls apply to that request?

That is the mindset required for effective IAM troubleshooting.

IAM Policy Types at a Glance

Before going deeper, it helps to distinguish policies that can grant permissions from controls that primarily limit or restrict permissions.

Policy / Control	Primary purpose	Grants permissions?	Can restrict access?
Identity-based policy	Grants permissions to a user, group, or role; can also contain explicit denies	Yes	Yes
Resource-based policy	Grants or denies access to supported resources	Yes	Yes
Permissions boundary	Defines the maximum permissions an identity can receive through identity-based policies	No	Yes
Session policy	Further limits permissions for a temporary session	No	Yes
SCP	Establishes organization-level permission guardrails	No	Yes
RCP	Establishes organization-level guardrails for supported resources	No	Yes
Explicit Deny	Explicitly prevents an applicable action	No	Yes - takes precedence over an applicable Allow

The important distinction is that not every policy or control affecting authorization grants permissions.

Some establish boundaries or restrictions.

1. Start With the Principal

Before looking at policies, determine who AWS thinks is making the request.

Run:

1
aws sts get-caller-identity

You may receive:

1
2
3
4
5
{
    "UserId": "AIDAXXXXXXXXXXXXX",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/alice"
}

Or, more commonly in modern AWS environments:

1
2
3
4
5
{
    "UserId": "AROAEXAMPLE:alice-session",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/DeveloperRole/alice-session"
}

That distinction matters.

You may think:

"I am testing as Alice."

AWS may actually be evaluating the request using an assumed-role session:

1
arn:aws:sts::123456789012:assumed-role/DeveloperRole/alice-session

The permissions associated with the role, the role session, resource policies, organizational controls, and other applicable authorization mechanisms may now become relevant.

This is why:

1
aws sts get-caller-identity

should be one of the first commands you run when troubleshooting permissions.

Do not start by editing the policy.

First establish who is actually making the request.

2. Identify the Complete Authorization Request

An authorization problem becomes much easier to reason about when you reduce it to four core elements:

1
2
3
4
5
6
7
Principal
    +
Action
    +
Resource
    +
Request Context

For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
Principal:
arn:aws:iam::123456789012:role/ApplicationRole

Action:
s3:GetObject

Resource:
arn:aws:s3:::finance-data/report.csv

Context:
Account, Region, session information,
source conditions, encryption,
organization controls, and other applicable conditions

This is much more useful than saying:

"The role has S3 access."

The role might have s3:GetObject but against the wrong resource.

It might have the correct resource but be restricted by a permissions boundary.

The account might be governed by an SCP.

The request might be subject to a condition that is not satisfied.

The object might be encrypted with AWS KMS and require additional authorization.

A resource policy might explicitly deny the request.

The application might not even be using the role you think it is using.

IAM troubleshooting starts by defining the request precisely.

3. Identity-Based Policies Are Only One Part of the Decision

Consider this policy:

1
2
3
4
5
6
7
8
9
10
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

At first glance, it looks straightforward.

An applicable statement allows:

1
s3:GetObject

against objects in:

1
my-bucket

But that does not necessarily mean every request will succeed.

Other authorization mechanisms and request conditions may affect the decision.

For example, an AWS Organization could have an applicable SCP containing:

1
2
3
4
5
6
7
8
9
10
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:GetObject",
      "Resource": "*"
    }
  ]
}

The identity-based policy contains an applicable:

1
Allow

The SCP contains an applicable:

1
Deny

The explicit deny takes precedence.

The result is:

1
DENY

The identity policy did not disappear.

It simply was not sufficient to authorize the request in the presence of the applicable restriction.

4. Explicit Deny Is the Most Important Rule

Consider these two statements:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "ec2:TerminateInstances",
  "Resource": "*"
}

and:

1
2
3
4
5
{
  "Effect": "Deny",
  "Action": "ec2:TerminateInstances",
  "Resource": "*"
}

If both statements apply to the request, the result is:

1
DENY

This is why explicit denies are powerful security controls.

For example:

1
2
3
4
5
6
7
8
9
{
  "Effect": "Deny",
  "Action": [
    "iam:DeleteRole",
    "iam:DeletePolicy",
    "iam:CreateAccessKey"
  ],
  "Resource": "*"
}

An applicable explicit deny can prevent those operations even when another applicable policy contains an Allow.

However, there is an important distinction.

A Deny statement does not automatically apply merely because it exists.

Its relevant elements must match the request.

For example, depending on the policy type, elements such as:

1
2
3
4
Action
Resource
Principal
Condition

must be evaluated in the context of the request.

Therefore:

The presence of a Deny is not enough. It must be an applicable Deny.

This distinction is critical when troubleshooting IAM.

5. Permissions Boundaries Are Not Permissions

This is one of the most common IAM misunderstandings.

Suppose a developer has this identity-based policy:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

You might conclude:

"The developer can access everything in S3."

Now imagine the identity has a permissions boundary containing:

1
2
3
4
5
6
7
8
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": "*"
}

The permissions boundary does not grant those permissions by itself.

Instead, it defines the maximum permissions that the identity can receive through its identity-based policies.

A useful simplified model is:

1
2
3
4
5
Identity-based permissions
             ∩
Permissions boundary
             ↓
Effective permissions

So, conceptually:

1
2
3
4
5
6
7
8
9
10
Identity policy:
s3:*

Boundary:
s3:GetObject
s3:ListBucket

Result through identity-based permissions:
s3:GetObject
s3:ListBucket

The boundary is therefore a maximum-permission guardrail, not a permission grant.

There is an important nuance.

Resource-based policies have their own authorization semantics. In particular, permissions granted directly to a role session through a resource-based policy are not always represented by the simple intersection model above.

Therefore:

The intersection diagram is a simplified model for permissions granted through identity-based policies. It is not a complete representation of every IAM authorization scenario.

When troubleshooting, ask:

Does this identity have a permissions boundary that limits permissions granted through its identity-based policies?

6. Session Policies Can Further Restrict Temporary Sessions

Temporary credentials introduce another authorization layer that is often overlooked.

When a principal assumes a role, the resulting role session can have a session policy.

For permissions granted through the role's identity-based policies, a useful simplified model is:

1
2
3
4
5
Role permissions
       ∩
Session policy
       ↓
Session permissions

A role may therefore have permission to perform an action while a particular session is more restricted.

This is especially relevant when applications use:

1
STS AssumeRole

or other temporary credential mechanisms that support session policies.

When troubleshooting an assumed-role request, do not stop at:

"The role has the permission."

Ask:

"What permissions apply to this particular session?"

As with permissions boundaries, resource-based policies can have additional evaluation semantics depending on how the principal is specified.

The diagram above should therefore be treated as a simplified model of permissions granted through identity-based policies, not the complete IAM authorization algorithm.

7. Service Control Policies Are Guardrails, Not Permission Grants

AWS Organizations introduces another important authorization layer.

Service Control Policies, or SCPs, establish organization-level permission guardrails for accounts and organizational units.

Suppose an IAM role has:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "ec2:*",
  "Resource": "*"
}

That does not necessarily mean the principal can perform every EC2 operation.

An applicable SCP could contain:

1
2
3
4
5
{
  "Effect": "Deny",
  "Action": "ec2:TerminateInstances",
  "Resource": "*"
}

That explicit deny can prevent the operation.

But there is an equally important point:

SCPs do not grant permissions.

An SCP establishes an organization-level boundary within which the account's IAM permissions operate.

A principal still needs applicable permissions that authorize the requested action.

Therefore, when an IAM role appears to have the correct permission but AWS returns AccessDenied, check whether the account is governed by AWS Organizations and whether applicable SCPs restrict the operation.

8. Resource Control Policies Add Another Organizational Layer

AWS Organizations also provides Resource Control Policies, or RCPs, for supported AWS resources and services.

RCPs establish organization-level controls over access to supported resources and do not grant permissions by themselves.

Like SCPs, they are guardrails rather than permission grants.

Therefore, in an environment using AWS Organizations, the authorization investigation may need to consider:

1
2
3
4
5
6
7
8
Identity-based policy
Resource-based policy
Permissions boundary
Session policy
SCP
RCP
Conditions
Explicit Deny

The exact controls that apply depend on the AWS service, resource, principal, and authorization model.

9. Resource-Based Policies Change the Picture

Some AWS resources support resource-based policies.

Amazon S3 is one of the most familiar examples.

An S3 bucket policy can contain:

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ApplicationRole"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Now authorization is being controlled from the resource side as well as potentially the identity side.

This becomes particularly important with cross-account access.

Imagine:

1
2
3
4
5
6
7
Account A
ApplicationRole
      |
      | s3:GetObject
      ↓
Account B
S3 Bucket

The cross-account authorization model must be configured correctly for the principal and resource.

For S3, this can involve the identity-based permissions of the calling principal and the bucket's resource-based policy, along with any applicable organizational restrictions and conditions.

The exact evaluation behaviour depends on the principal type and how the resource policy grants access.

This is why cross-account authorization problems often confuse engineers who inspect only the IAM role.

They are looking at only one side of the authorization relationship.

10. The Cross-Account Trap

Suppose Account A contains:

1
arn:aws:iam::111111111111:role/AppRole

and Account B owns:

1
arn:aws:s3:::production-data

The role might have:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::production-data/*"
}

Yet the request can still fail.

Why?

Because the resource is owned by another AWS account, so the appropriate cross-account authorization configuration must exist.

For an S3 bucket, the bucket policy may need to grant access to the intended principal.

A useful troubleshooting sequence is:

Who owns the resource?

Then:

Is this a same-account or cross-account request?

Then:

What resource-based policy applies?

Do not assume that the account making the API call owns the resource being accessed.

11. The Resource ARN Must Match

Another deceptively simple problem is the difference between:

1
arn:aws:s3:::my-bucket

and:

1
arn:aws:s3:::my-bucket/*

They represent different resource scopes.

For example:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket"
}

does not identify the object resource required for:

1
s3://my-bucket/file.txt

The object ARN is:

1
arn:aws:s3:::my-bucket/file.txt

Therefore, a policy can contain the correct action and still fail because the resource does not match.

When troubleshooting, verify:

1
2
3
4
Action
Resource ARN
Account
Region

Do not assume that a visually similar ARN represents the same resource type.

12. Actions and Resources Are Not Always One-to-One

AWS IAM actions can operate against different resource types.

For S3, for example:

1
s3:ListBucket

operates at the bucket level, while:

1
s3:GetObject

operates at the object level.

Therefore, a policy such as:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

does not automatically grant:

1
s3:ListBucket

The application may successfully retrieve:

1
s3://my-bucket/report.csv

but fail when attempting to list the bucket.

This produces another common troubleshooting mistake:

"The role has S3 access."

That statement is too vague.

The useful question is:

Which principal is calling which API action against which resource?

That is the level of precision required for IAM troubleshooting.

13. Conditions Can Change the Authorization Decision

An Allow statement may exist and still not apply because its conditions are not satisfied.

For example:

1
2
3
4
5
6
7
8
9
10
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalTag/Environment": "production"
    }
  }
}

The permission exists.

But it only applies when the relevant condition evaluates successfully.

Other conditions can restrict requests based on factors such as:

1
2
3
4
5
6
aws:SourceIp
aws:PrincipalArn
aws:PrincipalTag
aws:RequestedRegion
aws:SecureTransport
aws:MultiFactorAuthPresent

This is another reason why simply searching for:

1
"Effect": "Allow"

is insufficient.

You must determine whether the statement actually applies to the request.

14. Some AWS Operations Depend on Additional Permissions

One application operation can involve authorization to more than one AWS resource or service.

A classic example is Amazon S3 with SSE-KMS encryption.

Suppose an application has:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::finance-data/*"
}

For an SSE-KMS encrypted object, successful retrieval may also require the requesting principal to be authorized to use the relevant KMS key for decryption.

That can include:

1
kms:Decrypt

KMS authorization can involve IAM permissions, the KMS key policy, grants, and applicable conditions.

The operation can therefore involve:

1
2
3
4
5
6
7
8
9
10
11
12
13
Application
    |
    | s3:GetObject
    ↓
Amazon S3
    |
    | required decryption
    ↓
AWS KMS
    |
    | kms:Decrypt
    ↓
KMS Key

This is why service-specific dependencies matter when troubleshooting AccessDenied.

If S3 access appears correct, ask:

Is another AWS service involved in completing the operation?

Common examples include:

1
2
3
4
5
6
S3 + KMS
EC2 + KMS
Lambda + KMS
ECS + Secrets Manager
Lambda + Secrets Manager
SNS/SQS + KMS

The exact permissions depend on the architecture and service configuration.

15. `iam:PassRole` Is Another Common Hidden Dependency

Consider an engineer creating a Lambda function with an execution role.

The engineer may have permission to call the Lambda API but still receive AccessDenied because they lack:

1
iam:PassRole

For example:

1
2
3
4
5
6
7
8
9
10
Developer
    |
    | Create Lambda
    |
    +---- lambda:CreateFunction
    |
    +---- iam:PassRole
                |
                ↓
          Execution Role

iam:PassRole controls whether the caller can pass a particular IAM role to an AWS service.

Having permission to create a Lambda function does not automatically mean the principal can pass any IAM role to Lambda.

This is another example of why troubleshooting must focus on the complete operation, not just the most obvious API action.

16. Use IAM Policy Simulation Instead of Guessing

AWS provides the IAM Policy Simulator for analysing how applicable IAM policies affect a principal's requested actions against specified resources.

For example:

1
2
3
4
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/DeveloperRole \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/example.txt

You can also test multiple actions:

1
2
3
4
5
6
7
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/DeveloperRole \
  --action-names \
    s3:GetObject \
    s3:PutObject \
    s3:DeleteObject \
  --resource-arns arn:aws:s3:::my-bucket/example.txt

The simulator is useful for evaluating how applicable IAM policies affect a particular principal, action, and resource.

However, it does not reproduce every component of a live AWS authorization decision.

Real-world requests can involve resource-based policies, AWS Organizations controls, session context, service-specific requirements, conditions, and other factors that also need to be investigated.

Therefore, use the simulator as one diagnostic signal, not as proof that the live request must succeed.

The goal is to move from:

"Why doesn't this work?"

to:

"Which authorization condition is causing this request to be denied?"

That is a much better engineering question.

17. CloudTrail Provides Evidence of What Happened

Policy analysis helps you understand how the applicable authorization policies affect the request.

CloudTrail can provide evidence of what actually happened.

You can investigate details such as:

1
2
3
4
5
6
Which principal made the request
Which API operation was called
When the request occurred
Which resources were involved
The request source
Whether AWS recorded an error

But there is an important distinction when troubleshooting Amazon S3.

S3 object-level operations such as:

1
2
3
GetObject
PutObject
DeleteObject

are data events.

They are different from CloudTrail management events and require appropriate CloudTrail data-event logging if you want those object-level API calls captured.

Once data events are being logged, they can be investigated using the configured CloudTrail capabilities, including CloudTrail Lake where appropriate.

This distinction matters.

An engineer may search CloudTrail for:

1
GetObject

and find nothing, then incorrectly conclude that the request never happened.

The issue may simply be that S3 data-event logging was not configured.

Therefore:

Inspect available CloudTrail evidence where the relevant event type is being logged.

18. IAM Access Analyzer Can Help Too

IAM Access Analyzer is another valuable tool when investigating permissions.

It can help with areas such as:

1
2
3
4
5
Unintended external access
Resource policies granting access
Cross-account access
Policy validation
Unused permissions

For example, if an S3 bucket policy unexpectedly grants access to another AWS account, Access Analyzer can help identify that external access relationship.

For IAM troubleshooting, combining:

1
2
3
4
5
6
7
IAM Policy Simulator
+
IAM Access Analyzer
+
CloudTrail
+
Service-specific diagnostics

can provide significantly stronger evidence than repeatedly modifying policies and testing again.

19. `AdministratorAccess` Is Not a Troubleshooting Strategy

One of the worst approaches to an IAM problem is:

"Give it AdministratorAccess and see if it works."

If the problem disappears, you have learned very little.

You have only demonstrated that the principal now has broader permissions.

The original problem could still have been:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Incorrect resource ARN
Explicit Deny
SCP
RCP
Permissions boundary
Session policy
Resource policy
Missing action
Wrong principal
Cross-account configuration
KMS authorization
iam:PassRole
Condition mismatch
Service-specific dependency

Worse, you may have introduced a security vulnerability while hiding the original problem.

A better approach is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Identify principal
        ↓
Identify API action
        ↓
Identify resource, account and Region
        ↓
Check identity-based policies
        ↓
Check resource-based policies
        ↓
Check permissions boundary
        ↓
Check session policy/context
        ↓
Check SCP/RCP where applicable
        ↓
Check conditions and explicit denies
        ↓
Check service-specific dependencies
        ↓
Inspect CloudTrail evidence
        ↓
Use IAM Policy Simulator / Access Analyzer
        ↓
Fix the smallest required permission

That is least privilege in practice.

A Real Troubleshooting Scenario

Imagine an application running on Amazon EC2 attempts:

1
aws s3 cp s3://finance-data/report.csv .

The application receives:

1
AccessDenied

The developer checks the instance role and finds:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::finance-data/*"
}

Looks correct.

Instead of adding more permissions, start with:

1
aws sts get-caller-identity

If you're troubleshooting from the application environment, run the command using the same credentials and environment that the application uses, where practical.

Confirm the actual principal.

Then verify the exact object:

1
s3://finance-data/report.csv

Check:

1
2
3
Bucket account
Object ARN
Region

Then investigate the bucket policy.

If the bucket is in another account, verify the cross-account authorization configuration.

Then check whether the principal has a permissions boundary or session restrictions.

Then determine whether AWS Organizations controls such as SCPs or RCPs apply.

If the object is encrypted with SSE-KMS, investigate:

1
2
3
4
kms:Decrypt
KMS key policy
IAM permissions
KMS conditions

Then inspect available CloudTrail evidence, remembering that S3 object-level events require appropriate data-event logging.

Finally, use IAM Policy Simulator or Access Analyzer where appropriate.

Notice what happened.

We did not add permissions.

We collected evidence.

That is the difference between troubleshooting and guessing.

The IAM Debugging Checklist I Use

When I encounter AccessDenied, I reduce the problem to five questions.

Who?

Which IAM principal actually made the request?

1
aws sts get-caller-identity

What?

Which AWS API action failed?

1
2
3
4
s3:GetObject
ec2:DescribeInstances
iam:PassRole
kms:Decrypt

Where?

Which resource was targeted?

1
2
3
4
ARN
Account
Region
Resource ID

Why?

Which authorization mechanisms could affect the request?

1
2
3
4
5
6
7
8
Identity policy
Resource policy
Permissions boundary
Session policy
SCP/RCP
Conditions
Explicit Deny
Service-specific authorization

What evidence do I have?

Use AWS tooling and logs:

1
2
3
4
5
CloudTrail
IAM Policy Simulator
IAM Access Analyzer
Service-specific diagnostics
Application logs

If you can answer those five questions, most IAM authorization problems become considerably easier to reason about.

The Bigger Lesson

IAM is not simply a collection of JSON documents containing Allow statements.

It is an authorization system.

The important distinction is that AWS evaluates an authorization request, not simply a policy document.

That request has context:

1
2
3
4
5
6
7
8
9
Principal
Action
Resource
Account
Region
Session
Conditions
Applicable policies
Service-specific requirements

The authorization decision emerges from how those applicable controls interact.

That is why an IAM policy can look completely correct and the request can still fail.

The difference between a junior engineer and an experienced cloud engineer is often not knowing more IAM actions.

It is being able to reason about why a particular request was allowed or denied.

When you understand the evaluation model, an error such as:

1
AccessDenied

stops being mysterious.

It becomes a question of evidence.

Who made the request?

What did they try to do?

What resource did they target?

Which policy mechanisms applied?

Was there an applicable explicit deny?

Were there conditions that prevented an Allow from applying?

Did another AWS service introduce an additional authorization requirement?

Once you start thinking this way, IAM troubleshooting becomes less about adding permissions and more about understanding the system.

And that is ultimately what good cloud engineering is about:

Don't give the system more permission until you understand why it failed.

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

AWS IAM Policy Evaluation: What Actually Happens When an API Call Is Denied?

Olamide Kosile

The Mental Model You Need

IAM Policy Types at a Glance

1. Start With the Principal

2. Identify the Complete Authorization Request

3. Identity-Based Policies Are Only One Part of the Decision

4. Explicit Deny Is the Most Important Rule

5. Permissions Boundaries Are Not Permissions

6. Session Policies Can Further Restrict Temporary Sessions

7. Service Control Policies Are Guardrails, Not Permission Grants

8. Resource Control Policies Add Another Organizational Layer

9. Resource-Based Policies Change the Picture

10. The Cross-Account Trap

11. The Resource ARN Must Match

12. Actions and Resources Are Not Always One-to-One

13. Conditions Can Change the Authorization Decision

14. Some AWS Operations Depend on Additional Permissions

15. iam:PassRole Is Another Common Hidden Dependency

16. Use IAM Policy Simulation Instead of Guessing

17. CloudTrail Provides Evidence of What Happened

18. IAM Access Analyzer Can Help Too

19. AdministratorAccess Is Not a Troubleshooting Strategy

A Real Troubleshooting Scenario

The IAM Debugging Checklist I Use

Who?

What?

Where?

Why?

What evidence do I have?

The Bigger Lesson

15. `iam:PassRole` Is Another Common Hidden Dependency

19. `AdministratorAccess` Is Not a Troubleshooting Strategy