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 also thought straight away that it could be C, however, the questions mentions that the database is encrypted with an AWS KMS custom key already. So maybe the letter B could be right, since it already has a custom key, not the default KMS Key. What do you think?

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

Yes, can't share a snapshot that's encrypted with the default AWS KMS key. But as per the given information "The database is encrypted with an AWS Key Management Service (AWS KMS) customer managed key", it may not be the default AWS KMS key.

I agree with KZM. It is B. There's no need to create another custom AWS KMS key. https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/ Give target account access to the custom AWS KMS key within the source account 1. Log in to the source account, and go to the AWS KMS console in the same Region as the DB cluster snapshot. 2. Select Customer-managed keys from the navigation pane. 3. Select your custom AWS KMS key (ALREADY CREATED) 4. From the Other AWS accounts section, select Add another AWS account, and then enter the AWS account number of your target account. Then: Copy and share the DB cluster snapshot

It is B. There's no need to create another custom AWS KMS key. https://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/ Give target account access to the custom AWS KMS key within the source account 1. Log in to the source account, and go to the AWS KMS console in the same Region as the DB cluster snapshot. 2. Select Customer-managed keys from the navigation pane. 3. Select your custom AWS KMS key (ALREADY CREATED) 4. From the Other AWS accounts section, select Add another AWS account, and then enter the AWS account number of your target account. Then: Copy and share the DB cluster snapshot

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://aws.amazon.com/premiumsupport/knowledge-center/aurora-share-encrypted-snapshot/

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.

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.

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

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

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.

ANSWER - B

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.

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/

Yes, you are right, read my comment above.

Yes, as per the given information "The database is encrypted with an AWS Key Management Service (AWS KMS) customer managed key", it may not be the default AWS KMS key.

I think I would agree with you if option C say using a new "customer managed key" instead of AWS managed key

KMS key aliases are simply alternative names for KMS keys and do not affect access control. Access to encrypted data is governed by KMS key policies, that define who can use the key for encryption and decryption.