Developers report an EC2 application role gets AccessDenied when calling kms:Decrypt, though the identity policy allows it. The role was recently refactored with SCPs and permission boundaries. Which authorization analysis method pinpoints the cause of the failure?

The correct method is right because KMS authorization requires the intersection of identity policy, KMS key policy, service control policies, and permissions boundaries, and only simulation evaluates that full effective set with context keys and resource ARN to reveal an implicit deny or missing allow outside the identity policy that already permits the action. Validating the identity policy with analyzer checks fails by concept because it only confirms syntax and existing allow already stated in the scenario and cannot model hierarchical guardrails that can still deny. Inspecting the KMS key policy fails by concept because although KMS requires resource policy authorization, reviewing that document in isolation does not test whether organization controls or boundaries narrow the role. Searching CloudTrail history fails by concept because logging establishes who called what and when with error codes but does not compute policy evaluation logic to pinpoint which statement blocked access. A common exam caveat is to distinguish logging or single-policy review from evaluation, since questions mentioning SCPs plus boundaries signal a need for effective-permissions simulation rather than event confirmation. As a practical check, rerun simulation for the exact role, action kms:Decrypt, target key ARN, and applicable SCP and boundary ARNs with relevant condition context, then correct the overly restrictive guardrail or add explicit allow and retest with a least-privilege call.