A payroll customer managed key is pending deletion, and objects are still encrypted with it. Someone wants to re-encrypt every object under a new key before the waiting period ends. The key cannot be used while deletion is pending. What should be done first?
Select an answer to reveal the explanation.
Short Explanation
The key is in a locked drawer with a shredder timer, and your documents still name that key. You cannot re-encrypt what you cannot decrypt, so cancel the deletion while the waiting period is open. Racing the timer under a key that will not decrypt does not save the objects.
Full Explanation
A KMS key in PendingDeletion cannot be used for decrypt or encrypt. Re-encrypting the objects requires a decrypt under the key that encrypted them, so that work cannot start while deletion is pending. CancelKeyDeletion stops the deletion while the waiting period is still open. Canceling returns the key to Disabled, so you then enable it before any decrypt. After reads work, re-encrypt onto the new key on your own schedule and only later schedule deletion again. Waiting out the timer deletes the key material, and ciphertext encrypted under that key becomes unrecoverable, so there is nothing left to re-encrypt. Key ids are not reused by a new key, and a new key cannot decrypt ciphertext it did not wrap. Deleting the objects throws away the payroll data to avoid a key operation. Caveat: canceling deletion does not by itself enable cryptographic operations. The key comes back disabled and must be enabled before S3 can read the old objects. Operational check: the key state should leave PendingDeletion, a test read of an old object should succeed after the key is enabled, and only then should a copy under the new key begin.