An IAM policy that contains Allow is only one part of the authorization decision. To understand AWS access, you need to understand implicit denies, explicit denies, policy intersections, resource-based policies, and the request context.

================================================== ARTICLE STATUS

ARTICLE STATUS: TECHNICAL DRAFT REVIEWED

Research: YES AWS documentation: CHECKED Technical claims reviewed: YES Examples reviewed: YES — documentation-verified examples Hands-on AWS validation: DEFERRED Commands personally tested: NO Technical review: YES Editorial review: YES Final publication: AFTER FINAL EDITORIAL PASS

================================================== INTRODUCTION

A security researcher finds an IAM policy containing:

"Effect": "Allow", "Action": "s3:", "Resource": ""

At first glance, the conclusion seems obvious:

"This identity has full S3 access."

Sometimes that conclusion is correct.

Sometimes it is incomplete.

The identity may have a permissions boundary that limits what its identity-based policies can grant. The account may be controlled by an AWS Organizations service control policy. A session policy may further restrict a temporary session. A resource-based policy may provide another authorization path. An explicit Deny may override an Allow.

There is another important point: AWS does not simply read one IAM policy and make a decision. It evaluates the request in context and considers the policy types that apply to that request.

This is one of the most important concepts to understand before doing serious AWS security research.

If you misunderstand policy evaluation, you can report false positives, miss effective restrictions, or assume an attack path exists when an authorization boundary prevents it.

The goal of this article is to build a mental model for how AWS arrives at an Allow or Deny decision.

================================================== FROM POLICY DOCUMENT TO AUTHORIZATION DECISION

In the previous article, we looked at the structure of an IAM policy:

Effect
Action
Resource
Condition
Principal where applicable

That answered the question:

"What does this policy statement say?"

Now we ask a different question:

"What happens when an AWS principal actually sends a request?"

A simplified model is:

AWS request ↓ Authenticate principal ↓ Build request context ↓ Identify applicable policies ↓ Look for explicit Deny ↓ Determine whether required Allow conditions are satisfied ↓ Apply boundaries and organizational controls ↓ Final decision ↓ Allow or Deny

This is deliberately simplified. AWS has service-specific behavior and several policy types, and the exact evaluation path depends on the request.

AWS documents the basic rules clearly:

Requests are denied by default.
An applicable explicit Deny overrides an Allow.
An applicable Allow is required for the request to succeed.
Additional policy types can restrict the effective permissions.

That gives us the foundation for everything that follows.

==================================================

IMPLICIT DENY: ACCESS STARTS DENIED ==================================================

The first rule is easy to remember:

By default, an AWS request is denied.

This is commonly called an implicit deny.

Suppose an IAM user has no applicable policy allowing:

s3:GetObject

and the user tries to retrieve an object.

The result is a denial because there is no applicable Allow.

There does not need to be a policy containing:

"Effect": "Deny"

for the request to fail.

This distinction matters.

Implicit deny means:

"I did not find an applicable permission allowing this request."

Explicit deny means:

"A policy specifically denies this request."

These are different authorization states.

A useful mental model is:

No applicable Allow ↓ Implicit Deny

Applicable Allow ↓ Continue evaluating other applicable controls

Applicable explicit Deny ↓ Final Deny

================================================== 2. EXPLICIT DENY OVERRIDES ALLOW

The most important rule in IAM policy evaluation is:

Explicit Deny overrides Allow.

Imagine an identity-based policy allows:

{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket/*" }

A second applicable policy contains:

{ "Effect": "Deny", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket/private/*" }

A request for an object under the private path can match both statements.

The Allow does not win because it appears first or because it is broader.

The explicit Deny wins.

Think of the decision as:

ALLOW + ALLOW + DENY

DENY

This rule is extremely important during security research.

Finding a broad Allow is not enough to establish effective access when other applicable policies may contain Deny statements.

================================================== 3. IDENTITY-BASED POLICIES AND RESOURCE-BASED POLICIES

AWS commonly uses two major categories of permission policies:

Identity-based policies

These are attached to identities such as:

IAM users
IAM groups
IAM roles

They describe what those identities can do.

Resource-based policies

These are attached to resources and describe which principals can access those resources and what they can do.

Examples include:

S3 bucket policies
IAM role trust policies
Certain service-specific resource policies

The important security lesson is that authorization is not always visible from the identity alone.

Suppose a user does not have an identity-based Allow for a particular S3 operation.

That does not automatically prove the user cannot access an S3 resource.

A resource-based policy may also be relevant.

For requests within the same AWS account, AWS evaluates permissions granted by identity-based and resource-based policies together. When these are the applicable permissions policies, an Allow in either policy type can authorize the request, subject to permissions boundaries, SCPs/RCPs, session policies, conditions, service-specific behavior, and explicit denies. The exact result can also depend on the principal type named by the resource-based policy.

This is one reason security researchers should inspect both sides of an authorization relationship when the service supports resource-based policies.

Do not stop at:

"The IAM user policy does not contain this action."

Ask:

"Does a resource-based policy grant access to this principal?"

================================================== 4. THE INTERSECTION MODEL

Some policy types do not grant additional permissions. Instead, they establish a maximum boundary for what can be done.

This creates an intersection model.

For example, AWS IAM permissions boundaries limit the permissions that identity-based policies can grant to an IAM user or role.

Imagine the identity-based policy allows:

A = {s3:GetObject, s3:PutObject, s3:DeleteObject}

and the permissions boundary allows:

B = {s3:GetObject, s3:PutObject}

The effective identity permissions are constrained by the intersection:

A ∩ B

Result:

{s3:GetObject, s3:PutObject}

The identity-based policy contains DeleteObject, but the boundary prevents that permission from becoming effective through the identity-based policy.

This is why the following statement is incomplete:

"The role has s3:DeleteObject, therefore it can delete objects."

A better conclusion is:

"The identity-based policy grants s3:DeleteObject; effective access still depends on the other applicable policy controls and request context."

That is the language of a careful security assessment.

================================================== 5. PERMISSIONS BOUNDARIES

A permissions boundary is an advanced IAM control that sets the maximum permissions an identity-based policy can grant to an IAM user or role.

A boundary is not itself a normal grant of permissions.

This distinction is critical.

Consider:

Identity-based policy:

Allow s3:GetObject s3:PutObject s3:DeleteObject

Permissions boundary:

Allow s3:GetObject

The effective permissions granted through the identity-based policy are constrained to what the boundary permits.

From a research perspective, this creates an important verification step.

When you find a highly privileged identity-based policy, inspect whether a permissions boundary exists before concluding that the privilege is effective.

The same reasoning applies in the opposite direction.

Removing or weakening a permissions boundary can change the effective permissions of an identity if its identity-based policies already grant those capabilities.

That relationship becomes especially important later when we study IAM privilege escalation.

================================================== 6. AWS ORGANIZATIONS SERVICE CONTROL POLICIES

AWS Organizations service control policies, commonly called SCPs, can act as organization-level permission guardrails.

An SCP does not grant permissions to an IAM identity.

Instead, it can limit the maximum permissions available to IAM users and roles in accounts within an AWS Organization.

Consider a simplified example.

Identity-based policy:

Allow s3:*

SCP: an applicable policy whose allowed set includes only:

s3:GetObject s3:ListBucket

The SCP is a limiting control, not a permission grant. The identity-based policy still has to grant the requested action.

The identity-based policy alone looks extremely broad.

But the effective permission set is constrained by the applicable organizational control.

This produces another intersection-style relationship.

Identity permissions ∩ SCP permissions

Effective permissions, subject to other applicable controls

An SCP can therefore explain why an apparently powerful identity cannot perform an operation that its identity-based policy appears to allow.

For a researcher working inside an organization, this is a major reason why policy documents should not be interpreted in isolation.

================================================== 7. RESOURCE CONTROL POLICIES

AWS Organizations also supports resource control policies, or RCPs, for supported AWS services.

RCPs are resource-oriented organizational controls. For supported services, they establish the maximum available permissions for resources in member accounts within an organization. An RCP does not itself grant access; an applicable identity-based or resource-based policy must still provide the permission.

The important learning point for this article is not to memorize every RCP detail.

Instead, understand the larger model:

AWS authorization can include controls attached to identities, resources, sessions, and organizational boundaries.

Therefore:

"I found an Allow"

is not equivalent to:

"The request will succeed."

RCP behavior and service support should be checked against current AWS documentation when analyzing a specific environment.

================================================== 8. SESSION POLICIES

Session policies apply to temporary sessions created for IAM roles or federated users.

They can further restrict the permissions available to the resulting session.

Imagine a role has an identity-based policy that allows:

s3:GetObject s3:PutObject s3:DeleteObject

A session is created with a session policy that only permits:

s3:GetObject

The session cannot simply use all of the role's identity-based permissions.

The session policy constrains the session's effective permissions.

This becomes particularly relevant when analyzing temporary credentials.

A researcher may identify a role with broad permissions and later obtain temporary credentials for a session. The existence of the role's broad policy does not by itself prove that every session created from it has identical effective permissions.

The actual session context matters.

================================================== 9. THE REQUEST CONTEXT MATTERS

IAM policy evaluation is not performed against an abstract action name alone.

AWS evaluates the request in context.

That context can include information such as:

The principal making the request
The requested action
The target resource
The AWS account involved
The Region where relevant
Source information
Authentication information
Request-specific condition keys
Existing session information
Applicable policy controls

This is why Conditions are so important.

For example, a policy might allow an action only when a request satisfies a condition involving:

Source IP
Principal tags
Requested Region
Secure transport
MFA-related context
Specific AWS service context

The same Action may therefore be allowed in one request context and denied in another.

A researcher should ask:

"Under exactly what request conditions does this policy statement apply?"

not simply:

"Does this policy contain the action?"

================================================== 10. A SIMPLE SINGLE-ACCOUNT EXAMPLE

Consider a hypothetical IAM role called:

ResearchRole

Its identity-based policy allows:

{ "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::research-data/*" }

A researcher wants to upload an object.

The request is:

s3:PutObject

Target:

arn:aws:s3:::research-data/test.txt

At the identity-policy level, the request appears to match.

But the investigation is not finished.

The researcher should still ask:

Is there a permissions boundary?
Is the account governed by an applicable SCP?
Is there an applicable RCP?
Is the principal operating through a temporary session with a session policy?
Is there an explicit Deny?
Does the resource have an applicable policy?
Do the request conditions match?
Does the AWS service apply additional authorization requirements?

Only after considering the relevant controls can you confidently describe the effective authorization.

================================================== 11. SAME-ACCOUNT RESOURCE POLICY NUANCE

There is an important AWS-specific nuance that is easy to miss.

For same-account requests, resource-based policies can sometimes provide permissions in a way that is not equivalent to simply taking the intersection of identity-based permissions and resource-based permissions.

AWS documents different behavior depending on whether the resource-based policy grants access to:

An IAM user
An IAM role ARN
An assumed role session
A federated user session

For example, a resource-based policy that directly grants permissions to an IAM user or certain session principals can allow access despite an implicit deny in an identity-based policy, permissions boundary, or session policy in situations described by AWS's evaluation rules.

Role ARN and role-session behavior also differ.

This is one reason a simplified diagram such as:

Identity Policy + Resource Policy

Effective Access

should not be treated as the complete IAM algorithm.

The correct approach is:

Identify the principal type ↓ Identify the resource policy principal ↓ Identify identity/session/boundary controls ↓ Check explicit denies ↓ Apply AWS's documented evaluation rules

This detail will become increasingly useful when we study roles, STS, and cross-account access.

================================================== 12. CROSS-ACCOUNT REQUESTS ARE DIFFERENT

Cross-account access introduces another important requirement.

A permission granted in one account does not automatically create access to a resource in another account.

AWS's cross-account policy evaluation requires authorization on the relevant sides of the relationship.

A simplified conceptual model is:

Account A identity ↓ Identity-side authorization ↓ Cross-account relationship ↓ Account B resource authorization ↓ Final decision

The exact evaluation depends on the service and policy types involved.

This is intentionally only a foundation here.

The detailed mechanics of cross-account access and trust relationships belong later in the series, particularly Article 35.

For now, remember:

An IAM Allow in Account A does not automatically mean that Account A can access every resource in Account B.

================================================== 13. WHY ACCESSDENIED IS USEFUL EVIDENCE

Security researchers sometimes treat AccessDenied as a dead end.

It is often useful evidence.

Suppose you attempt an authorized API request and AWS returns an authorization error that identifies the principal and requested operation.

That result can provide evidence that:

The request reached an AWS service and an authorization decision was returned.
The identified principal was recognized for that request.
The requested operation was not authorized under the applicable policy context.

Do not generalize from a generic AccessDenied response beyond what the actual error and request establish.

Depending on the error, AWS may provide additional information about the reason for denial.

For example, AWS documents AccessDenied messages that identify explicit denies in permissions boundaries or session policies.

This can help you identify which control is limiting the request.

But be careful with the conclusion.

An AccessDenied response for one operation does not prove that the principal has no useful permissions.

Similarly, successful access to one resource does not prove broad access to the service.

Authorization is request-specific.

================================================== 14. SECURITY RESEARCHER WORKFLOW

When reviewing IAM permissions, use a structured process.

STEP 1 — Identify the principal

Determine whether you are dealing with:

IAM user
IAM role
Role session
Federated session
AWS service principal
Another principal type

STEP 2 — Identify the requested operation

Example:

s3:GetObject

STEP 3 — Identify the target resource

Example:

arn:aws:s3:::research-data/customer-record.json

STEP 4 — Find applicable identity-based policies

Check policies attached directly to the user or role and, for users, policies inherited through groups.

STEP 5 — Find applicable resource-based policies

Check whether the target service/resource supports them and whether they apply to the principal.

STEP 6 — Check conditions

Determine whether the request satisfies the relevant Condition blocks.

STEP 7 — Check permissions boundaries

If a boundary exists, determine whether it permits the requested action.

STEP 8 — Check organizational controls

Where applicable, inspect SCP/RCP constraints or work with the organization's administrator to understand them.

STEP 9 — Check session policies

For temporary sessions, determine whether a session policy constrains the request.

STEP 10 — Search for explicit Deny

One applicable explicit Deny can override an otherwise applicable Allow.

STEP 11 — Validate safely

If you are authorized to test the environment, perform the smallest safe request needed to establish whether the permission is effective.

STEP 12 — Determine impact

Do not stop at "allowed."

Ask what the principal can actually do with the permission and whether the resource contains security-sensitive data or functionality.

================================================== 15. FROM POLICY TO EFFECTIVE PERMISSION

Consider these two statements.

Statement A:

"The role has AdministratorAccess."

Statement B:

"The role's identity-based permissions include broad administrative actions, and no applicable boundary, organizational control, session restriction, or explicit deny was identified that prevents the tested operation."

Statement B is much stronger as a security assessment because it distinguishes a policy document from effective behavior.

This does not mean you always need to manually enumerate every policy before every statement.

It means the strength of your conclusion should match the evidence available.

A useful hierarchy is:

Policy statement discovered ↓ Potential permission identified ↓ Applicable policy context understood ↓ Effective permission established ↓ Operation safely validated ↓ Impact demonstrated

Each step increases confidence.

================================================== 16. COMMON RESEARCH MISTAKES

Mistake 1: Treating every Allow as effective access

Why it fails:

Other controls may constrain the permission.

Better approach:

Check the applicable evaluation context.

Mistake 2: Ignoring explicit Deny

Why it fails:

An applicable explicit Deny overrides an Allow.

Better approach:

Always consider Deny statements when determining effective access.

Mistake 3: Ignoring resource-based policies

Why it fails:

Some AWS services use resource-based authorization mechanisms that can materially affect access.

Better approach:

Inspect the resource side where supported.

Mistake 4: Treating a permissions boundary as a permission grant

Why it fails:

A permissions boundary defines a maximum for permissions granted through identity-based policies; it does not itself grant those permissions.

Better approach:

Separate granting policies from limiting controls.

Mistake 5: Assuming SCPs grant permissions

Why it fails:

SCPs act as organizational permission guardrails. They do not grant permissions to identities.

Better approach:

Treat them as an additional authorization boundary.

Mistake 6: Ignoring session policies

Why it fails:

Temporary sessions can have additional restrictions.

Better approach:

Include the session context when analyzing temporary credentials.

Mistake 7: Treating AccessDenied as proof that the identity has no useful access

Why it fails:

The denial applies to the specific request context.

Better approach:

Interpret the exact operation, resource, principal, and denial reason.

Mistake 8: Treating successful access to one resource as service-wide access

Why it fails:

AWS permissions are often resource- and condition-specific.

Better approach:

Test or analyze the exact scope of the permission.

================================================== 17. IAM POLICY EVALUATION AND PRIVILEGE ESCALATION

Policy evaluation becomes especially important when analyzing privilege escalation.

Suppose a low-privileged identity appears to have a sensitive IAM action.

A simplistic analysis might say:

"This is privilege escalation."

That is premature.

You still need to establish:

The action is actually allowed.
The required resource is accessible.
Required conditions can be satisfied.
The identity is allowed to invoke the operation.
Any target role or resource has the required trust or resource policy.
Boundaries or SCPs do not prevent the next step.
The resulting capability is actually more privileged.

This is why policy evaluation is a prerequisite for the later privilege-escalation articles.

A permission may look dangerous on paper but fail to produce the assumed attack path because another authorization control blocks it.

Conversely, a seemingly limited permission can become important when combined with another policy or resource relationship.

The researcher must prove the chain rather than infer it.

================================================== 18. A PRACTICAL AUTHORIZATION MATRIX

For serious assessments, it can help to build a small matrix.

Example:

Principal: ResearchRole Action: s3:GetObject Resource: arn:aws:s3:::research-data/*

Identity Allow: YES Resource Allow: UNKNOWN Permissions Boundary: YES — GetObject allowed SCP: UNKNOWN Session Policy: NONE KNOWN Explicit Deny: NONE FOUND Conditions: Match

Conclusion:

The identity-based policy supports the requested action, and the known boundary does not restrict it. Additional applicable controls still need to be considered before claiming effective access.

This style of note-taking is more useful than simply writing:

"S3 access found."

It preserves the reasoning behind the conclusion.

================================================== 19. AWS CLI AND POLICY RESEARCH

When an authorized AWS environment is available, the AWS CLI can help inspect the identity and IAM configuration.

For example:

aws sts get-caller-identity

This identifies the AWS identity associated with the credentials currently being used.

The result should be treated as environment-specific output. Never assume the exact account ID or ARN returned by a command.

To inspect IAM policies, the AWS CLI provides IAM commands for listing and retrieving policy information. The exact command required depends on whether you are examining a user, group, role, managed policy, or inline policy.

For policy simulation, AWS also provides IAM policy simulation APIs and CLI operations. These can help test whether a principal would be allowed or denied for specified actions and resources when you have the permissions and information required by the simulator.

A simulation result is useful evidence, but it should still be interpreted in the context of the actual request and service behavior.

No command output in this article is presented as personally observed output.

================================================== 20. LAB VALIDATION CANDIDATE

The core concepts in this article do not require an AWS account.

However, the following would be valuable to validate later in an authorized AWS lab.

LAB VALIDATION CANDIDATE 1 — IMPLICIT DENY

Objective:

Create an identity with no permission for a selected harmless read operation.

Verify:

The request is denied because there is no applicable Allow.

Evidence:

Policy configuration
Command used
AWS response
Identity context

LAB VALIDATION CANDIDATE 2 — EXPLICIT DENY

Objective:

Create an Allow for an operation and an applicable Deny for the same operation.

Verify:

The explicit Deny overrides the Allow.

LAB VALIDATION CANDIDATE 3 — PERMISSIONS BOUNDARY

Objective:

Create an identity-based policy that permits more actions than the attached permissions boundary.

Verify:

The boundary constrains the effective identity permissions.

LAB VALIDATION CANDIDATE 4 — RESOURCE-BASED POLICY

Objective:

Use a supported AWS resource policy to grant access and compare the result with identity-based authorization.

Verify:

How AWS evaluates the resource-based Allow for the chosen principal type.

LAB VALIDATION CANDIDATE 5 — SESSION POLICY

Objective:

Create a temporary role session with a restrictive session policy.

Verify:

The resulting session cannot use permissions outside the session's effective authorization.

LAB VALIDATION CANDIDATE 6 — ACCESS DENIED ANALYSIS

Objective:

Create a controlled denial scenario.

Verify:

Whether AWS identifies the relevant policy type or explicit deny in the returned authorization error.

These tests are not claimed as personally performed for this article.

They belong to the later Infinite Learning Lab Series.

================================================== 21. WHAT THIS MEANS FOR SECURITY REPORTING

Policy evaluation should change how findings are written.

Weak finding:

"Role has s3:* and can access all S3 data."

Why it is weak:

The statement assumes effective access and data exposure without proving the relevant authorization context or data access.

Stronger finding:

"The role's identity-based policy grants s3:* on Resource: *. The role also has [boundary/organizational/session/resource-policy context]. The tested s3:GetObject operation was [allowed/denied], and the accessible resource was [identified]."

The second version separates:

What was discovered
What policy says
What controls apply
What was actually validated
What impact was demonstrated

That distinction is central to responsible cloud security research.

================================================== 22. THE MENTAL MODEL TO REMEMBER

A useful simplified model is:

AWS REQUEST | v AUTHENTICATE | v REQUEST CONTEXT | v APPLICABLE POLICIES |

— — — — — + — — — — — + | | v v EXPLICIT DENY? ALLOW PATH? | | YES | YES| v v DENY Apply boundaries / organizational / session and resource controls | v FINAL DECISION /
ALLOW DENY

The exact AWS implementation is more detailed, but this model captures the key research lesson:

You need to understand the whole authorization context, not just one policy statement.

================================================== 23. HOW ARTICLE 8 CONNECTS TO THE SERIES

The progression so far is intentional.

ARTICLE 1 AWS Security Fundamentals ↓ ARTICLE 2 Accounts, Regions, Availability Zones & Resources ↓ ARTICLE 3 Shared Responsibility Model ↓ ARTICLE 4 AWS Attack Surface ↓ ARTICLE 5 AWS CLI Security Researcher Workflow ↓ ARTICLE 6 IAM Users, Groups, Roles & Policies ↓ ARTICLE 7 IAM Policy Structure ↓ ARTICLE 8 IAM Policy Evaluation Logic ↓ ARTICLE 9 Enumerating AWS Identity & Permissions ↓ ARTICLE 10 Managed vs Inline Policies ↓ ARTICLE 11 IAM Roles & Trust Policies ↓ ARTICLE 12 STS & AssumeRole ↓ ARTICLE 13 IAM Access Analyzer ↓ ARTICLE 14 Finding Excessive IAM Permissions ↓ ARTICLE 15 iam:PassRole ↓ ARTICLE 16 IAM Privilege Escalation Paths

Article 7 taught us how to read an individual policy statement.

Article 8 teaches us why that statement is only one part of the authorization decision.

Article 9 will move from policy theory into the practical problem of identifying what an AWS identity can actually access and what permissions are available to it.

================================================== 24. WHAT THIS ARTICLE INTENTIONALLY DOES NOT COVER

To keep the learning sequence clean, this article does not deeply cover:

IAM role trust policies
AssumeRole mechanics
STS session creation in detail
IAM Access Analyzer
IAM privilege escalation techniques
iam:PassRole attack paths
Detailed cross-account trust relationships
S3 bucket policy analysis
EC2 instance-role abuse
Lambda execution-role abuse

Those subjects have dedicated articles later in the series.

================================================== FINAL TAKEAWAY

IAM authorization is not a simple question of whether a JSON document contains Allow.

A request is evaluated in context.

The essential rules are:

Requests are denied by default.
An applicable Allow is required for the request to succeed.
An explicit Deny overrides an Allow.
Identity-based and resource-based policies can both participate in authorization.
Permissions boundaries can restrict what identity-based policies can grant.
AWS Organizations SCPs can constrain permissions at the organization/account level.
RCPs can impose resource-oriented organizational limits for supported services.
Session policies can restrict temporary sessions.
Conditions can make authorization depend on the request context.
Same-account resource-based policy behavior can differ depending on the principal type.
Cross-account authorization requires additional consideration and is not established merely by finding an Allow in one account.
A discovered permission is not the same thing as demonstrated impact.

For a security researcher, the most useful question is therefore not:

"Does this policy look powerful?"

It is:

"Given this principal, this action, this resource, this request context, and all applicable authorization controls, what can the principal actually do?"

That is the question that turns IAM policy reading into security analysis.

================================================== RESEARCH / TECHNICAL NOTE

This article was researched against current AWS documentation. The simplified diagrams and set-based examples are teaching models, not a complete representation of AWS enforcement internals.

Primary AWS sources:

AWS IAM — Policy evaluation logic https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
AWS IAM — How AWS enforcement code logic evaluates requests to allow or deny access https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html
AWS IAM — Access management for AWS resources https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html
AWS IAM — Policies and permissions https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
AWS IAM — Difference between explicit and implicit denies https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.html
AWS IAM — Cross-account policy evaluation logic https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html
AWS IAM — Troubleshoot AccessDenied errors https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_access-denied.html