What should a solutions architect do to meet these requirements?
Create a database snapshot. Copy the snapshot to a new unencrypted snapshot. Share the new snapshot with the acquiring company’s AWS account.
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 that uses a different AWS managed KMS key. Add the acquiring company’s AWS account to the KMS key alias. Share the snapshot with the acquiring company’s AWS account.
Create a database snapshot. Download the database snapshot. Upload the database snapshot to an Amazon S3 bucket. Update the S3 bucket policy to allow access from the acquiring company’s AWS account.
Explanations:
Creating a database snapshot and copying it to an unencrypted snapshot will result in loss of data security, as the snapshot will not be encrypted. Additionally, sharing an unencrypted snapshot does not meet the requirement for secure sharing of confidential data.
Creating a database snapshot and adding the acquiring company’s AWS account to the KMS key policy allows the acquiring company to access the encrypted snapshot securely. This method maintains encryption and adheres to best practices for data sharing.
Creating a snapshot using a different AWS managed KMS key and adding the acquiring company’s AWS account to the KMS key alias is incorrect because AWS managed keys cannot be shared in this manner. Customer managed keys are needed for cross-account access to encrypted snapshots.
Downloading the database snapshot and uploading it to S3 would not retain the database’s encryption and would require manual handling of sensitive data, posing security risks. This method does not align with the requirement to securely share the encrypted database backup.