DVA-C02 Troubleshooting and Optimization 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.

• ✗

  The security group for the ECS tasks is blocking inbound traffic from the ALB.

  Why it's wrong here

  If the security group for the ECS tasks were blocking inbound traffic from the Application Load Balancer (ALB), the health checks would consistently fail for all tasks, not intermittently. This would manifest as all tasks being marked unhealthy or never becoming healthy, rather than sporadic 503 errors. Intermittent failures suggest an issue within the application's processing rather than a fundamental network blockage that would prevent any connection.

• ✗

  The ECS tasks are running out of CPU credits, causing slow response times.

  Why it's wrong here

  Amazon ECS Fargate tasks utilize a CPU share model, where CPU is allocated as a fixed amount, rather than a CPU credit system found in burstable EC2 instances like T-types. Therefore, tasks cannot 'run out of CPU credits' in the same way. While insufficient CPU allocation can lead to general slow performance and increased latency, it typically results in application timeouts or slowness across all requests, not specifically intermittent 503 health check failures caused by a hanging endpoint.

• ✗

  The ECS service is configured with a task placement strategy that is causing tasks to be stopped and restarted frequently.

  Why it's wrong here

  Frequent task restarts due to a misconfigured ECS service placement strategy would primarily cause temporary unavailability as old tasks are stopped and new ones launched. While this might lead to brief periods of service disruption, it would not directly cause *existing* healthy tasks to intermittently fail ALB health checks with 503 errors. The issue described points to a problem within the running application's responsiveness, not its lifecycle management or task replacement.

• ✓

  The application is not properly handling timeouts to the third-party service, causing the health check endpoint to hang.

  Why this is correct

  When an application's health check endpoint makes a synchronous call to a third-party service without proper timeout handling, a slow or unresponsive external dependency can cause the health check to hang indefinitely. This prolonged unresponsiveness will eventually exceed the Application Load Balancer's configured health check timeout threshold. Consequently, the ALB will mark the task as unhealthy and return a 503 error for requests routed to it, leading to intermittent service disruptions as tasks are cycled.

Go deeper

Related to this question