A developer assumes a cross-account role and receives AccessDenied on dynamodb:Query, and the team must determine whether the identity policy, SCP, or resource policy caused the denial without changing permissions. Which diagnostic approach pinpoints the authorization failure cause?
Select an answer to reveal the explanation.
Short Explanation
You've hit a denial, and you don't want to guess which policy blocked you. Your Policy Simulator check reruns the role's call like instant replay so you'll see exactly where it got stopped.
Full Explanation
The correct approach reproduces the exact dynamodb:Query with the assumed role context in IAM Policy Simulator and supplements it with IAM Access Analyzer policy checks, which together evaluate identity allows, explicit denies, resource context and condition keys without changing permissions and can differentiate missing identity allow from resource-policy and SCP effects, whereas querying CloudTrail logs to correlate session ARN, time and error code is essential for scoping the incident but remains forensic rather than evaluative because logs prove the denial happened yet cannot simulate which policy type denied it, examining only the role identity policy and permission boundaries is sound least-privilege triage but fails completeness because cross-account Query needs identity allow plus resource allow plus no SCP deny, so an identity-only view cannot exclude the other two causes, similarly reviewing only the table resource policy and trust policy validates the resource side but ignores identity and organizational controls and therefore cannot pinpoint the source, with the exam caveat that implicit deny from a missing allow looks identical to explicit deny in the API error and requires checking all policy layers, and the practical check is to rerun simulation with exact table ARN, kms condition keys and session tags from CloudTrail to avoid false conclusions from mismatched context.