TL;DR: Deny by default, then evaluate every applicable policy together. An explicit Deny anywhere wins immediately and cannot be overridden. For ordinary same-account access, identity and resource grants combine. Cross-account access generally needs grants on both sides. Applicable SCPs, RCPs, boundaries and session policies can limit those grants; resource-policy behavior also depends on the principal receiving the grant.
How to approach it
Identify the principal, target resource and account boundary before evaluating permissions. Separate policies that grant access from policies that constrain it; this determines where a missing Allow matters.
A strong answer
For an IAM user or role, begin with implicit denial and identify applicable grants. Collect organization service control policies (SCPs), resource control policies (RCPs), any permissions boundary, identity policies, session policies and the target’s resource policy. Service-specific rules matter too, particularly KMS key policies and role trust policies.
If any of them contains an explicit Deny that matches, the request is denied and evaluation stops. There is no override, no precedence argument, no "but the admin policy allows it". An applicable SCP can constrain a member-account administrator. SCPs do not constrain the management account or service-linked roles.
If there is no applicable explicit deny, distinguish grants from limits:
- SCP sets the maximum available permissions for the whole account. It never grants anything; it only bounds what identity policies can grant.
- Permissions boundary does the same for one principal, capping what its identity policies can achieve.
- Identity policy grants to the principal.
- Resource policy grants access to named principals on the resource.
- RCP constrains access to supported resources in organization member accounts.
- Session policy limits permissions for the assumed session. These limiting policies do not grant access by themselves.
So a role can hold AdministratorAccess and still be denied if an SCP does not permit the action in that account. That single fact explains most confusing AccessDenied messages in a large organisation.
The cross-account case is worth stating precisely, because it is the most common real question. For ordinary same-account access, an Allow in either the identity policy or the resource policy can supply the grant, subject to applicable limits and service-specific rules. For cross-account, you need both: the resource policy in the target account must allow the calling principal, and the identity policy in the source account must allow the call. Either one alone fails. Within an account, distinguish a resource-policy grant to a role ARN from one to a role-session ARN: implicit denies in identity policies, boundaries and session policies do not constrain every resource grant identically. Use the AWS evaluation reference for the exact principal type.
Two mechanisms worth naming to show depth. sts:ExternalId in a trust policy prevents the confused-deputy problem when granting a third party access: the vendor assigns a unique value per customer and supplies it when assuming the customer’s role. The value need not be secret; its purpose is to stop another customer inducing the vendor to use the wrong role. And condition keys such as aws:PrincipalOrgID or aws:SourceVpce let you write resource policies that are broad in principal and narrow in context, which is how you avoid enumerating account IDs forever.
What interviewers probe next
"A role has AdministratorAccess and gets AccessDenied. Explain." SCP, permissions boundary, a session policy from the assume-role call, or an explicit deny on the resource policy. Four candidates, and the error message often names which.
"How do you debug it?" IAM Policy Simulator for the theory, CloudTrail for the actual denied event, which records the evaluated context. CloudTrail is the faster path in production.
"Why prefer roles over users?" Temporary credentials that expire, no long-lived access keys to leak, and an audit trail that names the assuming identity.
Common mistakes
Believing an Allow can override a Deny. It cannot, ever, and this is the single most important rule.
Treating every policy as an intersection. Additional identity or resource grants can increase access; boundaries and organization controls cap it.
Missing that cross-account requires both sides, which produces hours of debugging on the wrong account.