DVA-C02 · Question #440
A developer is building a microservice that uses AWS Lambda to process messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The Lambda function calls external APIs to enrich the S
The correct answer is A. Create an SQS FIFO queue. Enable message deduplication on the SQS FIFO queue.. Option A is correct because SQS FIFO queues provide built-in exactly-once processing via a content-based deduplication window of 5 minutes - since the duplicates arrived within 1 minute of each other, the FIFO queue's deduplication feature would detect and discard them before the
Question
A developer is building a microservice that uses AWS Lambda to process messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The Lambda function calls external APIs to enrich the SQS message data before loading the data into an Amazon Redshift data warehouse. The SQS queue must handle a maximum of 1,000 messages per second. During initial testing, the Lambda function repeatedly inserted duplicate data into the Amazon Redshift table. The duplicate data led to a problem with data analysis. All duplicate messages were submitted to the queue within 1 minute of each other. How should the developer resolve this issue?
Options
- ACreate an SQS FIFO queue. Enable message deduplication on the SQS FIFO queue.
- BReduce the maximum Lambda concurrency that the SQS queue can invoke.
- CUse Lambda's temporary storage to keep track of processed message identifiers
- DConfigure a message group ID for every sent message. Enable message deduplication on the
How the community answered
(62 responses)- A71% (44)
- B16% (10)
- C8% (5)
- D5% (3)
Explanation
Option A is correct because SQS FIFO queues provide built-in exactly-once processing via a content-based deduplication window of 5 minutes - since the duplicates arrived within 1 minute of each other, the FIFO queue's deduplication feature would detect and discard them before they ever reach Lambda, preventing duplicate writes to Redshift entirely.
Option B is wrong because reducing Lambda concurrency slows processing throughput but does nothing to eliminate duplicate messages already sitting in the queue - the duplicates would still both be delivered and processed, just more slowly.
Option C is wrong because Lambda's /tmp storage is local to a single execution environment; concurrent Lambda instances each have their own isolated /tmp, so there is no shared state across invocations to track which message IDs have already been processed.
Option D is wrong because message group IDs control ordering and parallelism within FIFO queues, not deduplication alone - and the answer as presented is incomplete/misleading; deduplication must be enabled on the queue itself (as A specifies), not just through grouping.
Memory tip: Think "FIFO = Exactly Once." Whenever an exam scenario describes duplicate SQS messages causing downstream data integrity problems, FIFO + deduplication is the AWS-native fix. The 5-minute deduplication window is the key detail - if duplicates arrive within that window, they're automatically discarded.
Topics
Community Discussion
No community discussion yet for this question.