DynamoDB for the AWS Developer Associate: Keys, Indexes, and Capacity

DynamoDB is the single service that separates candidates who pass the AWS Certified Developer - Associate (DVA-C02) comfortably from those who scrape by or fail. Amazon leans on it heavily because it is the database a serverless developer actually reaches for, and the exam knows most people arrive with a relational mindset that quietly sabotages them. Questions rarely ask you to recite a definition; they describe an access pattern, a throughput symptom, or a query that throws an error, and expect you to know why. This article teaches the three things that cause the most confusion — how keys work, when to use a local versus a global secondary index, and how capacity modes interact with hot partitions — so the DynamoDB questions on the AWS Certified Developer - Associate exam become some of the easiest points on the paper rather than the scariest.

Partition keys and sort keys: the thing relational habits get wrong

Every DynamoDB table has a primary key, and it comes in one of two shapes. A simple primary key is just a partition key. A composite primary key is a partition key plus a sort key. Understanding what each half does physically is the key to almost everything else.

The partition key is fed through an internal hash function, and the result decides which physical partition your item lands on. That is why it is sometimes called the hash key. The practical consequence is enormous: to read an item efficiently you must know its partition key, because that value is what tells DynamoDB which partition to look in. Query it and you get a single, targeted lookup. Omit it and your only option is a Scan, which reads the entire table and is the operation the exam wants you to avoid.

The sort key organizes items within a single partition. Every item that shares a partition key is stored together, ordered by its sort key, which is what makes composite keys powerful. Picture a table of customer orders where the partition key is CustomerId and the sort key is OrderDate. All of one customer's orders sit in the same partition, already sorted by date, so "give me this customer's orders from the last 30 days" is a single efficient range query. The sort key supports operators like begins_with, between, and greater-than, which is why people encode hierarchical values into it. If you want to filter on something, ask first whether it belongs in the sort key, because filtering there is cheap and filtering after a Scan is not.

This is also the heart of single-table design: rather than spreading data across many tables the way you would with a relational schema, experienced DynamoDB developers model multiple entity types in one table and lean on carefully constructed keys to serve every access pattern. You do not need to build production single-table designs to pass, but recognize that DynamoDB rewards designing around your queries first and your data second — the exact inversion of relational normalization.

LSI vs GSI: the distinction the exam loves

A secondary index lets you query a table by an attribute that is not the primary key. There are two kinds, and DVA-C02 tests the boundary between them relentlessly, because in practice choosing wrong is expensive.

A Local Secondary Index (LSI) keeps the same partition key as the base table but swaps in a different sort key. Because it is "local" to a partition, it can offer strongly consistent reads. The catch that shows up in exam questions: an LSI must be created when the table is created and can never be added later, and it shares the base table's throughput and the 10 GB per-partition-key size limit. If a scenario says a team wants a new query pattern on an existing table, an LSI is already off the table — literally.

A Global Secondary Index (GSI) is far more flexible. It can use a completely different partition key and sort key, it can be created or deleted at any time after the table exists, and it has its own separately provisioned throughput. The trade-off is that GSIs support only eventually consistent reads and are maintained asynchronously, so there is a small replication lag between a write to the base table and its appearance in the index. A well-crafted DVA-C02 question will hinge on exactly one of these facts: needs a different partition key, so it must be a GSI; needs strong consistency, so it must be an LSI; needs to be added after launch, so it must be a GSI. Reason from the requirement, not from memory. The practice questions for the DVA-C02 on ExamStudyApp drill this discrimination directly, and reviewing every miss with its explanation is what turns "I think it's a GSI" into an instant, confident answer.

On-demand vs provisioned capacity, and why hot partitions happen

DynamoDB bills throughput in read and write capacity units, and you choose how to supply them. Provisioned mode means you specify capacity up front; it is cheapest for steady, predictable traffic and can be paired with auto scaling. On-demand mode charges per request with no capacity to manage; it shines for spiky or unpredictable workloads where you cannot forecast load. The exam's rule of thumb: predictable and cost-sensitive leans provisioned, bursty leans on-demand.

Now the concept that quietly fails candidates: the hot partition. DynamoDB spreads your provisioned throughput across partitions, and your data is distributed by the partition key's hash. If your partition key has low cardinality or a badly skewed distribution — say you use Status with values like "ACTIVE" and "INACTIVE", or a date that funnels today's entire traffic onto one value — then a huge share of requests hammers a single partition. That partition can exhaust its slice of capacity and start throwing ProvisionedThroughputExceededException or throttling errors even though the table as a whole looks under-utilized. That last clause is the exact symptom the exam describes.

The fix is a high-cardinality partition key that spreads load evenly — a user ID, an order ID, or a synthetic key with a random or calculated suffix (write sharding) to fan a hot value across many partitions. Adaptive capacity smooths some imbalance automatically now, but the design principle still gets tested. When you see throttling on a table with plenty of spare capacity, think key distribution before you think "add more capacity." Recognize the developer-side response too: catching throttling exceptions and retrying with exponential backoff, which the SDKs do by default.

Turning understanding into a passing score

These three areas — key design, index selection, and capacity behavior — account for a disproportionate share of the DynamoDB questions you will face, and they reward genuine understanding over memorization. The way to lock them in is to keep meeting them in question form until the reasoning is automatic. Full-length timed DVA-C02 exam simulations put these concepts next to Lambda, API Gateway, IAM, and the rest of the developer toolkit exactly as the real exam interleaves them, and the readiness tracking shows when your scores are consistently clearing the pass mark on fresh questions. When adaptive practice stops finding weak spots in your DynamoDB answers and your timed runs hold steady above the bar, you are ready to book. For a structured path from shaky to certain on this material, the AWS Certified Developer - Associate practice set is built to take you there.