SOA-C02 Cost and Performance Optimization Practice Question
A SysOps administrator manages a fleet of 50 EC2 instances running a batch processing application. The instances are launched via an Auto Scaling group with a dynamic scaling policy based on CPU utilization. The company recently switched to a new workload that is memory-intensive, causing frequent scale-out events. The administrator notices that the CPU utilization remains below 40%, but memory usage is consistently above 80%. The scaling policy does not trigger appropriately, leading to performance degradation. The administrator must optimize the solution to respond to memory pressure without incurring unnecessary costs. Which action 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
✓
Create a custom CloudWatch metric for memory utilization and configure a target tracking scaling policy using that metric.
It directly addresses the memory bottleneck by creating a custom CloudWatch metric for memory utilization and using a target tracking scaling policy. This allows the Auto Scaling group to automatically adjust capacity based on actual memory pressure, which is the real performance issue. Option B (manual scaling) is not automated and may lead to over-provisioning or under-provisioning. Option C (step scaling with CPU) does not solve the memory problem, and a wider cooldown would only delay scaling. Option D (changing instance type) is a reactive measure that does not provide dynamic scaling and may increase costs without eliminating the need for scaling policies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a custom CloudWatch metric for memory utilization and configure a target tracking scaling policy using that metric.
Why this is correct
EC2 publishes only infrastructure metrics such as CPU, network, and disk I/O by default; memory utilization is invisible unless the CloudWatch agent publishes a custom metric. By creating a custom metric like mem_used_percent and attaching a target tracking scaling policy, the Auto Scaling group continuously adjusts capacity to keep average memory utilization at a specified target (e.g., 70%). This correlates scaling decisions with the actual memory-bound workload, preventing both wasted running instances and performance degradation from memory exhaustion.
- ✗
Increase the minimum size of the Auto Scaling group to 10 instances and use manual scaling for peak times.
Why it's wrong here
A fixed minimum size of 10 forces 10 instances to run 24/7 regardless of actual demand, so during quiet periods you pay for idle capacity and during sudden spikes those 10 may still be insufficient. Manual scaling relies on an administrator to preemptively change capacity for peak times, which is brittle and error-prone; if demand shifts unexpectedly, the group cannot react. This solution neither automates the decision nor targets memory utilization as the signal, leaving the original under-provisioning risk unresolved.
- ✗
Change the dynamic scaling policy to a step scaling policy based on CPU utilization with a wider cooldown period.
Why it's wrong here
Step scaling policies operate on an alarm threshold, but changing the metric to CPU utilization still ignores the actual bottleneck, which is memory; high memory pressure may occur with low CPU, so the policy would never trigger the needed scale-out. Widening the cooldown period also makes the group less responsive: after a scaling activity, the group is locked for a longer interval, meaning a sudden memory spike during the cooldown will not add instances in time. Therefore, this change addresses neither the metric choice nor the timeliness of scaling.
- ✗
Replace the current instance type with a memory-optimized instance type such as r5.large.
Why it's wrong here
Switching to a memory-optimized instance type like r5.large can temporarily relieve memory pressure, but it does not change the group's capacity behavior; the Auto Scaling group still relies on the existing CPU-based policies, which are insensitive to memory usage. When demand grows, even r5.large instances will exhaust memory, and without a metric-driven expansion policy the group will not add instances. Additionally, deploying r5.large across all 50 instances increases baseline cost without ensuring elastic response to load, so it treats a symptom rather than the underlying scaling deficiency.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.