DVA-C02 Troubleshooting and Optimization 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.

• ✗

  The queue uses long polling

  Why it's wrong here

  Long polling in SQS is a mechanism to reduce the number of empty responses and API calls by allowing consumers to wait for messages to arrive for up to 20 seconds. While it improves the efficiency of message retrieval, it does not influence the message's visibility after it has been received and processed. Therefore, long polling would not directly cause successfully processed messages to reappear or be reprocessed.

• ✗

  The queue has a dead-letter queue

  Why it's wrong here

  A Dead-Letter Queue (DLQ) in SQS is designed to capture messages that a consumer has failed to process successfully after a specified number of retries, indicated by the `maxReceiveCount` attribute. The question states messages are 'processed successfully,' meaning they would not typically be routed to a DLQ. The mere presence of a DLQ does not explain why successfully processed messages would be re-queued or require re-processing.

• ✗

  The messages are encrypted with SSE-SQS

  Why it's wrong here

  Server-Side Encryption for SQS (SSE-SQS) provides encryption of messages at rest and in transit using AWS Key Management Service (KMS) keys. This security feature ensures data confidentiality but has no impact on the operational lifecycle of a message within the queue, such as its visibility, processing time, or deletion status. Therefore, SSE-SQS would not cause successfully processed messages to reappear or be reprocessed by consumers.

• ✓

  The visibility timeout is shorter than the processing time or messages are not deleted after processing

  Why this is correct

  If the visibility timeout is shorter than the actual time required to process a message, the message will become visible again to other consumers before the initial consumer finishes and deletes it, leading to duplicate processing. Alternatively, if a consumer successfully processes a message but fails to explicitly call the `DeleteMessage` API, the message will remain in the queue and become visible again once its timeout expires, resulting in reprocessing. Both scenarios directly explain why messages might be processed successfully but still reappear.