35 DynamoDB Interview Questions and Answers

DynamoDB interviews usually test whether you can turn application access patterns into keys, indexes and safe writes, then explain the cost and consistency trade-offs. Know the core limits, but also be ready to diagnose a hot partition, handle pagination and distinguish transactions from batch operations. These questions cover the fundamentals and current features such as MRSC global tables, warm throughput and resource-based policies.

Q1. What is DynamoDB?

Amazon DynamoDB is AWS's managed NoSQL database for key-value and document data. AWS operates the underlying infrastructure and distributes table data across partitions. Applications access items through keys, indexes and service APIs rather than connecting to a database server they administer.

A useful interview answer includes the boundary: DynamoDB fits operational workloads with predictable access patterns, but does not provide general server-side joins. Table growth alone does not require a schema migration; a new access pattern might.

Q2. What are NoSQL databases?

NoSQL is a broad category of databases that use models other than the traditional relational model. Common families include key-value, document, wide-column and graph databases. “NoSQL” does not mean all these systems have the same consistency guarantees, query language or transaction support.

DynamoDB supports key-value and document data. Items can contain nested maps and lists, but efficient lookup still depends on the table or index keys.

Q3. What are DynamoDB's key features?

Key features include managed scaling, on-demand and provisioned capacity, secondary indexes, conditional writes, transactions, Streams, backups, PITR and global tables. Encryption at rest is always enabled. Newer capabilities include multi-attribute GSI keys, native vector search and managed zero-ETL integrations.

Do not describe ordinary DynamoDB requests as an in-memory, microsecond operation. DAX is the separate cache that can provide microsecond access for suitable cached reads; application latency also includes networking and processing.

Q4. What are the advantages of DynamoDB?

DynamoDB removes server maintenance, supports scalable key-based access and provides replication within a Region. On-demand capacity reduces capacity-planning work for variable traffic. Global tables can support regional access and resilience.

Explain the benefit with a workload, such as retrieving session records by ID during unpredictable traffic. Avoid calling it unconditionally cheapest or fastest: those conclusions depend on access patterns and operational requirements. The pros and cons comparison gives examples.

Q5. What are the disadvantages of DynamoDB?

Important trade-offs are no general JOIN operator, a fixed item-size limit, access-pattern-driven modeling and charges for data read, written, indexed and replicated. A workload dominated by ad hoc filtering may need extra indexes or another query system.

“No triggers” is an outdated answer: DynamoDB Streams can invoke Lambda processing after changes. It does not mean arbitrary stored procedures execute inside the database or that a stream consumer can reject an already committed write.

Q6. What are good DynamoDB use cases?

Sessions, shopping carts, orders, game state, message history, device state and workflow records are common examples. They often have identifiable keys and bounded reads or writes. A dashboard based on a maintained counter can also fit.

Data warehousing and general business-intelligence queries are not DynamoDB's core workload. Export or zero-ETL integrations can supply an analytical system while DynamoDB serves application requests. Native vector search adds embedding similarity retrieval for on-demand tables.

Q7. What is DynamoDBMapper, and what replaces it?

DynamoDBMapper is the object-mapping abstraction from AWS SDK for Java 1.x. That SDK reached end of support on December 31, 2025. For current Java applications, use AWS SDK for Java 2.x and DynamoDbEnhancedClient from the dynamodb-enhanced module.

The Enhanced Client maps Java objects to DynamoDB items and supports table operations without manually constructing every attribute value. AWS calls it the successor to DynamoDBMapper in the Enhanced Client documentation.

Q8. What is a partition key?

The partition-key value is input to DynamoDB's internal hash function, which determines data placement. A table can have a simple primary key consisting only of a partition key, or a composite primary key containing a partition key and sort key.

With a composite primary key, the pair identifies the item uniquely. Many items can share the partition-key value while using different sort keys. A partition key is a logical value; it is not a guarantee that an entire item collection always occupies one physical partition.

Q9. How does Query differ from Scan?

Query requires equality on the partition key and can narrow results with a sort-key condition. Scan evaluates items across a table or index. Both paginate, and both can apply filters after evaluation.

A Query is efficient when its key range matches the request. A filter that discards most of that range is a signal to reconsider the index. Query is not the only way to read: GetItem is the direct choice for a known complete primary key.

Q10. How does DynamoDB differ from Aurora?

DynamoDB uses key-value and document models with explicit key-based access paths. Aurora provides managed relational databases compatible with MySQL or PostgreSQL, including relational joins and SQL query planning.

DynamoDB also supports PartiQL for SQL-compatible syntax, so “one uses SQL and the other cannot” is too simplistic. Choose based on data relationships, query flexibility, scaling requirements and operations, rather than claiming that one database is universally faster. Avoid confusing Aurora's storage architecture with DynamoDB partition-key design.

Q11. Name five ways to read data from DynamoDB

Use the actual API names: BatchGet and TransactRead are not the service operation names. PartiQL and vector search are additional interfaces for their supported operations.

Q12. What are projections?

An index projection specifies which attributes the index stores: KEYS_ONLY, INCLUDE or ALL. Table primary-key attributes and index-key attributes are included automatically. Projection controls attributes, not which arbitrary items are returned by a filter.

A request's ProjectionExpression instead controls the attributes returned to the caller. On a base-table read, requesting fewer attributes reduces payload size but does not lower read capacity for the evaluated item. Keeping index entries small can reduce index storage and read costs.

Q13. How does DynamoDB protect against data loss?

DynamoDB replicates regional data across Availability Zones. On-demand backups and point-in-time recovery address recovery from accidental changes, while global tables support regional resilience. These mechanisms solve different failures and do not make every application mistake reversible by default.

PITR has a configurable 1 to 35 day window and restores into a new table. Enable it before an incident, rehearse the restore and application cutover, and set deletion protection explicitly. The PITR guide explains what must be configured again after restoration.

Q14. Does DynamoDB support atomic updates?

Yes. An UpdateItem operation atomically updates one item. Update expressions can set or remove attributes, add supported values and manipulate nested document paths. A ConditionExpression can ensure the existing item matches an expected version or state.

You do not need a multi-item transaction for an atomic change to one item. An unconditional counter increment is atomic but not inherently idempotent: retrying after an ambiguous response can apply the increment again. Design retry behavior accordingly.

Q15. What are DynamoDB Streams?

Streams capture item-level inserts, updates and deletes for 24 hours. Records can contain keys, old images, new images or both. Ordering is guaranteed for changes to an individual item, not globally across all items.

A change appears once in the stream, but a Lambda consumer processes records at least once and may see a repeated delivery. Make consumers idempotent and monitor their processing delay. Streams are useful for notifications, derived views and other post-write work.

Q16. What are the capacity modes and current pricing considerations?

On-demand charges for consumed request units and is the starting point for most workloads. Provisioned mode charges for allocated read and write capacity, with optional auto scaling. The choice is not simply “development versus production”; measure utilization and traffic variability.

In US East (N. Virginia), Standard on-demand throughput is $0.625 per million write request units and $0.125 per million read request units. Those are units, not necessarily API calls: size, consistency and transactions change consumption. The AWS pricing page lists other charges and Regions.

The always-free 25 RCU and 25 WCU allowance applies to provisioned Standard capacity, not on-demand requests. Standard's storage allowance is separate. Older answers using double the current on-demand unit prices predate the November 2024 price cut.

Q17. What is the maximum item size?

400 KB, including attribute names and values. This is a fixed constraint. Nested maps, lists and binary values count toward it; JSON wire representation and stored item size are not necessarily identical.

For a large entity, store attachments in S3 or split independently accessed parts into related items. Explain the resulting read and atomicity trade-offs rather than presenting splitting as a free workaround.

Q18. What does DynamoDB auto scaling do?

Application Auto Scaling adjusts provisioned capacity for tables and GSIs toward a target utilization, within configured minimum and maximum bounds. It is distinct from on-demand capacity mode.

Scaling reacts to metrics and takes time. Sudden peaks can still throttle, and increasing provisioned throughput does not fix every hot key. Discuss peak planning, warm throughput and request distribution when asked how to prepare for a launch.

Q19. What is DynamoDB Local?

DynamoDB Local is a downloadable development and testing implementation that accepts DynamoDB API calls at a local endpoint. It is useful for item operations, expressions and data-model tests without calling the hosted service.

It does not reproduce all production features or limits. Do not use it as proof of production throttling behavior, global replication, PITR or native vector search. Follow the local setup guide and validate service-specific behavior against AWS.

Q20. How many GSIs can a table have?

The default is 20 global secondary indexes per table, and the quota is adjustable. The fixed maximum for local secondary indexes is five, and LSIs must be defined when creating the table.

An interview answer should distinguish adjustable quotas from hard constraints. A larger allowed index count also does not mean every new index is a good design: each adds storage and write maintenance.

Q21. What is encryption at rest?

It protects stored table data using encryption and is always enabled in DynamoDB. Key options include an AWS owned key, the AWS managed aws/dynamodb key and a customer managed KMS key. The choice affects control, auditing, permissions and cost.

Encryption does not replace authorization or recovery controls. A principal with permitted write access can still change data. Disabling a customer managed key can also disrupt access, so key lifecycle management is part of operating the table.

Q22. What is DAX?

DynamoDB Accelerator is a managed cache for DynamoDB. It is useful for repeated eventually consistent reads when cache hits and the application's freshness requirements justify the cluster cost.

DAX is a separate service with a client and cluster configuration. It does not make all requests faster, and strongly consistent reads do not receive the same cache benefit. Explain the workload and consistency requirement before recommending it.

Q23. What are global tables, and what is MRSC?

Global tables replicate data across Regions. MREC uses asynchronous replication with last-writer-wins conflict resolution. MRSC synchronously replicates writes before acknowledging them and supports strongly consistent reads in replica Regions.

MRSC requires three participating Regions: three replicas, or two replicas and a witness. It does not support transactions, TTL or LSIs, and GSIs are still eventually consistent. The consistency mode cannot be changed after creation. The global tables guide covers the design implications.

Q24. What does BatchGetItem return?

BatchGetItem reads up to 100 items by complete primary key, across one or more tables, with a 16 MB response limit. It may return partial results and UnprocessedKeys, which the caller should retry with backoff.

Results are not ordered like the input, and missing items are not returned. Include keys in the requested projection so results can be matched to requests. Batch reads are not a substitute for a transactional read when atomicity across the set matters.

Q25. How do GSIs and LSIs differ?

A GSI can use different partition and sort keys from the base table and supports eventually consistent reads. It has separate throughput allocation in provisioned mode. An LSI shares the table's partition key, uses an alternative sort key and supports strongly or eventually consistent reads.

LSIs must be created with the table and impose a 10 GB limit on each item collection, including the base items and LSI entries sharing a partition-key value. GSIs can be added later. Both index design and projected attributes affect cost.

Q26. What are DynamoDB's transaction limits?

TransactWriteItems and TransactGetItems support up to 100 unique items and 4 MB of aggregate item data within one account and Region. A transaction cannot contain two actions on the same item, such as a separate condition check and update of that item.

Transactions consume twice the ordinary strongly consistent read or write units for the same item sizes. MREC transactions are atomic only in their originating Region; replication does not preserve a cross-Region transaction boundary. MRSC does not support transactions. See DynamoDB transactions.

Q27. What is warm throughput?

Warm throughput describes the read and write rates a table or index can support immediately. It is distinct from the billing mode, provisioned capacity and an on-demand maximum-throughput setting.

For a predictable launch spike, you can request pre-warming before traffic arrives, subject to quotas and a one-time charge. It prepares capacity for the peak; it does not repair poor key distribution or override a deliberately configured throughput cap.

Q28. Can you limit on-demand spending?

You can configure maximum read and write throughput for an on-demand table or GSI. Excess requests can be throttled, so the application must handle that outcome. These settings are best-effort throughput targets rather than guaranteed hard request ceilings.

They are also not a complete budget limit: storage, backups, replication and other charges still exist. Combine throughput settings with billing alerts and application controls. Use the pricing calculator to estimate the whole workload.

Q29. What are resource-based policies?

A resource-based policy attaches permissions to a DynamoDB table or stream. It complements identity-based IAM policies and supports authorized cross-account access. A table policy can cover the table's indexes.

Permissions still interact with explicit denies, organizational controls and encryption settings. For example, cross-account access through resource policies is not supported for a table encrypted with the AWS managed key. Resource policies do not make a table publicly accessible by default.

Q30. Why can a table throttle below its total capacity?

Traffic may concentrate on a hot partition or GSI key range, or a GSI may be the bottleneck. A physical partition supports up to 3,000 read units and 1,000 write units per second; request throughput depends on item size and consistency.

Inspect ThrottlingReasons and its resource ARN. Distinguish provisioned-capacity exhaustion, account quota, key-range pressure and an on-demand maximum. Use the corresponding CloudWatch metric and Contributor Insights before deciding to increase capacity, pre-warm or shard writes.

Q31. How should an application paginate a Query?

Continue while LastEvaluatedKey is present, passing it as ExclusiveStartKey to the next request. Query evaluates up to 1 MB per call, or the requested Limit number of items, before filters.

A filtered page can contain no items and still have a continuation key. Limit is not a promise to return that many matching records. Test this case explicitly instead of stopping pagination whenever Items is empty.

Q32. What are multi-attribute GSI keys?

A GSI can use up to four partition-key attributes and four sort-key attributes. All partition components need equality conditions, while sort-key conditions follow the declared order from left to right.

This reduces the need to concatenate synthetic GSI keys from existing fields. It does not change the base table's primary-key structure or enable arbitrary predicate combinations. Explain why a particular component order supports the application's requests.

Q33. How do you prevent concurrent lost updates?

Use a conditional write, often with a version attribute. Read the item and its version, then update only if the stored version still matches. On a condition failure, reload or return a conflict according to the application's behavior.

For a create-only operation, attribute_not_exists(pk) can prevent an existing item from being replaced. A read followed by an unconditional write is not equivalent because another writer can change the item in between.

Q34. What guarantees does TTL provide?

TTL identifies items for asynchronous deletion using a Number containing Unix epoch seconds. Expired items are typically deleted within a few days, and they remain readable until deletion. The application must enforce exact expiration rules itself.

The original deletion consumes no write capacity. MREC global tables charge for replicated deletes in other Regions; MRSC does not support TTL. TTL is useful for cleanup and retention, not a precise job scheduler.

Q35. How would you design a small order service?

Start with concrete requests: get one order, list a customer's recent orders, find warehouse orders awaiting fulfillment and reserve inventory. Choose base keys and indexes for those reads, then identify which writes require conditions or transactions.

Discuss a popular customer or warehouse, GSI consistency, duplicate payment callbacks, pagination and retries. Include PITR, deletion protection, throttling alarms and a capacity estimate. A strong design answer explains how it behaves during concurrency and failures, not just the table's attribute names.