L1. IAM Policy Evaluation Logic: Identity, Resource & SCPs

The Policy Types in Play

Every AWS request is evaluated against several categories of policy, and the exam expects you to know which ones can apply to a given request:

• Identity-based policies: attached directly to an IAM user, group, or role.
• Resource-based policies: attached to the resource itself, such as an S3 bucket policy or a KMS key policy.
• Permissions boundaries: an advanced feature that sets the maximum permissions an identity can have, regardless of what its identity-based policies grant.
• Service control policies (SCPs): applied at the AWS Organizations level to accounts and organizational units.
• Session policies: passed inline when a role is assumed, further restricting the session's permissions.

None of these operate in isolation. AWS combines every applicable policy for a request and runs it through a single evaluation algorithm.

The Evaluation Algorithm

AWS evaluates policies in a strict order:

1. If any applicable policy contains an explicit Deny, the request is denied. Full stop. Nothing overrides this.
2. If no explicit Deny exists, AWS checks whether any applicable policy contains an explicit Allow. If so, the request is permitted.
3. If neither is found, the request is implicitly denied by default. AWS is deny-by-default: permissions must be explicitly granted somewhere.

SCPs and Boundaries Never Grant, They Cap

A common point of confusion is treating SCPs or permission boundaries as if they grant access the way an identity-based policy does. They don't. Both are ceilings, not grants. An SCP with an Allow statement does nothing by itself; it simply permits the identity-based policy underneath it to take effect. The effective permission for any action is the intersection of what the identity-based policy allows and what the boundary or SCP permits.

Same-Account vs Cross-Account Access

Within a single account, if either the identity-based policy or the resource-based policy grants Allow, that is generally sufficient, this is effectively a union. Across accounts, the rules tighten: both the requester's identity-based policy and the resource's resource-based (or trust) policy must independently allow the action. A generous bucket policy alone does not help a cross-account caller whose own identity policy denies the action, and vice versa.

S3 is a notable, exam-tested exception to this rule: a bucket policy can grant access to an external account's principal on its own, without that principal needing a matching identity-based policy for the same action, though an explicit Deny anywhere still blocks the request.

Exam trap: SCPs apply to member accounts and organizational units within an AWS Organization. They do not apply to the management (payer) account, which is why the management account should be used sparingly for workloads.

Useful Condition Keys

Fine-grained policies often lean on global condition keys:

• aws:MultiFactorAuthPresent requires the caller to have authenticated with MFA.
• aws:PrincipalOrgID restricts access to principals belonging to a specific AWS Organization.
• aws:SourceIp restricts access based on the caller's IP address or CIDR range.

These keys appear constantly in exam scenarios involving conditional access and defense-in-depth policy design.