SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company runs a microservices application on Amazon ECS with the Fargate launch type. The application uses an Application Load Balancer (ALB) to distribute traffic. During a recent incident, one service became unresponsive, but the ALB continued to send traffic to it because the health check only verified that the container was running. The company wants to improve the health check to detect application-level failures and automatically replace unhealthy tasks. Which solution should a solutions architect recommend?

⚠ Common exam trap

The trap here is assuming that container-level health checks or increased timeouts can detect application-level failures, when they only check process liveness.

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

✓

Configure the ALB health check to use a custom path that returns a 200 OK only when the application is fully functional, and set the health check interval and thresholds appropriately.

Configuring the ALB health check to use a custom path that reflects application health ensures that only fully functional tasks receive traffic. This is a straightforward and effective way to detect application-level failures without introducing additional components. It leverages existing ALB features and integrates with ECS task replacement.

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 ALB health check timeout and unhealthy threshold to give the application more time to recover.
Why it's wrong here
Increasing timeout and threshold delays detection of unhealthy tasks and does not improve the ability to detect application-level failures. It may prolong the impact of an unresponsive service. The health check itself must be enhanced to verify application functionality, not just timing parameters.
✗
Enable ECS container health checks by adding a HEALTHCHECK instruction to the Dockerfile, and rely on ECS to replace unhealthy tasks.
Why it's wrong here
ECS container health checks only verify the container's health based on the Docker HEALTHCHECK command, which may not reflect application-level dependencies. The ALB would still route traffic to tasks that pass the container health check but are not functionally healthy. This does not meet the requirement to detect application-level failures.
✓
Configure the ALB health check to use a custom path that returns a 200 OK only when the application is fully functional, and set the health check interval and thresholds appropriately.
Why this is correct
A custom health check path allows the ALB to verify application-level health, not just that the container is running. By returning a 200 OK only when dependencies are available and the service is ready, the ALB can detect failures and stop routing traffic to unhealthy tasks. Adjusting intervals and thresholds ensures timely detection and replacement.
✗
Use AWS App Mesh to implement outlier detection and eject unhealthy tasks from the load balancing pool.
Why it's wrong here
AWS App Mesh provides service mesh capabilities, including outlier detection, but it requires significant changes to the application deployment and adds complexity. It is not necessary when the ALB can be configured with a custom health check. App Mesh is better suited for more complex microservices communication patterns.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question