基础设施即代码（IaC） - 面试题

#

★★★

1. IaC 安全扫描与策略即代码（tfsec/checkov/OPA conftest）

问题

如何用 IaC 安全扫描与策略即代码（tfsec/checkov/OPA conftest）保障基础设施安全？

考察点

静态扫描工具（tfsec、checkov、tflint）的作用
策略即代码（OPA conftest、checkov policy）的落地
在 CI/CD 流水线中的门禁集成

答案

IaC 安全扫描在代码进入 apply 之前拦截不安全配置，是"安全左移"的核心实践。静态扫描工具包括：tfsec（针对 Terraform 的安全扫描，检查开放端口、明文密钥、过宽权限等）、checkov（支持 Terraform/CloudFormation/K8s 等，内置大量合规检查与自定义策略）、tflint（语法与最佳实践 lint）。策略即代码（Policy as Code）用规则表达安全与合规要求：OPA（Open Policy Agent）+ conftest 用 Rego 语言对 IaC 配置做断言；checkov 也支持自定义策略。落地上，把扫描作为 CI 流水线的门禁（如 pipeline 中先跑 tfsec/checkov，失败即阻断 plan/apply），并配合策略即代码把"安全基线"（如禁止 SSH 0.0.0.0/0、必须启用加密、必须打标签）写进统一策略库，随 IaC 一起版本化、评审、审计。

解析

安全扫描的价值在于把"人工评审才能发现的问题"变成"自动拦截"。策略即代码进一步把安全要求从口头规范升级为可执行的、可审计的规则，并与 IaC 的版本化、评审流程天然契合，是规模化安全治理的关键。

示例代码

# OPA conftest 规则：禁止开放 SSH 到任意地址
package main

deny[msg] {
  input.resource.aws_security_group[_].ingress[_].cidr_blocks[_] == "0.0.0.0/0"
  input.resource.aws_security_group[_].ingress[_].from_port == 22
  msg = "SSH 不应开放到 0.0.0.0/0"
}

#

★★★

2. Terraform 工作流 init/plan/apply/destroy 与 refresh 的作用，plan 如何生成资源变更图并用于评审

问题

Terraform 工作流中 init/plan/apply/destroy/refresh 各有什么作用？plan 如何生成资源变更图并用于评审？

考察点

各命令的作用与执行顺序
plan 的变更图生成与 diff 输出
plan 用于评审与变更门禁

答案

Terraform 标准工作流为 init → plan → apply → （可选）destroy。init：初始化工作目录，下载 provider 与模块、配置 state 后端；plan：读取 state 与配置，对比生成变更计划（创建/修改/删除资源），输出 diff；apply：执行 plan 中的变更，更新 state；destroy：销毁托管资源；refresh：在 apply 前刷新 state 与真实资源同步（旧版显式，新版自动在 plan 中刷新）。plan 生成的是资源变更图（DAG），根据依赖关系决定资源创建/更新/销毁的顺序，并计算哪些资源需要先销毁（replace）或就地更新（in-place）。plan 的价值在于：一是预览变更，用于评审（团队/工具审阅，作为变更门禁）；二是评估影响面（哪些资源会重建、是否停机）；三是可用于 CI 集成，把 plan 输出作为 PR 评审依据。自动化的 apply 前必须过 plan 评审。

解析

plan 是 Terraform 安全性的核心：它把"变更提前、可审批"落到实处。理解 plan 的变更图（DAG）与 replace/in-place 的区别，才能评估变更对生产的影响并设计评审门禁。生产中常见"plan-only 进 CI，人工批准后 apply"的流程。

示例代码

terraform init            # 初始化 provider/模块/后端
terraform plan -out=plan.tfplan   # 生成变更计划
terraform plan -detailed-exitcode # 有变更时返回非 0
terraform apply plan.tfplan       # 应用计划
terraform destroy                 # 销毁资源

#

★★

3. IaC 流水线（plan 评审、apply 审批）设计

问题

IaC 流水线（plan 评审、apply 审批）如何设计？

考察点

IaC 流水线的阶段划分（lint、plan、plan 评审、apply、验收）
plan 评审与 apply 审批的门禁
环境隔离与安全（生产环境保护）

答案

IaC 流水线在 CI/CD 中实现"变更可评审、应用可审批"。典型设计：阶段一，lint/tfsec/checkov 静态检查与格式校验；阶段二，terraform init + plan，生成 plan 输出并作为 artifact 保存；阶段三，plan 评审门禁——把 plan 输出附到 PR/MR 或工单，由 reviewer 或自动化（如 plan 与上一次 diff 对比）评审，通过后才进入下一步；阶段四，apply 审批——对生产环境常配置人工审批（如 GitHub Actions 的环境审批、Jenkins 的审批节点、Terraform Cloud 的 run 审批），仅授权角色可批准；阶段五，apply 执行并做 post-apply 验证（如输出状态、资源健康检查）。对多环境，按 dev→staging→prod 逐步推进，用 workspace/目录隔离，配合 state 锁防止并发冲突。生产环境可加"变更保护"（如 prevent_destroy、审批 + 熔断）。

解析

IaC 流水线的本质是"把人为变更流程化、可审计"。plan 评审保证"看得见"，apply 审批保证"受控"，环境隔离保证"风险递进"。关键是把 plan 与 apply 分离，避免"直接 apply 无评审"的隐患。

#

★★

4. Terraform provisioner 的使用边界，即何时应避免 provisioner 而改用配置管理工具？

问题

Terraform provisioner 的使用边界是什么？何时应避免 provisioner 而改用配置管理工具？

考察点

provisioner（file/remote-exec/local-exec）的行为与局限
provisioner 的非幂等、无状态、失败难恢复问题
何时用配置管理工具（Ansible/Cloud-init/Packer）

答案

Terraform provisioner（file 上传文件、remote-exec 远程执行命令、local-exec 本地执行）用于在资源创建后做一些初始化，但它是"最后手段"。缺陷：provisioner 操作非幂等、不记录在 state 中（Terraform 不感知其副作用）、失败时难以恢复、destroy 时可能出问题，且依赖 SSH/连接，易被滥用。最佳实践：优先用配置管理工具（Ansible/Cloud-init/Packer）+ 不可变镜像（immutable image）来初始化软件配置，让 Terraform 只负责"资源与配置的声明"，把"部署内容"交给工具。当确实需要 provisioner 时（如初始化时获取一次性 token、触发刷新），应保持幂等、最小化、并考虑失败回滚。核心原则：Terraform 管资源生命周期，配置管理工具管软件与配置，二者分工。

解析

provisioner 的边界在于"是不是必需、是否幂等、能否被工具替代"。不可变基础设施理念下，用 Packer 构建镜像 + 用户数据（cloud-init）替代 provisioner 是主流；provisioner 只适合少数一次性、非幂等但有明确边界的场景。

#

★★

5. Terraform 状态的核心价值中状态文件的内容、敏感信息保护与损坏恢复如何管理

问题

Terraform 状态的核心价值是什么？状态文件的内容、敏感信息保护与损坏恢复如何管理？

考察点

state 文件的内容（资源 ID、属性、依赖、元数据）
敏感信息保护（明文密钥、加密、remote state）
state 损坏的检测与恢复

答案

Terraform 状态（state）是"资源与配置的映射"，记录每个托管资源的 ID、属性、依赖关系与元数据，是 Terraform 感知真实资源的依据。核心价值：plan 需要 state 对比当前配置与真实资源；apply 需要 state 更新资源映射；销毁依赖 state 定位资源。敏感信息保护：state 可能包含明文机密（如密码、密钥、IP），因此必须用远程 state 后端（S3/OSS）+ 加密（KMS/SSE），用 state 锁（DynamoDB）防止并发写，并限制 state 文件的访问权限（最小权限 IAM）。损坏恢复：state 损坏（如手动编辑、并发冲突、误删）会导致 plan/apply 异常，可通过备份（定期快照 state）、远程后端版本化管理、terraform state 子命令（mv/rm/pull/push）修复索引，必要时用 terraform import 重新导入真实资源重建 state。最佳实践是"永不手动编辑 state"。

解析

state 是 Terraform 的"真相"，其价值与风险并存。保护 state 的三件事：加密（远程后端）、加锁（防并发）、备份（防损坏）。恢复能力才是关键——损坏后能通过 import/备份重建，而不是依赖本地文件。

#

★★

6. lifecycle 元参数（create_before_destroy/prevent_destroy/ignore_changes）在资源更新与删除保护中的应用

问题

Terraform lifecycle 元参数（create_before_destroy/prevent_destroy/ignore_changes）在资源更新与删除保护中如何应用？

考察点

create_before_destroy 的先建后删
prevent_destroy 的删除保护
ignore_changes 的忽略属性变更

答案

lifecycle 元参数控制资源更新与销毁的行为。create_before_destroy：当资源需要替换（replace）时，先创建新资源、成功后再销毁旧资源，避免替换期间的停机，适合不能中断的资源（如数据库、负载均衡）；注意它会在替换期间短暂存在新旧两套资源，需考虑资源命名冲突与依赖。prevent_destroy：对资源设置删除保护，apply 时若计划销毁该资源则报错，防止误删重要资源（如生产数据库、存储桶），常用于需要强制保护的对象。ignore_changes：忽略指定属性的外部变更（如标签被外部工具自动更新、实例的类型被自动伸缩改动），避免 Terraform 每次 apply 都试图"纠正"这些由外部修改的属性，防止漂移与计划噪声。三者需按场景组合：核心资源用 prevent_destroy 保护，需平滑替换用 create_before_destroy，属性被外部管理用 ignore_changes。

解析

lifecycle 是 Terraform 对"变更安全"的精细控制。理解 apply 的"就地更新 vs 替换"是前提：可替换的资源配合 create_before_destroy 保可用性，珍贵资源用 prevent_destroy 防误删，外部托管的属性用 ignore_changes 避免无谓变更。

示例代码

resource "aws_db_instance" "db" {
  lifecycle {
    create_before_destroy = true
    prevent_destroy       = true
  }
}

resource "aws_launch_template" "web" {
  lifecycle {
    ignore_changes = [image_id, tags]
  }
}

#

★★

7. state 后端选型、状态锁与漂移检测（drift）

问题

Terraform state 后端如何选型？状态锁与漂移检测（drift）如何实现？

考察点

后端选型（local/S3/OSS/Terraform Cloud）
状态锁（DynamoDB）与并发控制
漂移检测（drift）与修复

答案

state 后端选型：本地（local）不适合团队协作；远程后端（S3/OSS、Terraform Cloud/Enterprise）用于共享与持久化。S3 后端 + DynamoDB 锁是标准组合：S3 存 state（可版本化、加密），DynamoDB 提供状态锁（locking），防止多个并发 apply 同时修改 state 导致冲突。Terraform Cloud 提供托管编排、plan/apply 工作区、审批与审计。漂移检测：真实资源与 state 不一致（如被控制台手工修改、被其他工具改动）时，Terraform 的 plan 会显示差异，用 terraform plan 检测漂移；修复方式：若漂移是期望的，用 terraform apply 让配置收敛回声明；若配置需要更新，先改配置再 apply；或对不希望管理的资源用 terraform state rm 脱离管理。可用第三方工具（如 Driftctl/CloudFormation drift detection）定期做漂移扫描。最佳实践是"远程后端 + 锁 + 定期漂移检测 + 变更经 IaC"。

解析

后端选型的核心是"能否共享、能否加锁、能否加密、能否审计"。S3+DynamoDB 是性价比高的社区标准；Terraform Cloud 提供更完整的治理。漂移检测是"基础设施被旁路修改"的雷达，配合 IaC 收敛才能保持声明与真实一致。

示例代码

terraform {
  backend "s3" {
    bucket         = "my-tf-state"
    key            = "prod/network.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "tf-state-lock"  # 状态锁
  }
}

#

★★

8. 已有资源 import 与 IaC 覆盖率提升

问题

如何把已有资源 import 进 Terraform 并提升 IaC 覆盖率？

考察点

terraform import 的用法与流程
import 后配置对齐与 state 修正
IaC 覆盖率评估与治理

答案

对已存在的"手工创建"或"非 IaC 管理"的资源，用 terraform import <address> <id> 将其实时资源导入 state，使 Terraform 开始管理它。流程：先写对应的 resource 块（或最小配置），再 import 导入，然后 terraform plan 对比导入后的配置与真实资源的差异，按需修正配置使 plan 收敛（无 diff 或只含预期变更），再 apply。注意：import 只写 state，不创建资源；导入后必须保证配置与真实一致，否则 plan 会显示大量 diff。为提升 IaC 覆盖率，可结合 terraform plan -detailed-exitcode 检测未纳入管理的资源，或用第三方工具（如 Terraformer 可自动生成 import 用的配置）批量导入。治理上，设定覆盖率目标（如关键资源 100% 纳入 IaC），对例外资源登记并定期复核。

解析

import 是把"存量资产收编进 IaC"的关键，但要避免"import 后配置与真实不一致导致 plan 混乱"。正确节奏是"先 import 再对齐再 apply"，并持续用覆盖率指标驱动治理，逐步消除旁路管理。

示例代码

terraform import aws_instance.web i-0abcd1234efgh5678
terraform plan   # 对比导入资源与配置的差异
terraform apply

#

★★

9. 模块版本治理与私有 module registry

问题

Terraform 模块版本治理与私有 module registry 如何落地？

考察点

模块化的价值与版本化
私有 module registry 的搭建
模块版本约束与升级策略

答案

Terraform 模块（module）把可复用的资源集合封装为标准化单元，版本化是模块治理的核心。模块版本治理：为模块打版本（semver），在使用处用 source + version 约束（如 ~> 1.2）锁定版本，避免升级破坏；模块按版本发布、变更走 changelog 与评审。私有 module registry：企业可自建私有 registry（GitHub + Terraform Registry 兼容、HashiCorp Private Registry、Terraform Cloud 私有 registry），或在 Git 仓库中直接以 source = "git::https://...//modules/xxx?ref=v1.2.0" 引用特定 tag/commit。治理要点：模块统一命名与规范（输入输出、文档、测试）、版本晋升策略（dev→staging→prod 用同一版本）、模块所有者与评审机制、依赖扫描与兼容性验证。用模块版本化避免"各自复制代码导致漂移"。

解析

模块治理的本质是"复用 + 版本 + 变更控制"。私有 registry 或 Git 引用都能实现版本化，关键是建立发布与升级流程，让团队在受控的版本上消费模块，避免碎片化与不兼容。

示例代码

module "vpc" {
  source  = "git::https://github.com/org/terraform-modules.git//vpc?ref=v1.2.0"
  cidr_block = "10.0.0.0/16"
}

#

★★

10. 远程 state 的加密与访问控制中对象存储后端加锁（DynamoDB）与最小权限如何落地

问题

远程 state 的加密与访问控制如何落地？对象存储后端加锁（DynamoDB）与最小权限如何配置？

考察点

远程 state 的加密（KMS/SSE）
对象存储后端 + DynamoDB 锁
最小权限访问控制

答案

远程 state 存有敏感信息（资源属性、机密），必须加密并限制访问。加密：S3/OSS 开启服务端加密（SSE-S3/SSE-KMS），确保 state 静态加密；传输用 TLS；DynamoDB 锁表也可加密。访问控制：用最小权限 IAM 策略，只允许 Terraform 运行角色（而非所有用户）访问 state 桶与锁表，限定 s3:GetObject/PutObject/DeleteObject 于特定 bucket/key，dynamodb:GetItem/PutItem/DeleteItem 于锁表，并禁用公共访问。加锁：DynamoDB 作为锁表，支持并发 apply 的锁冲突检测（获取锁失败则报错，防止两个 apply 同时写 state）。落地要点：state 桶开启版本化（便于恢复）、加密、基于 tag 的权限、锁表最小权限，配合 Terraform 的 backend 块声明。对多环境可用不同 key 路径隔离。

解析

远程 state 治理的核心是"加密 + 锁 + 最小权限 + 版本化"四件套。加密防泄露，锁防冲突，最小权限防越权，版本化防损坏。只有这些组合，state 才能安全地成为团队共享的"真相"。

示例代码

terraform {
  backend "s3" {
    bucket         = "tf-state-bucket"
    key            = "prod/app.tfstate"
    region         = "us-east-1"
    encrypt        = true
    kms_key_id     = "alias/tf-state"
    dynamodb_table = "tf-lock"
  }
}

#

★

11. IaC 安全中敏感变量注入（Vault/环境变量）、plan 泄露防护与策略即代码（OPA/checkov）如何落地

问题

IaC 安全如何落地？敏感变量注入（Vault/环境变量）、plan 泄露防护与策略即代码（OPA/checkov）如何实现？

考察点

敏感变量注入（Vault/环境变量/Secret Manager）
plan 敏感信息泄露防护
策略即代码（OPA/checkov）

答案

IaC 安全涵盖三个层面。其一，敏感变量注入：不要把明文密钥写进 IaC 代码或 state；用环境变量、Vault/Secret Manager（如 HashiCorp Vault、AWS Secrets Manager）+ Terraform 的 sensitive 标记与 data 引用在运行时注入，避免硬编码。Vault 可作为 provider 动态取 secret，或通过环境变量注入。其二，plan 泄露防护：plan 输出可能包含敏感值，用 sensitive = true 标记变量与输出，避免明文打印；把 plan 输出放在受限的 artifact 中，避免进入公开日志/PR。其三，策略即代码（Policy as Code）：用 OPA/conftest 或 checkov 定义并执行安全与合规策略（如禁止开放端口、必须加密、必须打标签），在 CI 作为门禁强制校验。三者结合，形成"开发期防硬编码、运行期安全注入、评审期策略拦截"的完整安全闭环。

解析

IaC 安全的关键是"不把机密落盘、不把敏感打印、用规则自动拦截"。Vault/Secret Manager 解决了机密来源，sensitive 标记与受控 artifact 解决了泄露，OPA/checkov 解决了"合规即代码"。三者缺一不可。

示例代码

variable "db_password" {
  type      = string
  sensitive = true  # 防止 plan 明文泄露
}

resource "aws_db_instance" "db" {
  password = var.db_password
}

#

★

12. IaC 排障常见场景中 state 与真实资源不一致、provider 版本升级破坏与 plan 差异的定位方法

问题

IaC 排障的常见场景有哪些？state 与真实资源不一致、provider 版本升级破坏与 plan 差异如何定位？

考察点

state 与真实资源不一致的排查
provider 版本升级导致的破坏
plan 差异的定位方法

答案

IaC 排障常见三类问题。其一，state 与真实资源不一致：真实资源被旁路修改/删除而 state 未更新，导致 plan 显示意外 diff 或 apply 报错。定位用 terraform plan 看 diff、terraform state show/list 查看 state 记录、用 terraform refresh 同步，必要时 terraform state rm 移除误管资源或 terraform import 重新导入。其二，provider 版本升级破坏：provider 升级后 schema 变化或行为改变，导致 plan 出现大量无谓 diff 或 apply 失败。定位用 terraform providers 查看版本、锁定 provider 版本（required_providers 的 version 约束）、用 changelog 评估变更、在测试环境验证。其三，plan 差异定位：先用 terraform plan -detailed-exitcode 确认是否有 diff，再用 -out 保存 plan 并 terraform show 查看具体变更，配合 -refresh=false 隔离刷新 vs 真实变更，逐项判断是漂移、配置变更还是 provider 变更。

解析

排障的核心是"分清差异来源"：是配置变更、真实资源漂移、还是 provider 语义变化。用工具链（plan/diff/state show/refresh）逐步隔离，并配合版本锁定与测试环境，能快速定位并避免误判。

示例代码

terraform plan -detailed-exitcode   # 有变更返回非0
terraform plan -out=p.tfplan
terraform show p.tfplan             # 查看详细变更
terraform state list                # 列出 state 中的资源
terraform state rm aws_instance.web # 移除误管资源

#

★

13. IaC 的工程实践中模块复用、远程状态后端与 CI 集成的组合如何落地

问题

IaC 的工程实践如何落地？模块复用、远程状态后端与 CI 集成的组合如何设计？

考察点

模块复用的组织方式
远程状态后端与多环境
CI 集成与流水线

答案

IaC 工程实践是"模块复用 + 远程状态 + CI 集成"的组合。模块复用：把 VPC、EC2、数据库等封装为标准化模块，按层（network/compute/data）与业务（app/service）组织，模块统一版本化、输入输出文档化，团队通过 registry 或 Git 引用复用。远程状态后端：用 S3/OSS + DynamoDB 锁共享 state，按环境（dev/staging/prod）用不同 key 或 workspace 隔离，state 加密、最小权限、版本化。CI 集成：把 init/plan/apply 放进流水线，plan 作为评审门禁、apply 需审批，生产环境双人复核；用 tfsec/checkov 做安全扫描，用 terraform fmt/validate 做格式校验。三者组合形成"代码化、可复用、可评审、可审计"的 IaC 体系：模块保证复用与一致，远程 state 保证协作与安全，CI 保证变更受控与可追溯。

解析

这三者互为支撑：模块让代码可复用，远程 state 让协作成为可能，CI 让变更受控。缺模块则重复代码，缺远程 state 则多人冲突，缺 CI 则变更失控。组合落地才能形成成熟 IaC 工程。

#

★

14. IaC 的评审与测试中 plan 输出评审要点、lint/单元测试与沙箱 apply 验证如何组织

问题

IaC 的评审与测试如何组织？plan 输出评审要点、lint/单元测试与沙箱 apply 验证如何落地？

考察点

plan 输出评审要点
lint 与单元测试（terraform fmt/validate、unit tests）
沙箱 apply 验证

答案

IaC 的评审与测试分三层。其一，plan 输出评审：评审重点看"是否创建/删除/替换资源"（尤其替换会带来停机）、是否有意外变更（如 deleting 生产资源）、敏感信息是否泄露、变更是否符合预期（如实例类型、安全组）。用 terraform plan -detailed-exitcode 与 -out 保存 plan 供评审。其二，lint 与单元测试：terraform fmt 检查格式、terraform validate 校验语法与 provider schema、tflint 做最佳实践 lint；单元测试用 terratest（Go）或 terraform test 对模块输入输出/资源生成做断言，验证逻辑正确性。其三，沙箱 apply 验证：在隔离的测试环境（dev/沙箱账号）实际 apply，验证资源可创建、配置正确、可回滚，通过后再晋升到生产。组织上把三层放进流水线：fmt/validate/lint + 单测→plan→评审→沙箱 apply→生产 apply。

解析

评审与测试是 IaC 质量保障。plan 评审"看变更"，lint 与单测"验逻辑"，沙箱 apply"验真实"。三者结合，在变更到达生产前把错误与风险拦截，避免"一次 apply 毁掉生产"。

#

★

15. Pulumi ESC 的定位中如何在 IaC 中管理环境变量、密钥与配置分层？

问题

Pulumi ESC 的定位是什么？如何在 IaC 中管理环境变量、密钥与配置分层？

考察点

Pulumi ESC（Environments, Secrets, and Configuration）的定位
环境变量、密钥与配置的分层管理
与 IaC 工作流的集成

答案

Pulumi ESC（Environments, Secrets, and Configuration）是 Pulumi 的托管配置与密钥管理服务，把"环境变量、密钥、配置"统一管理，并支持分层（环境继承）。定位：它相当于 IaC 世界中的"配置中心 + 密钥管理"，把散落在各处的环境变量与密钥集中化、可版本化、可访问控制。功能：Environment 定义一组配置（含环境变量、密钥引用、云凭证），支持环境之间继承（如 prod 继承 common），密钥用 Provider（如 AWS Secrets Manager、Vault、Pulumi 自管加密）加密存储；通过 pulumi config 或 ESC 环境注入到 IaC 运行。落地：按环境分层（dev/staging/prod/common），把密钥与配置分离，用敏感加密与访问控制（RBAC）限制谁能读，在与 CI/CD 集成时把 ESC 环境作为配置来源，避免硬编码。

解析

ESC 的价值在于"把配置与密钥从代码中剥离，集中且分层管理"。它解决了 IaC 长期痛点：密钥不落盘、配置可复用、环境可继承。适合与 Pulumi/Terraform 等 IaC 配合，形成"配置即服务"。

#

★

16. Terraform 与 CDK 的取舍中同云场景下编程式 CDK 与声明式 Terraform 哪个更合适

问题

Terraform 与 CDK 如何取舍？同云场景下编程式 CDK 与声明式 Terraform 哪个更合适？

考察点

CDK（AWS CDK、CDKTF）的编程式、抽象与组件化
Terraform 的声明式、跨云与成熟生态
项目类型与团队能力

答案

Terraform 是声明式 IaC，用 HCL 描述目标状态，跨云（AWS/Azure/GCP）、生态成熟、state 管理完善、社区模块丰富。CDK 分两类：AWS CDK（专属 AWS，用 TypeScript/Python 等编程语言定义资源，支持 L2 Construct 抽象、组件化、可复用逻辑）与 CDKTF（CDK for Terraform，用编程语言生成 Terraform 配置，仍走 Terraform 后端）。取舍：同云纯 AWS 场景，若团队熟练编程语言、需要抽象/循环/条件/组件复用、追求开发效率，AWS CDK 更合适；若需要跨云统一、需与现有 Terraform 生态/模块/云无关策略一致、或团队更熟 HCL，则 Terraform 更合适。CDKTF 是折中：编程语言享受 + Terraform 后端与 provider 生态。总体：追求"快速、可编程、AWS 专属"选 CDK，追求"跨云、成熟、声明式、生态"选 Terraform。

解析

取舍本质是"编程式抽象 vs 声明式生态"的权衡。CDK 用语言特性（循环、条件、类）提升表达与复用，Terraform 用声明式与成熟状态/模块生态保证跨云与可移植。同云且团队强于编程则 CDK 占优，跨云或依赖 Terraform 生态则 Terraform 更稳。

#

★

17. Terraform 与 CloudFormation/ARM/Bicep 的跨云策略对比

问题

Terraform 与 CloudFormation/ARM/Bicep 的跨云策略如何对比？

考察点

各工具与云厂商的绑定关系
Terraform 的跨云统一性
云原生工具（CloudFormation/ARM/Bicep）的深度集成

答案

云厂商原生 IaC 工具：AWS CloudFormation（与 AWS 深度集成、资源类型覆盖最全、内置 drift 检测）、Azure ARM Template/Bicep（Bicep 是 ARM 的简化声明式语言，编译为 ARM）、GCP Deployment Manager。它们与各自云深度绑定、原生支持（如 CloudFormation 的 rollback、StackSets 多账号、Bicep 的模块与 parameter 文件），但无法跨云统一。Terraform 是跨云抽象层，用一个 HCL 工作流管理 AWS/Azure/GCP/多云，统一 state、plan、apply 与 provider 生态，但跨云统一意味着对某云的"最新最全特性"支持可能滞后（需等 provider 更新）。对比与策略：单一云且深度依赖云原生产品（如 CloudFormation 的 StackSets、Bicep 的模块）时选云原生工具，享受原生集成与能力；跨云/多云/厂商中立/团队统一技能时选 Terraform，用一套工作流管理所有云。也可混合：Terraform 管跨云编排，云原生工具管特定云复杂资源。

解析

对比核心是"原生深度 vs 跨云统一"。云原生工具深度绑定、特性全，但被锁定；Terraform 统一、中立，但特性跟进有滞后。策略取决于"是否单一云、是否重原生特性、是否需厂商中立"。

#

★

18. Terraform 的 count/for_each/for 表达式在批量资源管理中的取舍

问题

Terraform 的 count/for_each/for 表达式在批量资源管理中的取舍是什么？

考察点

count 与 for_each 的区别
for 表达式在集合处理中的应用
批量资源管理的最佳实践

答案

count 与 for_each 都用于创建多个资源实例，但行为不同。count：基于整数创建 N 个实例，资源用 count.index 引用；缺点是当列表中间元素被删除/重排时，count 会按索引重排，导致资源被重建（索引漂移）。for_each：基于 map 或 set 创建，资源用 each.key/each.value 引用，键稳定，删除/修改某元素只影响该元素，不重排其他实例，更适合大部分批量场景。for 表达式用于在 map/list/set 之间做转换（如 for k,v in var.map : k => upper(v)），用于生成配置而非创建资源。取舍：若资源集合稳定、顺序无关紧要，count 够用；若集合可能变化（增删改），用 for_each 避免索引漂移；for 表达式用于数据变换。批量管理最佳实践：优先 for_each + map 保证稳定性，用 toset 转换保证唯一性，避免用 count 管理易变集合。

解析

取舍核心是"稳定性"。count 按索引编号，集合变化会牵动重建；for_each 按键，集合变化只影响对应项。理解这一点能避免"改一个节点导致全部重建"的坑。for 表达式是数据变换工具，与资源创建分离。

示例代码

variable "instances" {
  type = map(object({
    type = string
  }))
  default = {
    web = { type = "t3.micro" }
    api = { type = "t3.medium" }
  }
}

resource "aws_instance" "app" {
  for_each = var.instances
  instance_type = each.value.type
  tags = { Name = each.key }
}

#

★

19. 从手工变更迁移到 IaC 的路径中先 import 现有资源再治理漂移的工程节奏与风险控制

问题

从手工变更迁移到 IaC 的路径是什么？先 import 现有资源再治理漂移的工程节奏与风险控制如何落地？

考察点

存量资源 import 的迁移路径
漂移治理的节奏
迁移风险控制

答案

从手工变更迁移到 IaC 的典型路径是"摸底 → import → 对齐 → 治理漂移 → 增量上线"。摸底层：梳理现有资源清单、归属与依赖。import 层：把存量资源逐个 import 进 Terraform state，配置尽量对齐真实资源。对齐层：用 terraform plan 对比，把配置调整到 plan 收敛（消除与真实资源的意外 diff），形成基线。漂移治理层：此后所有变更都走 IaC，禁止旁路手工改；用 terraform plan 定期检测漂移并对漂移资源（若被手工改）收敛回配置或更新配置。风险控制：分批迁移（先低风险资源，如网络/安全组，再数据库/核心应用），每批 import 后先 plan 再 apply 验证，设置回滚与备份；对复杂资源在测试环境先演练；用 prevent_destroy 保护关键资源；迁移期间保持真实资源不中断（import 不重建资源，只接管）。节奏上"小步快跑、每步验证、可回退"。

解析

迁移的关键是"让 IaC 接管而不重建，逐步收敛漂移"。import 不重建资源，因此天然低风险；重点是分批复核、先对齐再治理、并持续用 plan 检测漂移，避免"一次迁移整个生产"的高风险。