You are responsible for a web application that consists of an Elastic Load Balancer (ELB) in front of an Auto Scaling group of EC2 instances.
Before deploying a new version of the application, a new AMI was created and the Auto Scaling Group was updated with a new launch configuration that refers to this new AMI.
During the deployment, you received complaints from users that the website was responding with errors.
All instances passed the ELB health checks.
What should you do in order to avoid errors for future deployments? (Choose 2 answers)
Click on the arrows to vote for the correct answer
A. B. C. D. E.Answers - C & D.
In this scenario, the ELB health check was passed which implies that the instances were successfully deployed using the new AMIs by the launch configuration and Auto Scaling group.
The deployment was successful, but as the users started using the application, they started receiving the error.
So, it implies that the errors are related to the application itself, not the setup.
Option A is incorrect because setting the short period of health check will not be useful in this scenario.
Option B is incorrect because you cannot change the launch configuration based on the CloudWatch alert.
Option C is CORRECT because the current health check might be just checking if the application/website is reachable or not.
i.e.
It may not be currently checking whether the application is fully functioning.
If the health check is configured to test the application fully, it will stop deploying the instances with the faulty application.
Option D is CORRECT because doubling the Auto Scaling size will give some lead time for instances to become healthy before the old instances get terminated (kind of Blue/Green Deployment).
Option E is incorrect because increasing the unhealthy threshold will not help this scenario since it does not prevent unhealthy instances from being deployed.
In this scenario, the Auto Scaling group was updated with a new launch configuration that refers to a new AMI, but users are experiencing errors during deployment. All instances have passed the Elastic Load Balancer health checks. To prevent such errors from happening during future deployments, we should take the following steps:
A. Add an Elastic Load Balancing health check to the Auto Scaling group. Set a short period for the health checks to operate as soon as possible to prevent premature registration of the instance to the load balancer.
Adding an Elastic Load Balancing (ELB) health check to the Auto Scaling group can help ensure that instances that are not ready to serve traffic are not added to the ELB. By setting a short period for the health checks to operate as soon as possible, we can prevent premature registration of the instance to the load balancer. This way, we can avoid adding instances that are still initializing or not fully functional to the load balancer and causing errors for users.
C. Set the Elastic Load Balancing health check that fully tests application health and returns an error if the tests fail.
The Elastic Load Balancer health check should fully test the application health to ensure that instances that are not fully functional are not added to the load balancer. If the tests fail, the health check should return an error to prevent the instance from serving traffic. By doing so, we can avoid adding instances that are not fully functional or have issues to the load balancer and causing errors for users.
Note: Options B, D, and E are incorrect for this scenario.
B. Enable EC2 instance CloudWatch alerts to change the launch configuration AMI to the previous one. Gradually terminate instances that are using the new AMI.
This option does not address the root cause of the issue, which is why users are experiencing errors during deployment. It also involves changing the launch configuration AMI to the previous one and gradually terminating instances that are using the new AMI, which may cause service disruptions and downtime for users.
D. Create a new launch configuration that refers to the new AMI, and associate it with the Auto Scaling group. Double the size of the Auto Scaling group, wait for the new instances to become healthy, and reduce back to the original size. If new instances do not become healthy, associate the previous launch configuration.
This option involves creating a new launch configuration that refers to the new AMI and doubling the size of the Auto Scaling group. While waiting for the new instances to become healthy, the original size of the Auto Scaling group should be reduced. If the new instances do not become healthy, the previous launch configuration should be associated. This approach is not recommended as it involves creating unnecessary instances and may cause service disruptions and downtime for users.
E. Increase the Elastic Load Balancing Unhealthy Threshold to a higher value to prevent an unhealthy instance from going into service behind the load balancer.
Increasing the Elastic Load Balancer Unhealthy Threshold to a higher value is not recommended as it may cause instances that are not fully functional or have issues to serve traffic, resulting in errors for users. Instead, we should focus on improving the Elastic Load Balancer health check to ensure that instances that are not fully functional are not added to the load balancer.