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.

• ✗

  Place all tasks in the same Availability Zone to reduce latency

  Why it's wrong here

  Collocating every task in a single Availability Zone trades resilience for the negligible latency saved over inter-AZ network hops. If that AZ experiences an outage, the entire service becomes unavailable because ECS cannot place replacement tasks elsewhere, and the service scheduler's default spread placement is overridden. A production microservice must tolerate an AZ failure, which requires distributing tasks across multiple AZs rather than pinning them to one.

• ✗

  Run a standalone Fargate task and use a CloudWatch alarm to restart it

  Why it's wrong here

  A standalone Fargate task is a one-shot invocation: ECS does not track its health or restart it if it exits, because only tasks managed by an ECS service benefit from desired-count reconciliation. A CloudWatch alarm can only notify or trigger another action (such as a Lambda function), not directly restart a Fargate task, and the intervention window leaves the service down. This approach lacks the automatic replacement that an ECS service provides, and also does not support multi-AZ distribution.

• ✗

  Use an EC2 launch type with a single instance to reduce complexity

  Why it's wrong here

  Running an EC2 launch type with a single instance creates a single point of failure: if that instance terminates, crashes, or is stopped for maintenance, every task on it is lost and the cluster has no registered container instance on which to place replacements. Even with an ECS service, desired count cannot be maintained because the service scheduler has no other instance in the cluster. Multi-AZ fault tolerance and enough capacity for tasks require a cluster of multiple instances, especially for a critical microservices workload.

• ✓

  Define an ECS service with a task definition, set desired count across multiple Availability Zones, and use Service Auto Scaling

  Why this is correct

  An ECS service with a task definition and a multi-AZ placement strategy is the correct pattern because the service scheduler continuously maintains the desired count, automatically replacing tasks that fail, become unhealthy, or lose connectivity. Distributing tasks across multiple Availability Zones ensures the service remains available even if an entire AZ goes down, as the remaining AZs still host task copies. Service Auto Scaling independently adjusts the desired count based on CloudWatch metrics or target tracking, providing elasticity and capacity management without sacrificing the resilience built into the service model.

Go deeper

Related to this question