DynamoDB queries, scans and capacity: DVA-C03 study notes and practice questions
What to know about DynamoDB queries, scans and capacity for the DVA-C03 exam, from the Development with AWS Services domain (30% of the exam guide), then 1 free question to test it. Part of the DVA-C03 study guide.
Access questions describe a slow or throttled read, or a result that looks incomplete. The fix is usually a different call, a better key or a condition on the request, not more capacity.
Query and Scan
A Query reads items that share one partition key value, optionally with a sort key condition. It is the call to design for.
A Scan reads every item in the table or index, then returns the matches. Its cost grows with table size.
A large operation can use up a table’s read capacity and cause ProvisionedThroughputExceeded. Reduce the page size with Limit or run the job at a quiet time.
A parallel scan can help a large table (the official guidance starts at about 20 GB) when read capacity is unused. It can also starve other traffic.
Filters and projections
A FilterExpression removes items after they are read. The filtered items still use read capacity. A smaller response does not mean lower cost.
A ProjectionExpression limits which attributes come back. It does not reduce the read capacity used, because capacity is based on the size of the whole item.
To reduce capacity, change the key design, add a sort key condition, or use a GSI whose keys match the query.
Pagination
Each Query or Scan call returns at most 1 MB of data, read before any filter is applied. If the response has a LastEvaluatedKey, send another request with it as ExclusiveStartKey.
Reading only the first response returns a partial list. This is a common reason customers appear to have “missing” tickets or orders.
Batch and transactional calls
BatchGetItem reads up to 100 items by primary key, possibly across tables. Keys it can’t read come back in UnprocessedKeys, and your code must retry them. Ignoring them loses items while the call still returns HTTP 200.
TransactWriteItems writes up to 100 items as one all-or-nothing change. Use it when a booking and a seat count must change together.
How to choose
Scenario wording
Answer
Items for one customer, filtered by a non-key attribute, large result
Query on the partition key with a sort key or GSI
Nightly list of all orders for one warehouse across the table
Query a GSI keyed by warehouse, not a Scan
Two changes must both succeed or both fail
Transactions
Read cost must drop and slightly stale data is acceptable
Eventually consistent reads, which use half the capacity of strongly consistent reads
Common traps
Filter as a cost fix. It cuts the response, not the read capacity.
It runs a Query on the Tickets table with partition key CustomerId and a FilterExpression that keeps only items where Status is open, and it sets Limit to 25. The code reads only the first response.
Agents report that customers with hundreds of tickets are shown only a few open tickets, or none. The team wants every open ticket returned, and it wants the query to stay on the one customer's partition.
What should the developer change?
Choose one answer.
AA. Keep the Query, and loop on ExclusiveStartKey using each response's LastEvaluatedKey until that key is absent.
BB. Remove the FilterExpression, and filter the open tickets in the application from the first response alone.
CC. Raise Limit to 1,000 so that each response can hold more of the customer's open tickets before the code stops reading.
DD. Replace the Query with a Scan that uses the same FilterExpression, since a scan is not limited to one partition key value.
B. Wrong: The first response is still only one page of at most 1 MB, so later pages would be missed. Filtering in the application also moves more data across the network.
C. Wrong: Limit caps how many items are read per page, and the page is still capped at 1 MB. A page can still contain no open tickets at all.
D. Wrong: A scan is paginated in the same way, and it reads every partition. It would be slower and cost more, and it would not stay on one customer.
Explanation
DynamoDB returns at most 1 MB per request, and Limit and the page cap are applied before the FilterExpression. A page can therefore contain no matching items and still carry a LastEvaluatedKey. The code must keep requesting pages until LastEvaluatedKey is absent.
Want more on DynamoDB queries, scans and capacity? The 5 full-length practice sets have 8 more DynamoDB queries, scans and capacity questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →