DOP-C02 Resilient Cloud Solutions Practice Question
A company runs a stateless web application on Amazon ECS with Fargate launch type. The application experiences intermittent traffic spikes. The company wants to ensure that the application can scale automatically and remain resilient to underlying infrastructure failures. Which combination of actions should the DevOps engineer take?
⚠ Common exam trap
Candidates often assume CPU utilization is the only valid scaling metric for web applications, but memory utilization can be more appropriate for stateless workloads, and they may overlook the critical need for service auto-recovery to handle infrastructure failures in Fargate.
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 an Application Auto Scaling target tracking policy based on memory utilization and enable Amazon ECS service auto-recovery.
It combines Application Auto Scaling target tracking based on memory utilization, which is a relevant metric for a stateless web application to handle traffic spikes, with Amazon ECS service auto-recovery, which automatically replaces unhealthy tasks to ensure resilience against underlying infrastructure failures. This approach provides both automatic scaling and fault tolerance without manual intervention.
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 a scheduled scaling policy for the Amazon ECS service to add tasks during known peak hours.
Why it's wrong here
Scheduled scaling policies adjust desired capacity only at predefined times, so they cannot react to the unexpected, spiky traffic this stateless web application experiences. If a surge occurs outside the scheduled window, the service remains under-provisioned and request latency or errors increase. Furthermore, scheduled scaling does not monitor live memory or CPU utilization, nor does it replace failed tasks, so it provides neither elasticity for real-time demand nor resilience to infrastructure failures.
- ✗
Launch tasks in a single Availability Zone and use an Application Auto Scaling target tracking policy based on CPU utilization.
Why it's wrong here
Running all ECS tasks in a single Availability Zone creates a single point of failure: if that AZ loses power or connectivity, the entire application goes down, violating high-availability expectations. While a CPU-based target tracking policy can adjust capacity based on compute load, it does not protect against zone failures, and if the application is memory-constrained, CPU utilization may remain low while memory exhausts, causing the policy to scale too late. A resilient design must distribute tasks across multiple Availability Zones regardless of the auto scaling mechanism.
- ✗
Configure a step scaling policy for the Amazon ECS service and increase the task memory size.
Why it's wrong here
A step scaling policy can add or remove tasks in response to defined CloudWatch alarm thresholds, but the additional measure of increasing task memory size does not increase task count or improve tolerance to task failures. Larger task memory definitions reduce the number of tasks that can run on each EC2 instance, potentially lowering overall service capacity and increasing cost. This approach also lacks any automatic replacement mechanism for unhealthy tasks, so a failed task permanently reduces capacity until manual intervention.
- ✓
Configure an Application Auto Scaling target tracking policy based on memory utilization and enable Amazon ECS service auto-recovery.
Why this is correct
An Application Auto Scaling target tracking policy with memory utilization as the metric dynamically scales out tasks when memory pressure increases and scales in when it subsides, providing immediate response to unpredictable workload spikes. Amazon ECS service auto-recovery, enabled through service health checks and automatic task replacement, ensures that any tasks that fail or become unhealthy are automatically restarted, maintaining desired availability. Together, these mechanisms deliver both elasticity—scaling with real-time demand—and resilience—self-healing from task or infrastructure failures—for the stateless web application.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 251 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 →
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.