SAP-C02 Design for New Solutions Practice Question

A company is building a serverless data processing pipeline using AWS Lambda, Amazon DynamoDB, and Amazon S3. The pipeline processes JSON files uploaded to an S3 bucket, transforms the data, and writes results to DynamoDB. The company wants to ensure the pipeline can handle bursts of traffic without data loss. Which TWO design decisions should the solutions architect make?

⚠ Common exam trap

Candidates often confuse DynamoDB Streams with a buffering mechanism for incoming writes, when in fact streams only capture post-write changes and do not prevent data loss from S3 event delivery failures.

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

✓

Configure DynamoDB with on-demand capacity mode.

Option A is correct because DynamoDB on-demand capacity mode automatically scales read/write throughput to absorb unpredictable bursts of traffic without provisioning or throttling, which directly prevents data loss when the Lambda pipeline writes results at variable rates. Option B is correct because inserting an Amazon SQS queue between S3 event notifications and Lambda decouples ingestion from processing, buffering burst events durably (up to 14 days) so Lambda can poll and scale consumers without dropping events. Option C is not appropriate because raising the Lambda timeout to 15 minutes only extends execution time and does nothing to buffer bursts or prevent data loss. Option D is not appropriate because DynamoDB Streams captures item-level changes after they occur and is used for downstream reactions, not for buffering incoming S3 events. Option E is not appropriate because S3 Transfer Acceleration only speeds up uploads to S3 via edge locations and does not address burst handling or data durability in the processing pipeline.

Answer analysis

Option-by-option breakdown

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

✓
Configure DynamoDB with on-demand capacity mode.
Why this is correct
On-demand capacity mode absorbs unpredictable bursts by instantly scaling to workload demand, so DynamoDB throttling cannot drop writes during traffic spikes. This directly satisfies the stem's requirement to handle bursts without data loss, unlike provisioned mode, which needs pre-set capacity and auto scaling that reacts too slowly.
✓
Use an Amazon SQS queue to buffer events from S3 before processing by Lambda.
Why this is correct
An SQS queue decouples S3 event notifications from Lambda, buffering bursts so invocations are retried and retained rather than lost when concurrency limits are hit. This satisfies the no-data-loss constraint, whereas direct S3-to-Lambda invocation can throttle and discard events during sudden spikes.
✗
Increase the Lambda function timeout to 15 minutes.
Why it's wrong here
A 15-minute timeout only extends how long one invocation may run; it does not raise the concurrent-execution ceiling, so throttled bursts still drop events. Longer timeouts suit genuinely long-running single invocations, not absorbing traffic spikes, which require reserved or provisioned concurrency and asynchronous retries.
✗
Use DynamoDB Streams to capture changes and process in batches.
Why it's wrong here
DynamoDB Streams capture changes made to DynamoDB, not the S3 upload events that trigger this pipeline, so they cannot buffer incoming bursts before Lambda processes them. Streams are correct for reacting to table item changes, such as replicating or aggregating writes downstream.
✗
Enable S3 Transfer Acceleration on the bucket.
Why it's wrong here
Transfer Acceleration speeds uploads into S3 edge locations over long distances; it does nothing for Lambda concurrency limits or DynamoDB write throttling, the actual burst-loss causes. It is correct when globally distributed clients upload large objects to a distant bucket and need faster throughput.

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

SAP-C02 Design for New Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question