Courseiva

SOA-C02 Reliability and Business Continuity Practice Question

A SysOps administrator is reviewing the reliability of a production system that uses Amazon DynamoDB as its primary data store. The table has on-demand capacity and a single partition key. The application experiences occasional throttling errors during peak hours. Which action would most effectively improve reliability?

⚠ Common exam trap

Candidates often assume throttling is always a capacity issue (solved by increasing RCU/WCU or enabling auto-scaling), when in reality it is often a data modeling problem where a single partition key creates a hot spot that no amount of capacity scaling can fix.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Review and optimize the partition key design to avoid hot partitions.

Throttling errors in DynamoDB with a single partition key are most often caused by uneven access patterns creating hot partitions. Optimizing the partition key design (e.g., using a composite key or adding a suffix to distribute writes) directly addresses the root cause by ensuring requests are spread evenly across partitions, which on-demand capacity alone cannot fix. This improves reliability by preventing throttling at the partition level, regardless of the table's total capacity.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Switch to provisioned capacity and set high read/write units.

    Why it's wrong here

    Switching to provisioned capacity and setting high read/write units does not resolve hot partitions because throttling occurs at the individual partition level, not at the table level. Even if you provision extra table capacity, a single partition in on-demand (or provisioned) mode is still limited to 3000 read capacity units and 1000 write capacity units, so an access pattern concentrated on one partition key value will continue to throttle. Additionally, provisioned capacity demands manual scaling or alarms, making it an operational burden with no benefit for this workload.

  • ✗

    Enable auto-scaling and increase the maximum capacity.

    Why it's wrong here

    Enabling auto-scaling and increasing the maximum capacity is ineffective here because auto-scaling applies only to provisioned mode, whereas the table is already using on-demand capacity, which scales elastically with traffic. Auto-scaling can only adjust the table-level throughput, and it cannot rebalance an uneven access pattern across partition keys. Even with a higher maximum capacity, throughput per partition remains capped, so a hot partition stays throttled.

  • ✓

    Review and optimize the partition key design to avoid hot partitions.

    Why this is correct

    Reviewing and optimizing the partition key design is the correct fix because DynamoDB distributes data across partitions based on the partition key's hash value, and on-demand or provisioned table capacity does not guarantee uniform load per partition. Each partition has its own throughput ceiling (3000 RCU / 1000 WCU), so a skewed access pattern—such as one overly popular item or a timestamp prefix—creates a hot partition that gets throttled even when the table's overall capacity is underutilized. Adding high-cardinality suffixes like random or calculated bits to the partition key spreads the writes and reads across many partitions, eliminating the bottleneck while preserving query access if the design accounts for it. This approach directly addresses the root cause rather than masking symptoms.

  • ✗

    Enable DynamoDB Accelerator (DAX) to reduce read latency.

    Why it's wrong here

    Enabling DynamoDB Accelerator (DAX) only caches item reads in memory, so it can reduce read latency and alleviate read-heavy hot spots, but it cannot help if the workload includes writes or if the throttling is caused by a partition-level imbalance. DAX serves reads from the cache and reduces read capacity units consumed, but it does not change how many partitions an item maps to or how traffic is distributed. It also adds cost and operational complexity, and it has no impact on write throttling or on hot partitions that are still hit for uncached reads.

About these practice questions

Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.