DOP-C02 Incident and Event Response Practice Question

A company has an AWS Lambda function that processes S3 events. The function is invoked multiple times for the same S3 object, causing duplicate processing. The engineer suspects the issue is related to retries from the S3 event notification or Lambda's built-in retry behavior. What is the MOST effective way to ensure idempotent processing?

⚠ Common exam trap

Candidates often confuse concurrency control (ReservedConcurrency) with idempotency, or assume SQS FIFO deduplication is a drop-in solution without realizing S3 cannot directly send events to FIFO queues.

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

✓

Use a DynamoDB table to store a record of processed S3 object keys and check for existence before processing.

Storing processed S3 object keys in a DynamoDB table and checking for existence before processing ensures idempotency at the application level. This approach directly handles duplicate invocations caused by S3 event retries or Lambda's built-in retry behavior, as the function can conditionally skip processing if the key already exists in DynamoDB. It provides a durable, consistent, and scalable mechanism to prevent duplicate processing regardless of how many times the function is invoked for the same object.

Answer analysis

Option-by-option breakdown

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

✗
Modify the S3 bucket event notification configuration to use a prefix filter that excludes duplicate objects.
Why it's wrong here
S3 event notifications use at-least-once delivery, so the same object key can trigger multiple events because of client retries, network retries, or Lambda's asynchronous retry policy. A prefix filter in the bucket notification configuration only restricts which object keys generate events based on the key's prefix; it cannot detect or skip duplicate object keys. Therefore, configuring a prefix filter will not exclude duplicate objects and will not eliminate duplicate invocations.
✓
Use a DynamoDB table to store a record of processed S3 object keys and check for existence before processing.
Why this is correct
Recording processed S3 object keys in a DynamoDB table and checking for existence before processing makes the Lambda function idempotent. Use a conditional write, such as PutItem with ConditionExpression: attribute_not_exists(partition_key), so the first invocation for a given object key proceeds and subsequent duplicates fail the condition and exit without side effects. This is the recommended pattern because it works regardless of how many duplicate events S3 delivers and does not depend on delivery semantics.
✗
Set the Lambda function's ReservedConcurrency to 1 to prevent concurrent executions.
Why it's wrong here
Setting ReservedConcurrency to 1 enforces a maximum of one concurrent execution of the Lambda function, but duplicate S3 events will still invoke the function sequentially, each running the full processing logic. The function would therefore process the same object multiple times, just not at the same time, so it does not achieve idempotency. Additionally, capping concurrency at 1 creates a throughput bottleneck and can cause throttling errors under normal load.
✗
Use an Amazon SQS FIFO queue as the event source and enable content-based deduplication.
Why it's wrong here
S3 event notifications can be sent to Lambda directly or to SQS only if the bucket notification is explicitly configured for that queue. Content-based deduplication in SQS FIFO suppresses messages only when the message body is identical and within a 5-minute deduplication interval; S3 event payloads typically differ in request IDs or timestamps, so they are not recognized as duplicates. Even with FIFO, Lambda's event source mapping processes messages at least once, so duplicate processing remains possible.

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

DOP-C02 Incident and Event Response Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question