DVA-C02 Troubleshooting and Optimization Practice Question

A developer is optimizing a DynamoDB table for a gaming leaderboard. The table stores player scores and is read-heavy. Queries often fetch the top 10 scores. Which indexing strategy best reduces RCU consumption?

⚠ Common exam trap

A common mix-up: candidates confuse local secondary indexes (LSIs) with global secondary indexes (GSIs), not realizing that LSIs are tied to the base table's partition key and cannot efficiently retrieve global top scores across all partitions.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a global secondary index with score as the sort key.

A global secondary index (GSI) with score as the sort key allows efficient retrieval of the top 10 scores by querying the index in descending order, reading only the required items. This minimizes read capacity unit (RCU) consumption compared to scanning the base table, as each query reads exactly 10 items (or fewer) rather than consuming RCUs for a full table scan or filtering large result sets.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Create a sparse index on player ID.
Why it's wrong here
A sparse index is only created for items where the indexed attribute exists. If 'player ID' is a primary key or a mandatory attribute for all player items, an index on it would not be sparse. More critically, indexing 'player ID' does not facilitate querying for "top scores" across all players, as 'player ID' provides no ordering information relevant to scores. This approach would not optimize the desired leaderboard query.
✗
Use a local secondary index on score.
Why it's wrong here
A Local Secondary Index (LSI) must share the same partition key as its base table and is limited to 10GB of data per partition key value. While an LSI can have 'score' as a sort key, querying for "top scores" across *all* players would still necessitate querying specific base table partition keys, or performing an inefficient scan. LSIs also share the base table's provisioned throughput, offering no independent scaling or RCU reduction for global leaderboard queries.
✗
Enable DynamoDB Accelerator (DAX) for caching.
Why it's wrong here
DynamoDB Accelerator (DAX) is an in-memory cache designed to significantly reduce read latency for frequently accessed data. While DAX can improve the performance of *repeated* leaderboard queries by serving cached results, it does not reduce the underlying Read Capacity Unit (RCU) consumption for the *initial* query to DynamoDB or for queries that do not benefit from caching. The primary goal of optimizing for "top scores" is efficient data retrieval, not just caching.
✓
Create a global secondary index with score as the sort key.
Why this is correct
A Global Secondary Index (GSI) has its own independent partition key and sort key, allowing for different access patterns than the base table. By creating a GSI with a common partition key (e.g., a static value like "LEADERBOARD") and 'score' as the sort key, all player scores can be grouped and efficiently queried. This enables a `Query` operation on the GSI, ordered by 'score' in descending order, to retrieve the top N results with minimal RCU consumption, scaling independently from the base table.

Go deeper

DVA-C02 Troubleshooting and Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question