DOP-C02 · Question #180
A company builds an application that uses an Application Load Balancer in front of Amazon EC2 instances that are in an Auto Scaling group. The application is stateless. The Auto Scaling group uses a…
The correct answer is A. Create a new launch template that uses the new AMI. B. Update the Auto Scaling group to use the new launch template. E. Create a new AMI from a running EC2 instance in the Auto Scaling group. Explanation Since the original AMI was deleted but the Auto Scaling group still has running EC2 instances (launched before the deletion), the recovery path is to create a new AMI from one of those existing running instances (E), then create a new launch template referencing…
Question
A company builds an application that uses an Application Load Balancer in front of Amazon EC2 instances that are in an Auto Scaling group. The application is stateless. The Auto Scaling group uses a custom AMI that is fully prebuilt. The EC2 instances do not have a custom bootstrapping process. The AMI that the Auto Scaling group uses was recently deleted. The Auto Scaling group's scaling activities show failures because the AMI ID does not exist. Which combination of steps should a DevOps engineer take to meet these requirements? (Choose three.)
Options
- ACreate a new launch template that uses the new AMI.
- BUpdate the Auto Scaling group to use the new launch template.
- CReduce the Auto Scaling group's desired capacity to 0.
- DIncrease the Auto Scaling group's desired capacity by 1.
- ECreate a new AMI from a running EC2 instance in the Auto Scaling group.
- FCreate a new AMI by copying the most recent public AMI of the operating system that the EC2
How the community answered
(41 responses)- A71% (29)
- C5% (2)
- D15% (6)
- F10% (4)
Explanation
Explanation
Since the original AMI was deleted but the Auto Scaling group still has running EC2 instances (launched before the deletion), the recovery path is to create a new AMI from one of those existing running instances (E), then create a new launch template referencing that new AMI (A), and finally update the Auto Scaling group to use that new launch template (B). This preserves the original, fully prebuilt configuration without needing to rebuild from scratch, which is critical since the application uses a custom AMI with no bootstrapping process.
- C (Reduce desired capacity to 0) is wrong because terminating all running instances would destroy the only remaining source from which a new AMI can be captured, leaving no recovery path.
- D (Increase desired capacity by 1) is wrong because the broken AMI reference is still in place at that point-adding capacity would simply trigger another failure.
- F (Copy the public OS AMI) is wrong because a generic public AMI won't contain the custom, prebuilt configuration the application requires; it would take significant work to recreate the original state.
Memory Tip: Think "Save → Reference → Apply" - Save what you have (create AMI from running instance), Reference it (new launch template), Apply it (update Auto Scaling group). Always preserve what's running before making changes!
Topics
Community Discussion
No community discussion yet for this question.