Why is this AWS request allowed or denied?

Start with one concrete request: who is calling, which action they want, which resource they want to use, and what context applies. For example: an assumed role session requests s3:GetObject on one object while using MFA from an approved network.

Authentication proves who the caller is. Authorization decides whether that caller may perform this action on this resource. Signing in with MFA can satisfy a policy condition, but MFA does not create permission by itself.

Begin from implicit deny: the request is denied unless a matching allow exists. Protect the account root user with MFA, avoid root access keys, and use attributable temporary sessions for routine work.

Write the resource precisely. An Amazon Resource Name, or ARN, identifies the requested AWS resource. A bucket ARN and an object ARN are different targets, and a policy that names one does not automatically match the other. Conditions can narrow the request further by network, time, tags, MFA, or other context.

This short request statement prevents guesswork. “The role cannot use S3” is too broad to diagnose. “This role session cannot call s3:GetObject on this object from this context” gives you a request that can be compared with policy statements one field at a time.

A policy statement matters only when its action, resource, principal where required, and conditions match the request. A matching allow can grant access, but only inside every applicable permission ceiling.

A permissions boundary, session policy, or service control policy does not grant access. It limits what another policy may grant. Think of a boundary as the outside edge of a drawing: an identity policy can allow only what remains inside that edge.

An applicable explicit deny wins over every allow. If no allow survives the relevant limits, the result remains denied. Resource policies add another possible allow path, and their exact behavior depends on the account and whether they name a user, role, or role-session principal. Record the full principal ARN before using an advanced exception.

Identity policies are attached to a user, group, or role and describe what that identity may do. Resource policies are attached to supported resources and describe which principals may use them. Cross-account access often needs authorization from both the caller side and the resource side.

Evaluate the request, not the policy name. A policy called ReadOnly might still omit the exact object, and a policy called Admin cannot overcome a deny. List matching statements in a small table, then apply permission ceilings and explicit denies before deciding the final result.

When access is denied, classify each relevant statement by policy type and effect. Then name the first deciding cause: missing allow, permissions boundary, session policy, organization ceiling, resource policy, or explicit deny.

Adding AdministratorAccess is not a useful diagnosis. It cannot override an explicit deny or a permissions ceiling, and it grants unrelated actions. Change only the missing action, resource, principal, or condition in the layer that actually decided the request.

After the change, test the intended action and nearby actions that must remain denied. IAM Access Analyzer can find external access and help refine permissions from activity, but it cannot know your business intent. Keep the normalized request and negative tests so another person can reproduce the answer.

For an object-read repair, test the intended object, another object in the same prefix, a neighboring forbidden prefix, and a write action. The positive case proves useful access. The negative cases prove that the repair did not silently grant a larger resource range or a more powerful action.

If the caller changes from a role ARN to an assumed-role session ARN, run the evaluation again. Those principal forms can follow different resource-policy branches. Reusing an old conclusion without the exact account and principal form is not a shortcut; it is a different request.