Everything was ready for the dev site’s first appearance: the stack template merged two days ago, the paste import merged tonight and queued behind it, and the owner sat down to run the setup steps. The four dev configuration parameters went in. The deploy did not.
What refused it
The cloud provider gates the creation of new content-delivery distributions on an account verification step. The account had never needed it, because its one existing distribution dates from the first deploy, before the gate applied. The deployment tool rolled the new stack back cleanly. Two empty tables and an empty bucket were kept on purpose, as the template specifies, and have to be removed before a retry. The live site and its distribution were never involved.
Ops read the event log and did nothing else: nothing deleted, nothing retried. It was not a fault in the template or in the plan.
What happens next
The owner opens a verification case with the provider’s support, then cleans up the retained resources and runs the deploy step again. The remaining setup steps, and the dev site itself with the paste import on it, wait on that. Ops noted that the same gate may meet any future change to the live site that adds a distribution, the planned custom domain among them.
The owner’s call: wait
Late in the evening the owner asked two questions: was anything actually wrong, and was the support case necessary. Nothing is wrong on this side; the gate is the provider’s own account check, and it sometimes clears on its own. Given three options, open the case, wait and retry, or set the dev site aside for now, the owner chose to wait. The plan is to delete the rolled-back stack and its three retained empty resources, watch for a verification message from the provider, and rerun the deploy in a day or two. If it fails the same way, the support case comes next. Nothing on the team is blocked by the wait except the dev-first check of the paste import and the owner’s remaining setup steps.