Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 96 discussion

The other options are not correct because they are not required for this use case. kms:GetKeyPolicy allows for the retrieval of the key policy for a CMK but it does not have any relation to client-side encryption of S3 objects, kms:GetPublicKey allows for the retrieval of the public key of a CMK, but it does not have any relation to client-side encryption of S3 objects and kms:Sign allows for signing a message using a CMK but it does not have any relation to client-side encryption of S3 objects.

When you want to do the client side encryption, your files are most likely above 4K in size. So, you would be performing envelope encryption. For that, you need a data key. You ask KMS to generate and give you the data key, supplying the kms CMK. KMS would generate a new data key, encrypt it with the CMK and return you both the encrypted and plain data key. AWS would never retain the data key; they will immediately discard it. You would now encrypt your data using the plain data key and immediately delete the plain data key (unencrypted). You store the encrypted data key that you got from KMS along with the encrypted data, which is then uploaded to s3. Note that AWS does NOT know about the data key at this point; only you know. KMS just holds the kms CMK that was used to encrypt the data key. So, you need access to KMS to decrypt the data key before using that decrypted data key to unencrypt your data. Similarly AWS cannot read your data, even though it has the KMS CMK and also the encrypted data key stored in s3. This is why you need the generateDataKey permission. Hope this helps.

Indeed, the question says client side encryption but the answer is all about S3-KMS.