SAP-C02 Continuous Improvement for Existing Solutions Practice Question
A company is using Amazon ECS with Fargate launch type for a microservices application. The application experiences intermittent latency spikes. CloudWatch metrics show high CPU utilization but no obvious pattern. What should the company do to identify the cause?
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
✓
Enable AWS X-Ray tracing on the ECS tasks to trace requests across microservices.
AWS X-Ray provides distributed tracing to pinpoint performance bottlenecks. Option A is wrong because increasing task size is a reactive fix that does not identify the cause. Option C is wrong because CloudWatch Synthetics monitors endpoint availability, not internal trace data. Option D is wrong because CloudWatch Logs Insights is for querying logs, not for tracing requests across microservices.
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 CPU and memory for all ECS tasks.
Why it's wrong here
Scaling CPU and memory masks the symptom without revealing which task, dependency or request pattern causes the spikes; the stem asks for diagnosis, not remediation. It is tempting because Fargate task sizing is the usual lever for sustained high utilisation, and would be right if metrics showed a persistent, uniform CPU ceiling rather than intermittent, patternless spikes.
- ✓
Enable AWS X-Ray tracing on the ECS tasks to trace requests across microservices.
Why this is correct
AWS X-Ray traces individual requests across microservices, exposing where latency accumulates within the call path rather than just aggregate CPU metrics. Since CloudWatch shows high CPU utilisation without an obvious pattern, X-Ray's per-request service map and segment timings pinpoint the specific downstream call or task causing intermittent spikes.
- ✗
Set up CloudWatch Synthetics canaries to monitor the endpoints.
Why it's wrong here
Synthetics canaries measure endpoint availability and latency from outside, revealing that spikes occur but not which task or dependency causes them. Canaries suit proactive uptime and SLA monitoring; correlating CPU spikes to specific tasks needs Container Insights or X-Ray tracing instead.
- ✗
Use CloudWatch Logs Insights to analyze application logs for errors.
Why it's wrong here
Application logs capture errors and exceptions, not the CPU contention or task-level resource behaviour producing the latency spikes, so no causal signal appears. Logs Insights is genuinely useful for tracing stack traces and request failures, and would be the right tool if the spikes correlated with logged errors rather than raw CPU saturation.
Go deeper
Related to this question
About these practice questions
This SAP-C02 question is part of Courseiva's 984-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 SAP-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 SAP-C02 exam.