AWS IAM Policy Evaluation

Purpose of This Lesson

This lesson explains how AWS authorizes requests after a principal attempts to access an AWS resource. The key skill is tracing the evaluation path across authentication, request context, applicable policies, explicit denies, and permission limits.

For the AWS Certified CloudOps Engineer Associate SOA-C03 context, focus on recognizing which policy type controls a scenario and determining whether the final result is an allow, an implicit deny, or an explicit deny.

Key Concepts

• Default decision: Requests begin as denied. An allow must be established by applicable policy statements.
• Explicit deny: A matching explicit Deny overrides every matching Allow.
• Implicit deny: No applicable allow exists, or a limiting policy does not allow the requested action.
• Identity-based policy: Attached to an IAM user, group, or role. It grants permissions to the identity.
• Resource-based policy: Attached to a resource, such as an Amazon S3 bucket. It defines which principals can access that resource.
• Permissions boundary: Sets the maximum permissions an IAM entity can receive from its identity-based policies.
• Service control policy (SCP): An AWS Organizations policy that limits the maximum permissions available to accounts in an organization or organizational unit (OU).
• Session policy: Used with assumed-role API actions to limit permissions for a session.
• Effective permissions: The permissions remaining after all applicable grants and restrictions are evaluated.

IAM Request Authorization Workflow

1. A request is submitted

Requests can originate from the AWS Management Console, the AWS Command Line Interface (CLI), or an AWS API call.

2. The principal is authenticated

AWS first verifies the identity making the request. For example, a console user may authenticate with a username and password. Authentication establishes who is making the request; it does not by itself grant permission to perform the requested action.

3. AWS builds the request context

The request context contains information needed for policy evaluation, including:

• Action: The requested operation, such as the Amazon S3 GetObject API action.
• Resource: The target AWS resource or object.
• Principal: The user, role, federated user, or application making the request.
• Environment data: Attributes such as source IP address, user agent, and SSL status. Policies can use this information for conditions.
• Resource data: Information associated with the resource being requested.

4. AWS evaluates applicable policies

AWS evaluates the policies that apply to the principal, resource, account, organization, and session. The result is a final authorization decision: allow or deny.

IAM Policy Evaluation Logic

The evaluation starts with a default deny and then considers whether applicable policies establish an allow. A useful decision sequence is:

1. Check for an explicit deny. If any applicable policy explicitly denies the request, the final result is Deny.
2. Evaluate an applicable organization SCP. If the principal’s account is governed by an SCP, the request must be allowed by the SCP. An SCP acts as a maximum-permission boundary for the account or OU; it does not grant permissions by itself.
3. Evaluate resource-based policies. If the requested resource has a resource policy, such as an S3 bucket policy, determine whether it allows the request.
4. Evaluate identity-based policies. Determine whether an applicable user, group, or role policy allows the action on the requested resource.
5. Evaluate a permissions boundary, if present. The requested permission must also be allowed by the boundary. A boundary limits what an identity-based policy can grant.
6. Evaluate session-related restrictions, if applicable. For a session principal or an assumed-role request, a relevant session policy may further restrict the request. If the session policy does not allow the action, the result is denied.
7. Return the final decision. If the request has an applicable allow and no applicable restriction or explicit deny blocks it, AWS allows the request. Otherwise, the result is an implicit or explicit deny.

The exact interaction of identity-based and resource-based policies can depend on the principal and policy context. Do not assume that adding an identity policy automatically bypasses a resource policy, boundary, SCP, session policy, or explicit deny.

Effective Permissions and Policy Combinations

Identity-based policy plus resource-based policy

For the policy combination described in the lesson, effective permissions can come from an allow in either the identity-based policy or the resource-based policy, provided no explicit deny or other limiting policy blocks the request.

A typical example is an IAM identity attempting s3:GetObject against an S3 object while both the identity and bucket have applicable policies. AWS evaluates the combined policy context rather than looking at only one policy document.

Identity-based policy plus permissions boundary

The effective permissions are the intersection of the identity policy’s grants and the permissions boundary’s allowed permissions. An identity policy may allow an action, but the action remains unavailable if the boundary does not allow it.

Identity-based policy plus organization SCP

The effective permissions are the intersection of the identity policy’s grants and the permissions allowed by the applicable SCP. The SCP limits what the account can use, even when an identity policy allows the action.

Session policies

Session policies can further limit permissions associated with an assumed-role session. When session restrictions apply, the requested action must also be permitted for that session.

Exam- or Assessment-Relevant Takeaways

• Always check for an explicit deny first. It overrides allows from identity-based, resource-based, boundary, SCP, or session policies.
• A default deny is not the same as an explicit deny. A default or implicit deny occurs when no applicable allow exists or a limiting policy fails to allow the request.
• An SCP is a maximum-permission control, not a permission grant. An identity policy and the SCP must both permit the requested action.
• A permissions boundary does not grant permissions. It limits the permissions that identity-based policies can grant to an IAM entity.
• Resource-based policies are attached to resources, such as S3 buckets, rather than to users, groups, or roles.
• Authentication answers “Who is making the request?” Authorization evaluates whether that authenticated principal may perform the requested action.
• When analyzing a scenario, identify the action, resource, principal, environmental conditions, and every applicable policy before deciding allow or deny.
• A policy statement must match the requested action and resource and satisfy its conditions; the lecture’s workflow emphasizes evaluating all applicable policies rather than stopping at the first allow.

Tool / Feature Decision Guide

Scenario or control	Policy or feature to inspect	Decisive reason
Permissions are granted directly to a user, group, or role	Identity-based policy	It defines permissions for an IAM identity.
Access is controlled by the target resource, such as an S3 bucket	Resource-based policy	It defines which principals may access the resource.
A delegated administrator must cap what an IAM entity can receive	Permissions boundary	It limits identity-based grants for that entity.
An organization wants to restrict member accounts or OUs	Service control policy	It sets a maximum permission ceiling across the organization structure.
Permissions must be restricted for an assumed-role session	Session policy	It can limit permissions for that session.
A request is unexpectedly denied despite an allow	Check explicit denies, SCPs, boundaries, resource policies, identity policies, and session restrictions	An allow is effective only when no applicable restriction or explicit deny blocks it.

Common Traps / Misconceptions

• “An allow always wins if I can find one.” False. An explicit deny always wins, and limiting policies such as boundaries, SCPs, and session policies can prevent an allow from becoming effective.
• “An SCP grants access.” False. An SCP limits maximum permissions; an identity or resource policy still needs to provide the relevant allow.
• “A permissions boundary gives the entity those permissions.” False. It defines the maximum permissions an identity-based policy may grant.
• “Authentication means the request is authorized.” False. Authentication identifies the principal; policy evaluation determines access.
• “No deny statement means access is allowed.” False. Requests are denied by default unless an applicable allow exists.
• “Only identity policies matter.” False. Resource-based policies, SCPs, permissions boundaries, and session policies can all affect the result.
• “A resource policy is attached to the requesting user.” False. Resource-based policies are attached to resources such as S3 buckets.
• “A policy can ignore the request context.” False. Actions, resources, principals, and environmental data such as source IP and SSL status can affect whether a statement applies.

Real-World Engineer / Analyst Notes

When troubleshooting an authorization failure, document the request before inspecting policy documents. Record the principal, API action, target resource, source conditions, and whether the request uses a role or session. Then inspect every policy layer that can apply.

A practical troubleshooting order is:

1. Look for an explicit deny.
2. Confirm that the requested action and resource are covered by an applicable allow.
3. Check whether an organization SCP limits the account or OU.
4. Check for a permissions boundary on the IAM entity.
5. Check resource-based policy conditions, especially for S3-style access.
6. Determine whether an assumed-role session or session policy adds another restriction.

This method avoids the common mistake of finding one permissive statement and assuming it explains the final result.

Quick Reference Summary

• Every request begins with a default deny.
• AWS authenticates the principal and builds a request context before evaluating authorization.
• The request context includes the action, resource, principal, environment data, and resource data.
• An explicit deny overrides every allow.
• Identity-based policies attach to users, groups, and roles.
• Resource-based policies attach to resources.
• Permissions boundaries limit identity-based grants.
• SCPs limit maximum permissions for organization accounts or OUs.
• Session policies can limit assumed-role sessions.
• Effective permissions depend on all applicable policies, not on a single allow statement.

Flashcards

Q: A user has an identity policy allowing an action, but an applicable policy explicitly denies it. What is the result and why?

A: The request is denied. An explicit deny overrides any allow from an identity-based or resource-based policy.

Q: What is the difference between authentication and authorization in an AWS request?

A: Authentication verifies the principal’s identity. Authorization evaluates whether that authenticated principal may perform the requested action on the resource.

Q: Which policy should you inspect when access is controlled by an S3 bucket itself rather than by the requesting IAM user?

A: Inspect the S3 bucket’s resource-based policy. Resource-based policies are attached to resources and define access for principals.

Q: An identity policy allows s3:GetObject, but a permissions boundary does not allow it. What is the effective result?

A: The request is denied because the effective permission must be allowed by both the identity-based policy and the permissions boundary.

Q: An account’s identity policy allows an action, but the applicable organization SCP does not allow it. What is the trap?

A: The SCP acts as a maximum-permission limit, so the identity allow is insufficient. The action is denied because it is not allowed by both policy layers.

Q: What information in the request context might a policy use to restrict access by network or client characteristics?

A: Environment data such as source IP address, user agent, and SSL status can be part of the request context and used in policy conditions.

Q: When would you inspect a session policy instead of only the role’s identity policy?

A: Inspect it when the request is associated with an assumed-role or session principal. A session policy can further restrict the permissions available to that session.

Q: What is the difference between an implicit deny and an explicit deny?

A: An implicit deny results from the absence of an applicable allow or from a limiting policy not allowing the action. An explicit deny is a matching Deny statement and overrides all allows.

Q: A request has both an identity-based policy and a resource-based policy. How should you reason about the effective permissions?

A: Evaluate both policy types together, while also checking for explicit denies and other limiting policies. In the lesson’s model, an allow can come from either applicable policy type when no restriction blocks it.

Q: Which control is designed to cap permissions granted to an individual IAM entity?

A: A permissions boundary. It sets the maximum permissions that identity-based policies can grant to that entity.

Q: Which control is designed to restrict the maximum permissions available to accounts in an AWS Organization or OU?

A: A service control policy. It limits account or OU permissions but does not itself grant access.

Q: What should you identify before evaluating a confusing authorization scenario?

A: Identify the principal, requested action, target resource, environmental conditions, and all applicable policy types. These elements determine which statements participate in evaluation.

Practice Questions

Question 1

An IAM role has an identity-based policy allowing s3:GetObject. The role’s account is in an AWS Organization, and the applicable SCP does not allow the S3 action. There is no explicit deny. What is the result?

A. The request is allowed because the identity policy allows it
B. The request is allowed because SCPs only apply to users
C. The request is denied because the SCP limits the account’s maximum permissions
D. The request is denied only if the S3 bucket policy also denies it

Correct answer: C

The decisive clue is the applicable SCP. The action must be allowed by both the identity policy and the SCP; an SCP can limit an account even when an identity policy allows the action.

Question 2

A user attempts to retrieve an S3 object. The request is authenticated, the identity policy allows s3:GetObject, and the bucket policy contains an applicable explicit Deny for the user’s source IP address. What happens?

A. The request is allowed because the identity policy is more specific
B. The request is allowed if the user has console access
C. The request is denied because the explicit deny overrides the allow
D. The request is denied only if a permissions boundary exists

Correct answer: C

The bucket policy’s matching explicit deny takes precedence over the identity-based allow. Source IP information can be part of the request context used by policy conditions.

Question 3

An IAM entity’s identity policy allows an API action. The entity also has a permissions boundary that does not allow that action. Which result should an engineer expect?

A. Allow, because boundaries are advisory only
B. Allow, because the identity policy is evaluated first
C. Deny, because effective permissions are limited by the boundary
D. Allow, unless the organization SCP denies it

Correct answer: C

A permissions boundary sets the maximum permissions that the identity-based policy can grant. The action must be permitted by both layers.

Question 4

An engineer is troubleshooting an authorization failure and has found one identity-based allow. Which next step best follows the IAM evaluation model?

A. Stop troubleshooting because the allow proves authorization
B. Check for explicit denies and other applicable limits such as SCPs, boundaries, resource policies, and session policies
C. Delete the resource-based policy
D. Re-authenticate the user without reviewing the request context

Correct answer: B

A single allow does not determine the final result. The engineer must check all applicable policies and restrictions, beginning with explicit denies.

WordPress Metadata

Suggested Slug:
aws-iam-policy-evaluation-soa-c03

Meta Description:
Learn how AWS IAM evaluates requests across identity, resource, boundary, SCP, and session policies, including explicit-deny precedence and effective-permission rules.

Tags:
AWS IAM, IAM policies, policy evaluation, identity-based policies, resource-based policies, permissions boundaries, service control policies, session policies, AWS Organizations, SOA-C03