Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in knowing when to use Global vs Local Secondary Indexes. In production, this is about knowing exactly how partition keys and sort keys affect query efficiency and scalability in DynamoDB. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechVibe Inc., an online marketplace platform, manages user-generated product reviews stored in an Amazon DynamoDB table named ProductReviews. Each review entry contains:
- A unique 16-digit Review ID (UUID)
- Product ID and User ID (both 16-digit UUIDs referencing other user and product tables)
- A Product Rating on a 1-to-5 scale
- An optional text comment from the reviewer
The table’s primary key is the Review ID (partition key).
The development team needs to efficiently retrieve the top 10 highest-rated reviews for a specific product.
The Requirement: #
Which DynamoDB index configuration will provide the fastest response time for querying the 10 reviews with the highest rating for a given product?
The Options #
- A) A Global Secondary Index (GSI) with Product ID as the partition key and Product Rating as the sort key
- B) A Global Secondary Index (GSI) with Product ID as the partition key and Review ID as the sort key
- C) A Local Secondary Index (LSI) with Product ID as the partition key and Product Rating as the sort key
- D) A Local Secondary Index (LSI) with Review ID as the partition key and Product ID as the sort key
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
- For developers, understanding the difference between GSI and LSI is paramount because LSIs require the same partition key as the base table and are limited to 10 GB per partition key, which often restricts scale.
- GSIs allow querying efficiently across different partition keys — here, Product ID — enabling fast retrieval of the top ratings sorted within that product context.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
The table’s partition key is Review ID, so queries filtering by Product ID cannot be efficiently served by the base table.
-
Index choice: The requirement is to query by product and sort by rating, retrieving top reviews by rating for a product.
-
Why a GSI with Product ID as partition key?
GSIs let you define an entirely different partition key than the base table—in this case, Product ID—so you can efficiently query all reviews per product. -
Sort key on Product Rating:
Sorting by rating on the GSI allows you to use Query APIs withScanIndexForwardset tofalseto get highest ratings first, limiting results to 10. -
Why not an LSI?
LSIs share the base table’s partition key (Review ID), making it unsuitable for querying by Product ID. LSIs work only when querying by the same partition key as the base table. -
Storage limits:
LSIs have a 10 GB limit per partition key, which is a serious bottleneck for high-traffic ecommerce apps.
The Trap (Distractor Analysis) #
- Option B: Using Review ID as the sort key on the GSI limits the ability to sort by rating; you want sorting on Product Rating, not Review ID.
- Option C: LSI requires the same partition key as the base table (Review ID), so cannot do queries using Product ID as a partition key; plus, LSIs can’t be created after table creation if data volume is large.
- Option D: An LSI with Review ID partition key and Product ID sort key is invalid usage—the partition key must match the base table’s.
The Technical Blueprint #
Developer CLI snippet for creating the GSI #
aws dynamodb update-table \
--table-name ProductReviews \
--attribute-definitions AttributeName=ProductID,AttributeType=S AttributeName=ProductRating,AttributeType=N \
--global-secondary-index-updates '[{"Create":{"IndexName":"ProductRatingIndex","KeySchema":[{"AttributeName":"ProductID","KeyType":"HASH"},{"AttributeName":"ProductRating","KeyType":"RANGE"}],"Projection":{"ProjectionType":"ALL"},"ProvisionedThroughput":{"ReadCapacityUnits":5,"WriteCapacityUnits":5}}}]'
The Comparative Analysis #
| Option | Index Type | Partition Key | Sort Key | Performance for Query | Use Case |
|---|---|---|---|---|---|
| A | GSI | Product ID | Product Rating | Fastest; allows direct query by product, sorting by rating | Best for filtering/sorting by attributes different from base key |
| B | GSI | Product ID | Review ID | Can query by product but no rating sort; slower for top ratings | Less suitable for sorting by rating |
| C | LSI | Review ID | Product Rating | Queries must include Review ID; cannot filter by product only | Invalid for this use case |
| D | LSI | Review ID | Product ID | Partition key mismatch; invalid | Does not support required query pattern |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick Global Secondary Index (GSI) when you need to query with a partition key different from the base table’s.
Real World #
In production, LSIs have niche use cases due to their size limits and must be designed upfront when table size is predictable. GSIs offer flexible, scalable query patterns.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.