Security policy requires annual automatic rotation for customer managed KMS keys that protect citizen PII DynamoDB tables. What should the developer enable?
Select an answer to reveal the explanation.
Short Explanation
Flip automatic rotation on the CMK—KMS keeps the same key ID while rotating backing material yearly. Do not disable keys and rewrite every Lambda, and ROT13 is not encryption. CMKs support automatic rotation.
Full Explanation
Security policy that requires annual automatic rotation for customer managed KMS keys protecting citizen PII DynamoDB tables is satisfied by enabling automatic key rotation on those CMKs. KMS rotates the backing key material on the annual schedule while the key ID/ARN remains stable for applications, which is the operationally friendly way to meet rotation mandates without rewriting every Lambda configuration each year.
Disabling all CMKs yearly and creating brand-new key IDs hardcoded into every Lambda causes outages and mass reconfiguration. Turning off KMS for ROT13 “encryption” of PII is not cryptography and fails compliance. Claiming CMKs cannot rotate and that only AWS owned keys exist is false—customer managed keys support automatic rotation.
Exam caveat: automatic rotation rotates key material; it is different from creating a brand-new key ID or from alias re-pointing strategies—know which control your policy text requires. Operational check: enable automatic rotation on the PII table’s CMK, verify the rotation status in console/CLI, confirm DynamoDB continues to read/write without application changes, and calendar-review CloudTrail for unexpected DisableKey or ScheduleKeyDeletion events.