DynamoDB capacity modes (on-demand, provisioned) in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding DynamoDB On-Demand Capacity Mode

Which statement correctly describes the behavior of DynamoDB when using the on-demand capacity mode?

A You pay a flat monthly fee for unlimited read and write operations regardless of usage.

B You must specify read and write capacity units in advance, and you pay for the provisioned capacity regardless of usage.

C You are limited to a fixed number of read and write operations per second, which cannot be changed after table creation.

D DynamoDB automatically scales capacity to handle incoming requests and you pay only for the read and write requests you use.

💡 Hint

Think about how DynamoDB handles sudden traffic spikes without manual capacity changes.

On-demand mode lets DynamoDB automatically adjust capacity to your workload. You pay only for the requests you make, without specifying capacity units upfront.

🧠 Conceptual

intermediate

Provisioned Capacity Mode Characteristics

Which of the following is true about DynamoDB's provisioned capacity mode?

A You pay only for the read and write requests you use, with no need to specify capacity units.

B You specify the number of read and write capacity units, and you are billed for these units whether used or not.

C Provisioned capacity mode automatically scales capacity based on traffic without any manual input.

D Provisioned capacity mode is only available for global tables and not for single-region tables.

💡 Hint

Consider how billing works when you reserve capacity in advance.

Provisioned mode requires you to set capacity units ahead of time. You pay for these units regardless of actual usage, which can save money if traffic is predictable.

❓ Architecture

advanced

Choosing Capacity Mode for a Variable Traffic Application

You have a new application with unpredictable traffic that can spike suddenly. Which DynamoDB capacity mode should you choose to minimize operational overhead and avoid throttling?

A On-demand capacity mode to automatically handle traffic spikes without manual intervention.

B Provisioned capacity mode with manual scaling to handle peak traffic.

C Provisioned capacity mode with auto-scaling enabled to adjust capacity automatically.

D On-demand capacity mode with reserved capacity units to reduce costs.

💡 Hint

Think about which mode best handles sudden unpredictable traffic without manual changes.

On-demand mode is designed for unpredictable workloads and automatically adjusts capacity to avoid throttling without manual scaling.

❓ security

advanced

Impact of Capacity Mode on Security and Access Control

How does choosing between on-demand and provisioned capacity modes affect the security and access control of a DynamoDB table?

A Capacity mode choice does not affect security or access control; IAM policies and encryption work the same for both modes.

B Provisioned mode requires additional encryption settings for security compared to on-demand mode.

C On-demand mode disables IAM policies, so access control is managed differently.

D On-demand mode automatically enables public read access for faster scaling.

💡 Hint

Consider if capacity mode changes how you manage permissions or encryption.

Security features like IAM policies and encryption are independent of capacity mode. Both modes support the same security controls.

❓ service_behavior

expert

Billing Behavior Differences Between Capacity Modes

Which billing behavior correctly distinguishes DynamoDB's on-demand capacity mode from provisioned capacity mode?

A On-demand mode charges a fixed monthly fee plus a small fee per request, while provisioned mode charges only per request.

B On-demand mode charges based on data storage size only, ignoring read/write requests.

C Provisioned mode charges for the capacity units you specify regardless of usage, while on-demand mode charges only for the actual read and write requests made.

D Both modes charge the same way, but on-demand mode offers discounts for reserved capacity.

💡 Hint

Think about how billing differs when capacity is reserved versus when it is flexible.

Provisioned mode bills for reserved capacity units regardless of usage, while on-demand bills only for actual requests, making it more flexible but sometimes more costly for steady workloads.

Practice

1. What is the main advantage of using DynamoDB's on-demand capacity mode?

easy

A. It offers a lower cost for steady, predictable workloads.

B. It automatically scales to handle any workload without manual capacity planning.

C. It requires you to set fixed read and write capacity units.

D. It limits the number of requests per second to a fixed amount.

Solution

1. Step 1: Understand on-demand mode behavior

   On-demand mode automatically adjusts capacity to meet traffic demands without manual input.

2. Step 2: Compare with provisioned mode

   Provisioned mode requires fixed capacity settings, unlike on-demand.

3. Final Answer:

   It automatically scales to handle any workload without manual capacity planning. -> Option B

4. Quick Check:

   On-demand = auto scaling without setup [OK]

Hint: On-demand means auto scale, no manual setup needed [OK]

Common Mistakes:

• Confusing on-demand with provisioned fixed capacity
• Thinking on-demand limits requests
• Assuming on-demand is cheaper for steady workloads

2. Which of the following is the correct way to specify provisioned capacity in a DynamoDB table creation JSON?

easy

A. { "Throughput": { "Reads": 5, "Writes": 10 } }

B. { "CapacityMode": "ON_DEMAND" }

C. { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } }

D. { "ReadUnits": 5, "WriteUnits": 10 }

Solution

1. Step 1: Recall provisioned capacity syntax

   Provisioned mode requires specifying ReadCapacityUnits and WriteCapacityUnits inside ProvisionedThroughput.

2. Step 2: Check options for correct JSON structure

   { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } matches the correct AWS DynamoDB API format for provisioned throughput.

3. Final Answer:

   { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } -> Option C

4. Quick Check:

   ProvisionedThroughput with Read/Write units = correct syntax [OK]

Hint: Provisioned capacity uses ProvisionedThroughput with Read/Write units [OK]

Common Mistakes:

• Using CapacityMode for provisioned capacity
• Missing ProvisionedThroughput wrapper
• Incorrect property names like ReadUnits

3. Given a DynamoDB table in provisioned mode with 5 read capacity units and 5 write capacity units, what happens if your application suddenly sends 20 write requests per second?

medium

A. Some write requests are throttled because they exceed the provisioned write capacity.

B. All 20 write requests succeed immediately without throttling.

C. DynamoDB automatically increases write capacity to 20 units instantly.

D. The table switches automatically to on-demand mode to handle the load.

Solution

1. Step 1: Understand provisioned capacity limits

   Provisioned mode limits throughput to the set capacity units (5 writes per second here).

2. Step 2: Analyze effect of exceeding capacity

   Sending 20 writes exceeds 5 units, causing throttling of excess requests.

3. Final Answer:

   Some write requests are throttled because they exceed the provisioned write capacity. -> Option A

4. Quick Check:

   Provisioned mode throttles excess requests [OK]

Hint: Provisioned mode throttles requests above set capacity [OK]

Common Mistakes:

• Assuming automatic capacity increase in provisioned mode
• Thinking on-demand mode applies automatically
• Believing all requests always succeed

4. You configured a DynamoDB table with provisioned capacity: 10 read units and 10 write units. Your application experiences throttling errors during peak hours. What is the best immediate fix to reduce throttling without downtime?

medium

A. Switch the table to on-demand capacity mode.

B. Reduce the size of items stored in the table.

C. Delete and recreate the table with higher capacity.

D. Increase the provisioned read and write capacity units.

Solution

1. Step 1: Identify cause of throttling

   Throttling occurs because provisioned capacity is too low for peak traffic.

2. Step 2: Choose immediate fix without downtime

   Increasing provisioned capacity units can be done live without deleting the table.

3. Final Answer:

   Increase the provisioned read and write capacity units. -> Option D

4. Quick Check:

   Increase capacity units to reduce throttling [OK]

Hint: Increase provisioned units live to fix throttling fast [OK]

Common Mistakes:

• Deleting and recreating table causes downtime
• Assuming switching to on-demand is instant and free
• Reducing item size does not fix capacity limits

5. A startup expects unpredictable traffic spikes and wants to minimize cost during low usage while avoiding throttling during spikes. Which DynamoDB capacity mode should they choose and why?

hard

A. On-demand mode because it charges per request and scales instantly without manual setup.

B. Provisioned mode with auto scaling enabled to adjust capacity automatically.

C. Provisioned mode with fixed capacity to control costs strictly.

D. On-demand mode but with a fixed maximum request limit to save costs.

Solution

1. Step 1: Understand startup's needs

   They want to avoid throttling during spikes and save cost during low usage.

2. Step 2: Compare capacity modes for unpredictable traffic

   On-demand mode charges per request and auto scales instantly, ideal for unpredictable spikes.

3. Step 3: Evaluate other options

   Provisioned with auto scaling helps but requires setup and may lag; fixed capacity risks throttling or cost waste.

4. Final Answer:

   On-demand mode because it charges per request and scales instantly without manual setup. -> Option A

5. Quick Check:

   Unpredictable traffic = on-demand mode best [OK]

Hint: Unpredictable spikes? Choose on-demand for auto scaling [OK]

Common Mistakes:

• Choosing fixed provisioned capacity for unpredictable traffic
• Assuming auto scaling is instant and always perfect
• Thinking on-demand has fixed request limits