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.

• ✗

  Create an AWS Config rule to detect failed status checks and trigger a remediation action.

  Why it's wrong here

  AWS Config rules evaluate resource compliance against desired configurations, not real-time instance health; they lack the ability to detect transient EC2 status check failures and trigger immediate instance replacement within an Auto Scaling group. This option is tempting because AWS Config can remediate non-compliant resources via automation, and in scenarios requiring enforcement of configuration baselines—such as ensuring instances have specific security groups or AMI IDs—it would be the correct choice. However, the stem demands automatic replacement based on live status checks, which is natively handled by Auto Scaling group health checks, not Config's compliance framework.

• ✗

  Create an AWS Lambda function that stops and starts the failed instance.

  Why it's wrong here

  Stopping and starting the failed instance via an AWS Lambda function is an out-of-band, procedural workaround rather than a managed recovery mechanism. It does not integrate with an Auto Scaling group's desired capacity or lifecycle hooks, so if the instance is part of an ASG, manually stopping it could conflict with the group's health check evaluations and capacity tracking. Furthermore, a stop/start operation does not guarantee that the underlying host or network impairment causing the status check failure will be resolved, and it requires custom logic to detect and respond to each failure—unlike Auto Scaling, which natively performs health checks and automatically replaces unhealthy instances.

• ✓

  Configure the Auto Scaling group to use EC2 status checks for health checks.

  Why this is correct

  Configuring the Auto Scaling group to use EC2 status checks for health checks is the correct native mechanism because Auto Scaling continuously monitors the StatusCheckFailed metrics (system status and instance status) for each instance in the group. When a status check fails, the ASG marks the instance as unhealthy, terminates it, and launches a replacement instance to maintain the desired capacity—all without custom code or manual intervention. This approach leverages Amazon's built-in health check integration and is the intended method for automatically replacing instances that have failed EC2 status checks, ensuring the web application remains available.

• ✗

  Create a CloudWatch alarm on the StatusCheckFailed metric and trigger an SNS notification.

  Why it's wrong here

  Creating a CloudWatch alarm on the StatusCheckFailed metric and triggering an SNS notification only alerts human operators or downstream systems about a failure; it does not perform any automatic remediation by itself. This option lacks the execution of a recovery action such as terminating or replacing the instance, so the failed instance would remain in service and continue failing health checks until someone manually responds to the notification. Moreover, CloudWatch alarms evaluate metrics over specified periods and are not designed to directly replace instances; that responsibility belongs to the Auto Scaling group's native health check mechanism, which also handles the replacement in a controlled and scalable manner.

Go deeper

Related to this question