Cloud IAM policy evaluation: effective permissions and explicit denies
Trace an AWS authorization decision across identity, resource, session and organization policies. Diagnose a denied request without assuming another Allow overrides a restrictive boundary.
TL;DR: Evaluate the exact principal, action, resource and request context across applicable policies. An explicit deny overrides an allow, and permission-limiting policies do not grant access by themselves. Resource-policy behavior also depends on the principal and service involved.
Begin with the request identity
A console user, IAM role and assumed-role session are related but distinct authorization principals. Record the actual identity making the failed request. An engineer inspecting a role's policy may overlook that the running job assumed a different role or received a restrictive session policy.
Next identify the API action and resource ARN, including any secondary resources or encryption keys involved. “Upload failed” can represent several API calls with different permissions. Capture the service error and request identifier before editing policy.
AWS's policy evaluation overview describes how policy types combine. Its detailed evaluation logic explains principal-specific resource-policy behavior that simple union/intersection diagrams often omit.
Different policy types serve different purposes
| Policy type | Main role | Mistake to avoid |
|---|---|---|
| Identity policy | Grant actions to an identity within applicable limits | Assuming it is the only relevant policy |
| Resource policy | Specify access at a supported resource | Ignoring account and principal-type behavior |
| Permissions boundary | Limit an identity's effective permissions in its applicable model | Treating the boundary as a grant |
| Session policy | Restrict a particular session | Inspecting only the parent role policy |
| Organization control policy | Apply organization-level limits to covered accounts/resources | Expecting it to create permissions |
| Endpoint or service-specific policy | Add controls on a particular access path | Ignoring the path used by the failing request |
A same-account resource grant to a session principal can behave differently from a grant to a role ARN. Do not claim every policy type always intersects identically. Use the provider's documented evaluation for the actual request.
This is a diagnostic outline, not a complete replacement for AWS's policy evaluator. Resource policies and service-specific checks require the detailed rules above.
Worked denial: the role already has Allow
Suppose a deployment job can write to a staging bucket but receives AccessDenied against a production bucket. The role's identity policy appears to allow the upload. First confirm the job's assumed-role identity and the exact target ARN.
The investigation might find an organization policy denying writes outside approved regions, a bucket-policy condition requiring a particular network path, or missing access to the key used for encryption. These are alternative hypotheses, not a claim that all three occurred.
Adding another broad identity-policy Allow cannot override an applicable explicit deny. Repair the intended condition or obtain a reviewed policy change at the correct layer. If the bucket requires an approved endpoint, sending the request through that path may be the architectural fix; deleting the bucket's restriction is a different security decision.
After the repair, test the intended upload and a denied case outside its scope. Preserve the policy diff and sanitized request evidence. A successful broad administrator test does not prove the deployment role has a correctly bounded permission set.
Conditions make context part of authorization
Policies can depend on tags, organization membership, source context, authentication properties and other service-supported condition keys. Check which keys are actually present for the request. A condition copied from a user session may not apply as expected to a service-to-service call.
Workload federation adds a separate trust decision before the resource request. Successfully obtaining temporary credentials proves the exchange succeeded; it does not prove the resulting role can perform the desired API operation.
Use provider audit logs and policy-analysis tools where supported, while respecting their simulation limits. Some context or resource-policy behavior may need a controlled live authorization test. Never describe a simulator's result as proof of every possible service-side condition.
Landing-zone design places these permission decisions inside account boundaries, organization policies and enrollment scope.
Explain the smallest effective repair
Can an SCP grant a role access to a bucket? No. Organization control policies constrain covered access; an appropriate grant must still exist through the relevant permission model.
Why can the same role succeed from one path and fail from another? The request context or endpoint policy may differ. Trace the network path and policy conditions together.
What is the safest first response to AccessDenied? Capture the identity, action, resource and context, locate the rejecting layer, then make the smallest justified change. Broad administrator access destroys the evidence needed to verify the intended boundary.
CloudTrail investigation explains which audit records can support this reconstruction and why a missing search result requires a collection-scope check.