AWS Certified Solutions Architect – Professional (SAP-C02) — Question 471

A solutions architect is creating an AWS CloudFormation template from an existing manually created non-production AWS environment. The CloudFormation template can be destroyed and recreated as needed. The environment contains an Amazon EC2 instance. The EC2 instance has an instance profile that the EC2 instance uses to assume a role in a parent account.

The solutions architect recreates the role in a CloudFormation template and uses the same role name. When the CloudFormation template is launched in the child account, the EC2 instance can no longer assume the role in the parent account because of insufficient permissions

What should the solutions architect do to resolve this issue?

Answer options

• A. In the parent account, edit the trust policy for the role that the EC2 instance needs to assume. Ensure that the target role ARN in the existing statement that allows the sts:AssumeRole action is correct. Save the trust policy.
• B. In the parent account, edit the trust policy for the role that the EC2 instance needs to assume. Add a statement that allows the sts:AssumeRole action for the root principal of the child account. Save the trust policy.
• C. Update the CloudFormation stack again. Specify only the CAPABILITY_NAMED_IAM capability.
• D. Update the CloudFormation stack again. Specify the CAPABILITY_IAM capability and the CAPABILITY_NAMED_IAM capability.

Correct answer: A

Explanation

When an IAM role is deleted and recreated, AWS IAM generates a new internal unique ID for the role, even if the name and ARN remain the same. Consequently, any existing trust policies in the parent account that referenced the old role will no longer recognize the recreated role until the trust policy is updated and saved again to refresh the mapping to the new unique ID. Modifying CloudFormation capabilities or altering the trust policy to point to the root principal does not address this specific ID mismatch issue.