Least privilege service identities
Diagnose Access denied before attaching an administrator policy
Identify the actual principal, action and target. A narrow correction is possible only after the failed operation is understood.
In this article
Confirm the runtime identity
Find the principal used by the failing workload through the platform's supported identity and audit tools. Compare it with the intended role and environment.
Check for accidental fallback to an old credential or a different deployment identity. An application configuration error can look like a missing permission while the correct role already has the required access.
Collect the action, resource and relevant request context without copying credentials into tickets or logs.
Evaluate the full policy context
Review the identity policy, resource policy and applicable organisational or session constraints using the provider's documented rules. An explicit restriction elsewhere may explain why adding another allow has no effect.
Verify the resource identifier and condition values. A request aimed at the wrong region, account or prefix should not be fixed by broadening the role to every resource.
For a synthetic report failure, an output path changes from reports/daily to reports/archive after a release. Determine whether that path change is intended before granting access to it.
Apply the smallest justified correction
Compare the operation with the approved permission matrix. If it is required, update the relevant scope and test the normal and prohibited paths. If it is unexpected, fix the application or investigate the behaviour.
Use the established emergency access process when an incident requires temporary broader authority. Record the owner and removal condition rather than leaving a permanent administrator attachment behind.
Remember policy propagation and credential behaviour when verifying the change. Follow the provider's supported procedure instead of repeatedly stacking grants while waiting for a result.
Confirm recovery and remove temporary access
Run the affected business workflow under the intended principal and verify its output. Check that unrelated access remains denied.
Remove any incident-only permission and record the final policy version. Review queued or partially completed work so recovery does not duplicate a report or leave an orphaned output.
Update the operation inventory and regression fixture if the incident revealed a legitimate missing path. The next operator should be able to explain the permission from the workload's purpose rather than from a past outage anecdote.
Primary sources
AWS: policy evaluation logicAWS: IAM security best practicesReferences checked 11 September 2026.