If there’s a single AWS service that decides whether you pass the AWS Certified Developer – Associate (DVA-C02) exam, it’s DynamoDB. It appears across all four exam domains — development, security, deployment, and troubleshooting — and the questions go well beyond “what is a NoSQL database.” You’ll be asked to design partition keys, choose between a GSI and an LSI under specific constraints, calculate read capacity units, and pick the right consistency model for a scenario.
This deep dive covers DynamoDB the way the DVA-C02 actually tests it: from a developer’s seat, with the real trade-offs, the exact formulas, and the traps that catch people who only skimmed the documentation. Whether DynamoDB is new to you or you’ve used it casually, this guide will get you to exam-ready confidence.
Why DynamoDB Dominates the DVA-C02
DynamoDB is AWS’s fully managed, serverless, key-value and document database. It delivers single-digit millisecond latency at any scale, with no servers to provision and automatic horizontal scaling. For a developer building cloud-native applications — exactly the persona the DVA-C02 validates — it’s the default data store for serverless and high-throughput workloads.
The exam loves DynamoDB because it forces you to make real design decisions. There’s no “just throw it in a relational database” escape hatch. You have to understand how data is physically partitioned, how indexes work, and how capacity is consumed. Get those fundamentals right and a large block of exam questions becomes straightforward.
Core Concepts: Tables, Items, and Attributes
DynamoDB’s vocabulary maps loosely to relational databases, but the differences matter:
| DynamoDB term | Relational analogy | Notes |
|---|---|---|
| Table | Table | A collection of items |
| Item | Row | Max size 400 KB (a common exam fact) |
| Attribute | Column | Items in a table need not share attributes |
| Primary key | Primary key | Partition key, optionally + sort key |
| Partition key | — | Determines which physical partition stores the item |
| Sort key | — | Orders items within a partition |
The 400 KB item size limit shows up regularly. If a scenario describes storing large objects (images, documents), the correct pattern is to store the object in Amazon S3 and keep only the S3 object key as an attribute in DynamoDB.
Primary Keys: The Single Most Important Topic
DynamoDB has two kinds of primary key, and choosing correctly is the foundation of every well-designed table.
- Simple primary key (partition key only): The partition key’s value is hashed to determine the partition. Each value must be unique. Good for pure key-value lookups like a user profile keyed by
userId. - Composite primary key (partition key + sort key): Items sharing a partition key are stored together, sorted by the sort key. This enables rich queries like “all orders for customer 123, sorted by date.”
The Hot Partition Problem
This is the concept the DVA-C02 tests most often, usually disguised as a performance-troubleshooting question. DynamoDB distributes data and throughput across partitions based on the partition key. If your partition key has low cardinality or uneven access — say, a status attribute where 90% of items are "active" — all that traffic hammers one partition. The symptom is throttling even though your table’s total provisioned capacity looks fine.
The fix the exam wants: choose a high-cardinality partition key with uniform access, such as userId, orderId, or a composite value. If a naturally low-cardinality key is unavoidable, add a random or calculated suffix (write sharding) to spread the load.
Exam phrasing to recognize: “Some items are throttled while overall consumed capacity is below provisioned capacity.” That’s a hot partition, and the answer is almost always about partition key design.
Secondary Indexes: GSI vs LSI
By default you can only query DynamoDB efficiently on the primary key. Secondary indexes let you query on other attributes. There are two types, and distinguishing them is a guaranteed exam topic.
| Feature | Global Secondary Index (GSI) | Local Secondary Index (LSI) |
|---|---|---|
| Partition key | Can differ from the table | Same as the table’s partition key |
| Sort key | Any attribute | Different sort key |
| When you can create | Any time | Only at table creation |
| Capacity | Its own provisioned throughput | Shares the table’s throughput |
| Consistency | Eventually consistent only | Supports strongly consistent reads |
| Limit per table | 20 (default, can increase) | 5 |
The decision tree the exam rewards:
- Need to query on a completely different partition key? → GSI (only option).
- Need a different sort key on the same partition key with strong consistency? → LSI.
- Already created the table and now need a new index? → GSI (LSIs can’t be added later).
A subtle but frequently tested GSI behavior: if a write to the base table can’t be propagated to the GSI because the GSI is under-provisioned, the base table write can be throttled. So always provision GSIs adequately.
Capacity Modes: Provisioned vs On-Demand
DynamoDB bills for throughput in one of two modes.
- On-demand: You pay per request; DynamoDB scales instantly. Ideal for unpredictable or spiky traffic, or new applications where you can’t forecast load. Zero capacity planning.
- Provisioned: You specify Read Capacity Units (RCU) and Write Capacity Units (WCU). Cheaper for predictable, steady traffic. Can be paired with Auto Scaling to adjust capacity within bounds.
Exam signal: “unpredictable,” “spiky,” “unknown traffic patterns,” “new application” → on-demand. “Steady,” “predictable,” “cost-sensitive at scale” → provisioned with auto scaling.
Capacity Unit Math (Memorize These)
The DVA-C02 will hand you a workload and ask for the required RCUs or WCUs. The rules:
Read Capacity Units (RCU): 1 RCU =
- 1 strongly consistent read/sec for an item up to 4 KB, or
- 2 eventually consistent reads/sec for an item up to 4 KB.
Item sizes round up to the next 4 KB.
Write Capacity Units (WCU): 1 WCU =
- 1 write/sec for an item up to 1 KB.
Item sizes round up to the next 1 KB.
Worked example: You need 100 strongly consistent reads/sec of 6 KB items.
- Round 6 KB up to 8 KB → that’s 2 × 4 KB blocks.
- Strongly consistent: 1 RCU per 4 KB block → 2 RCU per read.
- 100 reads/sec × 2 RCU = 200 RCU.
If those reads were eventually consistent, you’d halve it to 100 RCU.
Write example: 50 writes/sec of 2.5 KB items → round 2.5 KB up to 3 KB → 3 WCU per write → 50 × 3 = 150 WCU.
Practice these until they’re automatic. They’re free points if you know the formula and wasted minutes if you don’t.
Read Consistency
DynamoDB offers two consistency models on reads:
- Eventually consistent (default): May return slightly stale data right after a write, but costs half the RCUs and offers higher throughput.
- Strongly consistent: Always returns the latest data, costs double, and isn’t available on GSIs.
For the exam: if a scenario demands reading data immediately after writing it (read-your-writes), use strongly consistent reads — but remember that’s impossible on a GSI, which is sometimes the gotcha in the answer choices.
Query vs Scan
This distinction is tested constantly, and it’s a classic optimization question.
- Query retrieves items by partition key (and optional sort key conditions). It’s efficient — it reads only the matching partition.
- Scan reads every item in the table, then filters. It’s expensive and slow on large tables.
Exam rule: if a question describes a slow, capacity-hungry read pattern using Scan, the fix is to redesign to use Query, often by adding a GSI so the access pattern has an indexed key. Filter expressions don’t save capacity — DynamoDB consumes capacity for everything read before the filter is applied.
To reduce Scan impact when it’s unavoidable, the exam mentions parallel scans (split the table into segments) and pagination with Limit.
DynamoDB Streams
DynamoDB Streams capture an ordered, time-ordered sequence of item-level changes (inserts, updates, deletes) and retain them for 24 hours. This is a heavily tested feature because it enables event-driven architectures.
The canonical pattern: DynamoDB Streams → Lambda trigger. When an item changes, the stream invokes a Lambda function to react — update an aggregate, send a notification, replicate data, or maintain a search index.
StreamViewType controls what each record contains:
| StreamViewType | Contains |
|---|---|
KEYS_ONLY | Only the key attributes of the changed item |
NEW_IMAGE | The entire item after the change |
OLD_IMAGE | The entire item before the change |
NEW_AND_OLD_IMAGES | Both before and after |
If a question needs to compare what changed (old vs new values), the answer is NEW_AND_OLD_IMAGES.
DynamoDB Accelerator (DAX)
DAX is a fully managed, in-memory cache specifically for DynamoDB. It delivers microsecond read latency for read-heavy workloads and is API-compatible, so you point your existing DynamoDB SDK calls at the DAX cluster with minimal code change.
Exam discriminator: DAX is for caching DynamoDB reads. If the scenario is read-heavy on DynamoDB and asks for microsecond latency, the answer is DAX — not ElastiCache. ElastiCache is the generic answer for caching arbitrary data or relational query results. Also note: DAX caches reads, so it doesn’t help write-heavy workloads.
Transactions, TTL, and Optimistic Locking
A few more features round out the DVA-C02 DynamoDB syllabus.
Transactions (TransactWriteItems / TransactGetItems) provide all-or-nothing ACID operations across up to 100 items or multiple tables. Use them when a scenario requires that several writes succeed or fail together — like deducting inventory and creating an order atomically. They consume roughly double the capacity of standard operations.
Time to Live (TTL) lets you set an expiry timestamp attribute; DynamoDB automatically deletes expired items at no extra cost, on a best-effort basis (deletion can lag by up to 48 hours). Perfect for session data, temporary tokens, or logs. The exam answer for “automatically remove old items without manual cleanup” is TTL.
Optimistic locking uses a version number attribute and conditional writes (ConditionExpression) to prevent two clients from overwriting each other. The write succeeds only if the version matches what the client last read. This is the answer to “how do you prevent lost updates in a concurrent environment.”
Error Handling and the SDK
The DVA-C02 cares about how your code reacts to DynamoDB errors:
ProvisionedThroughputExceededException— you’re being throttled. The correct response is exponential backoff with jitter, which the AWS SDKs implement automatically via retries. Don’t answer “increase capacity” reflexively; the exam usually wants the resilient-client answer.ConditionalCheckFailedException— a conditional write’s condition wasn’t met (e.g., optimistic lock version mismatch). Handle it in application logic, not by retrying blindly.- Batch operations (
BatchGetItem,BatchWriteItem) can partially succeed; unprocessed items are returned inUnprocessedItemsand must be retried, again with backoff.
Security: IAM and Fine-Grained Access
Security is its own DVA-C02 domain, and DynamoDB has a neat feature here: fine-grained access control using IAM condition keys. With dynamodb:LeadingKeys, you can restrict an IAM principal to only the items whose partition key matches their identity — so a user can read only their own rows in a shared table.
{
"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:Query"],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/UserData",
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
}
}
}This pattern — pairing Amazon Cognito identities with dynamodb:LeadingKeys — is the textbook answer for “let mobile users access only their own data” scenarios. Also remember DynamoDB encrypts data at rest by default using AWS KMS.
A Quick Reference for Exam Day
| Scenario keyword | DynamoDB answer |
|---|---|
| Throttling below provisioned capacity | Hot partition — fix partition key |
| Query on a different attribute | GSI |
| Different sort key, strong consistency | LSI (at creation only) |
| Unpredictable / spiky traffic | On-demand capacity |
| Microsecond reads on DynamoDB | DAX |
| React to item changes | Streams + Lambda |
| Auto-delete expired items | TTL |
| Prevent lost updates | Optimistic locking / conditional write |
| All-or-nothing multi-item write | Transactions |
| Users access only their own items | IAM dynamodb:LeadingKeys |
| Slow full-table read | Replace Scan with Query (+ GSI) |
How to Turn This Into a Passing Score
Knowing these concepts is necessary but not sufficient — the DVA-C02 phrases questions to make two plausible answers look correct, and only repeated exposure trains you to spot the discriminating detail. The single highest-leverage prep activity is working through realistic scenario questions and reading why the wrong answers are wrong.
The AWS Developer Associate (DVA-C02) Mock Exam Bundle is built for exactly this. It runs in your browser with full-length, domain-weighted exams, and every question includes a detailed explanation that breaks down the DynamoDB reasoning — capacity math, GSI vs LSI calls, consistency trade-offs — so you internalize the patterns instead of memorizing answers.
To round out your preparation, pair this with our AWS Developer Associate serverless guide (DynamoDB is the data layer behind most serverless questions), the DVA-C02 study plan, and a set of practice questions to gauge your readiness.
Frequently Asked Questions
How much of the DVA-C02 is DynamoDB?
There’s no official per-service breakdown, but DynamoDB is among the most heavily represented services on the exam, appearing across development, security, deployment, and troubleshooting questions. Most candidates report DynamoDB and Lambda as the two services they saw most.
Do I need to memorize the RCU and WCU formulas?
Yes. You’ll get calculation questions, and they’re free points if you know the rules: 1 RCU = one 4 KB strongly consistent read (or two eventually consistent), 1 WCU = one 1 KB write, with sizes rounded up. Practice a few until the math is automatic.
What’s the easiest way to remember GSI vs LSI?
LSI is Local — same partition key, must be created with the table, max 5, supports strong consistency. GSI is Global — any partition key, created anytime, has its own throughput, eventually consistent only. When in doubt, GSI is the more flexible default; LSI only wins when you need strong consistency on an alternate sort key.
When should I use DynamoDB Streams vs polling?
Use Streams whenever you need to react to data changes in near real time without polling. The standard architecture is Streams triggering a Lambda function, which is more efficient and event-driven than repeatedly scanning the table.
Is DAX the same as ElastiCache?
No. DAX is a DynamoDB-specific in-memory cache that’s API-compatible with DynamoDB and delivers microsecond reads. ElastiCache (Redis/Memcached) is a general-purpose cache. On the exam, “read-heavy DynamoDB workload needing microsecond latency” points to DAX.
How do I prevent two users from overwriting the same item?
Use optimistic locking: store a version number attribute and use a conditional write (ConditionExpression) that only succeeds if the version matches what you last read. A mismatch raises ConditionalCheckFailedException, which your application handles.
Key Takeaways
- Partition key design is the foundation — high cardinality and uniform access prevent hot partitions.
- GSI vs LSI: GSI is flexible and added anytime; LSI needs the same partition key, table-creation timing, and offers strong consistency.
- Capacity math (RCU/WCU with rounding) is testable and learnable — drill it.
- On-demand for spiky traffic, provisioned + auto scaling for predictable load.
- Streams + Lambda power event-driven patterns; DAX delivers microsecond DynamoDB reads.
- TTL, transactions, and optimistic locking each answer a specific scenario keyword.
- Handle throttling with exponential backoff, not just “add capacity.”
Nail DynamoDB and you’ve conquered the most important — and most frequently tested — service on the DVA-C02. Combine this conceptual depth with realistic, explanation-rich mock exams, and you’ll walk into exam day ready to recognize every DynamoDB pattern they throw at you.