A new CloudFormation stack fails because an S3 bucket name is already taken. The previous stack was deleted with DeletionPolicy Retain, so the bucket is still in the account. Retrying the same template fails the same way. What should they do?
Select an answer to reveal the explanation.
Short Explanation
The name is taken by a bucket you kept on purpose when the old stack went away. You either adopt that bucket into the new stack or pick a new name. Hammering create again will keep hearing that the name exists.
Full Explanation
S3 bucket names are global for the partition, and a retained bucket still owns the name after its stack is gone. CloudFormation's create then fails with the resource already existing. Importing the bucket brings it under the new stack without a second copy. A different name also works if the old bucket should stay independent. Retrying cannot succeed while the name is taken. Block Public Access does not participate in name allocation. Deleting a VPC does not delete a retained bucket. Caveat: import requires the live bucket to match the template properties you declare, or the import is rejected. Operational check: after import or a rename, the stack create should pass the bucket resource, and the retained data should still be in the bucket you intended to keep. Import is a stack operation: the template describes the bucket, and you identify the existing bucket name as the resource to adopt. The retained objects stay. A new name is simpler when the old bucket must remain outside the stack, and the application then has to be pointed at the new name. Either choice ends the retry loop. Confirm the old stack really is gone so you are not fighting a stack that still owns the bucket.