A DynamoDB table's primary key is composed of a product identifier and an order date. Items must also be queried by customer identifier sorted by order date, which the primary key cannot serve. What is the native DynamoDB solution?
Show answer and explanation
Answer: B
A global secondary index defines an entirely new key layout over the same items, so indexing on customer with the order date as sort key lets the access pattern run as a fast, targeted query returning items already sorted by date. The index projects only the attributes the pattern needs, keeping the read cost proportional to the result set.
Because GSIs can be added or changed over time, they are also the flexible answer to evolving access patterns on a live table.
Why the other options are wrong
- A. A scan reads every item in the table and applies the filter afterward, so cost grows with table size no matter how few items match; it is proportional to the whole table, not the result.
- C. A local secondary index must share the base table's partition key, so items would still be grouped by product, and it can never answer queries keyed on the customer identifier.
- D. A hand-maintained duplicate table forces the application to keep two writes in sync and pay double the storage and write capacity, all to reproduce what an index does natively.
Exam tip. GSI freedom: any new partition and sort key over existing items. LSI restriction: the base table's partition key only, with an alternate sort key, and it must be created with the table.