DEA-C01 Data Operations and Support Practice Question

A company runs a data pipeline that uses AWS Glue to process data from an Amazon DynamoDB table and write results to Amazon S3. The Glue job runs on a schedule every hour. Recently, the job started failing intermittently with 'ProvisionedThroughputExceededException' errors from DynamoDB. What is the BEST solution?

⚠ Common exam trap

DEA-C01 often tests whether candidates jump to 'add more capacity' when the AWS-recommended answer for transient throttling is retry with exponential backoff — the exam wants the resilience pattern, not the brute-force capacity increase.

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

✓

Implement exponential backoff and retries in the Glue job for DynamoDB operations.

ProvisionedThroughputExceededException is a throttling error that occurs when request rate exceeds the table's provisioned read/write capacity, and AWS's documented best practice is to implement exponential backoff and retry logic so the client retries with increasing delays instead of hammering the table. This is the correct fix for intermittent throttling because it lets the Glue job ride out short bursts of capacity contention without failing. It also works whether the table is in provisioned or on-demand mode, and it is the least disruptive, most cost-effective change.

Answer analysis

Option-by-option breakdown

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

✗
Use DynamoDB Accelerator (DAX) to reduce read latency.
Why it's wrong here
DAX caches item reads, so it cannot reduce the consumed read capacity that Glue's scan or query operations generate, leaving throttling unresolved. It is tempting because DAX targets read-heavy DynamoDB workloads, and would be correct for latency-sensitive repeated point reads rather than throughput exhaustion.
✗
Change the Glue job schedule to run every 2 hours.
Why it's wrong here
Halving the run frequency reduces read pressure but leaves the throttling cause unaddressed, and the hourly requirement is unmet. It is tempting as a low-effort throttle reduction, and would be correct if DynamoDB capacity were genuinely fixed and the schedule negotiable.
✓
Implement exponential backoff and retries in the Glue job for DynamoDB operations.
Why this is correct
Exponential backoff with jitter retries throttled DynamoDB requests, letting the table's provisioned capacity recover between attempts. This directly addresses the intermittent ProvisionedThroughputExceededException, which signals transient throttling rather than a persistent capacity shortfall. Retries absorb those spikes without over-provisioning, satisfying the requirement to stop hourly Glue job failures.
✗
Increase the read capacity units of the DynamoDB table.
Why it's wrong here
Raising RCUs addresses the throttling directly, but the question asks for the best solution and Glue's on-demand reads can still spike; the stem expects reducing consumed capacity or using adaptive capacity instead. It is tempting because RCU increases are the obvious remedy for throughput errors, and would be correct for sustained predictable read demand.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DEA-C01 Data Operations and Support Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question