# 1. Ansible Inventory 动态发现与分组策略，如何管理大规模节点 A Inventory 只能静态维护 B 大规模节点不需分组 C 用动态 inventory 插件自动拉取节点，按环境/角色分组并用并发与分批管理大规模节点 ✓ 正确答案 D 动态 inventory 无法自动发现新节点
# 2. Ansible Module 开发自定义扩展的边界与测试策略 A 任何任务都应写自定义模块 B 自定义模块无需幂等 C 仅在内置模块无法覆盖时自定义，遵循 JSON 输出、check_mode 与幂等规范，用 ansible-test 测试 ✓ 正确答案 D 模块无需测试
# 3. Ansible Playbook 的幂等性设计原则，如何确保多次执行结果一致 A command 模块天然幂等 B 幂等性无关紧要 C 优先用幂等模块，非幂等命令用 register/when 与 changed_when 控制，并用 check mode 验证多次执行结果一致 ✓ 正确答案 D 每次执行都 changed 是正常的
# 4. Ansible Role 的最佳实践，如何组织可复用的配置代码 A 按职责单一组织 Role，规范目录与变量、用 Galaxy/requirements 管理复用并版本化 ✓ 正确答案 B 所有配置写在一个大 Playbook C Role 无需版本化 D 敏感变量可直接放 defaults
# 5. Ansible Tower/AWX 的企业级特性与多租户治理 A Tower/AWX 提供作业模板、调度、RBAC、审计，用组织/团队/权限隔离实现多租户治理 ✓ 正确答案 B AWX 只是命令行工具 C 多租户无需权限隔离 D Tower 无法与 CI/CD 集成
# 6. Ansible Vault 加密敏感数据的工程实践与密钥轮换 A 敏感数据可直接明文写入 B 用 ansible-vault 加密敏感数据，集中管理密钥并定期 rekey 轮换，CI 中密钥安全注入 ✓ 正确答案 C vault 密钥无需轮换 D vault 密码可明文放仓库
# 7. Ansible facts 收集的性能开销与 fact caching（redis/jsonfile）在大规模节点下的优化 A 用 fact caching（redis/jsonfile）复用 facts 并按需收集子集，减少大规模节点下的重复收集开销 ✓ 正确答案 B facts 收集无性能开销 C redis 缓存只适合单机 D 大规模节点无需缓存 facts
# 8. Ansible 性能优化中 forks、pipelining、async 与策略调优 A 用提高 forks、开启 pipelining、耗时任务 async 与合适的执行策略（free）配合，提升大规模节点执行效率 ✓ 正确答案 B forks 越大越好无需考虑资源 C pipelining 会降低性能 D async 无法用于耗时任务
# 9. Ansible handlers 与 notify 的触发机制、changed_when 配合与常见陷阱（多次触发、依赖顺序） A handler 在 Play 末尾、仅 changed 时执行且同一 handler 只执行一次，用 changed_when 控制触发、flush_handlers 处理顺序 ✓ 正确答案 B handler 每次 notify 都执行一次 C handler 在执行任务时立即运行 D changed_when 与 handler 无关
# 10. Ansible 与 Puppet/Chef/SaltStack 的选型对比 A Ansible 需要安装 agent B Ansible 无 agent、push 模式、YAML 易上手；Puppet/Chef 有 agent、pull 模式，适合长期状态管理，按架构与技能选型 ✓ 正确答案 C 所有工具都无 agent D Puppet 用 YAML 声明式
# 11. Terraform Import 与 State 操作的安全边界 A import 只接管真实资源，state 操作（rm/mv/push）需限制权限、备份并确认对齐，避免与真实资源失控 ✓ 正确答案 B state 可随意手动编辑 C state rm 会删除真实资源 D import 后无需 align 配置
# 12. Terraform Module 版本化与注册中心最佳实践 A 模块无需版本化 B 用 semver 版本化 + registry/Git 引用 + 版本约束与晋升流程，受控复用模块 ✓ 正确答案 C 模块升级无需评审 D 版本约束会破坏模块
# 13. Terraform Plan/Apply 工作流与 CI/CD 集成模式 A CI 中 plan 生成变更供评审，apply 需审批，多环境滚动执行，并用安全扫描做门禁 ✓ 正确答案 B CI 中直接 apply 即可 C plan 与 apply 无需分离 D 生产环境无需审批
# 14. Terraform Provider 自定义开发与数据源设计 A 任何情况都应自写 provider B 用 Plugin SDK/框架用 Go 实现资源 CRUD 与数据源只读，保证幂等与规范 schema ✓ 正确答案 C 数据源可以写操作 D provider 无需测试
# 15. Terraform State 管理与远程后端设计，如何解决团队协作冲突 A 各人用本地 state 即可 B 用远程后端 + 锁防并发写，拆分 state 减少冲突，并配合审批与串行化解决协作冲突 ✓ 正确答案 C 状态锁会阻止协作 D 拆分 state 无从谈起
# 16. Terraform 与 Pulumi/CDK 的选型对比与迁移路径 A Pulumi 是声明式工具 B 两者完全可以互换 C 迁移必须一次性完成 D Terraform 声明式、生态成熟，Pulumi/CDK 编程式、适合复杂逻辑，按技能与生态选型，迁移用转换工具 + 试点 ✓ 正确答案
# 17. Terraform 多环境管理中 Workspace、Directory 与 Module 策略 A 所有环境共用一个 state B Workspace 简单但隔离弱，Directory 隔离强，Module 参数化保复用，常组合使用 ✓ 正确答案 C Directory 无法复用代码 D Module 只能用于单环境
# 18. Terraform 漂移检测与自动修复的工程实践 A 用 plan 检测漂移，非期望漂移用 apply 收敛，外部管理属性用 ignore_changes，定期检测并告警 ✓ 正确答案 B 漂移无法检测 C 所有漂移都应 apply 纠正 D 漂移可能无法自动修复
# 19. Terraform 资源依赖图中隐式引用与 depends_on 显式依赖在并行 apply 中的行为差异 A 所有资源都并行执行 B 依赖图只影响删除 C depends_on 不影响执行顺序 D 隐式引用表达数据依赖自动排序，depends_on 表达逻辑依赖，无依赖资源并行执行，避免过度 depends_on ✓ 正确答案
# 20. Ansible 错误处理中 block/rescue/always 与 ignore_errors 的工程边界及何时必须失败停止 A 所有任务都应 ignore_errors B 关键失败也可忽略 C 用 block/rescue/always 结构化错误处理，ignore_errors 只用于可容忍任务，关键失败必须 fail fast ✓ 正确答案 D always 只在失败时执行
# 21. IaC 与配置管理工具的边界，即 Terraform 管资源、Ansible 管配置时两者如何协作分工？ A Terraform 应负责软件安装 B 两者职责可任意重叠 C Ansible 应创建云资源 D Terraform 管资源生命周期、Ansible 管配置软件，用传递信息串联，避免 provisioner 滥用与职责重叠 ✓ 正确答案
# 22. Terraform 使用的常见误区中滥用 provisioner、忽视 state 安全与缺乏模块化等问题如何避免？ A provisioner 是配置的首选 B 避免滥用 provisioner、忽视 state 安全与缺乏模块化，用配置管理工具、远程 state + 模块化等最佳实践规避 ✓ 正确答案 C state 无需加密 D 大 tf 文件更好维护
# 23. Terraform 在生产环境的落地案例中多环境管理、团队协作与变更审计如何组织？ A 各环境共用同一份 state B 用 Directory + Module + 独立 state 管理多环境，远程 state + PR 评审 + 审批 apply 协作，plan 留档与 state 版本化实现审计 ✓ 正确答案 C apply 无需审批 D 变更无需记录
# 24. 基础设施即代码（IaC）的核心概念与价值中声明式定义如何实现可重复、可审计的环境交付？ A 声明式 IaC 声明期望状态，由工具自动收敛实现可重复，结合代码与 plan/state 实现可审计 ✓ 正确答案 B IaC 是手工配置基础设施 C IaC 无法版本化 D 命令式与声明式完全一样
