County inspectors must filter field jobs by status and district without table scans. Status alone has only a few values. Which DynamoDB design best supports that query?
Select an answer to reveal the explanation.
Short Explanation
Status by itself is like labeling every open job “Open”—you pile the whole county into one hot shelf. Combine district (or district+status) into the GSI partition key so queries stay targeted and partitions stay balanced.
Full Explanation
Inspectors need Query-friendly filters on status and district without burning capacity on full-table Scans. A global secondary index whose partition key combines district with status (or uses district alone with status as sort key) keeps each query targeted to a balanced partition while supporting the ordering the field team needs. Spreading work across districts avoids concentrating every Open job into one hot partition, which is the classic failure mode of a status-only key.
Scanning the base table and filtering in application code works functionally but wastes read capacity, increases latency, and scales poorly as the county’s job history grows—exactly what the stem rules out. Making status the sole base-table partition key collapses low-cardinality values into few partitions and creates throttling risk during busy seasons. DynamoDB Streams capture item-level change events for downstream processors; they are not an ad-hoc query API for “find all Open jobs in District 4.”
Exam caveat: GSIs cost extra write capacity and storage, and eventual consistency on GSI reads is the default—design for that lag if inspectors expect immediate visibility after status flips. Operational check: load a representative mix of district/status combinations, Query the GSI for one district+status, verify no Scan appears in metrics, and watch for hot-partition throttling when status alone would have been the key.