SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator is troubleshooting an issue where an EC2 instance running a web server is becoming unresponsive under high load. The administrator has enabled detailed monitoring and set up CPUUtilization alarms. Which THREE additional steps could help diagnose the root cause? (Choose THREE.)

⚠ Common exam trap

Test-takers frequently confuse reactive scaling actions (like resizing the instance or adding Auto Scaling) with diagnostic steps, failing to recognize that the question asks for steps to diagnose the root cause, not to mitigate the symptom.

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

✓

Install the CloudWatch agent and collect disk space metrics.

Under high load, the web server could become unresponsive due to disk space exhaustion (e.g., from log files filling the root partition). The CloudWatch agent can collect disk space metrics, which are not available by default, allowing the administrator to correlate disk usage with performance degradation.

Answer analysis

Option-by-option breakdown

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

✓
Install the CloudWatch agent and collect disk space metrics.
Why this is correct
The CloudWatch agent is required to collect OS-level disk space metrics because default EC2 monitoring only provides hypervisor-level metrics such as CPU and network I/O. A full disk can cause application failures, failed log writes, or prevent service startup. Collecting this metric lets you correlate disk exhaustion with incident timing and configure alarms for early warning.
✗
Place the instance behind an Auto Scaling group.
Why it's wrong here
Placement in an Auto Scaling group is a capacity-scaling strategy, not a diagnostic procedure. It addresses the symptom of high load by adding instances, but the original instance still fails identically and you gain no insight into whether the failure was due to disk, memory, or a traffic pattern. Troubleshooting requires first obtaining observational data before changing architecture.
✓
Install the CloudWatch agent and collect memory metrics.
Why this is correct
Memory pressure causes the operating system to swap to disk, leading to severe performance degradation and unresponsive processes. Like disk space, memory metrics are not published by default in CloudWatch; the CloudWatch agent must be installed to capture them directly from the OS. These metrics are essential for confirming whether memory exhaustion coincided with the failure window.
✗
Increase the instance size to handle more load.
Why it's wrong here
Increasing the instance size is a reactive remediation that assumes the root cause is insufficient compute capacity. Without telemetry, you do not know if the problem is disk space, a memory leak, or a request flood, so you might pay for a larger instance while the actual fault continues. It is not a diagnostic action and can mask the real issue, leading to recurring outages.
✓
Enable access logs on the load balancer to analyze request patterns.
Why this is correct
Enabling load balancer access logs generates a detailed chronological record of each request, including client IPs, URL paths, and request processing times. Analyzing these logs can reveal anomalies such as a surge of requests to a single endpoint or a distributed traffic attack, which directly informs the root cause of instance overload. This is a non-intrusive observational step for troubleshooting.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question