Q87 — AWS DOP-C02 Ch.3

Question 87 of 100 | ← Chapter 3

A company runs an application on 12 Amazon EC2 instances. These instances run in an Amazon EC2 Auto Scaling group spanning three Availability Zones. On a typical day, each EC2 instance experiences 30% CPU utilization during business hours and 10% after business hours. CPU utilization spikes sharply during the first five minutes of business hours and increases gradually thereafter. A DevOps engineer needs to optimize cost while maintaining or improving application availability.

• A. Configure a target tracking scaling policy for the Auto Scaling group based on average CPU utilization, targeting 75%. Create a scheduled action for the Auto Scaling group to adjust desired capacity to six instances before business hours begin. ✓
• B. Configure the Auto Scaling group with two scheduled actions using Amazon EC2 Auto Scaling. Configure one action to launch nine EC2 instances at the start of business hours. Configure another action to terminate nine EC2 instances at the end of business hours.
• C. Migrate to AWS Application Auto Scaling. Configure a target tracking scaling policy based on average CPU utilization for the Auto Scaling group, targeting 75%. Create a scheduled action to reduce minimum instances to three at the end of business hours and reset to six before business hours begin.
• D. Migrate to AWS Application Auto Scaling. Configure a target tracking scaling policy based on average CPU utilization for the Auto Scaling group, targeting 75%. Create a scheduled action to terminate nine instances nightly at the end of business hours.

Correct Answer: A. Configure a target tracking scaling policy for the Auto Scaling group based on average CPU utilization, targeting 75%. Create a scheduled action for the Auto Scaling group to adjust desired capacity to six instances before business hours begin.

Explanation

Options C and D are invalid because AWS Application Auto Scaling does not manage EC2 Auto Scaling groups—it manages scalable resources like ECS services, DynamoDB tables, and Aurora clusters. Option B is suboptimal because it blindly starts/stops instances regardless of actual load, risking downtime during unexpected spikes or underutilization. Option A correctly combines dynamic scaling (target tracking at 75%) with proactive capacity adjustment (scheduled action to six instances before business hours), balancing cost efficiency and responsiveness to predictable load patterns.