DVA-C02 Troubleshooting and Optimization Practice Question
A company runs a microservices application on Amazon ECS with Fargate. The application includes a service that processes messages from an SQS queue. The service's CPU utilization is consistently above 80%, and messages are accumulating in the queue. The service is configured with a desired count of 2 tasks and auto scaling based on CPU utilization. What should a developer do to improve message processing throughput?
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
✓
Change the auto scaling metric to use the SQS queue's ApproximateNumberOfMessagesVisible.
The correct answer because using the SQS queue's ApproximateNumberOfMessagesVisible metric for auto scaling is more responsive to the actual workload than CPU utilization. When messages accumulate in the queue, scaling based on queue depth triggers task additions sooner, improving throughput. Option A is wrong because simply increasing the desired count without a dynamic scaling policy may not adapt to varying load and could lead to over-provisioning or under-provisioning. Option B is wrong because increasing task size (CPU/memory) does not directly address the scaling trigger; it might help a single task process more, but the bottleneck is the number of tasks. Option D is wrong because decreasing the batch size reduces the number of messages processed per poll, which would decrease throughput, not improve it.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the desired count of tasks to 5.
Why it's wrong here
Manually bumping the desired count to 5 is a one-time fix that ignores the auto scaling policy already in place; once the built-in CPU-based scaling re-evaluates, it can scale the count back down since CPU alone doesn't reflect the true backlog of unprocessed messages.
- ✗
Increase the task size to use more CPU and memory.
Why it's wrong here
Giving each task more vCPU and memory may reduce per-task processing time somewhat, but it does not fix the underlying problem that the scaling policy is tracking CPU rather than queue depth, so the fleet still won't scale out proportionally to the actual backlog.
- ✓
Change the auto scaling metric to use the SQS queue's ApproximateNumberOfMessagesVisible.
Why this is correct
Switching the target tracking metric to ApproximateNumberOfMessagesVisible makes scaling decisions proportional to the actual backlog size rather than an indirect CPU proxy, so the service adds tasks precisely when the queue grows and removes them as it drains, directly improving throughput.
- ✗
Decrease the batch size of messages polled from SQS.
Why it's wrong here
Reducing the SQS batch size means each polling cycle retrieves and processes fewer messages per API call, which lowers per-task throughput and would make messages accumulate in the queue even faster rather than helping to relieve the backlog.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.