Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 480 discussion

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.

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.

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

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.

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.

It's B for sure

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

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

it's custom IAM role name so C

Should be "A".

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.

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

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.

B is the correct answer