Your company has a set of EC2 instances sitting behind an Elastic Load Balancer.
There is a requirement to create an OpsWorks stack to host the newer version of this application.
The OpsWorks stack has been created and the current ELB was selected to host the newer version of the application.
Now the application is not responding to the requests.
What could be the cause?
Click on the arrows to vote for the correct answer
A. B. C. D.Answer - C.
The AWS Documentation mentions the following.
If you choose to use an existing Elastic Load Balancing load balancer, you should first confirm that it is not being used for other purposes and has no attached instances.
After the load balancer is attached to the layer, OpsWorks removes any existing instances and configures the load balancer to handle only the layer's instances.
Although it is technically possible to use the Elastic Load Balancing console or API to modify a load balancer's configuration after attaching it to a layer, you should not do so; the changes will not be permanent.
For more information on OpsWorks ELB layers, please visit the below URL:
http://docs.aws.amazon.com/opsworks/latest/userguide/layers-elb.htmlThe issue described in the question is that the application is not responding to requests after an OpsWorks stack has been created and the Elastic Load Balancer (ELB) was selected to host the newer version of the application. The possible causes of this issue are:
A. The OpsWorks stack is utilizing the instances of the current application after the ELB was attached to it. This is not a likely cause of the issue because an OpsWorks stack is a separate entity from the current application and would not automatically use the instances of the current application unless explicitly configured to do so.
B. The OpsWorks stack is configured to deploy the instances of the new version of the application in the same domain as that of the old instances. This is a possible cause of the issue. If the OpsWorks stack is configured to use the same domain as the current application, the ELB may still be routing traffic to the old instances, which would result in the application not responding to requests.
C. The ELB has de-registered the instances of the current application after it was attached to the OpsWorks stack. This is a likely cause of the issue. When an ELB is attached to an OpsWorks stack, the ELB will automatically de-register any instances that are not part of the OpsWorks stack. If the instances of the current application were not included in the OpsWorks stack, they would have been de-registered from the ELB and would not be able to respond to requests.
D. The OpsWorks web layer is utilizing the instances of the current application after the ELB was attached to the OpsWorks layer. This is not a likely cause of the issue because the OpsWorks web layer is a separate entity from the current application and would not automatically use the instances of the current application unless explicitly configured to do so.
In summary, the most likely cause of the issue is that the ELB has de-registered the instances of the current application after it was attached to the OpsWorks stack. Another possible cause is that the OpsWorks stack is configured to use the same domain as the current application.