A company wants to migrate a 10 GB PostgreSQL database from an on-premises server to Amazon RDS for PostgreSQL. The migration can tolerate several hours of downtime. Which migration method is the MOST straightforward?
This is the simplest method for a one-time migration with downtime tolerance.
Why this answer
Pg_dump and pg_restore are native PostgreSQL utilities that provide a straightforward, reliable method for migrating a 10 GB database with acceptable downtime. The 10 GB size is well within the practical limits of a logical dump, and the process requires no additional AWS services or complex configuration, making it the simplest approach for a migration that can tolerate several hours of downtime.
Exam trap
The trap here is that candidates may over-engineer the solution by choosing AWS DMS with ongoing replication, assuming it is always the best migration tool, when the question explicitly states that several hours of downtime are acceptable, making the simpler native pg_dump/pg_restore approach the most straightforward.
How to eliminate wrong answers
Option A is wrong because AWS DMS with ongoing replication is designed for minimal-downtime migrations and introduces unnecessary complexity (e.g., setting up a replication instance, source/target endpoints, and change data capture) for a scenario where several hours of downtime are acceptable. Option B is wrong because AWS SCT is used for schema conversion when migrating between different database engines (e.g., Oracle to PostgreSQL), not for migrating data between two PostgreSQL databases where the schema is already compatible. Option C is wrong because an Amazon RDS Read Replica cannot be created from an on-premises database; read replicas in RDS are only supported between RDS instances or from an RDS instance to an external source, not the reverse.