Table capacity modes (on-demand vs provisioned) in DynamoDB - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference in billing between on-demand and provisioned capacity modes

Which statement correctly describes how billing works for DynamoDB tables using on-demand capacity mode compared to provisioned capacity mode?

A On-demand charges based on the number of read/write requests, while provisioned charges a fixed rate regardless of usage.

B Provisioned charges based on the number of read/write requests, while on-demand charges a fixed monthly fee.

C On-demand charges a fixed monthly fee, and provisioned charges based on storage size only.

D Provisioned charges based on storage size only, and on-demand charges based on the number of read/write requests.

💡 Hint

Think about how you pay for what you use versus paying for reserved capacity.

On-demand capacity mode charges you only for the read and write requests your application makes. Provisioned capacity mode requires you to specify the number of reads and writes you expect, and you pay for that capacity whether you use it or not.

❓ query_result

intermediate

Result of switching capacity mode on a DynamoDB table

What happens to the table's capacity settings immediately after switching from provisioned to on-demand mode?

A The provisioned capacity units remain active and are billed alongside on-demand usage.

B The provisioned read and write capacity units are ignored and replaced by on-demand billing.

C The table is deleted and recreated with on-demand mode, losing all data.

D The table continues to use provisioned capacity until manually updated.

💡 Hint

Consider how capacity modes affect billing and usage immediately after switching.

When you switch to on-demand mode, the table no longer uses provisioned capacity units. Instead, it bills based on actual read/write requests.

❓ optimization

advanced

Choosing capacity mode for unpredictable traffic

You expect your DynamoDB table to have highly variable and unpredictable traffic spikes. Which capacity mode is best to minimize cost and avoid throttling?

A Provisioned mode with fixed capacity set to the highest expected traffic.

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

C On-demand mode to pay only for the requests made without capacity planning.

D Provisioned mode with manual capacity adjustments during spikes.

💡 Hint

Think about which mode handles unpredictable traffic without manual intervention.

On-demand mode automatically handles traffic spikes by charging per request, avoiding throttling without needing capacity planning.

🔧 Debug

advanced

Identifying cause of throttling in provisioned mode

A DynamoDB table using provisioned capacity mode is experiencing throttling errors despite having capacity units set higher than average usage. What is the most likely cause?

A Traffic spikes exceeded provisioned capacity units temporarily causing throttling.

B On-demand mode was accidentally enabled causing billing conflicts.

C The table's storage size exceeded the provisioned capacity units.

D Provisioned capacity units automatically scale down causing throttling.

💡 Hint

Think about how provisioned capacity handles sudden traffic spikes.

Provisioned capacity does not instantly scale for spikes, so temporary traffic bursts above provisioned units cause throttling.

🧠 Conceptual

expert

Impact of capacity mode on global secondary indexes (GSIs)

How does the choice between on-demand and provisioned capacity modes affect the billing and capacity management of Global Secondary Indexes (GSIs) in DynamoDB?

A GSIs do not consume capacity units and are free to use.

B GSIs always use provisioned capacity mode regardless of the table's mode.

C GSIs always use on-demand capacity mode regardless of the table's mode.

D GSIs inherit the table's capacity mode; on-demand tables have on-demand GSIs billed per request, provisioned tables require separate capacity units for GSIs.

💡 Hint

Consider how GSIs are billed in relation to the main table's capacity mode.

GSIs follow the capacity mode of their parent table. If the table is on-demand, GSIs are billed per request. If provisioned, GSIs require their own provisioned capacity units.

Practice

1. Which DynamoDB table capacity mode automatically adjusts to your application's traffic without requiring manual capacity settings?

easy

A. On-demand mode

B. Provisioned mode

C. Reserved mode

D. Manual mode

Solution

1. Step 1: Understand capacity modes in DynamoDB

   DynamoDB offers two main capacity modes: on-demand and provisioned. On-demand mode automatically adjusts capacity based on traffic.

2. Step 2: Identify the mode that adjusts automatically

   On-demand mode charges per request and scales automatically without manual settings, unlike provisioned mode which requires fixed capacity.

3. Final Answer:

   On-demand mode -> Option A

4. Quick Check:

   Automatic scaling = On-demand mode [OK]

Hint: Automatic scaling means on-demand mode [OK]

Common Mistakes:

• Confusing provisioned mode as automatic
• Thinking reserved or manual modes exist
• Assuming manual capacity adjustment is automatic

2. Which of the following is the correct way to specify provisioned capacity when creating a DynamoDB table using AWS CLI?

easy

A. --billing-mode PAY_PER_REQUEST

B. --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

C. --capacity-mode ON_DEMAND

D. --read-write-capacity 10

Solution

1. Step 1: Recall AWS CLI syntax for provisioned capacity

   Provisioned mode requires specifying read and write capacity units using --provisioned-throughput with ReadCapacityUnits and WriteCapacityUnits.

2. Step 2: Match correct syntax option

   --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 uses the correct syntax. The --billing-mode PAY_PER_REQUEST and --capacity-mode ON_DEMAND options specify on-demand mode, while --read-write-capacity is invalid.

3. Final Answer:

   --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 -> Option B

4. Quick Check:

   Provisioned throughput syntax = --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 [OK]

Hint: Provisioned mode uses --provisioned-throughput flag [OK]

Common Mistakes:

• Using PAY_PER_REQUEST flag for provisioned mode
• Confusing capacity mode flags
• Using invalid flags like --read-write-capacity

3. Consider a DynamoDB table in provisioned mode with ReadCapacityUnits=5 and WriteCapacityUnits=5. If your application suddenly sends 20 read requests per second, what will happen?

medium

A. All 20 read requests succeed without delay

B. The table switches to on-demand mode automatically

C. Some read requests may be throttled due to exceeding capacity

D. DynamoDB automatically increases capacity to handle 20 requests

Solution

1. Step 1: Understand provisioned capacity limits

   Provisioned mode sets fixed read/write capacity units. Here, 5 read units allow about 5 strongly consistent reads per second.

2. Step 2: Analyze traffic exceeding capacity

   Sending 20 read requests exceeds the provisioned 5 units. DynamoDB throttles excess requests instead of automatically scaling or switching modes.

3. Final Answer:

   Some read requests may be throttled due to exceeding capacity -> Option C

4. Quick Check:

   Exceeding provisioned units causes throttling [OK]

Hint: Provisioned mode throttles if requests exceed capacity [OK]

Common Mistakes:

• Assuming automatic scaling in provisioned mode
• Thinking all requests always succeed
• Believing table switches modes automatically

4. You created a DynamoDB table with the following command:

aws dynamodb create-table --table-name MyTable --billing-mode PROVISIONED

But you forgot to specify provisioned throughput. What will happen?

medium

A. Table is created with default capacity of 5 read and 5 write units

B. Table is created but capacity is unlimited

C. Table is created in on-demand mode automatically

D. Table creation fails with an error about missing provisioned throughput

Solution

1. Step 1: Check requirements for provisioned mode

   Provisioned mode requires specifying ReadCapacityUnits and WriteCapacityUnits explicitly during table creation.

2. Step 2: Understand AWS CLI behavior on missing parameters

   Omitting provisioned throughput causes AWS CLI to return an error because required parameters are missing.

3. Final Answer:

   Table creation fails with an error about missing provisioned throughput -> Option D

4. Quick Check:

   Missing provisioned throughput causes creation error [OK]

Hint: Provisioned mode needs capacity units specified [OK]

Common Mistakes:

• Assuming default capacity is assigned
• Thinking table switches to on-demand mode
• Believing capacity is unlimited without settings

5. A startup expects unpredictable traffic spikes but wants to control costs during low usage. Which DynamoDB capacity mode strategy is best to balance cost and performance?

hard

A. Use on-demand mode to automatically handle spikes and pay per request

B. Use provisioned mode with low capacity and manually increase during spikes

C. Use provisioned mode with high capacity to handle spikes

D. Switch between on-demand and provisioned modes daily

Solution

1. Step 1: Analyze startup traffic pattern

   Unpredictable spikes mean traffic varies a lot, so automatic scaling is important to avoid throttling or overpaying.

2. Step 2: Evaluate capacity mode options for cost and performance

   On-demand mode charges per request and scales automatically, ideal for unpredictable traffic and cost control. Provisioned mode requires manual adjustments and risks throttling or wasted capacity.

3. Final Answer:

   Use on-demand mode to automatically handle spikes and pay per request -> Option A

4. Quick Check:

   Unpredictable traffic = On-demand mode best [OK]

Hint: Unpredictable traffic? Choose on-demand mode [OK]

Common Mistakes:

• Choosing high provisioned capacity wastes money
• Manually adjusting capacity is slow and error-prone
• Switching modes daily is not supported