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.

• ✗

  Logging bypass via CloudTrail

  Why it's wrong here

  An IAM role's trust policy does not control whether AWS CloudTrail records activity. CloudTrail records each authenticated API call, including `sts:AssumeRole` and every action performed with the assumed role's temporary credentials, regardless of the trust policy's principal. A broad trust principal could result in unwanted access, but it cannot disable, bypass, or suppress CloudTrail event delivery; that would require separate configuration changes such as stopping the trail or removing its write permissions.

• ✗

  Cross-service confused deputy attack

  Why it's wrong here

  A cross-service confused deputy attack occurs when an AWS service with a privileged role is tricked into performing actions on an attacker's behalf, often because the trust policy lacks `aws:SourceArn` or `aws:SourceAccount` conditions. The issue in this scenario is direct assumption of the role by external actors, not a service being misled into using its own credentials on behalf of another service. Because the overly broad trust policy itself grants `sts:AssumeRole` to arbitrary principals, there is no confused intermediary included in the attack path.

• ✓

  Unauthorized access by an external attacker

  Why this is correct

  This is correct: an overly broad trust policy—for example `"Principal": "*"` without restrictive conditions—allows any AWS principal from any account to call `sts:AssumeRole` and obtain the role's temporary security credentials. Once assumed, the attacker receives all permissions attached to the role, enabling unauthorized actions in the account. In the absence of conditions like `aws:PrincipalArn`, `aws:PrincipalAccount`, or an external ID, there is no mechanism to distinguish legitimate principals from external attackers, so the role effectively exposes its permissions to the entire AWS ecosystem.

• ✗

  Privilege escalation by attaching additional policies

  Why it's wrong here

  Attaching additional IAM policies would require an attacker to already possess management-plane permissions such as `iam:AttachRolePolicy` or `iam:PutRolePolicy`. A broad trust policy only grants permission to assume the role; it does not grant permission to alter IAM policies unless the role's permission policy explicitly includes those IAM actions. Therefore, privilege escalation by adding policies would be a consequence of the role being overly privileged in its permissions policy, not a direct consequence of the trust policy allowing unauthorized external principals to assume it.

Go deeper

Related to this question