Amazon DVA-C02: Amazon DynamoDB & NoSQL Design — Study Guide
Part of the AWS Developer Associate DVA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Data modeling and access patterns
Designing DynamoDB begins with access patterns: every query should map to a primary key, global secondary index (GSI), or local secondary index (LSI); table design is driven by how the application reads and writes items, not by how a relational schema would be structured. Choose a high-cardinality partition key to avoid hot partitions and use a composite primary key (partition + sort key) when you need range queries; Query operations require equality on the partition key and optional KeyConditionExpression on the sort key. For SDKs favor the DynamoDB Document abstractions: use DynamoDBDocumentClient with AWS SDK for JavaScript v3 (marshall/unmarshall handled for you) or the DynamoDB Enhanced Client in Java to map objects to attributes. Implement single-table patterns only when read patterns share keys and you can encode item types via a type attribute; use sparse GSIs to expose secondary access paths by writing attributes only to items that need them. A common trap is overusing Scan: scanning large tables is expensive and paginated (LastEvaluatedKey); prefer Query with ProjectionExpression to reduce RCU usage. For conditional writes use UpdateItem with ConditionExpression or TransactWriteItems for multi-item atomicity; handle ConditionalCheckFailedException and back off with jitter.
Indexes, queries, and transactional patterns
Local secondary indexes are created only at table creation, share the same partition key as the base table, and consume table read capacity for queries, while GSIs can be added after table creation, have independent capacity or on-demand billing, and allow different partition keys. Query calls use KeyConditionExpression and ExpressionAttributeNames/Values; projection expressions reduce data transfer. GSIs are eventually consistent by default and incur additional write cost because every base-table write that projects indexed attributes creates corresponding GSI writes — plan WCUs accordingly and monitor ConsumedWriteCapacityUnits for the index. For strong consistency use GetItem or Query with ConsistentRead=true on the base table (GSIs do not support strongly consistent reads). Transactions (TransactWriteItems and TransactGetItems) guarantee atomicity across up to 25 items or 4 MB payload; use ReturnValuesOnConditionCheckFailure to inspect failures. BatchWriteItem and BatchGetItem are limited to 25 and 100 items respectively and are untransactional; code should handle UnprocessedItems by retrying with exponential backoff. A frequent gotcha is forgetting the cost and eventual-consistency implications of GSIs when migrating relational joins into indexes.
Capacity modes, performance tuning, and troubleshooting
Decide between provisioned and on-demand capacity based on predictability: provisioned with Auto Scaling (Application Auto Scaling for DynamoDB) gives control over RCU/WCU and cost for steady workloads, while on-demand simplifies bursty traffic without capacity planning but at higher per-request pricing. Enable Auto Scaling with target utilization and multiple scaling policies; monitor CloudWatch metrics like ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, SuccessfulRequestLatency, SystemErrors, and ConditionalCheckFailedRequests to detect hotspots and throttling. Use adaptive capacity to mitigate single-key throttling, but avoid relying on it — design for uniform key distribution. For read-heavy workloads consider DAX for microsecond reads or cache with Amazon ElastiCache; for write-heavy use write sharding (prefixes or buckets) to distribute writes across partitions. Troubleshoot by inspecting ProvisionedThroughputExceededException and implementing exponential backoff with jitter in SDK clients, enable CloudWatch Contributor Insights to find hot keys, and use Parallel Scan for large one-time analytics with segmented workers. Remember item size limits (400 KB) and that large items increase RCUs/WCUs; split large blobs into S3 with metadata in DynamoDB when necessary.
Streams, integrations, backups and operational best practices
DynamoDB Streams capture item-level changes (INSERT, MODIFY, REMOVE) in order per partition key and integrate directly with Lambda via an event source mapping (configure startingPosition as TRIM_HORIZON or LATEST, set batchSize and maximumBatchingWindowInSeconds, and tune bisectBatchOnError and maximumRetryAttempts). For robust processing use Lambda with a Dead-Letter Queue (SQS or SNS) or route stream records into Kinesis or Kinesis Data Firehose for analytics. Enable Time To Live (TTL) for automatic expiry of items; note TTL deletions are eventually processed and should not be relied on for immediate consistency. Use Point-in-Time Recovery (PITR) and on-demand backups for disaster recovery; for multi-region availability use Global Tables to replicate changes across regions. Apply least-privilege IAM roles to services and grant only necessary dynamodb:Query, dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:DescribeStream, and dynamodb:ListStreams actions for Lambdas. Common operational pitfalls include missing retry/backoff logic in consumers, inadequate GSI capacity planning, and failing to monitor Streams IteratorAge for lag detection; instrument with CloudWatch Logs and X-Ray to trace end-to-end latency.
Practical Problem: Use-Case Scenario
Scenario: AcmeMedia runs a metadata catalog in a single DynamoDB table in us-east-1 containing tens of millions of items. A newly launched image-processing pipeline needs a low-latency query by photographerId and uploadTimestamp range, and downstream Lambda consumers must reliably process changes.
Challenge: Add an efficient query path for photographerId + timestamp range without table redesign, ensure downstream Lambda processes stream records with at-least-once semantics, and avoid hot partitions for prolific photographers.
Recommended Approach:
- Create a GSI named photographer-gsi with partition key photographerId and sort key uploadTimestamp; use UpdateTable API or console to add the GSI and specify ProvisionedThroughput or On-Demand billing via UpdateTable and set IndexStatus monitoring.
- When writing items include the photographerId and uploadTimestamp attributes so index projection is sparse; choose ProjectionType=INCLUDE with non-key attributes needed for queries to reduce storage and write costs.
- Configure DynamoDB Streams ENABLED on the table and create a Lambda event source mapping with startingPosition=TRIM_HORIZON, batchSize tuned (e.g., 100), bisectBatchOnError=true, maximumRetryAttempts=2, and set an SQS queue as a Dead-Letter Destination in the Lambda function configuration.
- Implement SDK client retries with jitter (use AWS SDK built-in retry strategy) and apply write sharding if single photographerId still causes throttling (prefix photographerId with N buckets on write and strip prefix on read client-side).
Rationale: Adding a GSI exposes the required access pattern without changing the base primary key; projecting only necessary attributes reduces GSI write cost. Streams + Lambda with DLQ and retry controls provide reliable at-least-once processing, while sharding guards against hot partitions from high-cardinality traffic.
← Amazon API Gateway · All domains · CloudFormation →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →