An AccessDenied error means AWS evaluated a request and refused it. Adding broad administrator access hides the problem and creates risk. Start by reading what was denied.
1. Capture the full error
Keep the API or console message, the time, the account, the region, and the exact action you attempted. CloudTrail often shows the event name, the principal ARN, and whether an explicit deny or a missing allow blocked the call.
2. Identify the principal
Confirm whether the caller is an IAM user, an assumed role, a service role, or a federated identity. For EC2, Lambda, ECS and EKS workloads, check the instance or task role rather than your human console user. The wrong principal is a common reason “the policy looks fine” but still fails.
3. Separate explicit deny from missing allow
SCPs, permission boundaries, session policies and resource-based policies can deny a call even when an identity policy allows it. List the layers that apply to the principal and the resource. Fix the layer that is actually responsible instead of stacking another broad allow.
4. Grant the minimum action and resource
Add only the action and resource ARN required for the task, then re-test the same operation. Prefer temporary elevated access in a break-glass role when you are investigating production, and remove it when the ticket is done.
A useful next step: write the denied action, the principal ARN, and one sentence naming the policy layer you believe blocked it. That record shortens any support session dramatically.
What to bring to a support session
A redacted AccessDenied message, the intended action, and whether the caller is a human user or a workload role. Never share access keys or temporary credentials.
Official references
Published 3 November 2026. Check changes against your own environment and your team’s process.