IAM Policy Evaluation Logic

AWS 021

IAM authorization is rarely just 'there is an Allow, so it works.' AWS evaluates the request context and all applicable policy types. Understanding that decision process is the difference between guessing and troubleshooting.

What You Will Learn

• Understand the core concept and why it matters in real AWS environments.
• Learn the main AWS objects, controls and architecture patterns involved.
• See practical examples and common failure scenarios.
• Understand security, operational trade-offs and troubleshooting.
• Build a clear next step toward the following AWS topics.

Why This Topic Matters

AccessDenied errors are one of the most common AWS troubleshooting experiences. The painful part is that the policy you are looking at may be correct and the request can still fail because another policy or condition blocks it. Learning the evaluation model gives you a repeatable method instead of trial and error.

1. The Request AWS Evaluates

A request contains more than an action name. AWS evaluates context such as the principal, requested action, target resource and applicable environment or request attributes. Conditions in policies can inspect parts of that context.

For example, s3:GetObject against one bucket from one role is a different authorization question from s3:PutObject against another bucket from a different role.

2. The Implicit Deny

The default starting point is deny. An action needs an applicable allow for it to succeed. This means a policy does not need to explicitly deny every action you do not want to grant; permissions that are not allowed remain unavailable.

This default-deny model is a core security principle.

3. Explicit Deny Wins

An explicit Deny in an applicable policy overrides an Allow. This is why adding another allow policy may not fix an AccessDenied error.

For troubleshooting, search for denies across all relevant policy types rather than looking only for missing allows.

4. Identity-Based Policies

Identity-based policies are attached to users, groups or roles and describe actions an identity may perform. They are commonly used for workload roles and workforce permissions.

An identity policy can be very broad or very narrow. The engineering goal is to match it to the real responsibility of the identity.

5. Resource-Based Policies

Some AWS resources support resource-based policies. These policies are attached to the resource and can specify who may access it. S3 bucket policies and KMS key policies are important examples.

This creates a common troubleshooting trap: the identity policy may look correct while the resource policy contains a condition or principal restriction that changes the result.

6. Permissions Boundaries

A permissions boundary defines the maximum permissions that an identity-based policy can grant to a user or role. It does not itself grant permissions.

Think of it as a ceiling. If the identity policy asks for more than the boundary permits, the effective permissions are restricted. This is useful when delegating permission-management responsibilities safely.

7. Session Policies

Temporary sessions can also be affected by session policies. These provide another way to limit permissions during a session.

This matters in role-assumption and federation workflows because the policy attached to the role may not represent the full effective permission set of the current session.

8. Organizations SCPs and RCPs

In AWS Organizations, service control policies can act as permission guardrails for principals in member accounts. Resource control policies can provide guardrails for supported resources. These controls do not replace identity or resource policies as permission grants.

A useful mental model is that the final permission must survive every applicable boundary.

9. Conditions and Request Context

Conditions can restrict a policy based on request context such as source IP, MFA state, tags, principal attributes or other supported keys. A condition that evaluates false means that policy statement does not provide its intended allow.

Condition-heavy policies should be documented because the failure may not be obvious from the Action and Resource fields.

10. A Worked Troubleshooting Example

Suppose a Lambda role has s3:GetObject permission, but the function receives AccessDenied. First verify the function is using the expected role. Next verify the exact object ARN matches the policy resource. Then inspect the bucket policy, KMS permissions if the object uses customer-managed encryption, permissions boundaries, session constraints and organization controls.

This sequence is faster and safer than attaching s3:* to the role.

11. Cross-Account Access

Cross-account authorization adds another layer. The principal and the target resource belong to different accounts, so the resource owner and the principal's account both matter. Role assumption is a common pattern because the target account can define a trust relationship and then grant the assumed role appropriate permissions.

12. Policy Evaluation Diagram in Words

A practical way to reason about a request is: identify principal → identify action → identify resource → collect applicable policies → check explicit denies → verify required allows and boundaries → inspect conditions → evaluate organization controls → determine final decision.

This is not a replacement for the official evaluation documentation, but it is a useful operational checklist.

13. Common Mistakes

Do not assume an Allow guarantees access. Do not assume an SCP grants permissions. Do not ignore resource-based policies. Do not forget KMS when encrypted resources are involved. Do not change multiple policy layers at once during an incident.

Record the original error and policy state before making changes so the investigation remains understandable.

14. Practical Exercise

Create a small test role with access to one S3 prefix. Add an intentionally restrictive condition, test the failure, identify the request context that does not match, and correct the policy. Then add an explicit Deny and observe how it overrides the allow.

The objective is not memorization. It is learning to predict the result before pressing the console button.

15. Learning Progression

Once the basic model is comfortable, move to cross-account roles, KMS key policies, VPC endpoint policies, IAM Access Analyzer and Organizations guardrails. These topics expose the real-world complexity that appears in production systems.

At a Glance

Production Scenario: The Policy Looks Correct but the Request Still Fails

A developer opens a role and sees `s3:GetObject` allowed for the expected bucket. Yet the application still receives AccessDenied. This is where policy evaluation knowledge becomes practical. The request may be using a different role, the object ARN may not match, a bucket policy may restrict the principal, a permissions boundary may limit the role, an SCP may block the action, or a condition may fail. The fix is to reconstruct the request instead of editing policies until the error disappears.

Architecture Decision Guide

Keep policies readable and avoid unnecessary layers. Use explicit resource scope where the service supports it. Use conditions when they add meaningful control, but document them because conditions can be the hardest part to see during an incident. For high-risk permissions, test both the expected allow path and expected deny paths. Treat policy changes as code-like changes: review, test, deploy and monitor.

Interview Questions You Should Be Able to Answer

1. What is implicit deny? — A request is denied unless an applicable policy grants the required permission.
2. What is explicit deny? — A policy statement that directly denies the request and overrides an applicable allow.
3. Do permissions boundaries grant permissions? — No; they limit what identity-based policies can grant.
4. Do SCPs grant permissions? — No; they provide organization-level guardrails.
5. Why does request context matter? — Conditions and policy matching depend on who requested what, against which resource, and under which context.

Deep-Dive Checklist: Predicting an Authorization Decision

Before changing an IAM policy, write the request in plain language: 'Principal X wants to perform Action Y on Resource Z under Context C.' This forces the investigation to focus on the real request instead of a generic policy document.

Then list every policy layer that could matter. Start with identity-based and resource-based policies. Add permissions boundaries, session policies and organization controls where applicable. Inspect conditions carefully. If encryption is involved, add the KMS key to the investigation. If another account is involved, map the trust and resource ownership boundaries.

A useful habit is to predict the result before testing. If you believe the request should be allowed, explain exactly which policy statement grants it. If you believe it should fail, identify the boundary or deny that blocks it. This turns IAM from trial-and-error configuration into an auditable engineering process.

Professional Review Perspective

During a real incident, preserve evidence before making broad changes. Capture the principal ARN, failing action, resource ARN, Region, error message and recent policy changes. Then compare the request with the applicable policies. If you change several policy layers at once, you may restore access but lose the ability to explain the root cause. Good IAM troubleshooting therefore has two outputs: the service works again, and the organization understands why it failed and how to prevent the same failure.

Operational Depth

The same discipline helps with policy refactoring. Before replacing a broad policy with a narrower one, record the application's known API calls and test them in a non-production environment. Then compare observed access with intended access. This turns least-privilege work into an evidence-based process instead of a guessing exercise.

Final Practical Check

A practical final check is to explain the design to someone who did not build it. If they can identify who receives access, what the identity can do, which resources are protected, and what happens when access is revoked, the design is probably understandable. If the explanation depends on hidden assumptions, undocumented exceptions or one person's memory, the architecture needs more documentation and simplification.

Advantages

• Predictable authorization reasoning
• Faster AccessDenied troubleshooting
• Safer policy design
• Better understanding of multi-layer controls

Limitations and Considerations

• The evaluation model becomes complex with many policy types.
• A technically correct policy can still fail because of context or another control.
• Troubleshooting requires evidence rather than guesswork.

Practical Exercise

Create a test role with an S3 allow, then introduce a restrictive condition or explicit deny. Predict the outcome before testing and explain which policy layer produced the result.

Frequently Asked Questions

Does an Allow always mean access is granted?

No. Applicable boundaries, conditions, resource policies and organization controls can change the effective result.

What overrides an Allow?

An applicable explicit Deny overrides an Allow.

Do SCPs grant permissions?

No. SCPs provide organization-level permission guardrails.

Why check KMS when S3 access fails?

Encrypted data may require permission to use the relevant KMS key in addition to the storage permission.

How should I troubleshoot AccessDenied?

Identify the principal, action and resource, then inspect every applicable policy layer and condition systematically.

Related AWS Topics

AWS IAM → IAM users, groups, roles and policies → IAM Identity Center → KMS and encryption

AWS Learning Path / Next Step

Next, learn IAM Identity Center so the policy model can be applied to real workforce access across multiple accounts.

Conclusion

IAM policy evaluation becomes much less painful once you stop guessing and start following the request context and applicable policy layers. The skill is valuable because real AWS environments rarely fail for only one obvious reason.

Canonical URL: https://kodestree.com/iam-policy-evaluation-logic/