DOP-C02 Resilient Cloud Solutions Practice Question
A company runs a containerized application on Amazon ECS with Fargate. The application needs to be resilient to Availability Zone failures. Which THREE actions should the company take? (Choose THREE.)
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure the ECS service to spread tasks across multiple Availability Zones.
Spreading tasks across multiple Availability Zones ensures that an AZ failure does not impact all tasks, increasing resilience. Option C is correct because using a multi-AZ Amazon RDS or DynamoDB provides persistent data storage that survives AZ failures. Option D is correct because an Application Load Balancer with targets in multiple AZs distributes traffic and can route requests to healthy targets in other AZs if one fails. Option B is wrong because disabling managed service scaling reduces the application's ability to handle load changes and may impact availability. Option E is wrong because a single service discovery namespace does not provide AZ resilience; it only provides service discovery without redundancy across AZs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure the ECS service to spread tasks across multiple Availability Zones.
Why this is correct
Configure the ECS service with a spread placement strategy across Availability Zones (AZs) using either the ability to spread evenly or by AZ as a custom attribute. This guarantees that tasks are distributed redundantly, so if one AZ becomes unavailable, the remaining tasks in other AZs continue to serve traffic and provide capacity for service scaling to replace unhealthy tasks. Without this spread, Amazon ECS could place all tasks in a single AZ, creating a single point of failure that contradicts the goal of high availability.
- ✗
Disable managed service scaling to avoid resource contention.
Why it's wrong here
Disabling managed service scaling (such as target tracking or step scaling policies) removes the automation that adjusts the desired task count in response to load or failure events. This leaves the service at a fixed capacity, meaning it cannot absorb traffic spikes or compensate for tasks lost in an AZ failure, which actually worsens resource contention rather than avoiding it. Managed scaling works with placement strategies to maintain resilience; disabling it reduces the service's ability to self-heal and scale out, so this is not a valid resilience measure.
- ✓
Use a multi-AZ Amazon RDS or DynamoDB for persistent data.
Why this is correct
Using a multi-AZ Amazon RDS deployment (with synchronous replication to a standby in a different AZ) or DynamoDB (which automatically replicates partitions across three AZs within a Region) ensures the persistent data tier remains available and durable when an AZ fails. This is critical because ECS tasks are stateless and often rely on an external database; a single-AZ database would become inaccessible, causing the entire application to fail even if compute tasks are spread across AZs. Multi-AZ databases also provide automatic failover and a stable endpoint, allowing newly placed tasks in healthy AZs to reconnect without manual intervention.
- ✓
Deploy an Application Load Balancer (ALB) with targets in multiple Availability Zones.
Why this is correct
Deploying an Application Load Balancer (ALB) with subnets and registered targets in multiple Availability Zones provides the traffic distribution and health-checking layer needed to route requests only to healthy tasks in unaffected AZs. The ALB itself runs redundantly across AZs and automatically stops sending traffic to targets that fail health checks, such as tasks in an AZ that experiences an outage. This ensures that even if one AZ fails, the remaining tasks in other AZs receive the full traffic load, preserving availability at the edge. Without a multi-AZ ALB, even a properly spread ECS service would be unreachable from the internet if the load balancer were a single point of failure.
- ✗
Use a single service discovery namespace for all tasks.
Why it's wrong here
Using a single service discovery namespace (for example, AWS Cloud Map) for all tasks does not provide any placement, failover, or redundancy benefits because it only manages DNS records and instance discovery. A namespace identifies services and allows them to find each other, but it does not influence where ECS places tasks, how traffic is routed, or how failures are handled. While it may simplify naming, it cannot make the application resilient to an AZ outage; resilience requires spread placement, multi-AZ infrastructure, and proper failover mechanisms, not DNS organization.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company runs a microservices application on Amazon ECS with Fargate. The application includes a service that processes orders and stores them in an RDS PostgreSQL database. The company wants to ensure that the order service is resilient to AZ failures and can handle a sudden increase in order volume. Which TWO actions should the DevOps engineer take? (Choose TWO.)
medium- A.Increase the CPU and memory limits for the ECS task definition.
- B.Place an Amazon CloudFront distribution in front of the order service.
- ✓ C.Deploy the RDS instance in a Multi-AZ configuration.
- ✓ D.Configure the ECS service to run tasks in multiple Availability Zones.
- E.Use RDS Proxy to manage database connections.
Why C: Deploying the RDS instance in a Multi-AZ configuration provides automatic failover to a standby replica in a different Availability Zone, ensuring database resilience to AZ failures. Option D is correct because configuring the ECS service to run tasks in multiple Availability Zones distributes the order processing workload across AZs, improving both fault tolerance and scalability during sudden traffic spikes.
Variation 2. A company runs a stateless web application on Amazon ECS with Fargate. The application must be highly available across multiple Availability Zones. What is the BEST way to achieve this?
medium- ✓ A.Create an ECS service with tasks in multiple AZs and place an ALB in front.
- B.Use an Auto Scaling group of EC2 instances in a single AZ and run ECS tasks on them.
- C.Deploy a CloudFront distribution with multiple origins in different AZs.
- D.Deploy a single ECS service with tasks in one AZ and use an ALB.
Why A: Running an ECS service with tasks in multiple Availability Zones (AZs) and placing an Application Load Balancer (ALB) in front ensures that if one AZ becomes unavailable, the ALB can route traffic to healthy tasks in the remaining AZs. This architecture provides both high availability and fault tolerance for the stateless web application, as the ALB performs health checks and distributes requests across tasks in different AZs.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.