A DevOps engineer deployed a CloudFormation template that launches a web app (ALB, target group, launch template using Amazon Linux 2 AMI, Auto Scaling group, security group, and an RDS MySQL DB). The launch template’s user data runs a script to install and start the app. After updating the user data to a new app version and redeploying via the CI/CD pipeline, the ALB health checks fail and all targets show unhealthy. The CloudFormation stack shows UPDATE_COMPLETE, but an EC2 instance log shows Apache failed to start due to a configuration error. How can the engineer make CloudFormation fail the deployment if the user data script does not complete successfully?

The cfn-signal helper script is designed precisely for this scenario. It allows an EC2 instance's user data script to report success or failure back to CloudFormation. By adding the WaitOnResourceSignals update policy to the Auto Scaling group or EC2 instance resource in the CloudFormation template, CloudFormation will wait for a signal from the instance before marking the stack update as complete. If a failure signal is received or the timeout expires without a success signal, the stack update will roll back, preventing unhealthy deployments. Incorrect options: CloudWatch alarms on UnhealthyHostCount detect issues after deployment and cannot directly signal CloudFormation for rollback during the update process. Auto Scaling lifecycle hooks manage instance state transitions but don't inherently integrate with CloudFormation stack status for rollback based on user data script success/failure. Streaming cloud-init logs to CloudWatch and using Lambda to call SignalResource is overly complex and less direct than cfn-signal, which is purpose-built for this integration.