A university CloudFormation stack launches instances in a private subnet, then waits until the helper signals success. The instances boot and the application listens, but the signal never arrives and the subnet has no path to CloudFormation. What should be added?
Select an answer to reveal the explanation.
Short Explanation
The application is at the door, but the note saying so never leaves the building. You are waiting on cfn-signal, and that call cannot reach CloudFormation from a private subnet with no path to the service. A bigger instance does not create a path, and deleting the wait would hide a boot that failed tomorrow.
Full Explanation
A CreationPolicy holds the resource in CREATE_IN_PROGRESS until cfn-signal reports success or the timeout expires. The helper runs on the instance and calls the CloudFormation service endpoint. A private subnet with neither a route to a NAT gateway nor an interface VPC endpoint for CloudFormation cannot complete that call, so the stack waits even though the application is listening. Instance size does not create a route or an endpoint. Removing the CreationPolicy makes the stack proceed without proof that the instance finished bootstrapping, which defeats the signal. An SSH allow lets a person onto the box. It does not give the helper a path to the endpoint, and it leaves a management port as the deployment mechanism. Caveat: the endpoint's security group must allow the instances to reach it, and a NAT path also has to allow the HTTPS call out. Operational check: from a new instance, confirm the signal endpoint resolves and connects, then watch the stack event move off the wait after one successful signal.