CLF-C02 Billing, Pricing, and Support 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.

• ✗

  Configure IAM policies in each account to deny these actions

  Why it's wrong here

  Configuring IAM policies in each account is not an effective organization-level guardrail because IAM policies are account-local and can be modified or deleted by any account administrator, including the member account's own root user. They create no barrier that the account admin cannot remove, so they fail to prevent an attacker with administrative credentials from disabling CloudTrail or Config. SCPs, by contrast, operate above the account and are managed only by the organization's management account.

• ✓

  Apply Service Control Policies (SCPs) at the organization level

  Why this is correct

  Applying SCPs at the organization root or OU level is the correct preventive control because SCPs act as a permission boundary across every member account, and an explicit deny in an SCP makes the action non-performable even for the account root user. This means an attacker who compromises an administrator or root user in a member account still cannot turn off CloudTrail or Config if those actions are denied by an SCP. SCPs themselves cannot grant permissions, but they reliably restrict the maximum allowed permissions, and only an admin in the management account can modify them.

• ✗

  Use AWS Config rules to detect and alert on violations

  Why it's wrong here

  AWS Config rules are detective controls, not preventive ones: they evaluate resources against desired configurations and can flag a change after it has occurred, but they do not stop the disabling action from being executed. Even if an automatic remediation rule is set up, Config can only react after CloudTrail or Config has already been disabled, leaving a gap and potential evidence loss. To block the action before it happens, a preventive guardrail such as an SCP is required.

• ✗

  Enable MFA delete on all accounts

  Why it's wrong here

  Enabling MFA delete is a security feature for Amazon S3 bucket versioning—it requires a second authentication factor to permanently delete an S3 object version—so it has no bearing on who can disable CloudTrail trails or Config recorders. It is scoped entirely to protecting versioned S3 objects from accidental or malicious deletion, not to preventing administrative actions on monitoring services. Thus, it cannot satisfy the requirement to protect audit logging across the organization.

Go deeper

Related to this question