CLF-C02 Security and Compliance 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 Groups

  Why it's wrong here

  IAM Groups are logical containers used to attach permission policies to multiple IAM users at once within the same AWS account. They are an administrative convenience for managing the permissions of identities that you have already created as IAM users, but they have no ability to authenticate anyone — groups are not principals and do not possess credentials. Since the group is entirely internal to your account and operates on existing IAM users, it cannot be used to grant access to a party outside your AWS account; there is no way to add an external entity to an IAM group without first creating a permanent IAM user for that entity.

• ✓

  IAM Roles with cross-account access

  Why this is correct

  IAM Roles with cross-account access are the correct approach because they create a temporary, scoped trust relationship with an external identity. You configure the role's trust policy to allow a specific external AWS account or federated identity provider to call the Security Token Service (STS) AssumeRole operation, which provides short-lived credentials in return. The role's permission policy defines exactly which actions and resources the external party may access, so you apply fine-grained least-privilege controls without ever creating a permanent IAM user for that party. Because the credentials expire automatically (typically within one hour), this design reduces risk and is the standard pattern for granting controlled access to external collaborators or applications.

• ✗

  IAM password policies

  Why it's wrong here

  IAM password policies are account-local rules that enforce password complexity, minimum length, rotation, and reuse restrictions for IAM users already defined in your account. They apply only to credentials that exist within your own directory of identities, so an external party has no password to be governed by them. Rather than creating any grant of access, these policies merely constrain how internal users maintain their own login secrets, making them irrelevant to granting access to someone outside your AWS account.

• ✗

  Service Control Policies (SCPs)

  Why it's wrong here

  Service Control Policies (SCPs) are features of AWS Organizations that act as permission guardrails over all accounts in the organization. They are restrictive, not permissive: an SCP can deny or limit what principals in a member account can do, but it never grants new permissions or allows a principal to exist. Crucially, SCPs apply only to principals already present within member accounts, so they cannot provide a mechanism for an external party to gain authenticated access — they only shrink the effective permissions of identities the account already has.

Go deeper

Related to this question