A Lambda that connects to a legacy host must decrypt a sealed configuration blob using a customer managed KMS key before startup. What must the function do?
Select an answer to reveal the explanation.
Short Explanation
The Lambda asks KMS to open the sealed config—Decrypt or envelope data keys—with kms permissions on that CMK. Do not zip the raw key material into the package. KMS is very much callable from Lambda.
Full Explanation
A Lambda that must open a sealed configuration blob protected by a customer managed KMS key needs permission to call KMS Decrypt—or to use an envelope-encryption data-key pattern that ultimately depends on that CMK—before startup. The function retrieves ciphertext from a private store, decrypts with KMS under its execution role, and only then reads configuration. Hard-coding plaintext secrets in the deployment package defeats the sealed-blob design and leaks credentials through versioned artifacts.
Storing the CMK’s plaintext key material inside the Lambda ZIP is never appropriate; customers do not extract and embed CMK bytes that way, and doing so destroys the purpose of KMS. Disabling KMS and leaving the configuration blob in a public S3 object trades cold-start convenience for public exposure of municipal secrets. Claiming KMS APIs cannot be invoked from Lambda is false—Lambdas call KMS routinely when IAM and key policy allow.
Exam caveat: both the Lambda execution role identity policy and the CMK key policy must allow the decrypt; missing either side fails closed. Operational check: invoke the function with a sealed blob, confirm Decrypt appears in CloudTrail for the CMK, remove kms:Decrypt temporarily and confirm startup fails without falling back to hardcoded plaintext, then restore the permission for production.