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.

• ✓

  Use blue/green deployment with an immutable infrastructure.

  Why this is correct

  Blue/green deployment with immutable infrastructure creates an entirely new, identical environment (green) with the updated application version, leaving the existing production environment (blue) untouched. Once the green environment passes all health checks and tests, traffic is atomically shifted from blue to green. This strategy ensures zero downtime during deployment and provides an instant rollback capability by simply reverting traffic back to the healthy, unchanged blue environment if any issues arise with the new version.

• ✗

  Use all-at-once deployment to the Auto Scaling group.

  Why it's wrong here

  An all-at-once deployment replaces every instance in the Auto Scaling group simultaneously with the new application version. For an e-commerce platform, this approach introduces significant risk of service disruption and downtime, as all instances are unavailable during the update process until the new instances are provisioned, initialized, and pass health checks. There is no immediate fallback mechanism other than a full redeployment if the new version fails.

• ✗

  Use canary deployment shifting 10% traffic for 5 minutes.

  Why it's wrong here

  Canary deployment gradually shifts a small percentage of traffic (e.g., 10%) to the new application version, allowing for real-world testing with minimal user impact. While this helps detect issues early, the specified 5-minute shift is a testing period, not an instant rollback mechanism. If issues are detected, a rollback would still require manual intervention to stop the traffic shift and potentially redeploy the previous version, which is not as immediate or automated as blue/green's traffic switch.

• ✗

  Use in-place rolling update with a batch size of 50%.

  Why it's wrong here

  An in-place rolling update replaces instances in batches (e.g., 50% at a time) within the existing Auto Scaling group. This approach can lead to a mixed environment where old and new versions run concurrently, complicating troubleshooting. Furthermore, if the new version introduces critical issues, rolling back requires deploying the *previous* version to the remaining instances, which is a time-consuming redeployment process rather than an immediate, single-action traffic switch.

Go deeper

Related to this question