DOP-C02 Resilient Cloud Solutions 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 health check command only checks the process status, not the application's ability to serve requests.

  Why this is correct

  Using a process-only health check (e.g., checking that the PID exists) means the ECS/ALB considers the container healthy whenever the runtime is alive, regardless of whether the app can actually serve HTTP traffic. As a result, intermittent 500 errors caused by a hung worker, exhausted connection pool, or an unhandled exception inside request handling remain invisible to the health check, so the task stays in service and keeps receiving traffic. A valid health check should send a real request to the application's endpoint and verify the response code.

• ✗

  The application is missing environment variables that are required for certain requests.

  Why it's wrong here

  A missing environment variable—such as DATABASE_URL, API_KEY, or feature-flag configuration—typically causes deterministic failures: each request that depends on that variable will fail the same way until the task is redeployed with the correct value. Because the symptom is intermittent 500s while other requests apparently succeed, an environment variable gap is an unlikely root cause; such a misconfiguration would not randomly change behavior per request. ECS also injects environment variables at task start, so the failure pattern would be consistent across all tasks and requests.

• ✗

  The ECS service is configured with a target tracking scaling policy that reacts too slowly.

  Why it's wrong here

  A target tracking scaling policy responds to CloudWatch metrics like CPUUtilization or ALBRequestCountPerTarget, and its reaction time is measured in minutes due to metric aggregation and cooldown periods; but scaling lag alone does not cause individual healthy tasks to return intermittent 500s. Slow scaling would instead create a gradually worsening capacity deficit, where errors would become more frequent as load grows and then subside as new tasks register. Since the health check still passes and the question points to a health-check defect, a scaling policy that reacts too slowly explains sustained under-provisioning, not the intermittent HTTP 500s.

• ✗

  The container port and host port in the task definition do not match the ALB target group port.

  Why it's wrong here

  A port mismatch between the task definition's containerPort and the ALB target group's port is a static configuration error: the ALB health check will connect to the wrong port and consistently mark every target unhealthy, causing the service to cycle tasks and fail to route traffic at all. The inconsistency described (intermittent 500s) cannot result from a port mismatch, because the behavior is binary—either the health check succeeds and traffic is delivered, or it fails and the target is deregistered. With Fargate's awsvpc network mode, host port mapping is not relevant, further confirming this option is not the culprit.

Go deeper

Related to this question