DynamoDB keys, indexes and capacity

DynamoDB questions usually test key design, capacity math and which feature solves a stated access pattern.

Keys

• Partition key (hash): spreads items across partitions. Choose a high-cardinality value to avoid hot partitions.
• Sort key (range): optional; allows Query with conditions such as begins_with or between.

GetItem and Query use the key and are efficient. Scan reads the entire table and should be avoided; filters apply after reading, so you still pay for the data read.

Secondary indexes

	Local (LSI)	Global (GSI)
Partition key	Same as table	Any attribute
Created	Only at table creation	Any time
Capacity	Shares the table	Has its own
Consistency	Strong or eventual	Eventual only

Capacity math

• 1 RCU = one strongly consistent read of up to 4 KB per second, or two eventually consistent reads. A transactional read costs 2 RCUs.
• 1 WCU = one write of up to 1 KB per second. A transactional write costs 2 WCUs.
• Round item size up to the next 4 KB (reads) or 1 KB (writes).

Example: 6 strongly consistent reads per second of 10 KB items = 3 RCUs each (10/4 rounded up) x 6 = 18 RCUs.

On-demand mode suits unpredictable traffic; provisioned mode with auto scaling suits steady traffic. Exceeding provisioned capacity throws ProvisionedThroughputExceededException; the SDK retries with exponential backoff.

Write safety

• Conditional writes (ConditionExpression) implement optimistic locking and prevent overwrites.
• Atomic counters use UpdateItem with ADD.
• Transactions (TransactWriteItems) give all-or-nothing across items.
• BatchWriteItem is not atomic and may return UnprocessedItems.

Related features

• TTL: deletes items by an epoch-seconds attribute at no cost.
• DynamoDB Streams: ordered 24-hour change log that can trigger Lambda.
• DAX: in-memory cache for read-heavy, eventually consistent reads with microsecond latency.
• Item size limit: 400 KB. Store larger objects in S3 and keep the pointer.

Exam traps

• A filter expression does not reduce consumed read capacity.
• Strong consistency is not available on a GSI.
• DAX does not help strongly consistent reads or write-heavy workloads.
• Hot partition: fix the key design; raising capacity alone does not.
• You cannot add an LSI after table creation.

Practice questions

Choose an answer, then review the explanation to check your understanding.

1. A table is keyed by OrderId. The application also needs to query orders by CustomerId, which can be added at any time. What should be used?

1. A.A local secondary index
2. B.A global secondary index with CustomerId as partition key
3. C.A Scan with a filter
4. D.A second table written by hand

Show answer

Answer: B.A GSI can be created at any time and has its own partition key. An LSI must be defined when the table is created.

2. How many read capacity units does a strongly consistent read of an 8 KB item need?

1. A.1
2. B.2
3. C.4
4. D.8

Show answer

Answer: B.One RCU reads up to 4 KB strongly consistent, so 8 KB needs 2. An eventually consistent read would need 1.

3. Two clients may update the same item. How do you stop one from overwriting the other's change?

1. A.Use eventually consistent reads
2. B.Use a conditional write on a version attribute
3. C.Enable DynamoDB Streams
4. D.Use a Scan before each write

Show answer

Answer: B.A condition expression (optimistic locking) makes the write fail if the version changed.

4. Session items must disappear automatically after a day without consuming write capacity. What should be used?

1. A.A Lambda cleanup job
2. B.TTL on an epoch-timestamp attribute
3. C.A DAX cluster
4. D.A scheduled Scan

Show answer

Answer: B.TTL deletes expired items in the background at no write cost.