A. - "So let me get this straight, with the current company the data is protected and encrypted. However, for the acquiring company the data is unencrypted? How is that fair?" C - Wouldn't recommended this option because using a different AWS managed KMS key will not allow the acquiring company's AWS account to access the encrypted data. D. - Don't risk it for a biscuit and get fired!!!! - by downloading the database snapshot and uploading it to an Amazon S3 bucket. This will increase the risk of data leakage or loss of confidentiality during the transfer process. B - CORRECT

I believe the reason why option C is not the correct answer is that adding the acquiring company's AWS account to the KMS key alias doesn't directly control access to the encrypted data. KMS key aliases are simply alternative names for KMS keys and do not affect access control. Access to encrypted data is goverened by KMS key policies, which define who can use the key for encryption and decryption.

Create a database snapshot. Add the acquiring company’s AWS account to the KMS key policy. Share the snapshot with the acquiring company’s AWS account.

B. Create a database snapshot. Add the acquiring company’s AWS account to the KMS key policy. Share the snapshot with the acquiring company’s AWS account. Most Voted

Create a database snapshot of the encrypted. Add the acquiring company’s AWS account to the KMS key policy. Share the snapshot with the acquiring company’s AWS account.

To securely share a backup of the database with the acquiring company's AWS account in the same Region, a solutions architect should create a database snapshot, add the acquiring company's AWS account to the AWS KMS key policy, and share the snapshot with the acquiring company's AWS account. Option A, creating an unencrypted snapshot, is not recommended as it will compromise the confidentiality of the data. Option C, creating a snapshot that uses a different AWS managed KMS key, does not provide any additional security and will unnecessarily complicate the solution. Option D, downloading the database snapshot and uploading it to an S3 bucket, is not secure as it can expose the data during transit. Therefore, the correct option is B: Create a database snapshot. Add the acquiring company's AWS account to the KMS key policy. Share the snapshot with the acquiring company's AWS account.

Option B is the correct answer. Option A is not recommended because copying the snapshot to a new unencrypted snapshot will compromise the confidentiality of the data. Option C is not recommended because using a different AWS managed KMS key will not allow the acquiring company's AWS account to access the encrypted data. Option D is not recommended because downloading the database snapshot and uploading it to an Amazon S3 bucket will increase the risk of data leakage or loss of confidentiality during the transfer process.

https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html

It is C, you have to create a new key. Read below You can't share a snapshot that's encrypted with the default AWS KMS key. You must create a custom AWS KMS key instead. To share an encrypted Aurora DB cluster snapshot: Create a custom AWS KMS key. Add the target account to the custom AWS KMS key. Create a copy of the DB cluster snapshot using the custom AWS KMS key. Then, share the newly copied snapshot with the target account. Copy the shared DB cluster snapshot from the target account https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/

Is it bad that in answer B the acquiring company is using the same KMS key? Should a new KMS key not be used?

https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/

ANSWER - B