Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5
SOA-C02 Deployment, Provisioning, and Automation Practice Question
Drag and drop the steps to troubleshoot high CPU usage on an Amazon EC2 instance into the correct order.
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
✓
Check CloudWatch metrics, then Connect to instance, then Identify high CPU process, then Analyze process behavior, then Take corrective action
The correct order for troubleshooting high CPU usage on an EC2 instance starts with checking CloudWatch metrics to confirm the issue and gain initial insights. Next, connect to the instance using SSH or Systems Manager to access the operating system. Then, identify the process causing high CPU using tools like top or ps. After identification, analyze the process to understand its behavior, such as checking logs or memory usage. Finally, take corrective action, which may include stopping, killing, or optimizing the process, or scaling the instance up. This sequence ensures efficient and accurate troubleshooting.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Check CloudWatch metrics, then Connect to instance, then Identify high CPU process, then Analyze process behavior, then Take corrective action
Why this is correct
This is the correct order because you first verify CPU usage metrics to confirm the issue, then connect to the instance, identify the offending process, analyze its behavior to determine the root cause, and finally take appropriate action.
- ✗
Connect to instance, then Check CloudWatch metrics, then Identify high CPU process, then Analyze process behavior, then Take corrective action
Why it's wrong here
Connecting to the instance before checking CloudWatch metrics inverts the troubleshooting sequence because the EC2 CPUUtilization metric first confirms whether the complaint is CPU-related and reveals the pattern (e.g., sustained saturation vs. a brief spike) that guides your investigation. Connecting preemptively wastes time if the actual bottleneck is memory, disk I/O, or network, and you lose the context needed to correlate system behavior with instance-level performance. Only after verifying the metric should you connect to inspect running processes.
- ✗
Check CloudWatch metrics, then Identify high CPU process, then Connect to instance, then Analyze process behavior, then Take corrective action
Why it's wrong here
This order is impossible to execute correctly because CloudWatch does not expose process-level CPU usage; EC2 metrics like CPUUtilization aggregate the entire instance, so you cannot identify a specific high-CPU process without actually connecting to the instance and running commands such as top, ps aux --sort=-%cpu, or pidstat. Attempting to "identify high CPU process" before establishing a session has no technical basis, since the identification is necessarily the result of an in-instance observation. The correct sequence is to use CloudWatch to confirm the problem, connect, and then identify the process.
- ✗
Check CloudWatch metrics, then Connect to instance, then Analyze process behavior, then Identify high CPU process, then Take corrective action
Why it's wrong here
Analyzing process behavior before identifying the specific process is functionally backwards because analysis tools like strace, lsof, or checking per-process /proc statistics require a known PID or process name as the target; without first using top, ps, or pidstat to pin down which process is consuming CPU, you have no subject for behavioral analysis. Also, jumping into analysis before identification risks drawing conclusions from unrelated system activity. The logical dependency demands identification first, then behavior analysis, and only then corrective action.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 247 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.