Q64 — AWS SAA-C03 第17章

第 64/89 题 | ← 返回第17章

Q1364. 一家公司在 AWS 上托管了数十个多层应用程序。表示层和逻辑层由使用 Amazon EBS 卷的 Amazon EC2 Linux 实例组成。该公司需要一种解决方案，以确保在部署新功能时不会将操作系统漏洞引入 EC2 实例。该公司使用自定义 AMI 在自动扩展组中部署 EC2 实例。该解决方案必须能够扩展以处理公司托管的所有应用程序。哪种解决方案能够满足这些要求?

• A. 使用 Amazon Inspector 修补操作系统漏洞。在部署新的 AMI 时调用 Amazon Inspector。
• B. 使用 AWS Backup 备份每个已更新实例的 EBS 卷。使用 EBS 备份卷创建新的 AMI。使用现有的 Auto Scaling 组部署新的 AMI。
• C. 使用 AWS Systems Manager Patch Manager 修补自定义 AMI 中的操作系统漏洞。
• D. 当公司部署新功能时，使用 EC2 Image Builder 创建新的 AMI。将 update-linux 组件包含在新 AMI 的构建组件中。使用现有的自动扩展组部署新的 AMI。 ✓

正确答案: D. 当公司部署新功能时，使用 EC2 Image Builder 创建新的 AMI。将 update-linux 组件包含在新 AMI 的构建组件中。使用现有的自动扩展组部署新的 AMI。

解析

正确答案是 D。当公司部署新功能时，请使用 EC2 Image Builder 创建新的 AMI。将 update-linux 组件包含在新 AMI 的构建组件中。使用现有的自动扩展组来部署新的 AMI。解释:该公司需要一个可扩展、自动化且安全的解决方案来:防止通过自定义 AMI 部署的 EC2 实例出现操作系统漏洞。确保所有多层应用程序的一致性。与自动扩展组集成，实现无缝部署。为什么选项 D 是最佳选择:EC2 镜像构建器自动化 AMI 创建，确保所有实例均基于安全、标准化的镜像构建。包含 update-linux 组件，可在 AMI 构建过程中自动应用操作系统补丁和安全更新。可扩展性强，无需人工干预即可处理数十个应用程序。与自动扩展功能集成，可通过现有的自动扩展组自动部署新的 AMI。防止部署时出现漏洞通过将安全更新嵌入到 AMI 中，实例从启动时就安全无虞（不像部署后打补丁那样）。与修补正在运行的实例（这些实例可能已被攻破）相比，这可以减少攻击面。其他选项为何错误:A. 使用 Amazon Inspector 修复漏洞检查器仅检测漏洞，不进行修补。部署后扫描:实例可能在扫描和修补之前仍存在漏洞（风险窗口）。无 AMI 自动化:无法确保未来部署的安全性。B. 使用 AWS Backup + EBS 快照进行 AMI 备份备份不包含安全更新。从备份恢复可能会重新引入漏洞。手动从备份创建 AMI 的过程容易出错且不具备可扩展性。缺乏主动安全措施，依赖于被动备份而非预防性补丁。C. 在自定义 AMI 上使用 AWS Systems Manager Patch Manager补丁管理器会将更新应用于正在运行的实例，但不会更新 AMI 本身。实例可能仍然会使用旧的、存在漏洞的 AMI 启动，在补丁管理器运行之前，安全漏洞始终存在。对于数十个应用程序来说，这种方式不具备可扩展性，并且需要对每个实例进行手动或定时修补。对比表:选项:防止 AMI 创建过程中出现漏洞?自动化且可扩展?与自动扩展集成?最适合D（更新已集成到 AMI 中）（EC2 镜像构建器）（无缝部署）大规模主动安全 A（仅检测，不打补丁）（手动后扫描）（对 AMI 无影响）漏洞扫描（非预防） B（备份不打补丁）（手动创建 AMI）（无直接集成）灾难恢复（非安全） C（仅修补运行中的实例）（按实例打补丁）（AMI 仍然存在漏洞）部署后打补丁（被动）结论:方案 D 是最安全、可扩展且自动化程度最高的解决方案，因为:EC2 镜像构建器确保 AMI 在启动时已预先打好补丁，不存在任何漏洞实例。update-linux 组件可自动更新操作系统，减少人为错误。它与自动扩展功能兼容，不会对现有部署造成任何中断。避免选择 A、B 和 C（它们要么无法防止漏洞，要么不具备可扩展性）。最终答案:D