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.

• ✓

  Create an IAM role in the production account with a trust policy allowing the development account to assume it.

  Why this is correct

  This is the correct approach because it uses an IAM role with a trust policy that explicitly delegates the ability to assume the role to the development account. When the development account calls sts:AssumeRole, it receives temporary, automatically rotating credentials scoped to the permissions policy attached to the role, so no long-term access keys are stored or shared. The trust policy should also include a condition such as aws:SourceAccount to protect against the confused deputy problem and ensure only the intended development account can request the role.

• ✗

  Create IAM users in the production account and share access keys with developers.

  Why it's wrong here

  Sharing long-term access keys with developers is fundamentally insecure because these credentials are permanent, never expire, and cannot be portably scoped to the development account. If a key is leaked or a developer leaves, the entire production account is at risk until the key is manually rotated, and there is no way to attribute actions back to the individual developer. AWS security best practice—and the IAM model—requires using temporary credentials via role assumption rather than distributing static keys for cross-account access.

• ✗

  Establish a VPN connection between the accounts and use directory credentials.

  Why it's wrong here

  A VPN (or Direct Connect) establishes only an encrypted network path between your on-premises environment and AWS VPC; it does not create any IAM principal or grant permissions to call AWS APIs. IAM authorization is evaluated per-request based on the identity policy of the caller and resource policies, and it is entirely independent of the network route used to reach the AWS endpoint. Directory credentials (e.g., from AWS Managed Microsoft AD) could be used for identity federation via SSO, but a VPN alone provides no cross-account IAM access and does not authenticate to IAM or STS.

• ✗

  Create the same IAM users in both accounts with identical permissions.

  Why it's wrong here

  Creating identical IAM users in both accounts does not establish any trust relationship; each account has independently managed principals, and a user in the development account has no permission to authenticate as the corresponding user in the production account. This duplication forces developers to maintain two sets of credentials and requires constant manual synchronization to keep permissions in sync, leading to privilege drift and audit gaps because actions in production are performed by a separate, unlinked principal. Furthermore, it relies on long-term credentials and violates the security principle of least privilege, whereas role-based access provides temporary, centrally managed credentials with cross-account delegation.

Go deeper

Related to this question