DOP-C02 Resilient Cloud Solutions 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.

• ✗

  Reduce the receive message wait time (long polling) to poll the queue more frequently.

  Why it's wrong here

  Lowering the ReceiveMessageWaitTime to use short polling increases the frequency of SQS API calls and incurs additional cost, but polling more often does not increase the processing capacity of the backend workers. If the workers are already saturated, the backlog (ApproximateNumberOfMessagesVisible) keeps growing regardless of how frequently each worker polls. Long polling is an optimization for latency and cost, not a mechanism to add processing capacity.

• ✗

  Increase the visibility timeout of the SQS queue to allow more time for processing.

  Why it's wrong here

  Extending the visibility timeout only lengthens the period during which a message is hidden from other consumers after it is received; it does not make the workers process messages faster. Worse, it can exacerbate the backlog because failed or stuck messages remain hidden longer, delaying redelivery and allowing queue depth to accumulate. Visibility timeout is a duplicate-delivery control, not a throughput-enabling control.

• ✗

  Use an SQS FIFO queue instead of a standard queue to ensure ordered processing.

  Why it's wrong here

  Switching to an SQS FIFO queue provides strict message ordering and exactly-once processing, but it imposes hard throughput ceilings (300 API requests/s, or 3,000 messages/s with batching) and requires a message group ID, which can serialize consumers when processing a single group. The application's problem is a growing backlog during traffic spikes, not out-of-order messages; FIFO's lower throughput and ordering constraints would restrict, not improve, scalability.

• ✓

  Configure an Auto Scaling group for the backend workers with a scaling policy based on the SQS queue depth.

  Why this is correct

  The correct solution is to attach an Auto Scaling policy to the SQS queue depth metric (e.g., ApproximateNumberOfMessagesVisible) and configure the backend workers as an Auto Scaling group. As the number of available messages grows, the policy launches additional EC2 workers to increase aggregate polling and processing throughput; as the queue drains, it terminates excess workers. This directly ties compute capacity to the ingested message volume, which is the standard pattern for decoupled, event-driven autoscaling with SQS.

Go deeper

Related to this question