Correct the cross-account role trust policy after recreating a role with CloudFormation

Prescribe security controls. Determine security controls based on requirements.

Answer Correct answer: A — Edit the parent account trust policy so the existing sts:AssumeRole statement names the correct recreated role ARN.

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?

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. Correct Answer
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.
Update the CloudFormation stack again. Specify only the CAPABILITY_NAMED_IAM capability.
Update the CloudFormation stack again. Specify the CAPABILITY_IAM capability and the CAPABILITY_NAMED_IAM capability.

Community Votes

70%

30%

70% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Deleting and recreating a role generates a new unique role identifier, so a trust policy that names the old role as the principal now points at an ARN that no longer exists, and the sts:AssumeRole call fails.

A CloudFormation template recreates a role in a child account with the same role name, after which the EC2 instance profile can no longer assume the role in the parent account. The name is unchanged but the underlying principal has changed.

Adding a statement that trusts the root principal of the child account. That grants every principal in the child account the ability to assume the role, which is far broader than intended and introduces a privilege escalation path, and it also would not fix an already stale ARN reference.

Community Discussion (14 comments)

SKS 👍 8

Answer is A . The error occurs because the trust relationship in the parent account that allows the EC2 instance to assume a role may have been broken or misconfigured. This can happen when a role is recreated with a different ARN but the same role name. The trust policy must be updated to reflect the correct ARN. Option A addresses this by ensuring that the trust policy in the parent account contains the correct ARN for the role in the child account, allowing the sts:AssumeRole action. Option B, which allows the root principal to assume the role, is risky and should be avoided due to security implications.

jtzt2003 👍 5 Selected: A

It is A. B is incorrect because specifying the root principal opens access up to all principals in the child account that are allowed to use sts.

dv1 👍 1 Selected: B

There is no role ARN in the statement of a trust policy (only principal), so A is not correct.

TomTom 👍 1 Selected: A

A is correct. There is a statement in the question: "The EC2 instance has an instance profile that the EC2 instance uses to assume a role in a parent account." Therefore: Option A is the most accurate solution to address the issue of the EC2 instance not being able to assume the role in the parent account.

liuliangzhou 👍 2 Selected: A

This option is directly related to the issue mentioned in the explanation. When a character is recreated in a sub account, its ARN will change, but the character name may remain unchanged. If the ARN in the trust policy is not updated to reflect the new ARN, the EC2 instance will not be able to successfully assume that role. Therefore, updating the trust policy to include the correct ARN is the key to solving the problem. The 'correct ARN' here should refer to the ARN currently held by the character recreated in the parent account. That is to say, the corresponding ARN in the parent account policy needs to be updated. Option B adds a statement that allows the sub account root principal to perform the sts: AssemeRole operation. This is usually not the best practice, as allowing the root account to directly assume roles would pose security risks. The root account is the most powerful identity in AWS accounts and should be strictly protected.

asquared16 👍 1 Selected: B

It's B for sure

RotterDam 👍 2 Selected: A

(A) Because EC2 Instance 's role must be added as a trusted principal so that the parent role can trust it

mark_232323 👍 2 Selected: B

The issue is that the EC2 instance in the child account cannot assume the role in the parent account due to insufficient permissions, even though the role has been recreated in the CloudFormation template with the same name. Editing the trust policy of the role in the parent account and ensuring the target role ARN is correct does not grant the necessary permissions for the child account to assume the role. The trust policy governs which principals (accounts, users, roles, or services) are allowed to assume the role. In this case, the correct solution is option B

trungtd 👍 1 Selected: C

it's custom IAM role name so C

titi_r 👍 4 Selected: A

Should be "A".

titi_r 👍 1

In IAM roles, use the Principal element in the role trust policy to specify who can assume the role. For cross-account access, you must specify the 12-digit identifier of the trusted account. […] When you allow access to a different account, an administrator in that account must then grant access to an identity (IAM user or role) in that account. When you specify an AWS account, you can use the account ARN (arn:aws:iam::account-ID:root), or a shortened form that consists of the "AWS": prefix followed by the account ID.

tushar321 👍 2

C https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html#:~:text=If%20you%20have%20IAM%20resources%20with%20custom%20names%2C%20you%20must%20specify%20CAPABILITY_NAMED_IAM

teo2157 👍 2 Selected: B

The solutions architect should ensure that the trust relationship of the role in the parent account allows the child account to assume the role. The trust relationship is defined in the role's trust policy. The trust policy should specify the AWS account ID of the child account as a Principal.

devnv 👍 1

B is the correct answer

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The trust policy lives in the parent account and controls who may assume the role. When CloudFormation deletes and recreates the role, the role receives a new unique identifier, so the ARN referenced by the existing sts:AssumeRole statement in the trust policy no longer matches. Editing the parent account trust policy so the statement points at the correct target role ARN restores the assumption path without changing any permissions.

Why the Other Options Are Wrong

B: Trusting the root principal of the child account allows any principal in that account to assume the role, which is a much broader grant than the specific instance profile and is a privilege escalation risk. C: CAPABILITY_NAMED_IAM alone is only a CloudFormation acknowledgement flag and does not change any trust relationship, and specifying only that capability would fail for named IAM resources. D: Specifying both capabilities is also only an acknowledgement of the IAM resources being created and does not repair the trust policy in the parent account.

Community Comment Notes

The community voted 67 to 29 for A over B. The key argument was that trusting the child account root opens the role to any principal in that account permitted to call sts:AssumeRole, whereas correcting the ARN in the existing statement keeps the grant scoped to the instance profile. One dissenting comment noted the phrasing of option A, but the intent is the target principal in the trust statement.

Official Reference

https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial-trust-policy.html

Related Analysis

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide