The Policy Evaluation Decision Flow

When any request reaches AWS, the IAM engine runs a precise evaluation flow to decide Allow or Deny. Memorizing this order is one of the highest-value things you can do for the SCS-C02 exam, because tricky scenario questions hinge on which policy type wins when several are in play.

The starting point is always an implicit deny. If nothing in the evaluation grants access, the request is denied. This deny-by-default stance means you must explicitly Allow an action somewhere for it to succeed; silence equals denial.

The single most important rule: an explicit Deny anywhere in any applicable policy overrides every Allow. No matter how many statements grant the action, one matching Deny blocks it. This is how guardrails and SCPs enforce hard limits that lower-level policies cannot override.

AWS evaluates in this conceptual order: 1) check for an explicit Deny in any policy (SCPs, boundaries, identity, resource, session) — if found, deny. 2) If an SCP applies and does not allow the action, deny. 3) Check permission boundaries, session policies, and identity/resource policies for an Allow. Any gap results in the implicit deny.

Service Control Policies (SCPs) in AWS Organizations set the maximum permissions for an account. An action must be allowed by the SCP and by an IAM policy to succeed. SCPs never grant access on their own; they only cap or deny. If the SCP does not permit an action, no IAM allow can rescue it.

A permission boundary is an advanced policy that caps the maximum permissions of a specific user or role. The effective permissions are the intersection of the boundary and the identity policy. Like SCPs, a boundary can only limit; it never expands what an identity-based policy grants.

When a role is assumed with a session policy, that policy further narrows permissions for just that session. The result is again an intersection: the session can do no more than both the role's policies and the session policy allow. Session policies are how you scope down at assume time.

For same-account requests, a resource-based Allow can grant access even without an identity Allow (union). For cross-account, both are required. And throughout, any explicit Deny in any of these still wins. The resource policy participates in the same overall flow.

Suppose an identity policy allows s3:DeleteObject, but an SCP denies all s3:Delete* in production. Result: denied, because the explicit SCP deny overrides the identity allow. Reversing it, if the SCP allows but no identity policy grants the action, it is also denied by implicit deny. Both layers must agree to allow.

Exam scenarios layer SCPs, boundaries, identity, and resource policies, then ask the outcome. The reliable method is to scan for any explicit deny first, confirm the SCP allows, confirm the boundary and session allow, and confirm an identity or resource Allow exists. If all line up with no deny, the answer is allow.

Carry this checklist: (1) Any explicit deny? Deny. (2) SCP allow? If not, deny. (3) Boundary/session allow? If not, deny. (4) Identity or resource allow? If yes and no deny, allow; else implicit deny. Apply it mechanically and even multi-policy questions become straightforward.

Test the evaluation flow.

IAM evaluation starts at implicit deny, and an explicit Deny always wins. To allow an action: no explicit deny anywhere, the SCP must permit it, permission boundaries and session policies (intersections) must permit it, and an identity or resource Allow must exist. SCPs and boundaries only limit; they never grant.