DBS-C01 · Question #32
A company has migrated a single MySQL database to Amazon Aurora. The production data is hosted in a DB cluster in VPC_PROD, and 12 testing environments are hosted in VPC_TEST using the same AWS…
The correct answer is A. Run the master in Amazon Aurora MySQL. Create 12 clones in VPC_TEST, and script the clones. Explanation Option A is correct because Aurora Fast Clone technology creates a copy-on-write clone almost instantly and at minimal cost - it only stores the differences from the source, not a full copy of the data. Since testing results in minimal changes, the clones remain…
Question
A company has migrated a single MySQL database to Amazon Aurora. The production data is hosted in a DB cluster in VPC_PROD, and 12 testing environments are hosted in VPC_TEST using the same AWS account. Testing results in minimal changes to the test data. The Development team wants each environment refreshed nightly so each test database contains fresh production data every day. Which migration approach will be the fastest and most cost-effective to implement?
Options
- ARun the master in Amazon Aurora MySQL. Create 12 clones in VPC_TEST, and script the clones
- BRun the master in Amazon Aurora MySQL. Take a nightly snapshot, and restore it into 12
- CRun the master in Amazon Aurora MySQL. Create 12 Aurora Replicas in VPC_TEST, and script
- DRun the master in Amazon Aurora MySQL using Aurora Serverless. Create 12 clones in
How the community answered
(68 responses)- A82% (56)
- B1% (1)
- C4% (3)
- D12% (8)
Explanation
Explanation
Option A is correct because Aurora Fast Clone technology creates a copy-on-write clone almost instantly and at minimal cost - it only stores the differences from the source, not a full copy of the data. Since testing results in minimal changes, the clones remain small and cheap, and scripting their nightly refresh is straightforward and efficient for all 12 environments.
Option B is wrong because taking a nightly snapshot and restoring it 12 times is significantly slower (snapshots take time to create and restore) and more expensive, as each restore creates a full independent copy of the data consuming separate storage.
Option C is wrong because Aurora Replicas are designed for read scaling and high availability, not for independent test environments - they cannot diverge from the master with separate writes, making them unsuitable as isolated test databases.
Option D is wrong because Aurora Serverless adds unnecessary complexity and cost for a production master database; the cloning benefit exists regardless of whether Serverless is used, and Serverless is optimized for variable/intermittent workloads, not a stable production master.
Memory Tip: Think "Clone = Fast & Cheap Copy-on-Write" - Aurora Clones are like creating a shortcut to the data, only writing new changes, making them perfect for multiple test environments that barely modify data.
Topics
Community Discussion
No community discussion yet for this question.