DVA-C02 Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create a standalone Amazon RDS instance and reconfigure the application to use it instead of the in-environment database.

  Why this is correct

  Elastic Beanstalk's in-environment databases are tightly coupled to the environment's lifecycle, meaning they are terminated along with the environment, leading to data loss. By provisioning a standalone Amazon RDS instance, the database becomes an independent, persistent resource. This decouples the data layer from the application environment, ensuring data persistence across environment updates, terminations, or blue/green deployments, making it the recommended best practice for production applications.

• ✗

  Take a snapshot of the database before each deployment and restore it after the deployment completes.

  Why it's wrong here

  While snapshots provide a point-in-time backup, restoring a snapshot after a deployment would revert the database to its pre-deployment state. Any new data or modifications made by users or the application during the deployment window, even if brief, would be overwritten and permanently lost. This method does not ensure zero data loss and introduces significant downtime during the restore process, making it unsuitable for maintaining continuous data integrity in production.

• ✗

  Use the Elastic Beanstalk environment's 'Swap environment URLs' feature to perform a blue/green deployment.

  Why it's wrong here

  The 'Swap environment URLs' feature facilitates blue/green deployments by redirecting traffic to a newly deployed environment. However, if the database is configured as an in-environment resource, it is intrinsically linked to the specific Elastic Beanstalk environment it was created with. When the old (blue) environment is eventually terminated after a successful swap, its associated in-environment database is also deleted, resulting in complete and irreversible data loss. This feature alone does not address database persistence.

• ✗

  Create a new Elastic Beanstalk environment with a new RDS instance and migrate data manually.

  Why it's wrong here

  Creating an entirely new Elastic Beanstalk environment with a new, separate RDS instance necessitates a manual data migration process from the old database to the new one. This migration is complex, time-consuming, and highly prone to errors, especially for large datasets or during active application use. It introduces significant downtime and a high risk of data inconsistency or loss during the transition period, making it an inefficient and risky strategy compared to using a pre-existing standalone RDS instance.