Which statement best describes how reserved capacity affects billing in DynamoDB?
Think about how pre-purchasing capacity units can save money.
Reserved capacity lets you commit to a set amount of read and write capacity units for a 1- or 3-year term, which reduces costs compared to on-demand pricing.
Given a DynamoDB table with 100 reserved write capacity units and actual usage of 150 write capacity units in a billing hour, how many write capacity units are billed at the on-demand rate?
Reserved capacity covers part of the usage; the rest is billed on-demand.
The reserved capacity covers 100 units. The extra 50 units (150 - 100) are billed at the on-demand rate.
Which AWS CLI command correctly purchases reserved capacity for DynamoDB with 200 write capacity units for 1 year?
You need to specify the offering ID, not just the units.
The correct command requires the reserved capacity offering ID and the count of units to purchase. You must first describe offerings to get the ID.
You have multiple DynamoDB tables with varying workloads. How can you optimize reserved capacity purchases to reduce costs?
Think about sharing capacity across tables to maximize utilization.
Reserved capacity is shared across all tables in the account, so buying at the account level allows unused capacity from one table to cover others, reducing waste.
You purchased reserved capacity for 300 read units, but your billing shows you are still charged on-demand for all 300 read units. What is the most likely cause?
Check if the reserved capacity and table are in the same region.
Reserved capacity is region-specific. If purchased in a different region, it won't apply to tables in another region, causing on-demand charges.