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.

• ✗

  Increase the memory limit for each ECS task to accommodate memory leaks.

  Why it's wrong here

  Raising the memory limit for each ECS task merely delays the inevitable out-of-memory kill because the root cause—the memory leak—remains unaddressed. In a shared EC2 cluster, increasing per-task limits can reduce scheduling density and enlarge the blast radius when a container ultimately crashes. This approach does not introduce any failure isolation, so dependent services will continue to call into the failing service and experience timeouts, allowing cascading failures to propagate.

• ✓

  Implement circuit breaker patterns in the service discovery and client libraries to stop calling unhealthy services.

  Why this is correct

  Circuit breakers are a client-side resilience pattern that monitor outgoing requests to a dependency and, after exceeding a failure threshold, automatically fail fast without attempting the network call. In an ECS microservices environment with service discovery, this stops unhealthy services from being flooded with retries, preventing latency spikes and thread exhaustion in healthy services. By quarantining the failing service from call traffic, circuit breakers effectively stop cascading failures and allow the unhealthy service time to recover.

• ✗

  Enable connection draining on the ALB to allow in-flight requests to complete.

  Why it's wrong here

  ALB connection draining is designed for graceful deregistration and instance termination, allowing in-flight requests to finish before a target is removed from rotation. It does not prevent other services from initiating new requests to an unhealthy ECS task, nor does it help once the service is already degraded and new calls are still routed to it. Because connection draining only applies to existing connections, it has no ability to stop the propagation of failures to downstream clients.

• ✗

  Implement automatic scaling policies for ECS services based on memory utilization.

  Why it's wrong here

  ECS Service Auto Scaling based on memory utilization adjusts the desired task count only after average memory usage crosses a threshold, which lags behind a fast-spreading memory leak and cannot fix the leak itself. Adding more tasks spreads memory pressure but does not protect clients from calls to tasks that are already failing; scaling may even temporarily mask the problem until the entire cluster's capacity is exhausted. Ultimately, it fails to address the root cause or introduce failure isolation, so cascading failures remain possible.

Go deeper

Related to this question