AWS DevOps Engineer Professional Practice Test

In Elastic Beanstalk, why might more application versions remain after a new version is uploaded despite having a policy to keep only the last 3 versions?

1. The versions are not tagged.

2. The versions are still in use or were recently used by environments that were terminated.

3. The versions are corrupted.

4. The versions are on a different region.

The correct answer is: The versions are still in use or were recently used by environments that were terminated.

When a new application version is uploaded to Elastic Beanstalk, the service is designed to manage application versions by a defined retention policy. If the policy states that only the last three versions should be kept, one might still notice more than three versions lingering. This scenario is often due to the fact that the versions in question may still be in use or have been recently utilized by environments that are no longer active, but for which the versions remain retained temporarily. Elastic Beanstalk does not immediately delete versions that are associated with terminated environments. This retention is particularly useful because if a previously deployed application version must be reinstated quickly, it's available without needing to re-upload or recreate it. This provides a level of safety and flexibility for application management, as rolling back to a known good state swiftly can be critical for application uptime and recovery. The other options do not accurately reflect the behavior of Elastic Beanstalk. Versions are typically tagged as part of the deployment process; corruption would usually lead to failure in the deployment process; and versioning is managed per region, so being in a different region wouldn’t affect versions within the same region's application.