DVA-C02 - Development with AWS Services (32% of the exam) - Section 1.2

Write fault-tolerant application code using idempotency, retries with exponential backoff and jitter, and dead-letter queues.

Design idempotent operations so that repeated retries produce the same result, and implement exponential backoff and jitter to avoid thundering-herd failures. Recognise when to route unprocessable messages to dead-letter queues rather than blocking the main consumer.

IdempotencyExponential backoff and jitterDead-letter queuesRetry logic

Practice question for this objective

Free sampleDevelopment with AWS Servicesmedium

A developer calls Amazon DynamoDB from application code using the AWS SDK and sometimes receives a ProvisionedThroughputExceededException during traffic spikes. The developer wants the application to recover from these transient throttling errors automatically while spreading retries to avoid a synchronised retry storm across many clients. Which approach should the developer use?

ACatch the exception and immediately resend the same request in a tight loop until DynamoDB finally accepts the write or read.
BCatch the exception and retry after a fixed one second delay each time so every client waits the same interval before trying again.
CRely on the SDK retry behaviour using exponential backoff with jitter, raising the max attempts if the default retries are exhausted. Correct
DProvision the table for the highest expected peak capacity permanently so throttling errors never occur and no retry logic is needed.

Handle transient throttling by relying on SDK retries with exponential backoff and jitter rather than tight or fixed-interval loops. AWS SDKs automatically retry throttling and transient errors using exponential backoff that grows the wait between attempts and adds random jitter, which prevents many clients from retrying at the same instant and lets the service drain the spike.

Why A is wrong: An immediate tight retry loop hammers the table during throttling and offers no backoff, so many clients retry in lockstep and the throttling worsens rather than clearing.

Why B is wrong: A fixed delay still synchronises retries across clients into the same instants, so it forms a retry storm and lacks the growing wait that backoff provides.

Why C is correct: The AWS SDK retries throttling errors with exponential backoff and added jitter by default, which spaces and desynchronises retries so transient throttling clears without a storm.

Why D is wrong: Permanently over-provisioning wastes capacity, raises cost, and still cannot guarantee zero throttling during unexpected spikes, so the client must handle the error regardless.

See more DVA-C02 practice questions, answers explained.

Exam traps in Development with AWS Services

Answers that look right on this material and are not. Each one is a distractor from a different question in the DVA-C02 bank for this domain.

Switch every UpdateItem to a TransactWriteItems call so DynamoDB automatically retries the write internally until capacity is available.
Why it is wrong: Transactions cost double the capacity and do not auto-retry until capacity frees up; they raise throttling risk rather than absorb it.
Replace each failing PutItem with a Scan that locates the item first, on the assumption that read paths are throttled less than write paths.
Why it is wrong: A Scan is a read that does not perform the needed write and consumes large amounts of read capacity, so it neither completes the write nor relieves the throttling.
Use a fixed delay of one second before every retry so the wait time is predictable and easy to reason about.
Why it is wrong: A fixed delay is tempting for its simplicity, but it keeps all clients synchronised and does not back off as failures persist, so collisions continue.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.