AWS IAM Policy Evaluator

The order, in full

Evaluation starts from an implicit deny and works down. The first rule that produces a decision wins, and only the first rule can produce a Deny that nothing else can reverse. Note where the identity and resource policies sit: last, and only after both ceilings have already agreed.

1. explicit Deny in any policy      -> DENIED, final
2. service control policy            -> must Allow, or DENIED
3. permissions boundary              -> must Allow, or DENIED
4. identity or resource policy       -> Allow -> ALLOWED
5. nothing matched                   -> DENIED (implicit)

Specificity is irrelevant

This is the assumption that causes the most confusion, because it holds in almost every other permission system. A Deny on Action "*" and Resource "*" beats an Allow naming one exact object ARN. There is no most-specific-wins tiebreak and no ordering within a document: a Deny anywhere in any attached policy ends the evaluation.

Allow  s3:GetObject  on arn:aws:s3:::bucket/exact-file.csv
Deny   s3:*          on *

result: denied

Ceilings do not grant anything

A service control policy and a permissions boundary can only take permissions away. An SCP allowing Action "*" grants nobody anything: it merely declines to remove anything. Permissions still have to come from an identity or resource policy underneath. This catches people who attach a permissive SCP and expect access to appear.

Within an account, either side is enough

For a call inside one account, an Allow in the identity policy or in the resource policy is sufficient. Across accounts both are required: the caller's account must permit the call and the resource's account must permit the caller. A cross-account request that fails despite an obviously correct bucket policy is nearly always missing the identity half, and vice versa.

same account       identity Allow  OR  resource Allow
cross-account      identity Allow  AND resource Allow

Conditions decide whether a statement applies at all

A condition is not a separate check bolted on afterwards: a statement whose condition is not met simply does not apply, as though it were not there. That is why a Deny guarded by a condition is safe when the condition is false, and why the IfExists suffix matters so much: it makes the condition pass when the key is absent, which quietly turns a restriction into a no-op for any caller who does not send the key.

"Condition": {
  "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
}

fires when MFA is absent OR the key is missing entirely, which is not the same as "when MFA was not used"