SOA-C02 Security and Compliance 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.

• ✗

  iam:ListAccessKeys, iam:CreateAccessKey, iam:DeleteAccessKey, iam:PutUserPolicy

  Why it's wrong here

  Including iam:PutUserPolicy in this set is incorrect because that action governs the creation, deletion, and modification of inline policies attached to an IAM user, group, or role. Access key rotation only requires lifecycle actions directly on the access key objects themselves: listing, creating, deleting, and updating their status. Granting PutUserPolicy would also allow the user to alter their own permissions or those of others, an unnecessary and overly broad privilege that violates least privilege for a simple key rotation task.

• ✗

  iam:ListAccessKeys, iam:CreateAccessKey, iam:DeleteAccessKey, kms:*

  Why it's wrong here

  KMS permissions are completely unrelated to IAM access key rotation. IAM access keys are HMAC-based credentials used to sign AWS API requests, whereas AWS KMS keys are cryptographic keys used for encrypting and decrypting data. Granting kms:* would give the user full control over encryption keys, including creating, deleting, and managing KMS keys, which has no bearing on rotating their access keys. Including kms:* needlessly expands the security boundary and creates a critical risk if the user's account is compromised.

• ✗

  iam:GetUser, iam:CreateAccessKey, iam:DeleteAccessKey, iam:UpdateAccessKey

  Why it's wrong here

  This option omits iam:ListAccessKeys, which is essential for rotation. While iam:GetUser retrieves metadata about the user (such as ARN, user ID, and path), it does not return access key IDs or statuses, so the user cannot determine which existing keys to update or delete. Without ListAccessKeys, the iam:UpdateAccessKey action becomes effectively useless because the user cannot identify the AccessKeyId of the old key that must be deactivated during the rotation workflow. Therefore, allowing Create/Delete/Update without List does not provide a functional rotation capability.

• ✓

  iam:ListAccessKeys, iam:CreateAccessKey, iam:DeleteAccessKey, iam:UpdateAccessKey

  Why this is correct

  This set of four IAM actions is correct because it represents the minimum required permissions for a self-service access key rotation workflow. First, iam:ListAccessKeys lets the user enumerate their existing keys to identify which one is active or old. iam:CreateAccessKey allows them to generate a new active key, iam:UpdateAccessKey lets them mark the old key as Inactive to avoid downtime, and iam:DeleteAccessKey removes the old key after the new one is confirmed working. Together these actions support a safe, zero-downtime rotation while denying access to unrelated management functions such as policy editing or KMS administration.

Go deeper

Related to this question