AWS DVA-C02 Drill: Lambda & SQS Dead-Letter Queues - Reprocessing Failed Messages

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For DVA-C02 candidates, the confusion often lies in how to properly re-queue failed messages from an SQS dead-letter queue after a Lambda consumer fixes a bug. In production, this is about knowing exactly which AWS API calls handle message visibility and movement versus deletion—and what role the DLQ plays in message lifecycle. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

JetStream Software is developing a serverless event processing application. It uses an AWS Lambda function triggered by an Amazon SQS queue to process orders. The main SQS queue is configured with a dead-letter queue (DLQ) to capture failed messages. Due to a bug in the Lambda code, some messages failed processing and landed in the DLQ. The developer has fixed the bug and now wants to reprocess the failed messages stored in the DLQ by sending them back to the original SQS queue for Lambda invocation.

The Requirement:

#

Determine the correct method for resubmitting the failed messages from the SQS dead-letter queue back to the main SQS queue for reprocessing.

The Options

#

• A) Use the SendMessageBatch API to send messages from the dead-letter queue to the original SQS queue.
• B) Use the ChangeMessageVisibility API to configure messages in the dead-letter queue to be visible in the original SQS queue.
• C) Use the StartMessageMoveTask API to move messages from the dead-letter queue to the original SQS queue.
• D) Use the PurgeQueue API to remove messages from the dead-letter queue and return the messages to the original SQS queue.

Google adsense

#

leave a comment:

Correct Answer

#

A) Use the SendMessageBatch API to send messages from the dead-letter queue to the original SQS queue.

Quick Insight: The Developer API Imperative

#

• For Developer candidates, understanding SQS API semantics for message movement is critical. Dead-letter queues serve as a message archive; AWS does not provide a direct API to “move” messages back. Instead, you must read the messages from the DLQ and send them back to the main queue.
• ChangeMessageVisibility only affects visibility timeout, never moves messages across queues.
• StartMessageMoveTask is not an existing SQS API.
• PurgeQueue deletes messages permanently and does not “return” them to any queue.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option A

The Winning Logic

#

The DLQ in SQS is a separate queue that collects messages that failed processing after their max receive count is exceeded. AWS does not provide a built-in API to automatically “move” messages back to the source queue. The developer must:

1. Poll (consume) messages from the DLQ using ReceiveMessage.
2. For each message, call SendMessageBatch (or SendMessage) to send them back to the original SQS queue.
3. Delete the messages from the DLQ after successful re-ingestion.

This sequence ensures the messages are “replayed” for Lambda processing without being lost.

• ChangeMessageVisibility updates the visibility timeout for in-flight messages within the same queue, not across different queues.
• StartMessageMoveTask isn’t part of the SQS API at all.
• PurgeQueue deletes all messages from the queue permanently, no reprocessing occurs.

The Trap (Distractor Analysis):

#

• Option B: Changing visibility timeout affects messages only on the originating queue, not in a dead-letter queue scenario.
• Option C: This is a fake API; there is no built-in way to “move” messages automatically between queues.
• Option D: Purging removes messages irreversibly—definitely not what you want if your goal is replay.

The Technical Blueprint

#

# Example CLI commands to replay messages from DLQ back to main queue:

# Step 1: Receive messages from DLQ
aws sqs receive-message --queue-url <DLQ-URL> --max-number-of-messages 10

# Step 2: Send messages back to main queue using SendMessageBatch
aws sqs send-message-batch --queue-url <Main-Queue-URL> --entries file://batch.json

# Step 3: Delete messages from DLQ after confirmation
aws sqs delete-message --queue-url <DLQ-URL> --receipt-handle <receipt-handle>

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick SendMessageBatch when you see moving messages between queues in SQS.

Real World

#

In production, teams often create automation using Lambda or Glue scripts to poll DLQ messages and batch re-insert them to the source queue, ensuring minimal downtime and precise control over message replay.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.