SCS-C02 Management and Security Governance 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.

• ✗

  Create an IAM role with a deny policy for the action and attach it to all users

  Why it's wrong here

  An IAM role is an identity that must be assumed, not a policy that can be 'attached to users' to directly deny permissions. While a user trying to assume the role would inherit its deny policy, the user can simply choose not to assume the role, and the account root user is not subject to IAM role-based restrictions at all. Moreover, an existing session or direct API call with other credentials bypasses the role, so this approach does not create an organization-wide boundary.

• ✗

  Create an AWS Config rule to check for the action and automatically remediate

  Why it's wrong here

  AWS Config is a detective service that continuously records configuration changes and evaluates them against rules after the resource operation has already occurred. An automatic remediation action, such as a Systems Manager Automation document, runs asynchronously and could take minutes to execute or fail due to missing attachments, leaving the unintended change in effect in the interim. Config does not sit in the IAM or SCP authorization path, so it cannot deny the API action at request time and is not a preventive control.

• ✓

  Attach a service control policy (SCP) that denies the action at the root organization level

  Why this is correct

  A service control policy attached to the root organizational unit acts as a maximum permission boundary for every account under it, cascading through all child OUs and accounts. Because SCPs affect the effective permissions of all principals, including the account root users, an explicit deny statement overrides any allow from IAM-based or resource-based policies. This makes it the only option here that centrally prevents an action across the entire organization before the request can be executed.

• ✗

  Enable AWS CloudTrail and create a metric filter to alert on the action

  Why it's wrong here

  CloudTrail records API activity as audit events, and a metric filter can trigger a CloudWatch alarm when the action is detected, but this alerting happens only after the API call has been processed. The alarm cannot revoke the permission or intercept the request, so the unauthorized action may already be complete and any resulting damage (such as deleted resources or modified configurations) must be investigated and remediated manually. Alerting is a detective control, not a preventive guardrail, and cannot replace an SCP that denies the action in the first place.

Go deeper

Related to this question