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.

• ✗

  Configure a Dead Letter Queue (DLQ) to capture failed messages.

  Why it's wrong here

  Configuring a Dead Letter Queue (DLQ) is a mechanism for handling messages that fail to be processed successfully after a maximum number of retries. While DLQs prevent messages from being lost entirely, they do not directly ensure that a message is processed at least once by the primary consumer. Instead, they capture messages that have exhausted all retry attempts, moving them out of the main queue for later inspection or reprocessing, rather than facilitating initial at-least-once delivery.

• ✗

  Enable long polling on the SQS queue.

  Why it's wrong here

  Enabling long polling on an SQS queue is an optimization technique that reduces the number of empty responses and the cost associated with frequent polling. It instructs the consumer to wait for a specified duration (up to 20 seconds) for messages to become available before returning. However, long polling does not influence the message visibility timeout or the retry logic, and therefore, it does not guarantee at-least-once processing if a consumer fails or times out.

• ✗

  Use a FIFO queue to ensure exactly-once processing.

  Why it's wrong here

  An SQS FIFO (First-In, First-Out) queue guarantees both strict message ordering and exactly-once processing, meaning a message is delivered once and remains available until processed and deleted, without duplicates. The question asks for 'at-least-once' processing, which is a less stringent requirement than 'exactly-once.' While FIFO queues inherently provide at-least-once, their primary purpose and overhead are for stricter semantics, making them an over-engineered solution if only at-least-once is needed, and standard queues already offer at-least-once delivery.

• ✓

  Set the SQS queue's visibility timeout to be greater than the Lambda function's timeout.

  Why this is correct

  Setting the SQS queue's visibility timeout to be greater than the Lambda function's timeout is crucial for at-least-once processing. If the Lambda function fails or times out before successfully processing and deleting a message, the message will automatically become visible again in the queue once the SQS visibility timeout expires. This ensures that another consumer or a subsequent invocation of the Lambda function can pick up and re-process the message, guaranteeing it is processed at least once.

• ✓

  Use the SQS DeleteMessage API inside the Lambda function only after successful processing.

  Why this is correct

  Using the SQS DeleteMessage API inside the Lambda function only after successful processing is a fundamental pattern for ensuring at-least-once delivery. When a Lambda function receives a message, it becomes invisible for the duration of the visibility timeout. By explicitly deleting the message only after all processing logic has completed without error, any failure prior to deletion will cause the message to become visible again after its timeout, allowing it to be re-processed by another consumer or invocation.

Go deeper

Related to this question