Updating ELB Health Check Timer

Correct Answer - C.

Infrastructure as Code is a key concept for AWS DevOps professional exam according to the exam blueprint in https://d1.awsstatic.com/training-and-certification/docs-devops-pro/AWS%20Certified%20DevOps%20Engineer%20Professional_Exam%20Guide_v1.5_FINAL%20(2).pdf.

Besides, Infrastructure as Code itself has become a best practice for automating the provisioning of infrastructure services in AWS.

Option A is incorrect: Because the stack does not need to be deleted since the changes can be deployed by updating the stack using a new template.

Option B is incorrect: If the template is only updated with the new ELB health check timer, the stack drift will be lost since it was first created.

Option C is CORRECT: Because “Detect drift” is appropriate for understanding the changes for the resources in the stack.

Then all changes are recorded and version-controlled in the CodeCommit repo, which is a best practice for Infrastructure as Code.

Option D is incorrect: Although the usage of Change Set is a best practice, it does not mention saving the template changes to CodeCommit.

As a result, the modification is not tracked as code and may get lost.

Option C is more accurate than Option.

D.

Option B is the correct answer: Modify the template with the new Elastic Load Balancer health check timer. Update the stack using the new template. Submit the new template to the CodeCommit repository.

Here is a detailed explanation of why this option is the correct choice:

The Elastic Load Balancer (ELB) health check timer needs to be updated, which is part of the CloudFormation stack created one year ago. However, there is no information available to record the modifications done to the stack since its creation. As a result, we need to take the following steps:

1. Identify the current configuration: Before making any changes, it's important to identify the current configuration of the ELB and Auto Scaling group that are created using the CloudFormation stack. This will help in understanding the impact of any changes that are made.

2. Modify the CloudFormation template: Once the current configuration is identified, we need to modify the CloudFormation template with the new ELB health check timer. The modified template should be tested locally to ensure that it works as expected.

3. Update the CloudFormation stack: After modifying the CloudFormation template, we need to update the existing CloudFormation stack with the new template. This will apply the changes to the ELB and Auto Scaling group.

4. Submit the new template to the CodeCommit repository: Once the CloudFormation stack is updated, we need to submit the modified CloudFormation template to the CodeCommit repository. This will help in tracking the changes that were made to the stack.

Option A is incorrect because it suggests deleting the entire CloudFormation stack and rewriting the template from scratch. This is not necessary and would result in the loss of all the modifications made to the stack since its creation.

Option C is also incorrect because it suggests using the "Detect drift" feature to understand the changes made to the stack since its creation. While this feature can be useful, it's not necessary in this scenario as we already know that modifications have been made to the stack.

Option D is partially correct, but it misses the step of submitting the modified CloudFormation template to the CodeCommit repository. This is an important step as it helps in tracking the changes made to the stack. Additionally, creating a Change Set is optional but can provide an additional layer of safety when making changes to the stack.