AWS IAM Policy Evaluation Logic and Permission Boundaries – SAP-C02 Study Guide

Purpose of This Lesson

AWS authorization decisions depend on more than a single IAM policy. A request can be affected by identity-based policies, resource-based policies, AWS Organizations service control policies (SCPs), permissions boundaries, session policies, and explicit denies.

For the SAP-C02 exam, you must determine whether the effective permissions allow a request after all applicable policy types and guardrails are evaluated.

Key Concepts

Authentication precedes authorization

A request can originate from the AWS Management Console, AWS CLI, an SDK, or a direct API call. Before AWS evaluates permissions, it authenticates the principal, such as:

• An IAM user
• An IAM role session
• A federated user
• An AWS service or application
• The AWS account root user

Authentication establishes who is making the request. Authorization then determines whether that principal can perform the requested action.

The request context

AWS builds a request context containing information used during policy evaluation, including:

• Principal: The user, role, federated identity, application, or service making the request
• Action: The API operation, such as s3:GetObject
• Resource: The target resource, such as an S3 object or KMS key
• Environment data: Source IP address, VPC endpoint, TLS status, user agent, tags, and other condition data
• Resource data: Attributes and metadata associated with the requested resource

Policy conditions can use this context. For example, a policy might allow access only when the request comes from a specific VPC endpoint or source IP range.

Default deny

AWS authorization begins with an implicit deny. No permission exists unless an applicable policy produces an allow.

An implicit deny means no applicable allow was found. An explicit deny is a policy statement with Effect: Deny that matches the request.

The distinction matters because an explicit deny overrides every allow from another policy. An implicit deny can be overcome by an applicable allow, subject to any required guardrails.

Identity-based policies

Identity-based policies are attached to IAM users, groups, and roles. They specify which actions a principal may perform on which resources, optionally subject to conditions.

Examples include:

• An IAM role allowing s3:GetObject on a specific bucket prefix
• A group policy allowing developers to use selected EC2 APIs
• A user policy allowing access to a particular DynamoDB table

Resource-based policies

Resource-based policies are attached to supported AWS resources and specify which principals can access them. Common examples include:

• S3 bucket policies
• KMS key policies
• SQS queue policies
• SNS topic policies
• IAM role trust policies, which control who can assume a role

A resource policy can be essential for cross-account access. In a typical cross-account design, the resource account grants access in the resource policy and the principal’s account grants access through an identity-based policy, unless the service and policy pattern support a direct resource-policy grant.

Service control policies

SCPs are AWS Organizations guardrails applied to accounts, organizational units, or the organization root. They define the maximum permissions available to principals in member accounts; they do not grant permissions by themselves.

For a request in an account governed by an SCP, the action generally must be allowed by both:

1. An applicable identity-based or resource-based policy, and
2. The applicable SCP effective for the account

If the SCP does not allow the action, the request is denied even when an IAM policy allows it. The management account is not restricted by SCPs in the same way as member accounts.

Permissions boundaries

A permissions boundary is an advanced policy attached to an IAM user or role. It establishes the maximum permissions that identity-based policies can grant to that principal.

A boundary does not grant permissions. The effective identity permissions are limited to actions allowed by both the identity-based policy and the boundary. An explicit deny in either policy still wins.

Session policies

A session policy can be supplied when using APIs such as AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity. It limits the permissions available to the resulting session.

Like a permissions boundary, a session policy is a restriction rather than a grant. The session must have an applicable allow from the role’s permissions and the session policy must not exclude the requested action.

Role sessions and resource policies

Role-based authorization has an important AWS-specific nuance. A resource-based policy that grants permissions directly to a role session principal ARN can allow that session to access the resource even when an identity-based policy, permissions boundary, or SCP would otherwise limit the role. This does not defeat an explicit deny.

This behavior differs from a resource policy that grants access to the IAM role ARN rather than the assumed-role session principal. Exam questions often test this distinction. Always identify whether the resource policy names the role, the role session principal, or the account.

Exam-Relevant Takeaways

• Every request starts with an implicit deny.
• An explicit deny in any applicable policy overrides an allow.
• An allow in an IAM policy is not sufficient when an SCP, permissions boundary, or session policy limits the request.
• SCPs set account-level maximum permissions; they do not grant access.
• Permissions boundaries set the maximum permissions for a user or role; they do not grant access.
• Session policies restrict temporary credentials created through role-assumption APIs.
• Resource-based policies are central to cross-account access and service-specific authorization.
• The principal named in a resource policy matters, especially for assumed-role sessions.
• Conditions such as aws:SourceIp, aws:PrincipalOrgID, aws:SourceVpce, and encryption-related keys can change the result even when an action appears to be allowed.
• The root user is not governed by identity-based IAM policies in the same way as IAM users and roles, but resource policies, SCP behavior, and service-specific restrictions still require careful analysis.

Architecture Decision Guide

Requirement or situation	Policy mechanism to evaluate	Effective-permission rule
Grant a user, group, or role access	Identity-based policy	Must contain an applicable allow, unless a supported resource-policy path grants access
Control access directly on an S3 bucket, SQS queue, SNS topic, or KMS key	Resource-based policy	The resource policy must name an allowed principal and satisfy its conditions
Restrict what an entire member account or OU can use	AWS Organizations SCP	The request must be permitted by the applicable SCP; an SCP alone does not grant access
Delegate IAM administration while preventing privilege escalation	Permissions boundary	Effective identity permissions are limited to the intersection of the identity policy and boundary
Restrict permissions issued to a temporary role session	Session policy	The session receives only permissions permitted by the role/session authorization model and session policy
Deny access regardless of other allows	Explicit Deny	The matching explicit deny overrides all allows
Enable cross-account access	Resource policy plus principal-side authorization as required by the service	Confirm both accounts’ policies, SCPs, trust policies, conditions, and the service’s cross-account model

Common Exam Traps

Treating an SCP as a permission grant

An SCP such as Allow s3:* does not give a role S3 access. The role still needs an applicable IAM or resource-based allow.

Assuming an allow always wins

An explicit deny in an SCP, identity policy, resource policy, permissions boundary, or session policy overrides an allow elsewhere.

Confusing implicit and explicit deny

An implicit deny means no matching allow was found. An explicit deny is an actual matching deny statement. Adding an allow can overcome an implicit deny, but never an explicit deny.

Ignoring the permissions boundary

A role may have an identity policy allowing an action while its boundary omits that action. The effective permission is still denied.

Assuming resource policies always combine as an intersection

Identity-based and resource-based policies generally work together through their applicable allows, but assumed-role session principals and service-specific evaluation rules can produce different results. Inspect the exact principal in the resource policy.

Forgetting the role trust policy

A role’s permissions policy controls what the role can do after assumption. The role trust policy controls who or what can assume it. A permissive role policy cannot compensate for a trust policy that denies the caller.

Overlooking conditions

An allow statement may fail because the request uses the wrong source IP, VPC endpoint, principal organization, encryption context, TLS state, or resource tag.

Real-World Engineer Notes

• Use SCPs for organization-wide preventive guardrails, such as denying actions outside approved Regions or preventing disabling security services.
• Use permissions boundaries when delegating IAM role or user creation to application teams. Require delegated policies to remain within the boundary.
• Prefer narrowly scoped resource policies with specific principals, resources, and conditions rather than broad statements such as Principal: "*".
• For cross-account access, document both sides of the authorization path: the caller’s permissions, the target resource policy, the role trust policy if role assumption is used, and the SCPs in both accounts.
• When debugging an authorization failure, check the evaluated principal and session first. Temporary credentials represent a role session, not merely the role definition.
• IAM Policy Simulator and CloudTrail events are useful diagnostic tools, but service-specific behavior and condition keys still need to be verified in the relevant service documentation.

Quick Reference Summary

1. Authenticate the principal.
2. Build the request context: principal, action, resource, and conditions.
3. Find all applicable identity, resource, SCP, boundary, and session policies.
4. If any applicable statement explicitly denies the request, the result is Deny.
5. Otherwise, an applicable allow must exist.
6. SCPs, permissions boundaries, and session policies limit the permissions available through their respective authorization paths.
7. Resource-based policies and role-session principals can change how those limits apply.
8. If no valid allow remains, the result is an implicit Deny.

A useful simplified model is:

Explicit Deny anywhere       => Deny
Otherwise, required Allows   => Allow
Otherwise                     => Implicit Deny

For many identity-based requests, the effective permissions can be approximated as:

Identity policy
∩ Permissions boundary, when present
∩ Session policy, when present
∩ Applicable SCPs

Resource-based policies and role-session rules must then be evaluated according to the specific AWS service and named principal.

Flashcards

1. What is the starting state for an AWS authorization request?

An implicit deny.

2. What overrides an allow in another policy?

A matching explicit deny.

3. Do SCPs grant permissions?

No. SCPs define the maximum permissions available to accounts and principals within an organization.

4. What does a permissions boundary do?

It limits the maximum permissions that an IAM user or role can receive through identity-based policies.

5. What does a session policy do?

It restricts permissions for temporary credentials created through role-assumption APIs.

6. Where are identity-based policies attached?

To IAM users, groups, and roles.

7. Where are resource-based policies attached?

To supported resources such as S3 buckets, SQS queues, SNS topics, and KMS keys.

8. What is the difference between authentication and authorization?

Authentication verifies the caller’s identity. Authorization determines whether that authenticated principal may perform the requested action.

9. What is required for a normal identity-based request to succeed when an SCP applies?

An applicable allow in the identity or resource authorization path and an applicable SCP that does not exclude the action.

10. Why does the principal type in a resource policy matter?

A policy naming an assumed-role session principal can be evaluated differently from one naming the IAM role ARN, particularly with boundaries and SCP restrictions.

11. What does a role trust policy control?

Who or what can assume the role.

12. What data can a policy condition inspect?

Request context such as source IP, VPC endpoint, principal attributes, TLS state, resource tags, and encryption context, depending on the condition key.

Practice Questions

Question 1

An IAM role has an identity policy allowing s3:GetObject on a bucket. A permissions boundary is attached to the role, but the boundary does not allow s3:GetObject. What happens when the role attempts to retrieve an object?

Correct answer: The request is denied.

Explanation: A permissions boundary does not grant permissions and limits the role’s identity-based permissions. Because the action is not allowed by both the identity policy and the boundary, the effective permission is denied.

Question 2

A member account has an IAM role with an identity policy allowing ec2:RunInstances. The account’s SCP does not include an allow for ec2:RunInstances. There are no explicit denies. What is the result?

Correct answer: The request is denied.

Explanation: For a member account governed by an SCP, the action must be permitted by the applicable SCP as well as by an identity or resource-based authorization path. An SCP is a maximum-permission guardrail, not a grant.

Question 3

An S3 bucket policy grants s3:GetObject to the ARN of a specific assumed-role session. The role’s permissions boundary does not allow S3 access. There is no explicit deny. Which result is most accurate?

Correct answer: The resource-based grant to the role session can allow the request, subject to S3 policy evaluation and any applicable explicit denies.

Explanation: A resource policy that directly names a role session principal can have authorization behavior that bypasses identity-based limitations such as a permissions boundary. The exact principal and service-specific policy evaluation rules must be checked; an explicit deny would still override the allow.

Question 4

An IAM user has an identity policy allowing s3:GetObject. The bucket policy contains an explicit Deny for requests that do not use a particular VPC endpoint. The user accesses the bucket through the public internet. What happens?

Correct answer: The request is denied.

Explanation: The request does not satisfy the bucket policy condition, so the explicit deny applies. The identity-based allow cannot override it.

Question 5

An application needs to access an S3 bucket in another AWS account. The target bucket policy allows the application’s role ARN, but the role trust policy does not allow the application principal to assume the role. What is the immediate problem?

Correct answer: The application cannot obtain valid credentials for the role.

Explanation: The trust policy controls who can assume a role; the role permissions policy controls what the role can do after assumption. A bucket policy allow does not repair an invalid role-assumption path. Cross-account designs must validate the trust policy, role permissions, bucket policy, SCPs, and conditions.