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.

• ✗

  Use a single subnet for all tasks to simplify networking.

  Why it's wrong here

  Consolidating all ECS tasks into a single subnet confines their Elastic Network Interfaces to one Availability Zone, creating a single point of failure: if that AZ loses power or connectivity, every task becomes unreachable. Simplifying networking by collapsing subnets does not add fault tolerance; instead, it removes the ability for the service scheduler to disperse tasks across independent failure domains.

• ✓

  Configure the ECS service to place tasks in multiple Availability Zones.

  Why this is correct

  Placing tasks in multiple Availability Zones is a core high-availability strategy because each AZ is an isolated, independent failure domain. The ECS service scheduler spreads tasks across the chosen subnets, so when one AZ is impacted by an outage, the tasks in the other AZs continue serving traffic and the service can still meet its desired count. This addresses resilience by ensuring no single infrastructure failure can take down the entire service.

• ✗

  Increase the task memory reservation to handle peak load.

  Why it's wrong here

  Increasing the task memory reservation is a capacity-planning measure that prevents OOM kills during peak load, but it does not make the service resilient to infrastructure or dependency failures. Resilience is about maintaining availability despite failures, whereas memory allocation only addresses performance under a specific workload profile. Over-reserving memory can unnecessarily reduce the number of tasks your cluster can run, increasing cost without improving fault tolerance.

• ✓

  Implement a circuit breaker pattern for downstream dependencies.

  Why this is correct

  Implementing a circuit breaker pattern protects the service from cascading failures when downstream dependencies degrade or become unavailable. Instead of letting tasks time out and retry endlessly—which can exhaust connections, CPU, and memory—the circuit breaker quickly opens and returns a fallback error, giving the dependency time to recover. This resilience technique is complementary to infrastructure redundancy because it stops application-level failure propagation even when underlying tasks are healthy.

• ✗

  Use scheduled scaling to adjust task count based on historical patterns.

  Why it's wrong here

  Scheduled scaling adjusts the task count based on recurring historical patterns, such as daily or weekly traffic peaks, so it cannot react to unexpected demand spikes or sudden failures. It is a capacity optimization tool for predictable workloads, not a resilience mechanism, because it does not monitor actual health or load in real time. A resilient service uses target tracking scaling policies that adjust capacity based on current metrics like CPU utilization or request count.

Go deeper

Related to this question