# 1. ARM TrustZone 等可信执行环境的固件补丁如何评估与部署，与普通系统补丁有何不同？ A TEE 补丁与普通系统补丁完全一致，无特殊要求 B TEE 固件无需签名，可任意更新 C 需重点保证签名验证、信任根完整性与防降级回滚，更强调安全边界保护 ✓ 正确答案 D 回滚无需考虑安全，可随意降级
# 2. L1TF 漏洞的修复措施有哪些（微码、L1D 清空、超线程策略），如何评估与取舍？ A 关闭 SMT 是零代价的默认方案 B L1D 清空只影响虚拟化，无需关心性能 C 更新微码、启用 L1D 清空是基础缓解，关闭 SMT 更彻底但代价最高，需按威胁与性能取舍 ✓ 正确答案 D 微码更新即可彻底消除 L1TF，无需其他措施
# 3. LogoFAIL 类 UEFI 解析漏洞的修复流程，即固件更新评估、安全启动验证与回滚方案？ A 应评估兼容性、带外更新、验证安全启动并预留防降级回滚方案 ✓ 正确答案 B 回滚到无修复版本是安全的，无需限制 C 固件更新后无需开启安全启动 D 直接覆盖固件即可，无需验证与回滚
# 4. ZombieLoad 等 MDS 类漏洞如何修复，即微码更新、内核缓解参数与超线程（SMT）关闭如何权衡？ A 关闭 SMT 是默认且无性能损失的选择 B 内核缓解参数与 SMT 无关，可任意组合 C 微码更新后即可完全消除 MDS 风险，无需内核参数 D 常以微码+内核缓解参数为默认，高敏感/高密度环境再评估关闭 SMT，按威胁与性能取舍 ✓ 正确答案
# 5. 如何建立 CPU 微码漏洞（Meltdown/Spectre/MDS 等）的补丁台账与统一评估流程？ A 应建立含 CPU 型号、微码版本、CVE、缓解措施与部署状态的统一台账，并统一评估、分级部署 ✓ 正确答案 B 台账只需记录 CVE 编号即可 C 各团队可独立处理，无需统一台账 D 微码漏洞无需回溯复测，可一次部署完成
# 6. 如何评估并灰度发布 Meltdown 类 CPU 微码/内核补丁？ A 可直接在生产全量部署，无需测试与灰度 B 性能影响可忽略，无需评估 C 灰度发布后无需回滚预案 D 应先建性能基线、测试验证，再小批灰度、逐步放量并保留回滚预案 ✓ 正确答案
# 7. 针对 SSBD 等投机执行漏洞，如何评估并启用 CPU 微码与内核缓解措施？ A 应确认内核能力、安装微码并启用内核参数，验证生效并权衡性能影响后按需部署 ✓ 正确答案 B 启用 SSBD 无任何性能开销，可全局启用 C 只需启用微码，无需内核参数 D 投机执行漏洞缓解无需验证是否生效
# 8. DCIM 与带外管理（BMC）如何支撑服务器固件版本台账与批量更新？ A BMC 提供带外管理能力，DCIM 统一采集台账并按批次下发固件，实现远程批量更新 ✓ 正确答案 B 带外更新必须依赖操作系统在线 C BMC 只能查询，无法参与批量更新 D 固件台账无需统一，各服务器独立记录即可
# 9. UEFI 固件补丁的常规部署流程，即版本核对、带外更新通道与安全启动验证？ A 版本核对与安全启动验证可有可无 B 更新成功后无需任何验证 C 应核对版本、通过带外通道更新、启用安全启动验证并预留回滚预案 ✓ 正确答案 D 固件更新只能依赖操作系统在线完成
# 10. Windows 补丁管理（WSUS/Intune）与变更窗口 A WSUS 与 Intune 都只能全量推送，无法分批 B WSUS 适合本地/内网，Intune 适合云端设备，二者均按组审批、分批灰度并安排变更窗口 ✓ 正确答案 C 补丁可随时推送，无需变更窗口 D 补丁推送无需先测试验证
# 11. Zenbleed 等 AMD CPU 漏洞的修复选项（微码更新与软件缓解）如何选择与验证？ A 软件缓解是根因修复，无需微码 B Zenbleed 只影响 Intel CPU C 修复后无需验证微码版本 D 通常优先微码更新根因修复，软件缓解作临时过渡，并验证生效与性能影响 ✓ 正确答案
# 12. kernel livepatch 的实现原理与使用限制，即哪些修复可热补丁、哪些必须重启？ A livepatch 可处理任何内核修改，包括数据结构变更 B livepatch 通过函数级替换实现热修复，涉及结构布局/接口变更则必须重启，属临时缓解手段 ✓ 正确答案 C 应用 livepatch 后无需再做常规内核更新 D livepatch 无需依赖 ftrace 等机制
# 13. retpoline 如何缓解 Spectre v2 的间接分支预测攻击，其编译替换方式与性能影响是什么？ A retpoline 完全消除性能影响，可直接替代所有缓解 B retpoline 通过返回栈预测替代被污染的 BTB 间接跳转，阻断投机执行，有一定性能开销 ✓ 正确答案 C retpoline 只影响 Intel CPU，对内核无影响 D retpoline 是硬件修复，无需编译配合
# 14. 内核/固件升级后的性能回退验证与排障 A 无需升级前基线，升级后看感觉即可 B 性能回退一定是升级故障，直接回滚即可 C 应建立升级前基线、同条件复测对比、分层定位根因并保留回滚预案 ✓ 正确答案 D 性能验证无需对比基准与负载
# 15. 补丁分发基础设施如何设计，即本地补丁源/镜像如何支撑大规模批量安装并降低带宽压力？ A 应建立本地镜像源、分层就近分发、错峰限速并配合校验重试，以降低带宽与保障可靠 ✓ 正确答案 B 大规模分发无需控制并发与带宽 C 客户端都从公网拉取补丁，带宽可控 D 补丁完整性校验可有可无
# 16. 补丁合规率统计与例外豁免流程 A 合规率无需区分资产类别，统一口径即可 B 豁免后无需任何补偿措施或复核 C 例外豁免需明确原因、补偿控制与期限，经审批并到期复核，纳入残余风险跟踪 ✓ 正确答案 D 例外申请无需审批，可随意豁免
# 17. 补丁测试与灰度发布中测试环境验证、分批灰度、回滚预案与失败止损如何设计 A 应测试验证、小批灰度、设指标止损阈值并准备回滚预案，控制部署风险 ✓ 正确答案 B 测试通过后可直接全量部署，无需分批 C 灰度失败无需止损，继续放量即可 D 回滚预案只对固件重要，普通补丁无需回滚
# 18. 补丁管理中的资产可见性（CMDB 与漏洞扫描联动） A 资产清单与扫描结果无需关联，各自独立即可 B 新发现的资产无需回灌 CMDB C 补丁部署后无需更新 CMDB 字段 D 以 CMDB 为资产源，与漏洞扫描双向同步，以唯一标识关联，保证补丁覆盖无盲区 ✓ 正确答案
# 19. 零日漏洞（0-day）的紧急补丁响应流程 A 应情报监测、盘点资产、先临时缓解阻断、补丁发布后快速根治并验证复盘 ✓ 正确答案 B 临时缓解会掩盖漏洞，应避免使用 C 0-day 响应可与常规补丁同等节奏 D 0-day 只需等待官方补丁，无需临时缓解
# 20. PDU 等带外硬件固件补丁如何规划，即维护窗口、冗余切换与中断风险评估？ A 可随时更新，无需考虑窗口与冗余 B 带外硬件无需冗余，更新失败无影响 C 应选低峰窗口、通过冗余切换减少影响、评估中断风险并准备恢复预案 ✓ 正确答案 D 中断风险评估多余，直接更新即可
# 21. 如何针对不同类型资产（操作系统、中间件、固件）制定差异化的补丁策略与变更窗口？ A 所有资产应采用相同补丁节奏与窗口 B 固件更新最频繁，应优先处理 C 中间件补丁无需兼容性测试 D 应按资产类型（OS/中间件/固件）差异化设定节奏、窗口与风险评估，并统一台账与灰度回滚 ✓ 正确答案
# 22. 补丁管理与漏洞管理、配置管理、版本升级之间的边界与差异是什么？ A 补丁是局部安全修复、漏洞是缺口全过程、配置是基线一致性、升级是整体版本变更，互为补充 ✓ 正确答案 B 配置管理与补丁完全无关 C 版本升级不涉及安全，无需变更管理 D 四者目标相同，可互相替代
# 23. 补丁管理的常见误区有哪些（只补操作系统、跳过测试直接全量、缺少回滚预案），正确做法是什么？ A 正确做法是覆盖全资产、先测试、分批灰度、留回滚预案并与漏洞管理闭环 ✓ 正确答案 B 只补操作系统已足够，无需覆盖中间件与固件 C 跳过测试直接全量部署是最快的方式 D 补丁失败无需回滚，重启即可
# 24. 补丁管理的核心概念（补丁来源、基线、变更窗口、合规状态）是什么，适用哪些场景？ A 补丁基线仅用于记录补丁下载历史，与合规无关 B 补丁来源、基线、变更窗口、合规状态共同构成补丁管理框架，支撑合规与运维 ✓ 正确答案 C 变更窗口只影响测试，与生产无关 D 补丁来源可随意，无需可靠验证
