Exam SAP-C02 All QuestionsBrowse all questions from this exam
Go to Exam
Question 479

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?

    Correct Answer: A

    The correct answer involves editing the trust policy to ensure that the correct ARN for the role in the child account is specified. When a role is recreated, even if it has the same name, its ARN changes. The EC2 instance needs the correct role ARN to assume the role in the parent account. Allowing the root principal (as in option B) is not recommended due to security risks. Specifying only the CAPABILITY_NAMED_IAM or both IAM capabilities in CloudFormation (options C and D) does not address the trust policy issue. Therefore, to resolve the issue, the trust policy in the parent account must be updated with the correct ARN for the role, ensuring the EC2 instance can assume the role properly.

Discussion
SKS

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.

jtzt2003Option: 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.

titi_rOption: A

Should be "A".

tushar321

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

mark_232323Option: 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

trungtdOption: C

it's custom IAM role name so C

titi_r

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.

titi_r

E.g.: "Principal": { "AWS": "arn:aws:iam::123456789012:root" } "Principal": { "AWS": "123456789012" } The account ARN and the shortened account ID behave the same way. Both delegate permissions to the account. Using the account ARN in the Principal element does not limit permissions to only the root user of the account. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles A or B?!

teo2157Option: 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

B is the correct answer