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.

• ✗

  Use IAM Access Analyzer to generate findings when access keys are created.

  Why it's wrong here

  IAM Access Analyzer is a resource-policy analysis tool that identifies resources shared with external principals by inspecting S3 bucket policies, KMS key policies, IAM role trust policies, and similar constructs. It does not monitor or report on IAM access key creation events, and its findings never block API calls, so a principal who is allowed to call IAM:CreateAccessKey will still succeed. This makes it purely a read-only audit mechanism, not a preventive control for stopping key creation.

• ✗

  Configure IAM password policies in each account to disallow access keys.

  Why it's wrong here

  An IAM account password policy is a per-account setting that only controls password complexity, rotation, expiration, and reuse for IAM users who sign in to the AWS Management Console. Access keys are independent long-term credentials issued programmatically or via the console, and no password policy field exists to disable or deny their creation. Even with the most restrictive password policy, any IAM principal that has permission to call IAM:CreateAccessKey can still generate new access keys.

• ✓

  Apply an SCP that denies the IAM:CreateAccessKey action to all accounts in the organization.

  Why this is correct

  A service control policy attached to the organization root, an OU, or individual accounts can explicitly deny the IAM:CreateAccessKey action, and because SCP deny statements override all identity-based and resource-based allows in the affected accounts, no principal in those accounts can create a new access key. This provides a centralized, preventive guardrail that scales across all accounts without requiring per-account configuration or custom automation. It is important to note that an SCP only prevents future creation and does not remove or invalidate access keys that already exist.

• ✗

  Create an AWS Config rule in each account to automatically delete access keys.

  Why it's wrong here

  AWS Config is a reactive service that records configuration changes and evaluates rules after a resource exists or an API action has occurred; it cannot intercept and deny the IAM:CreateAccessKey action itself. Building per-account Config rules plus remediation actions to automatically delete newly created keys introduces detection latency, complex per-account setup, and the risk of inadvertently deleting keys needed for legitimate workloads. This approach is neither preventive nor scalable when the requirement is to prohibit access key creation across an entire organization from the start.

Go deeper

Related to this question