DVA-C02 Troubleshooting and Optimization Practice Question

An application uses an Amazon SQS queue to decouple microservices. The producer is sending messages, but the consumer is not processing them. The consumer is an Auto Scaling group of EC2 instances. The SQS queue's ApproximateNumberOfMessagesVisible metric is increasing. What is the MOST likely cause?

⚠ Common exam trap

DVA-C02 often tests the distinction between a growing message backlog caused by consumers not polling versus one caused by visibility timeout or DLQ settings, and candidates frequently blame queue configuration instead of the consumer's polling behavior.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The consumer instances are not polling the SQS queue.

If the ApproximateNumberOfMessagesVisible metric keeps rising while the consumer Auto Scaling group is running, the most likely cause is that the consumer instances are not polling the queue at all. Without active long-polling ReceiveMessage calls, messages accumulate and are never processed, even though the queue and permissions may be fine. This is the most direct explanation for a growing visible-message count with no consumption.

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 SQS queue policy denies access to the consumer.
Why it's wrong here
If the SQS queue policy denies access to the consumer, any ReceiveMessage API calls made by the consumer instances would fail with an AccessDenied error. Consequently, messages sent by producers would remain in the queue, and the ApproximateNumberOfMessagesVisible metric would continuously increase as no messages are successfully retrieved or processed. While this explains message accumulation, it points to a permissions misconfiguration rather than a lack of polling activity itself.
✓
The consumer instances are not polling the SQS queue.
Why this is correct
If consumer instances are not actively making ReceiveMessage API calls to the SQS queue, messages sent by producers will accumulate indefinitely. The ApproximateNumberOfMessagesVisible metric will continuously increase because no consumers are retrieving messages, thereby preventing them from being moved to the in-flight state or deleted. This scenario directly and most likely explains a sustained increasing trend of visible messages.
✗
The visibility timeout is set too low.
Why it's wrong here
A low visibility timeout means that after a consumer retrieves a message, it becomes visible again in the queue very quickly if not deleted within that short period. While this could lead to messages being processed multiple times or appearing visible frequently, it does not explain a continuous, unchecked increase in the ApproximateNumberOfMessagesVisible metric. Instead, it would likely cause a fluctuating or consistently high count, not a steady accumulation if consumers are otherwise active.
✗
The SQS queue has a dead-letter queue configured.
Why it's wrong here
Configuring a Dead-Letter Queue (DLQ) for an SQS queue is a mechanism for handling messages that fail to be processed successfully after a specified number of retries. Messages moved to a DLQ are effectively removed from the main queue, which would typically lead to a decrease in the ApproximateNumberOfMessagesVisible count on the primary queue, not cause it to continuously increase. Therefore, a DLQ configuration does not explain an increasing trend of visible messages in the primary queue.

Go deeper

DVA-C02 Troubleshooting and Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question