The correct choice is Configure an Amazon CloudWatch alarm on the StatusCheckFailed_System metric to trigger the EC2 recover action. This approach detects host level failures and initiates the EC2 recover action so the instance is moved to healthy hardware with minimal disruption.

The reason Configure an Amazon CloudWatch alarm on the StatusCheckFailed_System metric to trigger the EC2 recover action is correct is that the EC2 recover action targets system level problems such as host power loss or network failure and preserves the instance identity and attached EBS volumes. The preserved attributes allow the instance to come back on new hardware quickly and avoid significant data loss while only in memory state is lost.

Create an Amazon EC2 Auto Scaling group with minimum, maximum, and desired capacity set to 1 is not ideal because an Auto Scaling group will replace the instance rather than recover it in place and additional configuration is needed to reattach storage and preserve the original instance identity which increases downtime.

Create an Amazon CloudWatch alarm on the StatusCheckFailed_Instance metric to initiate the EC2 reboot action is incorrect because the instance status check covers guest operating system issues and a reboot does not fix host level failures such as underlying hardware power loss or network connectivity problems.

Use AWS Backup to take EBS snapshots every 15 minutes is helpful for reducing data loss but it does not provide automated instance recovery or a low recovery time objective since restoring from snapshots is a slower and more manual process.

Full AWS Practitioner Certification Question