某公司使用 IaC 建立了兩個 EC2 實例，這些實例多年來一直未曾變更。由於業務快速成長，營運團隊引入了 Auto Scaling group，以便在流量高峰時替換實例。公司政策要求每月進行作業系統安全性更新，有時需要重新啟動。在最近一次需要重新啟動的修補後，Auto Scaling group 終止了已修補的實例，並啟動了新的、未修補的實例。解決方案架構師應建議哪些行動組合，以防止這種情況再次發生？（請選擇兩項）

自動化 AMI 的修補是最佳實踐，因為它確保所有新啟動的實例都基於最新的、已修補的映像，從根本上解決了未修補實例的問題。這透過建立一個包含最新修補程式的新 AMI，然後更新啟動組態/範本以使用此 AMI，並觸發 Auto Scaling 實例刷新來實現。 修改 Auto Scaling group 的更新策略，將最舊的啟動組態作為替換目標，可以確保在實例替換時，Auto Scaling group 優先終止基於舊啟動組態（即未修補）的實例，並啟動基於最新啟動組態（即已修補）的實例。這有助於逐步淘汰舊實例，並引入已修補的新實例，而不會終止已修補的實例。 其他選項不夠完善： 建立第二個 Auto Scaling group 並手動修補，增加了管理複雜性且未能自動化。 放置 Elastic Load Balancer 並設定健康檢查是標準做法，但它僅驗證實例是否健康，而不是解決實例被替換為未修補版本的問題。 啟用終止保護會阻止 Auto Scaling group 替換實例，這與 Auto Scaling group 的彈性設計相悖，且無法解決修補問題。