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.

• ✓

  Verify security group rules allow traffic from the ALB, then verify health check settings (path, port, protocol), then check instance status and application health, then review ALB access logs and CloudWatch metrics, then replace the target instance if necessary.

  Why this is correct

  This order is correct because security group misconfigurations are a common cause of health check failures and should be checked first. Next, health check settings must align with the target application. Then, instance and application health are examined. Logs and metrics provide further insight before considering replacement.

• ✗

  Verify health check settings (path, port, protocol), then verify security group rules, then check instance status and application health, then review ALB access logs and CloudWatch metrics, then replace the target instance if necessary.

  Why it's wrong here

  Starting with health check settings is inefficient and can mislead you because a misconfigured security group can block all traffic from the ALB before the path, port, or protocol ever matter. If the ALB's source security group is not allowed on the target's security group, or the ALB is in a different VPC/subnet, health checks will fail regardless of the HTTP path or TCP port defined. Only after confirming that network paths and security group rules permit the health check traffic should you evaluate whether the health check configuration actually matches the target application's expected endpoint.

• ✗

  Check instance status and application health, then verify security group rules, then verify health check settings, then review ALB access logs and CloudWatch metrics, then replace the target instance if necessary.

  Why it's wrong here

  Probing instance and application health first is premature because a target instance can pass its EC2 status checks (e.g., 2/2) while still being marked unhealthy by the ALB due to an incorrect security group or health check rule. Without first verifying that the ALB can reach the instance via allowed security group rules and that the health check path is actually served by the application, you risk launching into debugging a healthy application. This ordering wastes time and can lead you to restart or replace an instance that is genuinely functioning but is isolated or misconfigured at the load balancer layer.

• ✗

  Review ALB access logs and CloudWatch metrics, then verify security group rules, then verify health check settings, then check instance status and application health, then replace the target instance if necessary.

  Why it's wrong here

  Reviewing ALB access logs and CloudWatch metrics before the basic configuration checks is counterproductive because those logs often lack the context needed to pinpoint the root cause. For instance, an access log might show 5xx responses or failed health checks, but you cannot determine whether the failure is due to a security group block (no log entry at all) or an unhealthy application until you've already confirmed the security group and health check settings. Additionally, if the health check is misconfigured (e.g., pointing to the wrong port), the CloudWatch HealthyHostCount metric will remain at zero even for perfectly healthy instances, making the metrics misleading without that prior knowledge.

Go deeper

Related to this question