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.

• ✗

  Use AWS Config rules to detect role creation and automatically delete the roles.

  Why it's wrong here

  AWS Config rules are a detective control, not a preventive control. When a new role is created, the rule evaluates the resource and only then can an auto-remediation action delete it, leaving a window where the role exists and may already be used to escalate privileges. Additionally, Config must be enabled in every member account with remediation configured, which is operationally heavy and still does not address the underlying permissions that allow role creation in the first place.

• ✗

  Set up a Lambda function that monitors CloudTrail and revokes role creation permissions.

  Why it's wrong here

  A Lambda function that monitors CloudTrail and revokes permissions is inherently reactive and suffers from a race condition because CloudTrail logs are delivered asynchronously and the role creation API call has already succeeded. Even if you subsequently remove the role creation permissions, the already-created malicious role can still be used to gain administrative access, and the monitoring function itself can be disabled or bypassed. This approach adds complexity without enforcing a strict organizational boundary.

• ✓

  Create an SCP that denies iam:CreateRole and iam:UpdateAssumeRolePolicy and attach it to the root organizational unit.

  Why this is correct

  This is the correct answer because an SCP attached to the root organizational unit is immediately inherited by all member accounts and acts as a preventive guardrail that cannot be overridden by any IAM policy, including the account administrator. Explicitly denying iam:CreateRole stops creation of new roles, and denying iam:UpdateAssumeRolePolicy prevents an attacker from modifying an existing role's trust policy to assume it from an untrusted account. Unlike reactive controls, SCPs take effect before the API call is allowed, and they can be managed centrally by the organization's management account.

• ✗

  Create an IAM policy that denies role creation and attach it to each user in every account.

  Why it's wrong here

  Attaching an IAM policy to each user is an incomplete and unscalable control because it applies only to a fixed set of principals at a single point in time, and any newly created user or role in the account will not inherit it unless it is also attached via a group or identity provider. Users with administrative access can detach or modify their own policies to bypass the deny, and the policy would need to be replicated and managed in every member account. This is also not a preventive guardrail at the organization level since it does not restrict the account root user or other roles that may already have role creation permissions.

Go deeper

Related to this question