Question

Difficulty: HardTroubleshooting CloudFormation and CI/CD Deployments

A developer manages a CI/CD pipeline in AWS CodePipeline. The pipeline has an AWS CodeBuild project that packages an application and an AWS CloudFormation deploy stage that performs a stack update. During a execution, the pipeline fails with two errors:

1. The CodeBuild project fails during the pre-build phase with the error: 'An error occurred (AccessDenied) when calling the AssumeRole operation: Role: arn:aws:iam::111122223333:role/CrossAccountDeployRole is not authorized to perform: sts:AssumeRole'.
2. The CloudFormation deployment fails immediately because the target stack is stuck in the UPDATE_ROLLBACK_FAILED state due to a resource that failed to clean up during a previous rollback.

Which of the following actions should the developer take to resolve these deployment pipeline failures? (Select TWO.)

  1. Update the trust policy of the CrossAccountDeployRole in account 111122223333 to allow the CodeBuild service role in the source account to perform the sts:AssumeRole action.Answer
  2. Run the continue-update-rollback command on the CloudFormation stack, optionally specifying the failing resource to be skipped, to return the stack to a stable UPDATE_ROLLBACK_COMPLETE state.Answer
  3. C
    Attach an identity-based permission policy to the CodeBuild service role that grants sts:AssumeRole on the CrossAccountDeployRole, without modifying the destination role's trust policy.
  4. D
    Perform a stack update directly on the CloudFormation stack using a modified template that excludes the failing resource to override the UPDATE_ROLLBACK_FAILED state.
  5. E
    Update the permissions policy of the CrossAccountDeployRole to allow the sts:AssumeRole action on the CodeBuild service role ARN.

Answer

To resolve the failures, the developer must update the trust policy of the CrossAccountDeployRole to trust the CodeBuild service role, and run the continue-update-rollback command on the CloudFormation stack to bring it back to a stable UPDATE_ROLLBACK_COMPLETE state.
The correct options are to update the trust policy of the CrossAccountDeployRole to trust the CodeBuild service role, and to run the continue-update-rollback command to return the locked CloudFormation stack to the stable UPDATE_ROLLBACK_COMPLETE state. Updating the trust policy is required because cross-account access relies on the trusting resource granting permission to the external identity. Running the continue-update-rollback command is the only valid way to transition a stack out of the UPDATE_ROLLBACK_FAILED state so it can accept updates again.

Step-by-Step Solution

1
Diagnose the cross-account AccessDenied error during role assumption.
Identify that the CodeBuild service role is attempting to assume CrossAccountDeployRole but lacks authorization.
For cross-account role assumption, the target role must have a trust policy (trust relationship) that explicitly trusts the principal of the calling role.
2
Update the trust policy of the target role (CrossAccountDeployRole).
The target role now allows sts:AssumeRole calls from the CodeBuild service role principal.
This establishes trust between the two AWS accounts, allowing CodeBuild to successfully assume the role to perform cross-account actions.
3
Diagnose the CloudFormation deployment block in the UPDATE_ROLLBACK_FAILED state.
Recognize that the stack is locked in a failed rollback state and cannot accept update commands.
When a resource fails to clean up during a rollback, CloudFormation stops the rollback and sets the stack state to UPDATE_ROLLBACK_FAILED. The stack remains locked until the rollback is addressed.
4
Execute the continue-update-rollback action on the CloudFormation stack.
The rollback resumes, optionally skipping the problematic resource, and finishes with a status of UPDATE_ROLLBACK_COMPLETE.
This operation unlocks the stack and returns it to a stable state, allowing the pipeline to deploy subsequent stack updates successfully.

Key Concept

Troubleshooting cross-account IAM role delegation and resolving locked CloudFormation rollback states.
Rate this question