SCS-C02 Infrastructure Security 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.

• ✓

  IAM roles with a trust policy that allows the external account.

  Why this is correct

  IAM roles are the native AWS mechanism for cross-account access: the role's trust policy explicitly names the external account (or its users/roles) as a principal, and the permission policy grants the specific actions the role can perform. When the external user assumes the role, AWS verifies that the trust policy allows the request and then issues temporary credentials scoped to the role's permissions, making this the correct and secure way to enable the cross-account assumption.

• ✗

  AWS Security Token Service (STS) to generate tokens.

  Why it's wrong here

  AWS STS is the service that issues temporary credentials when a role is assumed, but it does not itself define who is allowed to assume which role. STS simply processes the AssumeRole API call and relies on the role's trust policy to authorize the request; without a properly configured trust policy, STS will deny the call. Therefore, STS is a supporting component of the solution, not the mechanism that grants cross-account access.

• ✗

  IAM users in the source account with cross-account permissions.

  Why it's wrong here

  IAM users are entities that exist within a single account and are used to authenticate that account's own principals; they cannot be used to directly assume a role from another account. Cross-account role assumption requires a role in the target account with a trust policy that allows the external account's principals, and the source account must have a policy granting its users or roles permission to call sts:AssumeRole. Simply defining 'cross-account permissions' for an IAM user does not create the required trust relationship, and it also conflicts with the principle of not using long-term IAM users for cross-account access.

• ✗

  AWS Organizations service control policies.

  Why it's wrong here

  AWS Organizations service control policies (SCPs) are account-level permission boundaries that restrict the maximum permissions for all IAM principals in an account, but they do not establish any cross-account trust or define who can assume a role. SCPs can only deny or allow actions within the organization's accounts, and they cannot authorize a user from one account to assume a role in another. Therefore, SCPs may limit what a role can do after it is assumed, but they are never the mechanism that enables the assumption itself.

Go deeper

Related to this question