Courseiva

SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps admin notices that an EC2 instance's status check fails intermittently. The instance is part of an Auto Scaling group. What is the most appropriate first step to diagnose the issue?

⚠ Common exam trap

The trap here is that candidates often jump to terminating or rebooting the instance immediately, but the SOA-C02 exam emphasizes a methodical troubleshooting approach where reviewing status check history is the first step to differentiate between recoverable and irrecoverable failures.

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

✓

Review the instance's status check history in the EC2 console

The most appropriate first step is to review the instance's status check history in the EC2 console (Option D). This allows the SysOps admin to determine whether the failures are due to system status checks (e.g., underlying hardware issues) or instance status checks (e.g., OS-level problems). Since the instance is part of an Auto Scaling group, understanding the root cause is critical before taking any corrective action, as premature termination or reboot could mask the issue or lead to unnecessary replacements.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Stop and start the instance

    Why it's wrong here

    Stop and start the instance forces a migration to a new underlying physical host, which is the standard remedy for a failed System Status Check caused by AWS-side hardware or network issues. However, doing this before reviewing the status check history can cause unnecessary downtime and may change the public IP address unless you have an Elastic IP. It will not resolve an Instance Status Check failure where the guest OS is corrupted or the instance fails to boot, making it a premature action rather than a diagnostic step.

  • ✗

    Terminate the instance and let Auto Scaling replace it

    Why it's wrong here

    Terminating the instance and relying on Auto Scaling to replace it destroys all current diagnostics, including the status check history, instance store data, and any unsaved logs that could pinpoint the exact failure. This 'kill and recreate' approach risks respawning the same issue if the root cause lives in the AMI, user-data scripts, or startup parameters, leading to repeated availability gaps. Termination should be a last resort, never a first step, because it forfeits the opportunity to observe whether the failure is hardware-level or guest-level.

  • ✗

    Reboot the instance

    Why it's wrong here

    Rebooting the instance is only a temporary measure: it restarts the guest OS and may clear a transient instance-level problem like a temporary network obstruction or a hung process, but it does not affect the status of the underlying host hardware. If the System Status Check is failing, the instance will likely continue to fail after a reboot because the physical host is still impaired, and the reboot itself may hang if the OS is not responsive. Crucially, a reboot without consulting the status check history provides no information about the root cause, so you may be blind to a chronic failure.

  • ✓

    Review the instance's status check history in the EC2 console

    Why this is correct

    Reviewing the instance's status check history in the EC2 console is the correct first step because it tells you the exact type and persistence of the failure. The 'Status Checks' tab displays both System Status Checks and Instance Status Checks over time, allowing you to distinguish between an AWS infrastructure defect (hardware/network power loss) and a guest OS issue (corrupt file system, boot failure, or network misconfiguration). This pattern of history—whether the check is stuck, intermittent, or just recent—directly determines whether you should stop/start, reboot, or inspect the system log, making it the foundational diagnostic action.

About these practice questions

This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.