SOA-C02 Reliability and Business Continuity Practice Question

A company runs a stateless web application on EC2 instances in an Auto Scaling group across multiple Availability Zones. The application experiences increased latency during peak hours. The SysOps administrator needs to improve the application's performance and reliability. Which action should be taken?

⚠ Common exam trap

It's easy for candidates to confuse scaling metrics or instance sizing with the fundamental need to increase the maximum capacity limit when the group is already hitting its cap during peak load.

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

✓

Increase the maximum instance count in the Auto Scaling group.

Increasing the maximum instance count allows the Auto Scaling group to launch more EC2 instances during peak hours, distributing the load across more resources and reducing latency. This directly improves both performance (by handling more requests) and reliability (by maintaining capacity under increased demand).

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 larger EC2 instance types instead of smaller ones.
Why it's wrong here
Scaling vertically by choosing larger EC2 instance types is constrained by the maximum size available for each instance family and creates a single point of failure. A stateless web application is designed to distribute load across multiple instances, so adding more instances (horizontal scaling) is more elastic and can respond to traffic spikes beyond the limits of any single instance. Larger instances also lead to linearly increasing costs per unit of capacity and do not improve fault tolerance.
✗
Reduce the Auto Scaling group's cooldown period to scale out faster.
Why it's wrong here
Reducing the Auto Scaling group's cooldown period allows new instances to come into service faster, but it also shortens the time the group waits to evaluate metric stabilization. This can cause scaling thrashing, where the group launches and then immediately terminates instances in response to short-lived fluctuations, wasting resources and increasing costs. The ultimate constraint remains the maximum instance count, so a shorter cooldown does not enable the group to scale beyond its configured upper limit.
✗
Change the scaling metric from CPU utilization to memory utilization.
Why it's wrong here
Switching the scaling metric to memory utilization is problematic because EC2 memory usage is not emitted as a standard CloudWatch metric without installing a custom CloudWatch agent. Additionally, memory utilization may not reflect the actual web application load since requests can be served from cache and memory usage often stays flat until the instance is nearly saturated. For a stateless web app, better scaling metrics are CPU utilization, request count per target, or network throughput, which correlate more directly with traffic and the need to scale out.
✓
Increase the maximum instance count in the Auto Scaling group.
Why this is correct
Increasing the maximum instance count in the Auto Scaling group directly expands the group's capacity ceiling, allowing it to launch additional EC2 instances when demand spikes. This is the appropriate solution for a stateless web application because horizontal scaling distributes traffic across multiple instances and provides both elastic capacity and fault tolerance. With a properly configured scaling policy, the group can now add instances beyond its previous limit, accommodating higher traffic volumes without modifying the application.

Go deeper

SOA-C02 Reliability and Business Continuity Practice Question

Why each option matters

Option-by-option breakdown

Related to this question