Een DevOps-engineer heeft een CloudFormation-template geïmplementeerd die een web-app lanceert (ALB, target group, launch template met Amazon Linux 2 AMI, Auto Scaling group, security group en een RDS MySQL DB). De user data van de launch template voert een script uit om de app te installeren en te starten. Na het bijwerken van de user data naar een nieuwe app-versie en het opnieuw implementeren via de CI/CD-pipeline, mislukken de ALB health checks en tonen alle targets 'unhealthy'. De CloudFormation-stack toont UPDATE_COMPLETE, maar een EC2-instantielog toont dat Apache niet kon starten vanwege een configuratiefout. Hoe kan de engineer CloudFormation de implementatie laten mislukken als het user data-script niet succesvol wordt voltoemd?

De correcte optie is het gebruik van de cfn-signal helper met het WaitOnResourceSignals updatebeleid. Dit stelt CloudFormation in staat om te wachten op een signaal van de EC2-instantie, wat aangeeft of de user data succesvol is uitgevoerd. Als het script mislukt of de timeout verstrijkt zonder signaal, zal CloudFormation de update als mislukt markeren. De andere opties zijn minder geschikt: Een CloudWatch-alarm op UnhealthyHostCount detecteert het probleem pas nadat de instanties al zijn gestart en de health checks falen, wat niet voorkomt dat CloudFormation de update als succesvol beschouwt. Een Auto Scaling lifecycle hook kan worden gebruikt om acties uit te voeren tijdens de levenscyclus van een instantie, maar het is niet de primaire methode om CloudFormation direct te informeren over het succes of falen van user data-scripts. Cloud-init logs streamen naar CloudWatch en een Lambda-functie gebruiken is een complexere oplossing die meer