Question 1

What is DynamoDB?

Accepted Answer

DynamoDB is a fully managed, serverless key-value and document database offering single-digit millisecond latency at any scale, with automatic replication across three Availability Zones, no servers to manage, and capacity that can scale on demand. It is accessed over an API rather than a SQL connection. The framing to lead with is that it trades query flexibility for guaranteed performance at scale: latency stays flat whether the table holds a thousand items or a billion, because every access is a key lookup rather than a scan.

Question 2

What is a partition key and a sort key?

Accepted Answer

The partition key determines which physical partition an item lives on, via a hash of its value. The sort key orders items within a partition and enables range queries. Together they form the primary key, which must be unique. A table can have a partition key alone, or a composite key of both. The design consequence is that all items sharing a partition key are stored together and can be retrieved with one efficient Query, ordered by sort key. That single fact drives every DynamoDB data model, including single-table design.

Question 3

What is a hot partition and how do you avoid it?

Accepted Answer

A hot partition is one receiving a disproportionate share of traffic because many requests share a partition key value — a single popular product, or a key that is a date. It limits throughput because per-partition capacity is bounded. Avoid it by choosing high-cardinality, evenly-accessed partition keys, or by write sharding with a suffix. Adaptive capacity mitigates this by isolating frequently-accessed items and reallocating capacity, so it is less catastrophic than it once was, but a genuinely skewed key still limits you. Naming write sharding — appending a random suffix and querying all shards — is the concrete remedy.

Question 4

What is the difference between Query and Scan?

Accepted Answer

Query retrieves items by partition key, optionally filtered by a sort key condition, reading only the matching items — efficient and cheap. Scan reads every item in the table or index and then applies filters, consuming capacity proportional to the whole table regardless of how few items match. The consequence to state plainly is that Scan in production is almost always a design failure, because cost and latency grow with table size rather than result size. If you need a Scan, the access pattern needs an index or a different key design.

Question 5

What is the difference between a Global Secondary Index and a Local Secondary Index?

Accepted Answer

A GSI has a different partition key from the base table, can be created at any time, has its own provisioned capacity, and is eventually consistent. An LSI shares the table's partition key with a different sort key, must be created with the table, shares the table's capacity, supports strongly consistent reads, and imposes a 10 GB limit per partition key value. The practical guidance is to prefer GSIs because they can be added later and have no item-collection size limit. The 10 GB constraint on LSIs is the specific fact interviewers check, since exceeding it fails writes for that partition key.

Question 6

What are the capacity modes and how do you choose?

Accepted Answer

Provisioned mode reserves read and write capacity units, is cheaper for predictable steady traffic, and supports auto scaling and reserved capacity discounts. On-demand mode charges per request with no capacity planning, scales instantly, and suits unpredictable or spiky traffic and new applications where the pattern is unknown. The rough guidance is that on-demand costs more per request but avoids over-provisioning, so the break-even depends on utilisation — a table at consistently high utilisation is cheaper provisioned. Starting on-demand and moving to provisioned once the pattern is understood is the pragmatic sequence.

Question 7

What are read and write capacity units?

Accepted Answer

One write capacity unit is one write per second for an item up to 1 KB. One read capacity unit is one strongly consistent read per second for an item up to 4 KB, or two eventually consistent reads. Transactional operations consume double. Larger items consume proportionally more. The eventually-consistent-costs-half rule is the practical lever: reads that tolerate slight staleness cost half as much, which at scale is a substantial saving. Knowing the 4 KB and 1 KB boundaries lets you estimate capacity from item size, which is the actual skill.

Question 8

What consistency options does DynamoDB offer?

Accepted Answer

Eventually consistent reads are the default and may not reflect a very recent write, but cost half as much. Strongly consistent reads return the latest value and cost double, but are not available on global secondary indexes and cannot be served from a different region in a global table. The GSI restriction is the fact that catches people: an index query cannot be strongly consistent, so any read-after-write requirement must go through the base table's primary key. That constraint often shapes the data model.

Question 9

What is single-table design and why is it used?

Accepted Answer

Single-table design stores multiple entity types in one table, using generic partition and sort key attributes with type prefixes so that related entities share a partition key and can be retrieved together in one Query. It minimises round trips and takes advantage of DynamoDB's strength at retrieving item collections. The honest position is that it is powerful but hard to evolve and hard for new team members to read, and AWS guidance has softened towards using multiple tables where access patterns are simple. Being able to argue both sides is better than advocating it unconditionally.

Question 10

How do you model data for DynamoDB?

Accepted Answer

Start from the access patterns, not the entities: list every query the application must perform, then design keys and indexes so each is a single Query or GetItem. Denormalise and duplicate data where it is read together. Use composite sort keys for hierarchies, and overloaded GSIs to serve several patterns with one index. The reversal from relational modelling is the point — you normalise for writes in SQL and denormalise for reads in DynamoDB. Interviewers ask for the access-pattern list first, and a candidate who starts drawing entities has the method backwards.

Question 11

What are DynamoDB Streams?

Accepted Answer

Streams capture an ordered, time-ordered sequence of item-level changes — insert, modify, remove — retained for 24 hours, with configurable view types including old image, new image or both. Lambda can consume them with an event source mapping, and they are the basis for global tables. The main uses are propagating changes to another store, maintaining aggregates, and triggering workflows. The reliability detail is that Lambda processes stream shards in order per partition key, so ordering is preserved per item, which is often the property that matters.

Question 12

What are DynamoDB global tables?

Accepted Answer

Global tables replicate a table across regions with multi-active writes, so any region accepts writes and changes propagate to the others, typically within a second. Conflicts are resolved last-writer-wins based on timestamp. Last-writer-wins is the critical caveat: concurrent writes to the same item in different regions silently discard one. Any design with genuinely concurrent cross-region writes to the same item needs application-level conflict handling, and interviewers probe whether you know that.

Question 13

What are DynamoDB transactions?

Accepted Answer

TransactWriteItems and TransactGetItems provide ACID guarantees across up to 100 items in one or more tables in a single account and region, with all-or-nothing semantics and optional condition checks. They consume double the capacity of the equivalent non-transactional operations. The limits — 100 items, single region, double capacity — are what shape their use: transactions are for genuine invariants like a balance transfer, not a default. Conditional writes with a single item are cheaper and cover many cases people reach for transactions to solve.

Question 14

What is a conditional write and why is it useful?

Accepted Answer

A conditional write applies only if a condition expression evaluates true — for example put this item only if it does not already exist, or decrement stock only if it is above zero. It provides optimistic concurrency and atomicity for a single item without a transaction. It is the mechanism behind idempotency: writing a processed-message record with attribute_not_exists on the key makes duplicate processing fail cheaply. Naming that use is what connects the feature to a real problem interviewers care about.

Question 15

What is DynamoDB Accelerator (DAX)?

Accepted Answer

DAX is an in-memory cache in front of DynamoDB, API-compatible so the client change is minimal, reducing read latency from single-digit milliseconds to microseconds for cached items. It provides an item cache and a query cache and handles write-through invalidation for its own writes. The caveat is that DAX is eventually consistent with the underlying table and does not see writes made directly to DynamoDB bypassing DAX, so stale reads are possible. It also runs as a cluster in your VPC, which reintroduces some infrastructure to manage.

Question 16

What is TTL in DynamoDB?

Accepted Answer

Time to live marks items for automatic deletion after a timestamp stored in a designated numeric attribute. Deletion is asynchronous and free — it consumes no write capacity — but can take up to 48 hours after expiry, and expired items may still be returned by reads until removed. The delay is the fact that matters: TTL is a cost-management mechanism, not a correctness one, so any query that must not return expired items needs an application-level filter. TTL deletions also appear in Streams, which is useful for archival workflows.

Question 17

How do you back up and restore DynamoDB?

Accepted Answer

On-demand backups create a full backup with no performance impact and are retained until deleted. Point-in-time recovery keeps continuous backups for up to 35 days, allowing restore to any second. Both restore to a *new* table. AWS Backup can manage both centrally with cross-region and cross-account copies. The restore-to-a-new-table behaviour shapes the recovery runbook: you restore then cut over, and restore time scales with table size. Cross-account backup copies are the control that survives a compromised account, which is the scenario worth designing for.

Question 18

What are the item and attribute limits in DynamoDB?

Accepted Answer

Maximum item size is 400 KB including attribute names. Partition key values up to 2048 bytes and sort key up to 1024 bytes. A maximum of 20 GSIs and 5 LSIs per table. Query and Scan return at most 1 MB per call before pagination. The 400 KB item limit is what forces large payloads into S3 with a pointer in the item — the claim-check pattern. The 1 MB page limit is why any code reading a large collection must handle LastEvaluatedKey pagination, which is a common bug when it is omitted.

Question 19

How do you handle items larger than 400 KB?

Accepted Answer

Store the large payload in S3 and keep only a reference — bucket, key, size, checksum — in the DynamoDB item. Alternatively split the item across several with a shared partition key and a sort key sequence, reassembled on read, though that complicates atomicity. The S3 pointer is almost always the right answer because it also reduces read cost, since you no longer consume capacity for data most queries do not need. Naming that cost benefit alongside the size limit is the fuller answer.

Question 20

What is adaptive capacity?

Accepted Answer

Adaptive capacity automatically reallocates throughput toward partitions receiving more traffic and can isolate frequently-accessed items onto their own partitions, so moderately uneven access no longer immediately causes throttling. It works automatically with no configuration. It reduced but did not eliminate the hot-partition problem — a genuinely extreme skew still throttles, and there is a ceiling per partition. Saying that it mitigates rather than solves the problem is the accurate position.

Question 21

What causes throttling in DynamoDB and how do you diagnose it?

Accepted Answer

Exceeding provisioned capacity on a table or index, exceeding per-partition limits due to a hot key, or exceeding on-demand's ability to scale for a sudden extreme spike. Diagnose with CloudWatch ThrottledRequests and consumed versus provisioned capacity, and CloudWatch Contributor Insights to identify the most-accessed keys. Contributor Insights is the specific tool that identifies the hot key by name, which turns a capacity mystery into a data-model fix. Naming it rather than only the CloudWatch metrics is what shows practical debugging experience.

Question 22

How does DynamoDB auto scaling work?

Accepted Answer

In provisioned mode, application auto scaling adjusts read and write capacity to keep utilisation near a target percentage, within configured minimum and maximum bounds. It reacts to sustained change rather than instantaneous spikes, so a sudden burst can still throttle before capacity increases. The lag is the limitation to name: auto scaling responds over minutes, so a step-function traffic increase will throttle in the interim. For known spikes, scheduled scaling or on-demand mode is the correct answer rather than relying on reactive scaling.

Question 23

What is the difference between BatchGetItem, BatchWriteItem and transactions?

Accepted Answer

Batch operations group up to 100 gets or 25 writes into one request for efficiency, but each item succeeds or fails independently and unprocessed items are returned for retry. Transactions are all-or-nothing across up to 100 items with ACID guarantees and double capacity cost. The unprocessed-items behaviour is the trap: a batch call that returns 200 may still have failed some items, and code that ignores UnprocessedItems silently loses writes. Naming that requirement to retry is the practical detail.

Question 24

How is DynamoDB priced?

Accepted Answer

Provisioned mode charges for provisioned read and write capacity per hour plus storage per GB-month. On-demand charges per million read and write request units plus storage. Additional charges apply for GSIs, Streams reads, global table replicated writes, backups, PITR, DAX and data transfer. Global tables are the cost surprise worth naming: every write is charged in every replica region as a replicated write unit, so a three-region global table roughly triples write cost. Storage of GSIs is also frequently forgotten.

Question 25

What is a sparse index and why is it useful?

Accepted Answer

A sparse index is a GSI whose key attribute exists on only some items, so only those items appear in the index. It is used to query a small subset efficiently — for example indexing only orders with status "pending" by writing the index attribute only while pending and removing it when complete. It is one of the most elegant DynamoDB patterns because it turns "find all items in state X" from a Scan with a filter into a small, cheap Query. Recognising the pattern by name is a strong signal of real modelling experience.

Question 26

What is index overloading?

Accepted Answer

Index overloading reuses one GSI to serve several access patterns by writing different values into the generic index key attributes depending on the entity type — so GSI1PK might hold a customer ID for one entity type and a status for another, with the sort key disambiguating. It exists because there is a limit of 20 GSIs per table and each has a cost, so packing patterns into shared indexes is how single-table designs stay within budget. The trade-off is readability, which is the main criticism of single-table design.

Question 27

How do you implement pagination in DynamoDB?

Accepted Answer

Query and Scan return at most 1 MB and a LastEvaluatedKey when more data exists; you pass it back as ExclusiveStartKey to continue. Client-facing pagination should encode that key as an opaque cursor rather than using offset-based pages, which DynamoDB does not support. There is no offset or page number, so implementing "jump to page 7" requires a different design or a separate index. Explaining why cursor pagination is the only efficient model, rather than treating it as a limitation, is what shows understanding.

Question 28

How do you secure DynamoDB?

Accepted Answer

IAM policies scoped to specific tables and indexes, with fine-grained access control using condition keys such as dynamodb:LeadingKeys to restrict a user to their own items. Encryption at rest is on by default with an option for a customer-managed KMS key. VPC endpoints keep traffic off the internet, and CloudTrail data events record item-level access. Fine-grained access control with LeadingKeys is the feature to name for multi-tenant applications, since it enforces tenant isolation in IAM rather than in application code. That is a genuinely stronger control than filtering in the query layer.

Question 29

What is DynamoDB export to S3 and why use it?

Accepted Answer

Export to S3 writes a full or incremental table export to S3 in DynamoDB JSON or Ion format without consuming read capacity, using the continuous backups. It is the way to run analytics with Athena, Glue or EMR without scanning the table and affecting production. The no-capacity-consumed property is the point: previously, analytics on DynamoDB meant a Scan that competed with production traffic. Incremental exports make ongoing analytics pipelines practical rather than a nightly full dump.

Question 30

How would you implement a leaderboard in DynamoDB?

Accepted Answer

DynamoDB cannot sort across partitions, so a global ranked list needs a design: either a single partition key such as the game and season with score as the sort key — accepting the hot-partition risk and 10 GB item collection limit — or maintain the ranking in ElastiCache Redis sorted sets and use DynamoDB as the durable store. Recognising that DynamoDB is the wrong tool for ranked queries and proposing Redis for the ranking is the stronger answer. Interviewers use this question to see whether you force the data model onto the database or pick the right store for the access pattern.

Question 31

How would you implement a many-to-many relationship?

Accepted Answer

With an adjacency list: store both directions as items sharing a partition key. For students and courses, write items with partition key STUDENT#id and sort key COURSE#id, and a GSI inverting them so you can query courses by student and students by course with the same table. The inverted GSI is the idiomatic pattern and it is exactly the kind of modelling question DynamoDB interviews use. Being able to write the key structure rather than describing it abstractly is what demonstrates real experience.

Question 32

What happens if you need a query pattern you did not design for?

Accepted Answer

You add a GSI if the new pattern can be served by a different key — which is possible without downtime, though it backfills and costs capacity — or you restructure and migrate data. If it requires arbitrary ad-hoc querying, export to S3 and query with Athena, or replicate to a relational store or OpenSearch. The honest answer includes that DynamoDB punishes unanticipated access patterns, which is the main argument for a relational database when requirements are uncertain. Naming replication to OpenSearch for full-text and ad-hoc search is the practical complement.

Question 33

What is the difference between DynamoDB and Amazon Keyspaces or DocumentDB?

Accepted Answer

DynamoDB is AWS's native key-value and document store with its own API. Keyspaces is a managed Cassandra-compatible service for teams with existing CQL workloads. DocumentDB is MongoDB-compatible for teams with existing MongoDB applications. The compatible services exist mainly for migration and skills reuse. The recommendation for new development is DynamoDB, because it is the most deeply integrated and genuinely serverless. Choosing a compatibility service should be driven by an existing codebase or team expertise rather than by preference for the query language.

Question 34

How do you migrate from a relational database to DynamoDB?

Accepted Answer

Enumerate access patterns first and design the key schema for them — a table-by-table translation will perform badly. Then migrate with DMS or a custom pipeline, run dual writes or CDC to keep both in sync, validate with reconciliation, shift reads gradually, then writes. Expect application changes, since joins must be resolved by denormalisation. The point interviewers want is that this is a data-model redesign, not a data movement exercise. A candidate who proposes DMS and nothing else has missed that the schema is the hard part and the tool is the easy part.

Question 35

What is optimistic locking in DynamoDB?

Accepted Answer

You store a version attribute on the item and write with a condition that the version matches the value you read, incrementing it on success. A concurrent writer whose version is stale fails the condition and must re-read and retry, preventing lost updates without any locking. It is the standard concurrency control for DynamoDB because there are no row locks, and the SDK document mappers implement it for you. Naming the retry requirement — the caller must handle the conditional check failure — is the part people omit.

Question 36

What is DynamoDB Contributor Insights?

Accepted Answer

Contributor Insights produces CloudWatch metrics identifying the most frequently accessed and most throttled partition keys on a table or index, so you can see which specific keys are causing hot-partition problems. It answers the question CloudWatch capacity metrics cannot: which key is hot. That turns "we are being throttled at 60% of provisioned capacity" from a mystery into a specific data-model fix, which is why it is the right tool to name.

Question 37

How do you handle a counter that many clients increment?

Accepted Answer

A single item has a per-item write ceiling, so a very hot counter throttles. Shard it: write to one of N counter items chosen at random and sum them on read. Alternatively aggregate in a stream consumer, or use ElastiCache for the live count with DynamoDB as the durable record. The sharded counter is the canonical pattern and mirrors the equivalent in other NoSQL stores. Choosing N as a trade-off between write throughput and read cost — since reading requires N gets — is the detail that shows you have implemented it.

Question 38

What are DynamoDB best practices for cost control?

Accepted Answer

Choose the right capacity mode for the traffic shape and revisit it; use eventually consistent reads where staleness is acceptable to halve read cost; project only needed attributes into GSIs rather than ALL; avoid Scans; use TTL to expire data rather than storing it forever; keep items small with large payloads in S3; and use reserved capacity for stable provisioned workloads. GSI projection is the underused lever: projecting ALL duplicates every attribute into the index, doubling storage and write cost. Projecting only the keys and the few attributes the index query needs is often a large saving.

Question 39

What is a projection expression and why does it matter?

Accepted Answer

A projection expression limits which attributes are returned by a read, so the response is smaller and the client does less work. It does not reduce consumed read capacity, however — DynamoDB reads the whole item and charges for it, then filters the response. That capacity is charged on the full item, not the projection, is the fact interviewers use to check whether you understand the cost model. To actually reduce read cost you need smaller items or a GSI with a narrow projection, not a projection expression.

Question 40

Design a DynamoDB data model for an e-commerce order system.

Accepted Answer

List the access patterns first: get order by ID, list orders by customer newest first, list items in an order, get product by ID, list orders by status for operations. Then a single table with PK and SK: CUSTOMER#id / ORDER#timestamp#id for the customer view, ORDER#id / ITEM#id for the line items sharing the order partition, and a GSI keyed on status and timestamp — made sparse so only open orders are indexed. Large product descriptions live in S3 with a pointer, TTL expires abandoned carts, and Streams feed an analytics pipeline. The closing scenario. The markers of a strong answer are enumerating access patterns before touching the schema, using the sort key to co-locate an order with its items so one Query returns both, and making the status index sparse so it stays small and cheap.

AWS DynamoDB Interview Questions and Answers

How to use this set