During an incident drill, an operator disables a CMK that still encrypts historical archive objects an archives Lambda must decrypt. What operational impact should the team expect?
Select an answer to reveal the explanation.
Short Explanation
Disable the CMK and Decrypt hangs a “closed” sign—the archives Lambda cannot open historical objects until someone re-enables the key. Ciphertext does not carry a spare offline master key. Know that blast radius before you flip the switch in a real incident.
Full Explanation
Disabling a CMK immediately blocks cryptographic operations that need that key. During an incident drill, if an operator disables a CMK that still protects historical archive objects, the archives Lambda’s Decrypt calls fail until the key is re-enabled. Ciphertext remains in S3, but it is unreadable without a usable key state—exactly the operational impact teams must anticipate before using DisableKey as a response action.
It is incorrect that disabling has no effect until a deletion waiting period completes—disable and schedule-deletion are different states, and disable already breaks Decrypt. S3 will not automatically re-encrypt all objects under a new AWS owned key within minutes because a CMK was disabled. Ciphertext does not embed a permanent offline copy of the CMK that lets Lambda decrypt forever without KMS.
Exam caveat: prefer careful key grants and temporary policy denials over surprise DisableKey in production; practice drills should include re-enable verification. Operational check: disable a lab CMK protecting test archives, confirm the Lambda fails decrypt, re-enable the key, confirm reads resume, and update the incident runbook with that expected behavior for historical evidence.