SOA-C02 Cost and Performance Optimization Practice Question

A company runs a critical web application on EC2 instances behind an ALB. The application experiences unpredictable traffic spikes. The SysOps administrator wants to ensure that the application can handle spikes without performance degradation while minimizing costs. Which TWO actions should the administrator take?

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

✓

Use a mix of On-Demand and Spot Instances in the Auto Scaling group.

Spot Instances can reduce costs if the application can handle interruptions. Option D is correct because target tracking scaling adjusts capacity based on load. Option B is wrong because DynamoDB auto scaling is not relevant for EC2. Option C is wrong because scheduled scaling cannot handle unpredictable spikes. Option E is wrong because increasing instance size may not be as cost-effective as scaling out.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Use a mix of On-Demand and Spot Instances in the Auto Scaling group.
Why this is correct
A mixed instances policy in an Auto Scaling group lets you define an On-Demand base capacity plus Spot percentage for the remaining instances. This maintains baseline availability through On-Demand instances while using lower-cost Spot capacity to absorb unpredictable traffic spikes. Spot interruptions can occur, but the ASG automatically replenishes capacity, and you can configure instance rebalancing and termination handling.
✗
Use Amazon DynamoDB auto scaling to handle the spikes.
Why it's wrong here
Amazon DynamoDB auto scaling adjusts the provisioned read/write capacity of a DynamoDB table based on actual traffic, not the compute capacity of EC2 instances. It does not launch, register, or terminate EC2 instances, nor does it affect the web application's compute fleet. Attempting to use it for EC2 spike handling is a service mismatch and provides no scaling for web servers.
✗
Use scheduled scaling to add instances during expected peak hours.
Why it's wrong here
Scheduled scaling relies on predictable time-based patterns, such as adding capacity before a known marketing event or a daily business-hours cycle. The question states the spikes are unpredictable, so advance time schedules would either over-provision during low demand or fail to scale when the spike unexpectedly arrives. Dynamic policies, not time-based rules, are the correct response to non-periodic load bursts.
✓
Use a target tracking scaling policy based on CPU utilization.
Why this is correct
A target tracking scaling policy selects a CloudWatch metric (e.g., EC2 CPUUtilization) and automatically adds or removes instances in the ASG to keep the metric near the target value. It is proactive in responding to actual load rather than predicted load, which handles unpredictable spikes. It also manages cooldowns and instance warm-up to avoid flapping, making it a fully dynamic and dependable scaling solution.
✗
Use larger EC2 instance types to handle spikes.
Why it's wrong here
Switching to larger EC2 instance types is a form of vertical scaling that has a hard upper limit (the largest available instance size) and becomes expensive if the instances are underutilized during normal load. It also requires a launch template change and a rolling replacement, which can cause downtime if not done carefully. Horizontal scaling via an ASG is more elastic, cost-efficient, and fault-tolerant for unpredictable spikes.

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question