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.

• ✗

  Use AWS Lambda with a scheduled CloudWatch Events rule to rotate the keys.

  Why it's wrong here

  Lambda + CloudWatch Events can call the IAM API to create a new access key, deactivate the old one, and update whatever downstream system consumes the credentials, but this requires you to build and maintain all of the state machine logic yourself: tracking which key is active, storing the rotation state, and handling failures/rollbacks. It also forces you to reimplement Secrets Manager's built-in integration, and the scheduled trigger only means rotation happens on a timer, not automatically tied to the secret version lifecycle. The biggest miss is that this approach has no native secret storage, no versioning, and no audit trail tied to a secret—so it's a workable but fragile custom solution, not the service-native answer.

• ✗

  Create a script that runs on an EC2 instance using cron to rotate the keys.

  Why it's wrong here

  A cron-driven script on an EC2 instance assumes the instance is always running, patched, and its IAM role has permission to rotate keys; if the instance is stopped, terminated, or the script errors mid-rotation, the corporate access credentials can be left in a broken half-rotated state with no built-in rollback. Unlike a managed secret store, this script has no integrated version history, no automatic propagation to consuming applications, and no central audit trail—you would need to hard-code or distribute the new key to every consumer yourself. This also creates an open security risk because the EC2 instance itself now holds the ability to rotate IAM user keys, effectively becoming a high-value target, while Secrets Manager provides encrypted storage and fine-grained access policies.

• ✓

  Store the access keys in AWS Secrets Manager and use automatic rotation.

  Why this is correct

  AWS Secrets Manager natively supports automatic rotation for IAM user access keys: you configure a rotation schedule (e.g., every 30 or 90 days), and the service creates a new access key, updates the secret with the new credentials, and deletes the old key after a safe handoff—all with versioning so you can stage the new secret separately from the current one. It does not require you to write any custom scheduling code because Secrets Manager uses an AWS-provided Lambda rotation function template for IAM user keys, and it can alternate between two active keys to avoid downtime for downstream systems. This directly meets the need to 'require access to the service' without manual intervention, and it also gives you fine-grained IAM permissions to control who can access or rotate the secret, plus CloudTrail audit logs of rotation events.

• ✗

  Enable IAM access key rotation in the IAM console.

  Why it's wrong here

  The IAM console's 'Access key rotation' feature only reports the age of existing keys and lets you manually create/delete them; it does not have any automatic rotation capability. Even the older 'rotate' button only archives an existing key and asks you to create a new one, so you are still required to update any hard-coded consumer immediately and then return to the console to delete the old key. There is no scheduling, no versioning, and no orchestration with the application that consumes the keys—so this option does not satisfy 'automatic rotation' and would still leave the legacy application broken until someone manually propagates the new credentials.

Go deeper

Related to this question