What must the SysOps administrator do to meet these requirements with the LEAST administrative overhead?
Take a snapshot of the RDS DB instance in the production account. Amend the KMS key policy of the production-rds-key KMS key to give access to the migration account’s root user. Share the snapshot with the migration account.
Create an RDS read replica in the migration account. Configure the KMS key policy to replicate the production-rds-key KMS key to the migration account.
Take a snapshot of the RDS DB instance in the production account. Share the snapshot with the migration account. In the migration account, create a new KMS key that has an identical alias.
Use native database toolsets to export the RDS DB instance to Amazon S3. Create an S3 bucket and an S3 bucket policy for cross account access between the production account and the migration account. Use native database toolsets to import the database from Amazon S3 to a new RDS DB instance.
Explanations:
Taking a snapshot and sharing it with the migration account is a straightforward way to transfer the database. Updating the KMS key policy to allow access to the migration account ensures that the encrypted snapshot can be accessed by the target account without requiring additional manual key management or creating a new key.
Creating an RDS read replica requires the target account to have access to the original KMS key. Replicating the KMS key would involve unnecessary complexity and overhead, and sharing snapshots is a simpler solution for this use case.
While sharing the snapshot is correct, creating a new KMS key with an identical alias in the migration account introduces unnecessary complexity. The KMS key policies can be updated in the original account, avoiding the need for a new key.
This option involves additional complexity by using native database tools, exporting to S3, and managing cross-account access for S3. This method is more cumbersome than simply taking and sharing a snapshot, which is more efficient for this task.