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.

• ✗

  The security group inbound rule for HTTPS is misconfigured.

  Why it's wrong here

  The security group already has an inbound rule permitting HTTPS (port 443) from the required sources, so a misconfigured inbound rule cannot explain the failure. If the rule were missing or too restrictive, the TCP handshake would time out before reaching the instance, affecting all traffic, including SSH. The scenario indicates SSH works, and a security group is stateless only if it is a network ACL; a security group issue would not selectively block port 443 while leaving port 22 open unless the rules explicitly allow that. Given the rules are correctly configured, the root cause must be at the guest OS or application layer.

• ✗

  The instance has an incorrect route table entry.

  Why it's wrong here

  A route table entry applies to all traffic leaving the subnet, not to specific destination ports. Since SSH connectivity to the instance succeeds, the instance must have a valid route back to the client's network, and any route table misconfiguration would disrupt all IP connectivity, not just HTTPS. The fact that port 443 fails while port 22 succeeds points to a service-level issue on the instance rather than a network-layer routing problem. Therefore, an incorrect route table entry is not a plausible cause for this port-specific failure.

• ✓

  The web server service is not running or crashed.

  Why this is correct

  The web server service is likely not running or has crashed after boot, which would leave port 443 closed while SSH (port 22) remains active because no guest OS process is listening on the HTTPS port. EC2 status checks only detect hardware, hypervisor, and network reachability issues; they do not monitor application processes or service states inside the instance. With CPU utilization at 5% and correct security group rules, the most consistent explanation is that the web server process (e.g., httpd, nginx, or IIS) is not started. Check the service status and application logs, then restart the service to restore connectivity.

• ✗

  The instance has insufficient CPU credits.

  Why it's wrong here

  Insufficient CPU credits would cause the instance to be throttled to the baseline CPU performance, but the scenario explicitly states CPU utilization is 5%, which indicates the instance is not resource-constrained. If credit exhaustion were the issue, you would typically observe high CPU utilization near the baseline, overall poor performance, or a CloudWatch alarm for CPU credit balance, not a complete failure of a single port. Moreover, CPU throttling affects all processes on the instance, so SSH sessions would also be sluggish or fail. Therefore, the lack of HTTPS connectivity is unrelated to CPU credit availability.

Go deeper

Related to this question