DynamoDB data modeling: DEA-C01 study notes and practice questions
What to know about DynamoDB data modeling for the DEA-C01 exam, from the Data Store Management domain (26% of the exam guide), then 2 free questions to test it. Part of the DEA-C01 study guide.
DynamoDB questions describe access patterns and ask how to model the table, or why it throttles.
Keys
Partition key: decides which partition stores an item. Use a key with many distinct values that are accessed evenly (user ID, device ID). A few hot values cause throttling.
Sort key: orders items within a partition, enabling range queries (begins_with, between) such as “all orders for a customer in March”.
Write sharding: add a random or calculated suffix to spread very hot keys.
Indexes
Global secondary index (GSI)
Local secondary index (LSI)
Keys
Different partition and sort key
Same partition key, different sort key
Created
Any time
Only at table creation
Capacity
Its own
Shares the table’s
Consistency
Eventually consistent
Strong or eventual
An under-provisioned GSI can throttle writes to the base table.
Capacity and features
On-demand for unpredictable traffic; provisioned with auto scaling for steady traffic.
TTL deletes expired items automatically at no cost.
DynamoDB Streams capture item changes for Lambda or replication; Kinesis Data Streams for DynamoDB gives longer retention and more consumers.
Export to S3 (full or incremental, from point-in-time recovery data) uses no read capacity; query the export with Athena.
Import from S3 creates a new table from CSV, JSON or Ion.
Zero-ETL to Redshift or OpenSearch.
Modeling approach
Start from the access patterns, not entities. Single-table design stores related entities together so one query fetches them.
Common traps
Scans for analytics on a production table. Export to S3.
A low-cardinality partition key (status, date) causing hot partitions.
Needing an LSI on an existing table. Only GSIs can be added later.
A public library consortium stores loan records in one Amazon DynamoDB table. Two access patterns matter most: the members' app lists a member's current loans, and the catalog team looks up which members hold a given book. The first design used branch_id as the partition key, so one busy central branch receives most of the writes.
The team wants both access patterns served by queries rather than scans, and it wants the writes spread evenly across partitions.
Which table design meets these requirements?
Choose one answer.
AA. Keep branch_id as the partition key, and add a global secondary index on member_id so that the member's loans can be queried.
BB. Use book_id as the partition key with no sort key, and rely on scans for the member's loans, which the app runs once a day.
CC. Use a random number from 1 to 10 appended to branch_id as the partition key, and scan all ten suffixes for each member lookup.
DD. Use member_id as the partition key and loan_date as the sort key, and add a GSI with book_id as its partition key.
Show the answer and explanation
Answer: D
A. Wrong: The base table still concentrates writes on the busy branch, so the hot partition remains. The global secondary index helps the member lookup but does not spread the writes the team asked to balance.
B. Wrong: Scans read the whole table and are expensive at scale, and the team wants queries. A partition key on book_id can also concentrate popular titles on a few partitions.
C. Wrong: Write sharding spreads the writes, but reading a member's loans then needs ten queries for each lookup. The option also scans for the catalog pattern, which the team wanted served by queries.
DynamoDB spreads items by partition key, so a key with many distinct values, such as member ID, avoids a single busy partition. A sort key on loan date keeps a member's loans in one query, and a global secondary index on book ID serves the catalog lookup by query. Keeping branch as the key or scanning either access pattern leaves one of the requirements unmet.
A pet insurer's policy-admin system keeps policy records in an Amazon DynamoDB table that serves customer and agent traffic all day. The analytics team needs a full daily copy of the table in Amazon S3 in a format that Athena can query, and the export must not slow the production traffic.
The table already has point-in-time recovery turned on for backups.
Which approach meets these requirements?
Choose one answer.
AA. Use the DynamoDB table export feature to write the table to S3 from point-in-time recovery data, using no read capacity.
BB. Run an AWS Glue job every night that scans the whole table with the DynamoDB connector, and writes the results to S3.
CC. Run an AWS Lambda function every hour that calls Scan on the table with a small page size, and appends each page to a file in S3.
DD. Query the table from Amazon Athena with a federated query connector every morning, and write the results to a new S3 table.
B. Wrong: A full scan consumes read capacity from the same table that serves production traffic, so it can slow customers and agents. The option is the pattern the team wants to avoid.
C. Wrong: Hourly paged scans still use the table's read capacity many times over the day, and they run slowly for a full copy. The option keeps the production impact the team wanted to avoid.
D. Wrong: A federated query against a DynamoDB table reads the table directly and uses its read capacity. The option has the same production impact as a scan.
Explanation
DynamoDB table export writes a full copy to S3 from point-in-time recovery data, so production read capacity stays free for customers and agents. Scans, paged reads and federated queries all read the live table and compete with production traffic.
Want more on DynamoDB data modeling? The 5 full-length practice sets have 10 more DynamoDB data modeling questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →