Before shipping, a developer checks whether an IAM policy that allows dynamodb:Query only on a table ARN also covers Query calls that target a global secondary index. What should they understand?
Select an answer to reveal the explanation.
Short Explanation
Querying a GSI is a different door than querying the base table—IAM often wants the index ARN on the resource list. A table-only ARN can leave index Query denied. GSIs are not an S3 API.
Full Explanation
IAM authorization for DynamoDB Query is resource-sensitive. Query calls that target a global secondary index generally require the index ARN—or other appropriate resource coverage—in the policy, not only the base table ARN. A developer who allows dynamodb:Query solely on the table ARN may see AccessDenied when the SDK queries a GSI, even though equivalent Queries against the base table succeed. Ship policies that list both table and index ARNs used by the case or tax access patterns.
Assuming any table ARN automatically authorizes every index operation is a common false belief on the exam. DynamoDB indexes do appear as distinct ARNs in IAM Resource elements. GSIs are not queried with s3:GetObject; inventing an S3 permission requirement for DynamoDB indexes is incorrect.
Exam caveat: use precise ARNs for known indexes or carefully constrained resource patterns that cover indexes without granting unrelated tables in the account. Operational check: apply a policy with only the table ARN, Query the base table (success) and the GSI (expect AccessDenied); add the index ARN and confirm the GSI Query succeeds on the same municipal access path before production release. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.