DVA-C02 Development with AWS Services Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Publish the failed messages to an SNS topic for later processing.

  Why it's wrong here

  While publishing to an SNS topic could notify downstream systems of failures, it requires custom application logic within the Lambda function to catch errors and explicitly publish messages. This approach bypasses SQS's native message lifecycle management, including retries and dead-letter queue functionality, introducing unnecessary complexity and custom error handling that must be maintained. It is not the standard or most efficient way to handle message processing failures for SQS-triggered Lambdas.

• ✗

  Log the error and delete the message from the queue.

  Why it's wrong here

  Logging the error provides visibility into the failure, but immediately deleting the message from the SQS queue means the message is permanently lost. This prevents any further attempts to process the message, making it impossible to re-process it after a fix is deployed or to inspect its contents for root cause analysis. It effectively discards valuable data that could be crucial for debugging and recovery.

• ✗

  Increase the visibility timeout of the SQS queue.

  Why it's wrong here

  Increasing the visibility timeout only grants the Lambda function more time to process a message before it becomes visible again in the queue for other consumers. While useful for long-running tasks, it does not address the core problem of messages that consistently fail processing. Such messages would simply remain in the primary queue, repeatedly timing out and being re-delivered, without providing a mechanism to isolate them for debugging or prevent them from blocking other messages.

• ✓

  Configure a dead-letter queue (DLQ) for the SQS queue.

  Why this is correct

  Configuring a dead-letter queue (DLQ) for the SQS queue is the standard and most robust solution for handling message processing failures. When a Lambda function fails to process a message a specified number of times (defined by the maxReceiveCount on the redrive policy), SQS automatically moves that message to the DLQ. This isolates problematic messages for later inspection and debugging, prevents them from continuously blocking the main queue, and ensures no data is lost, allowing developers to analyze and re-process them.

Go deeper

Related to this question