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.

• ✓

  Create an ECS service with tasks in multiple AZs and place an ALB in front.

  Why this is correct

  Running ECS tasks in multiple Availability Zones ensures that an AZ failure does not cause total loss of capacity. The ALB performs health checks and routes traffic only to healthy targets, so if tasks in one AZ become unhealthy, traffic automatically shifts to tasks in the other AZ. Additionally, ECS service scheduler maintains desired task count across AZs, and with service auto scaling you can scale based on request count or CPU. This architecture provides both resiliency and elasticity.

• ✗

  Use an Auto Scaling group of EC2 instances in a single AZ and run ECS tasks on them.

  Why it's wrong here

  An Auto Scaling group can only maintain or replace EC2 instances, but if the entire ASG is pinned to a single AZ, an outage in that AZ takes down every instance and every running task. Even if the ASG scales out, it cannot move capacity to another AZ because the launch configuration or template specifies a single subnet placement. ECS tasks scheduled on these instances are equally vulnerable; there is no cross-AZ failover possible, so the application is not highly available.

• ✗

  Deploy a CloudFront distribution with multiple origins in different AZs.

  Why it's wrong here

  CloudFront is a content delivery network for caching and accelerating delivery of static content at edge locations, not a compute service for running application containers. You cannot place an ECS task behind CloudFront as an origin for dynamic compute in a way that provides high availability for the application tier; CloudFront does not manage or schedule ECS tasks. While multiple origins could be specified, CloudFront does not do health checks for failover based on application availability in the same way as an ALB; it can use origin failover but that's for CDN content, not for providing HA compute capacity.

• ✗

  Deploy a single ECS service with tasks in one AZ and use an ALB.

  Why it's wrong here

  Deploying a single ECS service in one AZ means all tasks share the same failure domain. If that AZ becomes unavailable, the ALB has no healthy targets in another AZ to which it can route traffic, so all users experience downtime. Even if the ALB is itself multi-AZ, the bottleneck is the compute capacity in a single AZ. ECS service auto scaling may try to replace tasks, but in the same AZ which is degraded, so it doesn't restore availability.

Go deeper

Related to this question