EC2 Auto Scaling: SOA-C03 study notes and practice questions
What to know about EC2 Auto Scaling for the SOA-C03 exam, from the Reliability and Business Continuity domain (22% of the exam guide), then 3 free questions to test it. Part of the SOA-C03 study guide.
Auto Scaling questions cover choosing policies, handling slow-booting instances, and fixing groups that don’t behave.
Scaling policies
Policy
Use
Target tracking
Keep a metric near a value (CPU 50%, requests per target, SQS backlog per instance)
Step scaling
Different responses for different alarm breach sizes
Scheduled
Known times (every weekday at 8:00, a launch date)
Predictive
Recurring daily or weekly patterns; launches capacity ahead of time
Policies can work together; the group takes the action that gives the most capacity.
Features
Health checks: turn on ELB health checks so instances failing the load balancer’s check are replaced, not just those failing EC2 status checks. A health check grace period gives new instances time to start.
Warm pools keep pre-initialized instances stopped (or hibernated, or running) for fast scale-out when boot is slow.
Lifecycle hooks pause instances at launch (to install software) or termination (to copy logs or drain work).
Instance refresh replaces instances to roll out a new launch template version, with a minimum healthy percentage and optional checkpoints.
Instance maintenance policy controls whether replacements launch before or after terminating.
Default instance warm-up stops new instances’ metrics affecting scaling until they’re ready.
Scale-in protection stops specific instances being terminated.
Mixed instances policy: several instance types, On-Demand base plus Spot.
Troubleshooting
Symptom
Check
Instances launch and terminate in a loop
Failing health checks too early: lengthen the grace period, fix the application or the health check path
No launches
Activity history: invalid AMI, missing key pair, insufficient capacity, subnet out of IPs, service quota
Doesn’t scale in
Minimum capacity, scale-in protection, or cooldown
Common traps
Slow boot and unpredictable spikes: a warm pool, not just a lower threshold.
Group never replaces a hung app: add ELB health checks.
A ski resort's booking site runs in an EC2 Auto Scaling group.
Each instance writes application logs to its local disk, and the compliance team needs every log file, including those on instances removed during scale-in. Today, logs from terminated instances are lost.
An upload script already exists and takes about two minutes to copy the logs to Amazon S3.
How should a CloudOps engineer make sure the script finishes before an instance is terminated?
Choose one answer.
AA. Turn on instance scale-in protection for the group so that Auto Scaling does not terminate instances that still hold log files.
BB. Add a lifecycle hook for instance termination, run the upload script when the hook fires, and then complete the lifecycle action.
CC. Raise the group's default cooldown to five minutes so that each instance has time to run the upload script before it is terminated.
DD. Add the upload script to the instances' user data so that it runs whenever the operating system begins to shut down.
Lifecycle hooks are the Auto Scaling feature for running custom actions when an instance launches or terminates. A termination hook holds the instance in a wait state until the action completes or the heartbeat timeout passes. Scale-in protection, cooldowns and user data do not provide a controlled pause before termination.
An esports league's match-replay service runs in an EC2 Auto Scaling group with a target tracking policy.
Each new instance needs about 12 minutes to start, because it loads a large index into memory during its first boot. Sudden demand spikes after big matches are not predictable, and users see errors before new capacity is ready.
The league wants new capacity in service much faster, while keeping the cost of idle capacity LOW.
What should a CloudOps engineer configure?
Choose one answer.
AA. Add a warm pool to the group that keeps pre-initialized instances in the Stopped state.
BB. Add a predictive scaling policy so that the group launches instances ahead of demand based on forecast load.
CC. Raise the group's minimum and desired capacity so that enough running instances are always ready for the largest spike.
DD. Lower the default instance warmup on the target tracking policy so that new instances count toward the metric sooner.
Show the answer and explanation
Answer: A
A. Right: Correct. Warm pool instances complete the slow initialization once and then wait stopped, so the group mostly pays only for their EBS volumes. On scale-out they start and enter service much faster than new launches. Learn more: Warm pools for Amazon EC2 Auto Scaling (opens in a new tab)
When instances have a long initialization and demand is not predictable, a warm pool keeps pre-initialized instances ready next to the group. Stopped warm instances avoid most compute charges and still reach service far faster than a fresh launch. Predictive scaling needs repeating patterns, and keeping extra instances running costs more.
A regional bank's branch application runs in an EC2 Auto Scaling group.
Every weekday at 8:00, when branches open, CPU jumps from 15 percent to 80 percent within minutes, and the group takes 10 minutes to catch up. During the rest of the day, load rises and falls without a pattern.
The team wants capacity ready before the morning surge and steady CPU near 50 percent the rest of the day.
Which TWO scaling policies should a CloudOps engineer configure? (Choose two.)
Choose two answers.
AA. A target tracking policy that keeps the group's average CPU utilization at 50 percent.
BB. A step scaling policy on memory utilization from the AWS/EC2 namespace that adds instances in larger steps.
CC. A predictive scaling policy that learns the weekday pattern and launches capacity ahead of the 8:00 surge.
DD. An instance refresh scheduled for 7:45 every weekday so that new instances are running when the branches open.
EE. A simple scaling policy with a 30-minute cooldown that adds one instance each time CPU passes 70 percent.
Auto Scaling policies can work together. Predictive scaling handles the known weekday spike by launching capacity before it arrives, and target tracking handles everything else by holding CPU near the target. When policies overlap, the group uses the one that gives the larger capacity.
Want more on EC2 Auto Scaling? The 5 full-length practice sets have 10 more EC2 Auto Scaling questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →