SCS-C02 Identity and Access Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Attach a policy to the user in the production account allowing sts:AssumeRole for the development role ARN.

  Why this is correct

  This is correct because cross-account role assumption requires two halves: the role's trust policy in the development account must list the production account (or the user ARN) as a trusted principal, and the user in the production account must have an IAM identity policy that explicitly grants sts:AssumeRole against the development role's ARN. Without this identity-side permission, the user is not authorized to call AssumeRole even though the role trusts the account. Attaching the policy to the user therefore completes the authorization chain and allows the user to receive temporary credentials for the development role.

• ✗

  Modify the trust policy of the role in the development account to allow the user ARN instead of the account ARN.

  Why it's wrong here

  Adjusting the trust policy to name the user ARN changes who is allowed to request the role, but it does not automatically give that user permission to make the sts:AssumeRole API call. In AWS, permission to call sts:AssumeRole must be granted in the calling account via an IAM policy on the user or a group the user belongs to. Trust policies and identity policies are evaluated separately; the trust policy only gates whether a principal can be trusted once it attempts the call. Therefore this modification alone still leaves the user unable to assume the role.

• ✗

  Set up a VPC peering connection between the accounts.

  Why it's wrong here

  VPC peering connects private networks and allows traffic between VPCs using private IP addresses, but it operates at the network layer and has no bearing on AWS IAM authentication or authorization. The user in the production account and the role in the development account do not communicate over a network path for AssumeRole; the STS service receives an API call over the public AWS endpoint. Setting up a VPC peering connection therefore neither grants nor facilitates the sts:AssumeRole permission needed for this cross-account access.

• ✗

  Create a new IAM user in the development account with the same name.

  Why it's wrong here

  IAM users are local to the AWS account in which they are created, so a user with the same name in the development account is a completely different principal with its own credentials and permissions than the user in the production account. Duplicating the user does not link the two identities and does not grant the development-account user any ability to act in the production account. The correct pattern is to assume an IAM role, which vends temporary credentials, rather than creating a second long-term user. This also avoids managing additional credentials and keeps the authorization path centralized.

Go deeper

Related to this question