SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company runs a microservices application on Amazon ECS with the EC2 launch type. The application consists of multiple services that communicate over HTTP. The operations team wants to improve observability and reduce the time to diagnose performance issues between services. They have already enabled CloudWatch Logs and metrics. They want to trace requests as they flow through the services and identify latency bottlenecks. What should a solutions architect recommend?

⚠ Common exam trap

The trap here is thinking that CloudWatch ServiceLens or VPC Flow Logs can provide tracing without code changes, but X-Ray requires instrumentation to generate the trace data that ServiceLens then visualizes.

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 by instrumenting the application code and running the X-Ray daemon as a sidecar container in each ECS task.

AWS X-Ray is designed for distributed tracing of microservices. Instrumenting the application with the X-Ray SDK and running the X-Ray daemon as a sidecar in each ECS task enables the collection of trace data. This provides a service map, latency analysis, and error identification. Other options do not capture application-level request flows or require code instrumentation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Configure CloudWatch ServiceLens to automatically trace requests without code changes.
Why it's wrong here
CloudWatch ServiceLens combines X-Ray traces with CloudWatch metrics and logs, but it does not automatically trace requests without code instrumentation. You still need to instrument your application with the X-Ray SDK to generate trace data. ServiceLens is a visualization layer that uses X-Ray data; it is not a standalone tracing solution. Without instrumentation, there would be no traces to display.
✓
Enable AWS X-Ray tracing by instrumenting the application code and running the X-Ray daemon as a sidecar container in each ECS task.
Why this is correct
AWS X-Ray provides end-to-end tracing of requests as they travel through microservices. By instrumenting the application with the X-Ray SDK and running the X-Ray daemon as a sidecar in each ECS task, the daemon can collect trace data and send it to X-Ray. This allows visualization of service maps, latency analysis, and identification of bottlenecks. It integrates natively with ECS and is the recommended approach for distributed tracing in microservices.
✗
Use AWS CloudTrail to log all API calls between services and analyze the logs in Amazon Athena.
Why it's wrong here
CloudTrail records AWS API calls made within your account, not application-level HTTP requests between microservices. It does not capture the flow of requests through your services or provide latency breakdowns. Analyzing CloudTrail logs in Athena would not give insights into inter-service communication or performance bottlenecks. This is not a tracing solution for application requests.
✗
Enable VPC Flow Logs on the ECS cluster's VPC and analyze the logs with Amazon QuickSight.
Why it's wrong here
VPC Flow Logs capture IP traffic metadata, such as source/destination and bytes transferred, but not application-level request paths or latency. They cannot trace a request across services or identify which service is causing a bottleneck. QuickSight is a BI tool for visualization, but the underlying data lacks the necessary detail for distributed tracing. This approach would not meet the observability requirements.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question