How AWS decides whether to allow a call

1. 01

   Ordinary resource access starts denied

   A new IAM identity cannot list your S3 buckets without a grant. Having credentials does not itself grant resource permissions. There are specific exceptions: STS GetCallerIdentity returns your account and caller identity without requiring an allow, even when that action has an explicit deny. Use the default-deny model for resource access, and check the API documentation for exceptions.

2. 02

   That base case has a name: implicit deny

   When nothing in the account says yes, the answer is no. It is called *implicit* because no policy had to be written to produce it. Most permission errors a beginner hits are implicit denies: nobody blocked you, it is simply that nobody ever allowed you.

3. 03

   An allow has to come from a document you can point at

   Permissions arrive from identity policies attached to a user, a group the user belongs to, or a role they assumed; and for a handful of services, from a resource policy attached to the thing being touched — a bucket policy, a queue policy, a KMS key policy. If you cannot point at the document that grants a call, the call is denied.

4. 04

   Which is why the first fix that works is usually the wrong one

   AdministratorAccess supplies broad identity-based allows, so it can hide a missing permission. It does not bypass explicit denies, organization controls, permissions boundaries or service-specific access requirements. Grant the action the task requires and verify the resource scope instead of expanding access until the error disappears.

1. 01

   It is one algorithm, and it always runs in the same order

   AWS collects every policy that could apply to the call — identity policies, resource policies, permissions boundaries, session policies, and any Service Control Policies from AWS Organizations — and evaluates them together. The result is a single decision, and the order that produces it never changes.

2. 02

   Step one: is there an explicit deny anywhere?

   If any applicable policy contains a matching statement with `"Effect": "Deny"`, the call is denied and evaluation stops. Nothing overrides it. Not AdministratorAccess, not a resource policy, not being the account owner if a boundary or SCP is involved. This is why a deny statement is the strongest tool in IAM and why it should be used sparingly and precisely.

3. 03

   Step two: do the ceilings permit it?

   SCPs and permissions boundaries are filters, not grants. A call has to be inside every applicable ceiling to survive. The critical property — and the one exam questions are built on — is that a ceiling can only ever reduce. Attaching a boundary that allows `s3:*` to a user with no policies grants that user nothing at all.

4. 04

   Step three: is there an explicit allow?

   For the simplified identity-policy case taught here, the requested action and resource need an applicable allow within the relevant controls. Actual AWS evaluation also depends on the principal and policy type: direct resource-policy grants, role sessions, cross-account access and service-specific exceptions need their own rules. The local simulator covers a documented subset.

5. 05

   Why the order is deny-first and not allow-first

   Because a security boundary that could be widened by adding another policy would not be a boundary. Deny-first means a control team can attach a deny to an Organizational Unit and be certain that no account administrator underneath can undo it by granting themselves more. The guarantee runs in exactly one direction, and that is what makes it worth anything.

1. 01

   A role, unless the thing is a human without federation

   Assuming a role returns temporary credentials. CLI AssumeRole sessions default to one hour; duration and service-managed sessions follow the applicable rules. Roles avoid distributing long-lived user access keys, but temporary credentials can still leak and remain usable until they expire or are revoked. EC2 instance profiles, Lambda execution roles and ECS task roles provide service-specific ways to supply permissions.

2. 02

   A group is a management tool, not a security boundary

   Groups exist so that a permission lives in one place when five people need it. Nothing assumes a group and nothing is granted to a group as a principal — a group cannot appear in a resource policy. Put policies on the group, put people in the group, and the "why does this one engineer have S3 write" question stays answerable.

3. 03

   A user with long-lived access keys is a liability you are choosing to accept

   Access keys do not expire, do not rotate themselves, and end up committed to repositories with reliable regularity. There are real cases for them — an on-premises server, a third-party tool that cannot federate — and in those cases the answer is a narrow policy, a rotation schedule, and an alarm. The answer is not "and also AdministratorAccess so it stops erroring".

Official references & further reading

These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.

• IAM: policy evaluation
• IAM and STS: quotas
• STS: GetCallerIdentity exception