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 a CloudWatch alarm on CPU utilization that triggers an Auto Scaling policy to replace the instance

  Why this is correct

  A CloudWatch alarm on CPUUtilization monitors the metric in near real-time and, when breached, triggers an Auto Scaling policy that terminates the affected instance, after which the Auto Scaling group automatically launches a fresh replacement. This directly addresses the intermittent high latency by reacting to the actual symptom (high CPU) as it occurs, rather than relying on predetermined schedules, and the managed replacement ensures capacity is maintained without manual intervention.

• ✗

  Use Auto Scaling scheduled scaling actions to replace instances at peak times

  Why it's wrong here

  Scheduled scaling actions execute on a fixed cron or recurrence schedule, which assumes that traffic and CPU patterns are predictable. Intermittent high latency does not follow a consistent timeline, so pre-scheduled replacements will either fire too early, too late, or not at all, and cannot adapt to a sudden CPU spike. These actions are designed for planned peak windows, not for responding to real-time utilization, making them useless for an unpredictable, intermittent problem.

• ✗

  Use AWS Lambda to periodically check CPU and terminate high-CPU instances

  Why it's wrong here

  Using Lambda to periodically poll CPU Utilization and then terminate instances is a custom, out-of-band control loop that lacks Auto Scaling integration. Terminating an instance directly does not automatically launch a replacement unless you also implement separate logic to call the EC2 RunInstances API or force a scale-in, and the periodic polling interval (e.g., every few minutes) adds latency that worsens the outage. Additionally, this approach bypasses Auto Scaling health checks and lifecycle hooks, making the process error-prone and unable to maintain the desired capacity reliably.

• ✗

  Configure the ALB health check to mark instances unhealthy when CPU is high

  Why it's wrong here

  ALB health checks operate at Layers 4 and 7 and verify an instance's ability to respond to HTTP(S) or TCP requests; they do not measure CPU utilization or any other CloudWatch metric. You cannot configure an ALB health check to directly mark an instance unhealthy based on CPU because the health check merely attempts a request (such as GET /) and considers the instance unhealthy on connection or HTTP failure. Even if the application were customized to return a 5xx under high CPU, that would be a manual application-level signal, not an ALB-native CPU check, and it would only stop routing traffic—it would not automatically replace the instance unless Auto Scaling were also configured.

Go deeper

Related to this question