Within one municipal permit partition key, clerks need items sorted either by create-date or by fee-amount without copying the table. Which DynamoDB feature fits?
Select an answer to reveal the explanation.
Short Explanation
Same neighborhood (partition), different street sort—by date or by fee. An LSI keeps the same partition key and gives you another sort key so you don’t clone the whole table.
Full Explanation
When clerks stay inside one municipal permit’s partition key but need a different sort order—create-date versus fee-amount—a local secondary index is the purpose-built answer. An LSI shares the base table’s partition key and supplies an alternate sort key, so you Query the same partition with fee-amount ordering without copying the table or inventing a new partition scheme. That matches “same neighborhood, different street sort” without a full redesign.
A GSI that makes fee-amount alone the partition key changes the access pattern entirely and is a poor fit when the requirement is alternate ordering within an existing partition, not a new cross-partition lookup by fee. S3 Select over exported JSON is analytics over a snapshot, not an online alternate sort key on live DynamoDB items. DAX accelerates reads with a cache; it does not define secondary sort keys or change how items are ordered in the table.
Exam caveat: LSIs must be defined at table creation time and count against the per-table index limits; if the table already exists without an LSI, you may need a GSI or a table rebuild—know that constraint on the exam. Operational check: Query the LSI for one permit partition sorted by fee-amount, compare item set membership to the base table Query by create-date, and confirm both return the same logical items without Scan.