5.2.4. Analyzing Authorization Failures
First Principle: Authorization failures in AWS produce specific error messages and are recorded in CloudTrail. The fastest path to diagnosis is checking the error code, then systematically evaluating each policy layer that could cause the denial.
IAM Policy Simulator:
- Test IAM policies without making actual API calls
- Simulate "what would happen if identity X tried action Y on resource Z?"
- Shows whether the result is Allow or Deny, and which policy caused it
- Use case: verify policy changes before deploying them
IAM Access Analyzer:
- Policy validation: Check policies for errors, security warnings, and best-practice violations
- External access: Identify resources shared with external entities (accounts, organizations)
- Unused access: Find unused roles, access keys, and permissions
- Policy generation: Generate least-privilege policies based on CloudTrail access patterns
Troubleshooting Authorization Denials:
| Error Message | Meaning | Check |
|---|---|---|
AccessDenied | No Allow or explicit Deny | Identity policy, resource policy, SCP |
AccessDeniedException | Service-specific denial | Service-level permissions (KMS key policy, S3 bucket policy) |
UnauthorizedAccess | Not authorized for this specific action | Permission boundary, session policy |
Systematic Diagnosis:
- Check CloudTrail for the exact error event
- Check SCPs — does the organization allow this action?
- Check permissions boundaries — does the boundary include this action?
- Check identity policies — does the role/user have an Allow?
- Check resource policies — does the resource allow access from this principal?
- Check session policies — was the session scoped down?
- Check for explicit Deny in ANY layer
⚠️ Exam Trap: Access Analyzer's "unused access" feature is the recommended tool for implementing least privilege over time: deploy broad initial access, then use Access Analyzer to identify and remove unused permissions based on actual usage.
Scenario: A Lambda function suddenly can't write to a DynamoDB table after an account-level SCP change. The function's execution role has the correct permissions, but the new SCP restricts DynamoDB access to specific table name patterns. Access Analyzer identifies the SCP as the blocking policy.
Reflection Question: Why must authorization troubleshooting check ALL policy layers systematically, and why is the SCP layer often the most overlooked?
