A SysOps Administrator is using the AWS CLI to troubleshoot a CloudFormation stack that is stuck in the UPDATE_ROLLBACK_FAILED state. The rollback failed because the original custom IAM service role associated with the stack was deleted. The administrator has created a new IAM role with the correct permissions to manage the stack's resources. However, when the administrator executes `aws cloudformation continue-update-rollback --stack-name my-stack --role-arn arn:aws:iam::123456789012:role/NewCFNServiceRole`, the command fails with an AccessDenied error stating that the administrator's IAM user is not authorized to perform the action on the resource. Which of the following describes the root cause of this error, and how should it be resolved?
- AThe trust policy of the new IAM role does not allow the administrator's IAM user to assume the role. To resolve this, add the administrator's IAM user ARN to the sts:AssumeRole action in the trust relationship of the new role.
- BThe rollback failed due to a target capacity mismatch in the underlying resources. To resolve this, the administrator must change the deployment strategy to an in-place rollback by adding the --use-in-place flag to the command.
- The administrator's IAM user policy is missing the iam:PassRole permission for the new role's ARN. To resolve this, add a policy to the administrator's IAM user that grants iam:PassRole for the new role.Answer
- DCloudFormation does not support changing the service role of a stack during a rollback operation. To resolve this, the administrator must recreate the deleted IAM role using the exact same name and ARN as the original service role.