A CloudFormation stack for a studio fails with CREATE_FAILED. The first failed event is an IAM role, and the status reason says the deploying user is not authorized to perform iam:CreateRole. What should be fixed?
Select an answer to reveal the explanation.
Short Explanation
The stack event is telling you the deployer is not allowed to create the role. You grant iam:CreateRole and run the stack again. A bigger instance does not answer an authorization error, and neither does rebuilding the VPC.
Full Explanation
CloudFormation reports the resource and the status reason on the failed event. This reason is an IAM authorization failure for iam:CreateRole, so the deploying principal's policies, or an explicit deny above them, must change before a retry can create that role. A larger instance type does not grant iam:CreateRole. Deleting the VPC is unrelated to the failed role and risks everything else in that network. Data events do not add IAM permissions, so updating the stack with only that change fails the same way. Caveat: if a permission boundary or an SCP is the deny, adding an identity allow is not enough; the event's encoded message is what you match to the policy. Operational check: after the permission is in place, the role event should leave CREATE_FAILED and the stack should continue past it. The events list is in chronological order and the first CREATE_FAILED is the one that stopped progress; later failures are often consequences. iam:CreateRole may be missing from the deployer, or an SCP may deny IAM changes in the account. Match the error text to that policy, grant the smallest action that creates this role, and update the stack rather than deleting it.