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 choosing the right type of DynamoDB secondary index to support multiple query access patterns efficiently without incurring performance penalties. In production, this is about knowing exactly when to use a Global Secondary Index (GSI) instead of a Local Secondary Index (LSI) or scanning. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechFlow Systems develops an order management platform that stores customer purchase orders in an Amazon DynamoDB table named OrdersTable. The table is keyed by customer_id as the partition key and order_id as the sort key, with an order_date attribute. Recently, a new requirement emerged to support queries that retrieve orders based on order_date and order_id, independent of the customer_id.
A new AWS Lambda function needs to be implemented to efficiently support this new access pattern.
The Requirement: #
Identify the MOST operationally efficient way for the developer to enable querying orders by order_date and order_id within the Lambda function.
The Options #
-
A) Add a new local secondary index (LSI) to the DynamoDB table that specifies
order_dateas the partition key andorder_idas the sort key. Write the Lambda function to query this new LSI. -
B) Write the Lambda function to perform a full table scan on
OrdersTable, and in the function code filter and combine the results byorder_dateandorder_id. -
C) Add a new global secondary index (GSI) to the DynamoDB table that specifies
order_dateas the partition key andorder_idas the sort key. Write the Lambda function to query this new GSI. -
D) Enable DynamoDB Streams on the table with both new and old images. Use the Lambda function to process the stream records and query DynamoDB Streams for
order_dateandorder_id.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Imperative #
DynamoDB GSIs allow you to define new partition and sort keys to efficiently support alternate access patterns, without the restrictions of LSIs or costly scans.
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 C
The Winning Logic #
-
DynamoDB local secondary indexes (LSIs) must use the original table’s partition key (
customer_id), so you cannot change the partition key toorder_datein an LSI. This automatically rules out Option A. -
Scanning the table (Option B) is highly inefficient and does not scale as data grows because it requires reading (and possibly filtering) the entire dataset, leading to higher latency and Lambda execution costs.
-
Using DynamoDB Streams (Option D) is intended for capturing change data and reacting to item-level changes, not for querying data patterns. You cannot query a DynamoDB Stream like a table or index.
-
A Global Secondary Index (GSI) allows a new partition key and sort key different from the table’s primary key — perfect for supporting queries by
order_dateandorder_id. It is the most operationally efficient and scalable approach for this new access pattern.
The Trap (Distractor Analysis): #
-
Why not Option A? LSIs share the same partition key as the base table. Trying to use
order_dateas a partition key in an LSI is invalid DynamoDB design. -
Why not Option B? Table scans can cripple your application as the size of
OrdersTablegrows, increasing cost and latency. -
Why not Option D? DynamoDB Streams are event-driven and not queryable for arbitrary access patterns. They serve a different purpose.
The Technical Blueprint #
# CLI command to create the GSI with partition key order_date and sort key order_id
aws dynamodb update-table \
--table-name OrdersTable \
--attribute-definitions AttributeName=order_date,AttributeType=S AttributeName=order_id,AttributeType=S \
--global-secondary-index-updates '[{"Create":{"IndexName":"OrderDateIndex","KeySchema":[{"AttributeName":"order_date","KeyType":"HASH"},{"AttributeName":"order_id","KeyType":"RANGE"}],"Projection":{"ProjectionType":"ALL"},"ProvisionedThroughput":{"ReadCapacityUnits":5,"WriteCapacityUnits":5}}}]'
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Invalid design (LSI with different partition key) | N/A | Not applicable |
| B | Simple scan + filter | Poor at scale; expensive Lambda invocations | Not recommended for production |
| C | Moderate: GSI creation, query API calls | Highly performant, scalable | Best fit for new query patterns |
| D | Complex stream processing logic | Inefficient for querying; event-driven only | For change processing, not queries |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick a Global Secondary Index (GSI) when you see a need for alternative partition keys or querying patterns not supported by the base table keys.
Real World #
Sometimes, teams resort to scans during prototyping but quickly realize scalability bottlenecks, switching to GSIs for production readiness.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.