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.

• ✓

  IAM roles

  Why this is correct

  IAM roles are the correct mechanism because they support cross-account trust relationships: the organization can configure a role in a target account with a trust policy allowing principals from a central account to assume it. When a user or service in the central account calls sts:AssumeRole, AWS STS returns temporary credentials scoped to the role's permissions policy, enabling centrally governed access across accounts. This is the standard way to grant access to AWS accounts, and it can be combined with AWS Organizations' central management for auditing and policy enforcement.

• ✗

  Service control policies (SCPs)

  Why it's wrong here

  Service control policies are applied at the AWS Organizations account or OU level and define the maximum permissions that any principal in that account can have; they act as boundary guardrails, not grants. An SCP can deny or restrict an individual IAM role or user, but it cannot create a role, issue credentials, or allow a principal from another account to authenticate into an account. Therefore SCPs are a permission boundary control, not a mechanism for granting cross-account access.

• ✗

  Resource-based policies

  Why it's wrong here

  Resource-based policies, such as an S3 bucket policy or a Lambda resource policy, grant access to specific resources for named principals, and some can reference cross-account principals directly without needing a role. However, they are service-specific and apply only to the individual resource that carries the policy, so they cannot serve as a general, centralized method for giving users or services access to an entire AWS account. For account-wide cross-account access, you still need an IAM role that can be assumed after the resource-based policy determines resource-level authorization.

• ✗

  IAM groups

  Why it's wrong here

  IAM groups are simply logical collections of IAM users inside a single AWS account and are used only to attach the same permissions policies to multiple users with a consistent identity. A group has no trust relationship, no policy of its own beyond attached permissions, and cannot be assumed or referenced as a principal outside the account, so it cannot authorize access from another account. Groups exist as an administrative convenience within an account, never as a cross-account access mechanism.

Go deeper

Related to this question