Jeff’s Note #
Unlike generic exam question dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, a common pitfall is misunderstanding how to model DynamoDB tables for flexible data with inconsistent attributes and multi-faceted query patterns. In production, it’s about knowing how to use composite primary keys and GSIs correctly to efficiently retrieve data while keeping the schema adaptable. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A startup named CineTrail wants to build a backend service to store movie information. Each movie record includes a title, release year, and a genre. They also want to store additional metadata about the cast and production crew, but this metadata varies widely across movies—some movies have attributes like “assistantDirector,” while others might have “animalTrainer,” and so forth. These extra properties are not consistent across all movies.
The Requirement: #
Develop a data store design that supports the following access patterns efficiently:
- Given a movie title and release year, retrieve all information about that specific movie.
- Given a movie title, retrieve all versions (all years) of movies with that title.
- Given a genre, retrieve all movies in that genre with all their details.
The Options #
- A) Create an Amazon DynamoDB table with a composite primary key: title as the partition key and release year as the sort key. Create a global secondary index (GSI) using genre as the partition key and title as the sort key.
- B) Create an Amazon DynamoDB table with a composite primary key: genre as the partition key and release year as the sort key. Create a global secondary index with title as the partition key.
- C) Create a relational table on Amazon RDS with columns for title, release year, and genre, and configure title as the primary key.
- D) Use Amazon RDS, create a table with title as the primary key, and store all other attributes serialized into one JSON column.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
The key here is correctly using DynamoDB’s single-table design pattern with composite keys and GSIs to accommodate multiple query types without costly scans or inconsistent data modeling. Option A supports flexible schemas (DynamoDB’s document model) and multi-dimensional queries efficiently.
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 #
- DynamoDB’s flexible schema model accommodates inconsistent movie metadata easily, allowing each movie item to have different attributes.
- The composite primary key with title (partition key) and release year (sort key) provides efficient point lookups and ranged queries for all movies with the same title across years.
- The additional GSI with genre as the partition key and title as the sort key enables queries by genre, returning all movies in that category sorted by title.
- This design avoids inefficient full table scans and enables high-throughput queries using DynamoDB’s indexes and partitioning.
The Trap (Distractor Analysis): #
- Why not Option B?
- Using genre as the primary partition key complicates retrieving a movie by title and release year. The sort key being release year alone loses uniqueness for a title query. Also, the GSI lacks a sort key, reducing query flexibility.
- Why not Option C?
- Using RDS with title as primary key doesn’t allow duplicate titles with different release years, which violates the use case. Also, RDS rigid schema makes inconsistent metadata complicated.
- Why not Option D?
- Storing JSON in RDS can work for flexible schema but querying by genre or release year would require inefficient JSON parsing or full scans, impacting performance.
The Technical Blueprint #
# Example CLI command to create DynamoDB table and GSI for Option A
aws dynamodb create-table \
--table-name Movies \
--attribute-definitions \
AttributeName=title,AttributeType=S \
AttributeName=releaseYear,AttributeType=N \
AttributeName=genre,AttributeType=S \
--key-schema \
AttributeName=title,KeyType=HASH \
AttributeName=releaseYear,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--global-secondary-indexes \
"[{
\"IndexName\": \"GenreTitleIndex\",
\"KeySchema\": [
{\"AttributeName\":\"genre\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"title\",\"KeyType\":\"RANGE\"}
],
\"Projection\": {\"ProjectionType\":\"ALL\"},
\"ProvisionedThroughput\": {\"ReadCapacityUnits\":5,\"WriteCapacityUnits\":5}
}]"
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case Fit |
|---|---|---|---|
| A | Medium (Primary + GSI) | High - supports 3 query patterns efficiently | Flexible schema + multi-key queries |
| B | Medium (Primary + GSI) | Medium - GSI missing sort key reduces query granularity | Poor for title+year lookups |
| C | Low (RDS table) | Low - rigid schema, no multi-key search | Rigid schema limits inconsistent metadata |
| D | Low (RDS + JSON col) | Low - querying JSON inefficient | Allows flexible schema but poor query performance |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick DynamoDB with composite keys and GSIs when the use case requires flexible, inconsistent schema data and multiple query patterns.
Real World #
While you might consider RDS for complex relational queries, when you face inconsistent attributes and diverse access patterns like in this scenario, DynamoDB’s single-table design with GSIs offers better performance and simpler scaling.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.