SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator is troubleshooting a slow-running application on an EC2 instance. CloudWatch metrics show high CPU utilization but low disk I/O. The instance type is t3.medium. Which action would most likely improve performance?

⚠ Common exam trap

The trap here is that candidates may focus on disk or memory improvements because the application is 'slow,' but the CloudWatch metrics clearly point to a CPU bottleneck, and the t3 family's credit-based performance model is a common exam pitfall.

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

✓

Change the instance type to c5.large, which provides dedicated CPU performance.

The t3.medium is a burstable instance that relies on CPU credits. High CPU utilization with low disk I/O indicates the application is CPU-bound and the instance has likely exhausted its CPU credits, causing performance throttling. Changing to a c5.large provides dedicated, consistent CPU performance without credit-based limitations, directly addressing the bottleneck.

Answer analysis

Option-by-option breakdown

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

✓
Change the instance type to c5.large, which provides dedicated CPU performance.
Why this is correct
c5.large instances are compute-optimized with dedicated vCPUs, so they do not rely on CPU credits or burst capacity. When the current burstable instance exhausts its CPU credit balance, it is throttled to the baseline utilization level, causing the application to run slowly. By moving to c5.large, you get consistent, full CPU performance for sustained periods, directly addressing the CPU-bound bottleneck.
✗
Increase the instance memory by changing to r5.large.
Why it's wrong here
r5.large is a memory-optimized instance that provides 16 GiB of RAM, significantly more than the current instance, but it does not alleviate CPU saturation. The symptom is high CPU utilization or a low CPU credit balance, not memory pressure, so adding RAM leaves the actual bottleneck untouched. Moreover, r5.large has the same vCPU count as many current generation instances, so it would not meaningfully increase compute throughput for a CPU-bound workload.
✗
Enable EBS-optimized on the instance and use provisioned IOPS SSD volumes.
Why it's wrong here
Enabling EBS optimization and switching to provisioned IOPS (io1/io2) volumes boosts storage throughput and reduces EBS wait times, but this has no effect on how many CPU cycles the application receives. A CPU-bound process will remain starved for compute even with extremely fast storage. EBS optimization adds dedicated network connectivity to EBS, and PIOPS guarantees I/O performance, but neither increases vCPU capacity or resolves a negative CPU credit balance.
✗
Increase the size of the EBS volume to improve disk throughput.
Why it's wrong here
Increasing the EBS volume size raises the baseline I/O limits for gp2 volumes, but disk I/O has not been identified as the limiting factor in this scenario. The application's slowness is driven by CPU exhaustion or throttling, so adding storage throughput will not reduce CPU utilization or allow more instructions per second. In fact, resizing the volume would incur additional costs and administrative overhead while providing zero benefit to a CPU-bound workload.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question