Topics / ☁️AWS Cloud Practitioner

Amazon DynamoDB — Managed NoSQL

By Pritesh Yadav 19 min read —

Amazon DynamoDB is a fully managed, serverless NoSQL key-value database that gives you single-digit-millisecond response times at any scale. There are no servers to patch, it scales automatically, and you never write SQL or do table joins. The hardest exam points are not what DynamoDB does, but telling it apart from look-alike services: RDS (relational), ElastiCache (in-memory cache), DAX (DynamoDB's own cache), and the difference between on-demand and provisioned capacity.

Most confused here: DynamoDB = NoSQL key-value (no joins, no SQL); RDS = relational/SQL. DAX = a cache built into DynamoDB; ElastiCache = a general-purpose cache for other databases. On-demand = pay-per-request with no planning; provisioned = you set capacity up front. Global Tables = multi-region replication (not a backup).

Q1 A team is choosing a database for a mobile game leaderboard that stores millions of player records and is looked up only by a unique player ID, never with complex multi-table queries. They need consistent single-digit-millisecond reads at massive scale with no servers to manage. Which AWS service fits best?

  1. Amazon DynamoDB
  2. Amazon RDS for PostgreSQL
  3. Amazon Redshift
  4. Amazon Aurora
Answer: A
Why A is correct: DynamoDB is a fully managed NoSQL key-value database. When data is accessed by a simple key (the player ID) at huge scale and needs millisecond latency with zero server management, it is the natural fit.
Why the other options are wrong:
  • B — RDS for PostgreSQL is a relational SQL database meant for structured data and joins; it is not the best match for a simple key lookup at this scale and still needs more capacity planning.
  • C — Redshift is a data warehouse for analytics over large historical datasets, not for fast single-record lookups.
  • D — Aurora is a relational (MySQL/PostgreSQL-compatible) database; it is SQL-based and not a key-value store.
Common trap: Aurora is also "managed and scalable," so candidates pick it. But Aurora is relational; the key signal here is "key-value, no complex queries," which points to DynamoDB.

Q2 An application using DynamoDB is reading the same small set of "hot" items millions of times per second, and the team wants to push read latency from milliseconds down to microseconds without changing the database. Which service adds an in-memory cache designed specifically for DynamoDB?

  1. Amazon ElastiCache for Redis
  2. Amazon CloudFront
  3. AWS Global Accelerator
  4. Amazon DynamoDB Accelerator (DAX)
Answer: D
Why D is correct: DAX (DynamoDB Accelerator) is a fully managed in-memory cache built into DynamoDB. It sits in front of the table and serves cached reads in microseconds instead of milliseconds, with no application rewrite.
Why the other options are wrong:
  • A — ElastiCache is a general-purpose cache, but it is not purpose-built for DynamoDB and would require you to manage cache logic in your application code.
  • B — CloudFront is a content delivery network that caches web content at edge locations, not database reads.
  • C — Global Accelerator improves network routing to your application endpoints; it does not cache database queries.
Common trap: ElastiCache and DAX are both in-memory caches, so they look interchangeable. DAX is the DynamoDB-native answer ("microseconds, no app changes"); ElastiCache is the generic cache for other databases.

Q3 A company is launching a new app worldwide and cannot predict traffic — it may spike unpredictably and then drop to almost nothing. They want a DynamoDB billing mode where they pay only for the read and write requests they actually use, with no capacity planning. Which capacity mode should they choose?

  1. Provisioned capacity
  2. Reserved capacity
  3. On-demand capacity
  4. Spot capacity
Answer: C
Why C is correct: On-demand capacity charges per request and scales instantly to whatever traffic arrives. It is ideal when traffic is unpredictable or spiky because you do not have to estimate or reserve throughput in advance.
Why the other options are wrong:
  • A — Provisioned capacity requires you to set expected read/write throughput ahead of time, which is hard when traffic is unknown and risks under- or over-provisioning.
  • B — "Reserved capacity" is a discount on provisioned throughput for steady, predictable workloads — the opposite of unpredictable traffic.
  • D — "Spot capacity" is not a DynamoDB billing mode (Spot is an EC2 concept).
Common trap: Candidates borrow EC2 terms like "Spot" and "Reserved." For DynamoDB the two real modes are on-demand (pay-per-request, unpredictable traffic) and provisioned (planned capacity, steady traffic).

Q4 A global retailer wants its DynamoDB-based shopping cart to be readable and writable with low latency from users in North America, Europe, and Asia, with data kept in sync across all three regions. Which DynamoDB feature provides this multi-region, active-active replication?

  1. DynamoDB point-in-time recovery
  2. DynamoDB Global Tables
  3. DynamoDB Streams
  4. Cross-Region Read Replicas
Answer: B
Why B is correct: Global Tables automatically replicate a DynamoDB table across multiple AWS regions, and all replicas can be read and written (active-active). This gives users in each region fast local access with data kept in sync.
Why the other options are wrong:
  • A — Point-in-time recovery is a backup feature that lets you restore to an earlier moment; it does not replicate across regions for low latency.
  • C — DynamoDB Streams capture a log of item changes for triggers/processing; they are a building block, not a turnkey multi-region table.
  • D — "Read Replicas" is an RDS/Aurora concept, not the DynamoDB term, and would only scale reads, not provide active-active multi-region writes.
Common trap: "Read Replicas" sounds like the multi-region answer, but that is RDS terminology. For DynamoDB multi-region the keyword is Global Tables.

Q5 A developer migrating from a relational database asks how to write a query in DynamoDB that joins a "Customers" table to an "Orders" table the way SQL does. What is the correct guidance?

  1. DynamoDB supports SQL JOINs once you enable the relational mode
  2. DynamoDB performs joins automatically in the background for every query
  3. You must attach Amazon Redshift to DynamoDB to enable joins
  4. DynamoDB does not support SQL joins; you model data so it is retrieved by key without joins
Answer: D
Why D is correct: DynamoDB is a NoSQL database and does not do SQL-style joins across tables. You design (model) your data so the records you need are fetched directly by key, often storing related data together.
Why the other options are wrong:
  • A — There is no "relational mode" that adds joins; DynamoDB is non-relational by design.
  • B — DynamoDB never performs cross-table joins automatically; that is simply not how a key-value store works.
  • C — Redshift is a separate analytics warehouse; bolting it on does not give DynamoDB join capability.
Common trap: Candidates from a SQL background assume any database can join. The defining trait of DynamoDB on the exam is "NoSQL, no joins" — if you need joins, that signals a relational service like RDS.

Q6 A team needs a database to store user session state for a high-traffic web application — small items, accessed by a session key, requiring very fast and reliable reads and writes that persist even if a cache node restarts. Which fully managed service is the best persistent fit?

  1. Amazon DynamoDB
  2. Amazon RDS for MySQL
  3. Amazon S3
  4. Amazon EFS
Answer: A
Why A is correct: Storing session state by a session key is a classic DynamoDB use case: small key-value items, fast reads/writes, automatic scaling, and durable persistence so sessions survive restarts.
Why the other options are wrong:
  • B — RDS is relational and heavier than needed for simple key-based session lookups at high scale.
  • C — S3 is object storage for files and is not designed for the millisecond, high-frequency read/write pattern of live sessions.
  • D — EFS is a shared file system for files mounted by servers, not a key-value store for session records.
Common trap: ElastiCache is also a known session-store option, but it is an in-memory cache; if durability ("persist even if a node restarts") matters, DynamoDB is the safer managed choice the exam expects.

Q7 A startup wants to avoid managing servers, patching, replication setup, and capacity scaling for their database. They want AWS to handle all of that while they just store and retrieve key-value data. Which phrase best describes why DynamoDB meets this need?

  1. It is a self-managed database you install on EC2
  2. It is a relational database that requires a DB instance class
  3. It is a fully managed, serverless NoSQL database
  4. It is an in-memory cache that loses data on restart
Answer: C
Why C is correct: DynamoDB is fully managed and serverless — there are no servers, instances, or patching for you to handle. AWS runs the infrastructure; you only work with tables and data.
Why the other options are wrong:
  • A — You never install DynamoDB on EC2; that would be self-managed, the opposite of what is described.
  • B — Choosing a "DB instance class" is an RDS/Aurora task; DynamoDB has no instance to size.
  • D — DynamoDB persists data durably; it is not an in-memory cache that loses data on restart.
Common trap: "DB instance class" wording is a giveaway for RDS, not DynamoDB. DynamoDB's identity is serverless with no instances to choose.

Q8 An application has a very steady, predictable workload of about 2,000 reads and 1,000 writes per second, all day, every day. The team wants the lowest cost and is comfortable estimating throughput in advance. Which DynamoDB capacity choice is most cost-effective?

  1. On-demand capacity
  2. Provisioned capacity
  3. Burst-only capacity
  4. Elastic capacity
Answer: B
Why B is correct: Provisioned capacity lets you set a fixed read/write throughput that matches a steady, predictable workload, usually at a lower cost than pay-per-request. Predictable traffic is exactly when provisioned wins on price.
Why the other options are wrong:
  • A — On-demand is great for unpredictable spikes but generally costs more per request for steady, well-known traffic.
  • C — "Burst-only capacity" is not a DynamoDB capacity mode.
  • D — "Elastic capacity" is not a named DynamoDB billing mode.
Common trap: On-demand is marketed as "no planning needed," so people default to it. But for steady, predictable load the cheaper, exam-correct answer is provisioned.

Q9 A solutions team needs to decide between DynamoDB and Amazon RDS for a new system. Which requirement most strongly indicates that Amazon RDS (relational) — not DynamoDB — is the right choice?

  1. The data is simple key-value pairs accessed by a single ID
  2. The workload needs to scale to millions of requests per second with millisecond latency
  3. The application needs complex SQL queries with joins across many related tables
  4. The team wants a serverless database with no instances to manage
Answer: C
Why C is correct: Relational databases like RDS are built for structured data with relationships and complex SQL queries and joins. When joins and rich querying are core requirements, RDS is the right tool, not DynamoDB.
Why the other options are wrong:
  • A — Simple key-value access by a single ID is the textbook DynamoDB pattern, not a reason to pick RDS.
  • B — Extreme scale at millisecond latency favors DynamoDB, not RDS.
  • D — "Serverless, no instances" describes DynamoDB; RDS uses managed DB instances.
Common trap: Every option sounds like a database benefit. The deciding factor between the two is the data shape: joins/complex SQL → RDS; key-value at scale → DynamoDB.

Q10 A team confuses DAX with ElastiCache. Which statement correctly describes the key difference between the two on the CLF-C02 exam?

  1. DAX is a relational database; ElastiCache is a NoSQL database
  2. DAX is an in-memory cache built specifically for DynamoDB; ElastiCache is a general-purpose in-memory cache usable with many data sources
  3. DAX stores data permanently on disk; ElastiCache replicates across regions
  4. DAX is only for RDS; ElastiCache is only for DynamoDB
Answer: B
Why B is correct: DAX is a caching layer purpose-built to accelerate DynamoDB reads (down to microseconds). ElastiCache (Redis or Memcached) is a broader in-memory cache you can put in front of many databases or use for sessions, queues, and more.
Why the other options are wrong:
  • A — Neither is a database in this sense; both are in-memory caches, and the relational/NoSQL labels are wrong.
  • C — A cache holds data in memory for speed; this description misstates how both services work.
  • D — It reverses reality — DAX is the DynamoDB-specific one, and ElastiCache is general-purpose.
Common trap: Because both are in-memory caches, candidates swap them. Remember: DAX = DynamoDB-only accelerator; ElastiCache = generic cache for many uses.

Q11 A managed-service marketing slide claims DynamoDB delivers "single-digit-millisecond performance at any scale." For the exam, what does this performance claim mean in plain terms?

  1. Queries complete in single-digit minutes regardless of load
  2. It guarantees zero latency for all requests worldwide
  3. Performance only applies to analytical batch reporting jobs
  4. Typical read/write requests return in a few milliseconds even as traffic grows very large
Answer: D
Why D is correct: "Single-digit-millisecond" means individual requests typically finish in a few milliseconds, and DynamoDB holds that speed as data and traffic scale up. It is the core performance promise for key-value access.
Why the other options are wrong:
  • A — Minutes would be enormously slow; the claim is about milliseconds.
  • B — No service guarantees literally zero latency; there is always some small delay.
  • C — DynamoDB targets fast operational (transactional) access, not batch analytics, which is Redshift's job.
Common trap: Misreading the unit. "Single-digit-millisecond" is a few thousandths of a second — fast operational reads, not analytics or impossible "zero latency."

Q12 A retailer running a flash sale expects DynamoDB traffic to jump from a few hundred to tens of thousands of requests per second within minutes, then drop back down. They want the table to grow and shrink capacity by itself without manual intervention. Which DynamoDB capability addresses this?

  1. Automatic scaling (on-demand or auto scaling on provisioned)
  2. Manual capacity reconfiguration during the event
  3. Vertical scaling to a larger instance type
  4. Increasing the DB instance class size
Answer: A
Why A is correct: DynamoDB scales automatically — on-demand mode instantly adapts to traffic, and provisioned mode can use auto scaling to raise and lower capacity. Either way, the table grows and shrinks without you manually intervening.
Why the other options are wrong:
  • B — Manual reconfiguration is exactly what they want to avoid and is risky during a sudden spike.
  • C — "Vertical scaling to a larger instance type" is a server/instance concept; DynamoDB has no instances to resize.
  • D — "DB instance class" is RDS terminology; DynamoDB does not use instance classes.
Common trap: "Instance type" and "instance class" are EC2/RDS language. DynamoDB scales without instances — that wording alone marks the wrong answers.

Q13 A company stores product catalog data in DynamoDB and also wants a separate, very fast in-memory store for temporary leaderboard rankings and pub/sub messaging shared by several different applications. Which service is the better fit for that separate in-memory workload?

  1. Amazon ElastiCache
  2. DynamoDB Accelerator (DAX)
  3. Amazon Athena
  4. Amazon Neptune
Answer: A
Why A is correct: ElastiCache is a general-purpose in-memory data store (Redis/Memcached) that handles fast leaderboards, pub/sub messaging, and shared caching across multiple apps — workloads that go beyond just accelerating one DynamoDB table.
Why the other options are wrong:
  • B — DAX only accelerates reads of a DynamoDB table; it cannot serve generic pub/sub or non-DynamoDB workloads.
  • C — Athena queries data in S3 using SQL; it is not an in-memory store.
  • D — Neptune is a graph database for relationships, not an in-memory cache or message store.
Common trap: DAX and ElastiCache both cache, so candidates pick DAX. But DAX is locked to DynamoDB; when the need is general-purpose in-memory across many apps, ElastiCache is the answer.

Q14 An IoT platform ingests sensor readings from millions of devices, writing huge volumes of small key-value records that must be stored with predictable low latency and elastic scaling. Which service is purpose-built for this high-write, key-value workload?

  1. Amazon Redshift
  2. Amazon RDS for SQL Server
  3. Amazon QuickSight
  4. Amazon DynamoDB
Answer: D
Why D is correct: Massive volumes of small key-value writes that need elastic scale and steady low latency are a classic DynamoDB use case. It absorbs high write throughput automatically without server management.
Why the other options are wrong:
  • A — Redshift is for analytical queries over large datasets, not high-frequency operational writes.
  • B — RDS for SQL Server is relational and would struggle to scale to millions of devices as smoothly or cheaply.
  • C — QuickSight is a business-intelligence dashboard tool, not a database.
Common trap: High data volume tempts people toward Redshift, but volume of analytics is different from volume of small operational writes. Key-value + high write rate = DynamoDB.

Q15 A developer says "Global Tables means my DynamoDB data is automatically backed up so I can recover from accidental deletes." Why is this understanding incorrect?

  1. Global Tables only work in a single region, so no backup is possible
  2. Global Tables provide multi-region replication for availability and low latency, not point-in-time backup or recovery from bad writes
  3. Global Tables are a billing feature with no effect on data
  4. Global Tables replace the need for any durability in DynamoDB
Answer: B
Why B is correct: Global Tables replicate data across regions so users get local low latency and the data stays available if a region has issues. But because every replica syncs, an accidental delete propagates everywhere — for recovering from mistakes you need backups or point-in-time recovery instead.
Why the other options are wrong:
  • A — Global Tables specifically span multiple regions; saying single-region is factually wrong.
  • C — They very much affect data by replicating it across regions; it is not merely a billing label.
  • D — DynamoDB already stores data durably on its own; Global Tables add cross-region reach, not a replacement for durability.
Common trap: Replication is mistaken for backup. Replication copies all changes (including deletes) across regions; backup/point-in-time recovery is what protects against bad writes.

Q16 A new architect is comparing how you interact with DynamoDB versus a relational database. Which statement is accurate for the CLF-C02 exam?

  1. DynamoDB organizes data into tables with rows and enforces foreign-key relationships like a relational database
  2. DynamoDB requires you to define all columns and types up front before inserting any item
  3. DynamoDB stores items in tables and is accessed primarily by keys, without the fixed schema, joins, and SQL of a relational database
  4. DynamoDB and a relational database both require manually managing the underlying servers
Answer: C
Why C is correct: DynamoDB stores flexible "items" in tables and you retrieve them by key. Unlike relational databases, it has no rigid table-wide schema, no foreign-key joins, and no SQL query language.
Why the other options are wrong:
  • A — DynamoDB does not enforce foreign-key relationships; that is a relational feature.
  • B — Items can have different attributes; you do not define every column up front like a relational schema.
  • D — DynamoDB is serverless with no servers to manage, so this is false for at least DynamoDB.
Common trap: Candidates project relational habits (fixed schema, foreign keys) onto DynamoDB. Its NoSQL nature means flexible items, key access, and no joins.

Q17 A team currently uses ElastiCache in front of their own database but loses cached data whenever a node is replaced, which breaks user sessions. They want a managed store where the session data is durable by default and still very fast for key-based access. Which service best resolves the durability concern?

  1. Keep using ElastiCache exactly as is
  2. Move session data to Amazon DynamoDB
  3. Move session data to Amazon CloudFront
  4. Move session data to Amazon S3 Glacier
Answer: B
Why B is correct: DynamoDB persists data durably while still offering fast key-based access. Moving session state there removes the risk of losing it when an in-memory cache node is replaced.
Why the other options are wrong:
  • A — Keeping ElastiCache as-is does not fix the stated problem of losing data on node replacement.
  • C — CloudFront is a CDN for caching web content at the edge, not a durable session database.
  • D — S3 Glacier is cold archival storage with retrieval delays — completely unsuitable for live, fast session access.
Common trap: ElastiCache is fast but in-memory (can lose data); when durability matters for fast key-value access, DynamoDB is the managed, persistent answer.

Q18 Which combination of characteristics correctly describes Amazon DynamoDB for the CLF-C02 exam?

  1. NoSQL key-value, fully managed and serverless, automatic scaling, single-digit-millisecond latency
  2. Relational, SQL-based, requires choosing an instance size, single-region only
  3. In-memory cache that loses data on restart and is used only to speed up RDS
  4. Object storage service designed for storing large media files and backups
Answer: A
Why A is correct: This is the exact identity of DynamoDB: a NoSQL key-value database that is fully managed and serverless, scales automatically, and delivers single-digit-millisecond response times.
Why the other options are wrong:
  • B — DynamoDB is not relational or SQL-based, uses no instance size, and can span regions via Global Tables.
  • C — That describes an in-memory cache (ElastiCache/DAX), not DynamoDB, which durably persists data.
  • D — Object storage for large files describes Amazon S3, not DynamoDB.
Common trap: Each wrong option borrows the identity of a look-alike service (RDS, ElastiCache/DAX, S3). Lock in DynamoDB's four-word signature: NoSQL, serverless, auto-scaling, millisecond.

Continue reading

☁️ AWS Cloud Practitioner

Cloud Concepts, Value Proposition & Cloud Economics

☁️ AWS Cloud Practitioner

AWS Well-Architected Framework & the Six Pillars

☁️ AWS Cloud Practitioner

The Shared Responsibility Model