SOA-C02 Cost and Performance Optimization 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.

• ✗

  Manually stop the instances at 5 PM and start them at 9 AM each weekday.

  Why it's wrong here

  This approach relies on a human remembering to execute the EC2 StopInstances and StartInstances API calls at exact times each day. It is not automated, creates significant operational overhead, and any missed or delayed action results in either unnecessary compute spend or unscheduled downtime. A fully manual process also does not scale across multiple accounts or regions.

• ✗

  Create an Auto Scaling group with a scheduled scaling action to set desired capacity to 0 during off-hours.

  Why it's wrong here

  A scheduled scaling action adjusts the Auto Scaling group's desired capacity, and when set to zero the group terminates all EC2 instances rather than stopping them. Termination is destructive: instance IDs are lost, instance-store data is deleted, and any running workloads are disrupted. Auto Scaling groups only manage launch and termination, not the EC2 StopInstances action, so this cannot preserve instance state for a start/stop schedule.

• ✗

  Set up a CloudWatch alarm that stops instances when CPU utilization is below 1% for 30 minutes.

  Why it's wrong here

  This is a reactive, utilization-based action rather than a fixed schedule, so instances could be stopped at any time CPU remains below 1% — including daytime lulls or holidays — causing unexpected outages. It also does not guarantee a 5 PM stop or a 9 AM start; if a batch job briefly spikes CPU, the alarm will not trigger, and instances will remain running all night. CloudWatch alarm actions can send a stop, but they do not provide a recurring scheduled start time.

• ✓

  Use the AWS Instance Scheduler to define a schedule that stops instances at 5 PM and starts them at 9 AM on weekdays.

  Why this is correct

  The AWS Instance Scheduler is a reference solution that deploys AWS Lambda functions and Amazon DynamoDB tables via AWS CloudFormation to automatically issue EC2 StopInstances and StartInstances calls based on user-defined daily or weekly periods. It works by evaluating instance tags against stored schedules, supports time zones, and can handle large fleets across accounts and regions. Because it stops rather than terminates instances, EBS-backed volumes, private IP addresses, and instance IDs are preserved.

Go deeper

Related to this question