It wasn’t the query. It was the roles.
When you run mission-critical workloads on DynamoDB, database roles aren’t a side concern. They define what queries can run, where, and under which guardrails. Inconsistent permissions break automation. Over-permissive roles create silent security holes. The fastest way to fix both is to tie role design directly to the query runbooks your team actually uses.
A DynamoDB query runbook should do more than show you a few example commands. It must encode the real production logic: key schema expectations, index lookups, conditional expressions, throughput safety, and paging patterns. Without role-aware runbooks, developers test queries in one environment only to watch them fail in another.
The right process is simple but exact. First, define IAM roles for discrete query patterns: read-only, write-heavy, analytic reads from global secondary indexes, or admin-level scans for maintenance. Attach least-privilege permissions to each. Next, bind those roles to the runbooks. Do not allow ad-hoc queries outside their assigned role unless there’s a logged override. This keeps execution clean, predictable, and secure.