一家公司使用 IaC 创建了两个 EC2 实例，这些实例多年来一直未曾更改。由于业务快速增长，运维团队引入了一个 Auto Scaling 组，该组在高峰期会替换实例。公司政策要求每月进行操作系统安全更新，有时需要重启。在最近一次需要重启的补丁更新后，Auto Scaling 组终止了已打补丁的实例，并启动了新的、未打补丁的实例。解决方案架构师应建议采取哪种组合措施来防止这种情况再次发生？（选择两项。）

自动化 AMI 的修补并使用实例刷新是最佳实践。通过创建包含最新补丁的 AMI，并更新启动配置以使用此 AMI，可以确保所有新启动的实例都是已打补丁的。实例刷新会逐步替换旧实例，从而保持服务可用性。 修改 Auto Scaling 组的更新策略，将其设置为以最旧的启动配置作为替换目标，可以确保在实例刷新过程中，Auto Scaling 组会优先替换使用旧启动配置的实例。这与自动化 AMI 修补和实例刷新结合使用，能够确保所有实例最终都更新到最新的、已打补丁的 AMI。 在 Auto Scaling 组前面放置 ELB 并启用终止保护是无效的，因为终止保护会阻止 Auto Scaling 组替换实例，这与弹性伸缩和实例更新的目的相悖。创建第二个 Auto Scaling 组并手动修补效率低下且容易出错。将 ELB 放置在 Auto Scaling 组前面并配置健康检查是标准做法，但它不能解决实例被替换后未打补丁的问题。