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.

• ✗

  Update the application code directly on the EC2 instances without redeploying the environment.

  Why it's wrong here

  Directly modifying EC2 instances bypasses Elastic Beanstalk's management layer, leading to configuration drift where the actual state diverges from the desired state defined in the environment configuration. This makes the environment non-reproducible, complicates troubleshooting, and prevents Elastic Beanstalk from properly managing updates or scaling, violating the principles of immutable infrastructure.

• ✗

  Create a new environment configuration, update the code, and swap the CNAME of the environments.

  Why it's wrong here

  While a CNAME swap facilitates a zero-downtime application deployment by redirecting traffic to a new, pre-warmed environment, it does not isolate the database if it was provisioned as part of the Elastic Beanstalk environment. Any changes to the new environment's configuration, or even a rebuild, could still impact or destroy the attached database, making it unsuitable for protecting persistent data during environment updates.

• ✓

  Decouple the database from the Elastic Beanstalk environment by creating a separate RDS instance and connecting the application to it externally.

  Why this is correct

  Decoupling the database by provisioning a standalone Amazon RDS instance outside the Elastic Beanstalk environment ensures its independent lifecycle management, allowing for separate scaling, backups, and patching. The application then connects to this external database using environment properties, guaranteeing data persistence and availability even if the Elastic Beanstalk environment is rebuilt, terminated, or updated, which is critical for production workloads.

• ✗

  Use Elastic Beanstalk's platform updates while keeping the database attached to the environment.

  Why it's wrong here

  Elastic Beanstalk platform updates, whether in-place or immutable, apply changes across the entire environment, including any database instance provisioned *within* that environment. Keeping the database attached means it is subject to these updates, potentially causing downtime, data loss, or requiring a full rebuild of the database instance, which is generally unacceptable for production databases.