The company runs a complex customer system and consists of 10 different software components. All backed up by RDS. You adopted Opswork to simplify the management and deployment of that application and created a stack and layers for each component.

Answer options:

A.Assign a custom recipe to each layer that replaces the underlying AMI. Use OpsWorks life-cycle events to incrementally execute this custom recipe and update the instances with the new AMI.
B.Specify the latest AMI in the custom AMI at the stack level. Terminate instances of the stack and let OpsWork launch new instances with the new AMI.
C.Identify all EC2 instances of your OpsWork stack, stop each instance, replace the AMI ID property with the latest AMI ID, and restart the instance. To avoid downtime, make sure no more than one instance is stopped at the same time.
D.Create a new stack and layers with identical configuration, add instances with the latest AMI specified as a custom AMI to the new layers, switch DNS to the new stack, and tear down the old stack.
E.Add new instances with the latest AMI as a custom AMI to all OpsWork layers of your stack and terminate the old ones.

Answer - D and E
Option A is incorrect because you would have to re-launch new instances to change the AMI, and you can`t do that with chef recipes only.
Option B is incorrect because the AMI replacements should be done without incurring application downtime or capacity problems. So if you shutdown the stack, all applications will be stopped.
Option C is incorrect because the application could face the problem of insufficient capacity.
Option D is CORRECT because it represents a common practice of Blue-Green Deployment which is carried out for reducing the downtime and risk by running two identical production environments called Blue and Green. Please see the "More information.." section for additional details.
Option E is CORRECT because you can only add new instances at the layer level by specifying to use Custom AMI at the stack level.
More information on Blue-Green Deployment:
Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.
At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live, and Green is idle.
As you prepare a new version of your software, deployment and the final stage of testing takes place in an environment that is not live: in this example, Green. Once you have deployed and fully tested the software in Green, you switch the router. So all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.
This technique can eliminate downtime due to application deployment. In addition, blue-green deployment reduces risk: if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.
Please refer to the below URL for more details.
https://d0.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf