Explanation:
The deployment was either run with immutable updates or in traffic splitting mode - Immutable deployments perform an immutable update to launch a full set of new instances running the new version of the application in a separate Auto Scaling group, alongside the instances running the old version. Immutable deployments can prevent issues caused by partially completed rolling deployments.
Traffic-splitting deployments let you perform canary testing as part of your application deployment. In a traffic-splitting deployment, Elastic Beanstalk launches a full set of new instances just like during an immutable deployment. It then forwards a specified percentage of incoming client traffic to the new application version for a specified evaluation period.
Some policies replace all instances during the deployment or update. This causes all accumulated Amazon EC2 burst balances to be lost. It happens in the following cases:
Managed platform updates with instance replacement enabled Immutable updates Deployments with immutable updates or traffic splitting enabled
Ultimate access to all questions.
No comments yet.
During a test deployment in an AWS Elastic Beanstalk environment, a developer observed that the accumulated burst balances for Amazon EC2 instances had been reset to zero.
What could be the potential reasons for this occurrence?
A
The deployment was either run with immutable updates or in traffic splitting mode
B
The deployment was run as a Rolling deployment, resulting in the resetting of EC2 burst balances
C
When a canary deployment fails, it resets the EC2 burst balances to zero
D
The deployment was run as a All-at-once deployment, flushing all the accumulated EC2 burst balances