Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in knowing when to properly use Global Secondary Indexes (GSIs) versus Local Secondary Indexes (LSIs). In production, this is about understanding DynamoDB’s indexing constraints, partition key design, and how queries perform when switching from primary key lookups to attribute-based queries. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
SoftNest Technologies runs an e-commerce platform where product orders are tracked using an Amazon DynamoDB table named Orders. This table is designed with a single primary partition key: orderId. There is no sort key currently defined.
The engineering team wants to introduce a new feature that allows querying the orders by customerId, which is an attribute in the existing items but not part of the table’s primary key structure.
The Requirement: #
Determine the best way to enable querying the Orders table by customerId without impacting existing access patterns.
The Options #
- A) Modify the main table’s primary key schema by adding
customerIdas the sort key alongsideorderId. - B) Create a new global secondary index (GSI) on the table with
customerIdas the partition key. - C) Create a new local secondary index (LSI) on the table with
customerIdas the partition key. - D) Create a new local secondary index (LSI) on the table with
orderIdas the partition key andcustomerIdas the sort key.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Imperative #
- For Developers: GSIs allow querying on a non-key attribute with a new partition key. LSIs require the same partition key as the base table — you cannot create LSIs on a different partition key.
- Attempting to change the primary key on a live table requires table rebuild/migration.
- GSIs are flexible and scalable for attribute-based queries like
customerId.
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 B
The Winning Logic #
In DynamoDB, querying by an attribute that is not part of the primary key or sort key requires a secondary index. There are two main types:
- Local Secondary Index (LSI): Can only be created at table creation with the same partition key and a different sort key. Cannot use a different partition key.
- Global Secondary Index (GSI): Can be created on any attribute(s) as partition and optional sort key, and can be added after table creation.
Since customerId is not part of the primary key and the team wants to query by it independently, creating a GSI with customerId as the partition key is the correct option. This allows fast, scalable queries by customer without changing the base table.
The Trap (Distractor Analysis): #
- Why not A? Changing the primary key requires table rebuild, data migration, and downtime — highly impractical for a live production table.
- Why not C? LSIs must share the same partition key as the base table. Defining a different partition key (
customerId) on LSI is invalid. - Why not D? LSIs must have the same partition key as the base table (
orderId). UsingcustomerIdas sort key is valid but does not support query patterns wherecustomerIdis the partition key.
The Technical Blueprint #
# Create a Global Secondary Index on 'customerId'
aws dynamodb update-table \
--table-name Orders \
--attribute-definitions AttributeName=customerId,AttributeType=S \
--global-secondary-index-updates '[{"Create":{"IndexName":"CustomerIdIndex","KeySchema":[{"AttributeName":"customerId","KeyType":"HASH"}],"Projection":{"ProjectionType":"ALL"},"ProvisionedThroughput":{"ReadCapacityUnits":5,"WriteCapacityUnits":5}}}]'
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | High (table rebuild) | Potentially best for order+customer queries, but high operational cost | Rarely advisable for live tables |
| B | Moderate (GSI creation) | Efficient querying by customerId, scalable | Best for adding new access patterns dynamically |
| C | Invalid API call / not allowed | N/A | Cannot create LSI with different partition key |
| D | Allowed but limited | Useful if querying by orderId and filtering by customerId | Does not satisfy requirement to query by customerId alone |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick a Global Secondary Index (GSI) when you need to query by a non-key attribute that requires a different partition key.
Real World #
In production, you might use GSIs with projections and provisioned throughput tuned for your query load. You might also consider cache layers like DynamoDB Accelerator (DAX) if read latency is critical.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.