SOA-C02 Monitoring, Logging, and Remediation Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Network connectivity issues

  Why it's wrong here

  Network connectivity issues are classified as system status check failures because they typically originate from AWS-side infrastructure, such as loss of power, network link outages, or routing problems. Instance status checks, on the other hand, monitor the health of the guest OS and applications, so a problem that is purely external to the instance would not trigger a failed instance status check. Therefore, while network issues may make the instance unreachable, they would be indicated by a system status check, not the instance status check the administrator is troubleshooting.

• ✗

  Detached EBS root volume

  Why it's wrong here

  A detached EBS root volume would prevent the instance from booting or accessing the operating system entirely, but this scenario is detected by AWS as a system status check failure because the problem lies in the underlying storage attachment infrastructure. The instance status check cannot even begin to run if the root volume is not available, as the OS never loads enough to respond to health checks. Thus, a detached root volume is not a valid cause of an instance status check failure, which requires the OS to be running but unhealthy internally.

• ✓

  Misconfigured firewall or iptables

  Why this is correct

  A misconfigured firewall or iptables ruleset can block all inbound and outbound traffic, effectively making the instance unreachable despite the OS running normally. The instance status check performs a network reachability test at the OS level, and if the packet filtering rules prevent the response, the check fails, indicating an instance-level problem. Since the issue stems from guest OS configuration rather than AWS infrastructure, it is correctly identified as an instance status check failure.

• ✗

  Insufficient memory for applications

  Why it's wrong here

  Insufficient memory for applications can cause performance degradation, swapping, or application crashes, but the Linux or Windows kernel typically remains responsive enough to answer the health probes used by instance status checks. These checks depend on basic OS functionality, such as the network stack and process scheduler, which do not necessarily require sufficient memory for user applications. Therefore, while low memory is a serious problem, it would not directly cause an instance status check failure unless it leads to a kernel panic, which is not the typical outcome.

• ✓

  Corrupted file system

  Why this is correct

  A corrupted file system, particularly on the root volume, can prevent the OS from mounting the disk, cause kernel panics, or result in the entire system becoming unresponsive and unable to process any requests. Since the corruption is within the guest OS environment and does not require AWS-side intervention, it is reported as a failed instance status check. The instance status check detects this because the OS fails to respond to the network-level reachability probe, confirming that a corrupted file system is a valid cause of an instance status check failure.