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 existing environment with the new version.

  Why it's wrong here

  Updating the existing environment with the new version triggers an in-place rolling deployment that temporarily serves traffic from instances running both old and new code, and any failed health check can leave the environment impaired with no instantaneous rollback. Blue/green requires a completely separate environment so the original remains untouched and fully available until you are ready to switch traffic. This option contradicts the isolation principle that defines blue/green deployment.

• ✓

  Swap the CNAMEs of the two environments.

  Why this is correct

  Elastic Beanstalk assigns each environment a CNAME (e.g., myapp-env.eba-123.us-east-1.elasticbeanstalk.com), and the 'Swap environment CNAMEs' action atomically exchanges the DNS names of the blue and green environments. This makes the new environment assume the old environment's URL, instantly redirecting all traffic to the green stack with zero downtime. It is the core traffic-shifting mechanism for blue/green on Elastic Beanstalk, and you can roll back by swapping the CNAMEs again.

• ✓

  Terminate the old environment after verifying the new environment.

  Why this is correct

  Terminating the old environment is the final cleanup step in a blue/green deployment, executed only after the new environment has passed health checks and business verification. This releases the compute resources and associated Elastic Beanstalk resources of the blue environment, but it must be done after the CNAME swap so the old environment no longer receives traffic. Skipping it would leave you paying for idle infrastructure and potentially running duplicate resource-consuming services.

• ✗

  Update the Route 53 DNS record to point to the new environment.

  Why it's wrong here

  Elastic Beanstalk's blue/green flow uses the platform-managed CNAME swap to reroute traffic, so manually changing a Route 53 record is unnecessary and actually bypasses the environment's built-in URL mechanism. If you are using a custom domain, the recommended practice is to point that domain as an alias or CNAME to the Elastic Beanstalk environment URL, which remains the same during the swap because the CNAME is swapped on the managed domain. Manual Route 53 edits introduce extra DNS propagation delay and human error, and they do not update the environment's own endpoint that EB health monitoring relies on.

• ✓

  Deploy the new application version to a separate Elastic Beanstalk environment.

  Why this is correct

  Creating a separate Elastic Beanstalk environment and deploying the new application version to it establishes the 'green' stack that will eventually serve production traffic. This second environment operates in parallel with the original, running its own instances, load balancer, and autoscaling group, so your existing environment remains completely unaffected. It gives you a full staging platform to run smoke tests and performance checks before any traffic is redirected.

Go deeper

Related to this question