DOP-C02 Resilient Cloud Solutions Practice Question
Your company runs a multi-tier web application on AWS. The web tier consists of EC2 instances behind an Application Load Balancer (ALB) in an Auto Scaling group across three Availability Zones. The application tier runs on a separate Auto Scaling group of EC2 instances that process requests from the web tier. The database tier uses an Amazon RDS for PostgreSQL Multi-AZ deployment. All application servers write logs to Amazon CloudWatch Logs. Recently, the operations team reported that during peak hours, the web tier experiences intermittent 503 errors. The ALB access logs show that the errors occur when the target group's healthy host count drops to zero momentarily. The Auto Scaling group's minimum and desired capacity is 6, with a maximum of 12. The scaling policy is based on average CPU utilization, with a target of 60%. The health check grace period is 300 seconds. The application health check endpoint returns a 200 status when healthy. The DevOps engineer suspects that the scaling policy is too slow to react to traffic spikes. The engineer wants to implement a more proactive scaling approach. Which solution should the engineer implement?
⚠ Common exam trap
The trap is assuming that tuning reactive scaling parameters (cooldown, step adjustments, grace period) will solve a proactive capacity problem, when the real fix is forecasting-based scaling.
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
✓
Implement a predictive scaling policy combined with dynamic scaling to proactively adjust capacity based on forecasted traffic.
Predictive scaling uses machine learning to forecast future traffic based on historical patterns and proactively provisions capacity ahead of predicted demand, which directly addresses the slow reaction of reactive CPU-based scaling. Combining predictive scaling with dynamic scaling provides both proactive baseline capacity and reactive adjustments for unexpected spikes. This is the AWS-recommended approach for cyclical traffic patterns with intermittent 503 errors caused by insufficient capacity during peaks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement a predictive scaling policy combined with dynamic scaling to proactively adjust capacity based on forecasted traffic.
Why this is correct
Predictive scaling uses the Auto Scaling group's historical load data with machine learning to forecast future demand, generating scheduled scaling actions before the predicted load arrives. By pairing it with dynamic scaling (target tracking or step), you cover both the expected trend and real-time deviations, ensuring that instances are already available before traffic peaks. This proactive capacity prevents the healthy host count from ever collapsing to zero, unlike purely reactive policies that still have to wait for alarms and instance startup.
- ✗
Implement a scheduled scaling policy that increases capacity 30 minutes before the expected peak.
Why it's wrong here
Scheduled scaling relies on manually defined times for predictable load patterns, such as a daily 9 a.m. peak. If the actual peak shifts earlier, lasts longer, or exceeds the forecasted level, the pre-scheduled increase may be too late or too small, leaving the ASG unable to maintain a sufficient number of healthy hosts. It also offers no feedback loop to adjust capacity based on current traffic, so it cannot compensate for unexpected spikes and can still result in zero healthy instances.
- ✗
Increase the health check grace period to 600 seconds to give new instances more time to become healthy.
Why it's wrong here
Increasing the health check grace period only delays when new instances are evaluated by ELB health checks; it does nothing to increase the total number of instances or speed up scaling out. If the true problem is that existing instances are overwhelmed and failing health checks due to insufficient capacity, a longer grace period will keep unhealthy instances in rotation longer, potentially making the outage worse. It also cannot remediate an already zero-healthy-host state, and standard grace periods like 300 seconds are already sufficient for most bootstrapping.
- ✗
Switch to a step scaling policy with a lower cooldown period and a greater scaling adjustment.
Why it's wrong here
Step scaling with a lower cooldown and larger adjustment is still a reactive mechanism that responds only after CloudWatch alarms fire. Even if it triggers a large scale-out immediately, the time needed to launch, bootstrap, and pass health checks means the healthy host count can still drop to zero during a rapid traffic surge. Lower cooldowns may allow more aggressive scaling, but they do not eliminate the inherent latency of reacting after the fact, which is why proactive predictive scaling is required.
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.