Amazon DOP-C02: 基础架构即代码和配置管理 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

属于 AWS DevOps Engineer Professional DOP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

AWS 上的基础设施即代码 (IaC) 和配置管理为基础设施和应用程序的预置与配置提供了可重复、可审计且受治理的方式。CloudFormation 和 AWS Cloud Development Kit (CDK) 以声明方式或通过可合成 CloudFormation 的代码来描述资源。AWS OpsWorks 和 AWS Systems Manager 等配置层在 EC2 和混合实例集中强制执行并报告所需状态。密钥、参数和镜像烘焙完善了整个生命周期，实现了大规模的不可变、安全部署。

CloudFormation 堆栈、变更控制和治理

CloudFormation 堆栈是部署的基本单元。围绕生命周期边界和所有权设计堆栈，以最小化爆炸半径。谨慎使用参数，优先选择带有映射或 SSM 查找功能的、有明确倾向性的默认值。仅通过 Outputs 和 Fn::ImportValue 导出和导入稳定、共享的值，以避免紧密耦合。

嵌套堆栈封装了可重用的组件，并使父模板保持小巧。父堆栈可以向子堆栈传递参数并使用其输出，从而实现模块化架构（例如，一个共享网络嵌套堆栈被一个应用程序堆栈使用）。保持嵌套堆栈专注于单一职责（VPC、数据层、应用层），并对其进行独立版本控制。

StackSets 可跨多个账户和区域部署单个模板。通过 AWS Organizations 使用服务托管权限模型，可自动部署到组织单元 (OU) 并自动包含新账户。配置操作首选项（最大并发账户/区域数、失败容忍度）来控制部署节奏。针对每个账户或区域的参数覆盖功能，可让您根据本地约束调整标准模板。监控 StackSet 和堆栈实例的偏差，以检测带外变更。

变更集 (Change sets) 提供了安全、可人工审查的更新。务必先执行 CreateChangeSet，检查逐个资源的影响、替换情况和潜在的数据丢失，然后再执行 ExecuteChangeSet。将变更集集成到自动化管道中，以实现门控审批。

偏差检测 (Drift detection) 可验证堆栈资源是否与模板匹配。定期对关键堆栈和 StackSets 运行偏差检测；请理解，并非所有资源类型的所有属性都会被评估（不支持的属性会报告为“未检查”）。将偏差视为一个事件：进行调查，捕获上下文，并通过更新堆栈或将偏差代码化后重新应用来纠正。

堆栈策略 (Stack policies) 是在更新期间保护关键资源的 JSON 文档。禁止对不可替代的资源（例如，生产数据库、Route 53 托管区域）进行更新，并使用 StackPolicyDuringUpdateBody 为特定变更临时开辟一个精确的操作路径，然后恢复更严格的策略。结合终止保护 (termination protection) 和 DeletionPolicy (Retain/Snapshot) 作为护栏。对于具有外部状态的资源（如 S3 存储桶），需规划其删除行为。如果存储桶在删除前必须被清空，应实现一个自定义资源，在删除堆栈时清除对象。

AWS CDK 和 CloudFormation 可扩展性

AWS CDK 使用熟悉的语言（TypeScript、Python、Java、.NET、Go）对基础设施进行建模。Construct 是 CDK 的构建块：

• L1 construct (CfnXxx) 从 CloudFormation 规范生成，与资源一一对应。
• L2 construct 添加了高级意图和合理的默认值（例如，ApplicationLoadBalancedFargateService）。
• L3 “模式”组合多个 L2，形成即用型架构。

一个 CDK 应用程序包含一个或多个堆栈。在执行 cdk synth 期间，应用程序会解析上下文查找（例如，VPC ID），渲染资产，并生成一个 CloudFormation 模板。在部署之前，cdk bootstrap 会创建环境的资产存储桶和角色。使用 cdk diff 预览变更，然后使用 cdk deploy 提交模板和资产；CDK 内部使用变更集，并会显示和确认安全敏感型变更（IAM 或资源替换）。通过 Aspects 为堆栈和资源打标签，以强制执行组织范围的标签策略。当 L2 抽象无法满足需求时，可使用“逃生舱口”(escape hatches) (node.defaultChild) 或降级使用 L1 construct。

CloudFormation 自定义资源 (custom resources) 将 IaC 的能力扩展到任何可通过 API 访问的内容。一个由 Lambda 支持的自定义资源会接收带有 RequestId、PhysicalResourceId 和属性的 Create、Update 和 Delete 事件。该函数必须：

• 保持幂等性，并在超时窗口内向预签名的 ResponseURL 返回成功/失败。
• 设置一个稳定的 PhysicalResourceId 来跟踪更新，并在 Delete 事件时驱动清理工作。
• 为最终一致性的下游服务处理重试和稳定等待。

为 Lambda 使用最小权限的 IAM 执行角色，在 API 调用中加入指数退避机制，并通过 RequestId 进行日志关联。对于大型或长时间运行的操作，可考虑使用 Step Functions，并让自定义资源等待一个执行令牌。在适用时，优先选择 CloudFormation Registry 中可重用、有版本的提供程序。

基础设施即代码中的密钥和参数

切勿在模板或代码中硬编码密钥。使用动态引用在部署时解析敏感值：

• Secrets Manager: {{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage}}
• SecureString Parameter Store: {{resolve:ssm-secure:parameter-name:version}}

动态引用可防止密钥被存储在堆栈模板或事件中。不要将密钥放置在 CloudFormation 会以明文形式记录的输出（Outputs）或资源属性中。授予 CloudFormation 执行角色解密或检索引用值的权限，并将 KMS CMK 的范围限定在需要访问的主体（principals）上。

Parameter Store 非常适合用于非机密配置（如功能标志、AMI ID、端点）。使用带版本的 SSM 参数可实现安全回滚和跨环境的原子化提升。在 CDK 中，使用 ssm.StringParameter.fromStringParameterName 导入值，或使用 fromSecureStringParameterAttributes 导入安全值，并将参数读取操作接入到用户数据（user data）或应用程序引导脚本中。

Secrets Manager 专为生命周期控制、轮换和审计而设计。将轮换功能与支持的引擎（如 RDS、Aurora）或自定义 Lambdas 集成。在运行时引用密钥，而不是将其烘焙到 AMI 中，以避免过时材料的扩散。对于容器化或无服务器工作负载，可通过由 Secrets Manager 引用支持的环境变量注入密钥，或通过 ECS/TaskDefinition 密钥进行挂载；通过使用短 TTL 的连接池和重试机制，以最小的停机时间进行轮换。

配置管理与不可变基础设施

AWS OpsWorks 提供预设了特定范式的配置管理。OpsWorks Stacks 使用 Chef cookbooks 和生命周期事件（Setup、Configure、Deploy、Undeploy、Shutdown）来编排应用程序的配置和部署，并通过健康检查支持自动修复，这些检查可以停止/启动或替换实例。在过去，OpsWorks 也提供托管的 Chef Automate 和 Puppet Enterprise；如今，许多团队转而标准化使用 Systems Manager 进行基于代理的编排，或者自行运行 Ansible/Chef/Puppet 控制平面。Ansible 并未与 OpsWorks 原生集成；替代方案是使用 Systems Manager State Manager 来运行 playbook，或者使用 AWX/Ansible Automation Platform 并结合 SSM Session Manager 连接和 EC2 动态清单。

AWS Systems Manager 是用于混合云配置的现代化控制平面：

• State Manager 通过关联（Association）来强制执行期望状态，这些关联可以按计划、基于事件或在实例启动时运行 SSM 文档（YAML/JSON）。使用 AWS-RunShellScript、AWS-ApplyAnsiblePlaybooks、AWS-ConfigureDocker 和自定义文档来收敛配置。通过参数化关联并按标签定位目标，可以实现整个机群范围的变更。
• 配置合规性功能可以呈现关联状态和 Patch Manager 的结果。使用补丁基线（patch baseline）来定义批准的分类，将其与维护窗口（Maintenance Window）绑定，并按实例标签、补丁组（patch group）或资源组跟踪合规性。混合激活（Hybrid Activation）功能可将本地节点注册为托管实例，以实现统一治理。
• Inventory 记录软件包、文件和 Windows 更新；Resource Data Sync 将数据导出到 S3 和 Athena 以进行企业级报告。将 SSM 合规性与 AWS Config 规则和自动修复（Systems Manager Automation 运行手册）相结合，以形成从检测到修复的闭环。

不可变基础设施消除了漂移并加速了回滚。EC2 Image Builder 通过以下方式将镜像管道代码化：

• 组件（安装、加固、验证步骤），以文档形式表示。
• 镜像配方，用于组合组件和基础镜像。
• 基础设施配置，定义子网、安全组、实例配置文件和日志记录。
• 分发配置，用于将 AMI 复制到不同区域并共享给其他账户。

添加测试组件以验证 CIS 基准、代理健康状况（SSM/CloudWatch）和应用程序冒烟测试。对镜像进行版本控制并使用语义化标签进行标记。将 AMI ID 发布到 Parameter Store（例如，/app/frontend/ami），并在 Auto Scaling 启动模板中引用它们。使用滚动或蓝绿部署策略进行部署；替换实例而不是进行原地修补，以保持不可变性。将漏洞扫描（Amazon Inspector）的结果反馈到管道的晋级门控中。不要将密钥烘焙到镜像中；在启动时通过实例元数据服务 v2（Instance Metadata Service v2）和对 SSM/Secrets Manager 的引用来检索。

实际问题场景

Capital One 需要为其面向客户的平台标准化多账户、多区域的部署，同时强制执行严格的治理、密钥管理并消除配置漂移。该环境横跨 AWS Organizations 中的数百个账户，并对数据库访问和操作系统加固实施了严格控制。

1. 使用 AWS CDK 对基础设施建模并合成为 CloudFormation

• 实现用于 VPC、ALB、Auto Scaling 组和 Aurora 的 L2/L3 构造。在 CI 中使用 cdk synth 和 cdk diff 来生成和验证模板及变更集。
• 为什么选择 CDK：通过构造实现强大的组合和重用，通过 Aspects 实现编程化策略以实施组织范围的标签和护栏，并与 CloudFormation 原生集成以保证可审计性。

2. 通过 CloudFormation StackSets 分发基线网络和护栏堆栈

• 创建服务管理的 StackSets，以安全和沙箱 OU 为目标，推广共享的 VPC 端点、标准的 CloudWatch 告警和 IAM 边界。启用自动部署到新账户的功能，并设置容错和并发控制。
• 为什么选择 StackSets：实现组织规模的、一致的推广，能自动包含新账户，并内置漂移检测功能。

3. 使用堆栈策略和变更集保护关键资源

• 应用堆栈策略，拒绝更新 Aurora 集群和 Route 53 区域。在生产环境的管道中，要求在执行 ExecuteChangeSet 之前必须先 CreateChangeSet 并获得人工批准。
• 为什么选择堆栈策略/变更集：强制执行最小权限的变更，并在高风险变更前提供人工审核。

4. 使用 Lambda 支持的自定义资源扩展 IaC

• 实现一个 Custom::S3BucketCleanup，在堆栈删除时清空应用程序存储桶；以及一个 Custom::AuroraParameterTuner，在创建后应用数据库引擎参数。
• 为什么选择自定义资源：弥补声明式预置中的功能差距，同时保持其生命周期与堆栈绑定。

5. 使用 Secrets Manager 和 Parameter Store 集中管理密钥和配置

• 将数据库凭证和 API 密钥存储在 Secrets Manager 中，并使用 Lambda 进行轮换；将 AMI ID、功能标志和端点发布到 Parameter Store。在 CloudFormation 中通过动态引用引用这些值，并在应用程序运行时通过 CDK 导入。
• 为什么选择这些服务：关注点分离——密钥管理包含轮换和审计，参数管理用于非机密配置且易于推广。

6. 通过 Systems Manager State Manager 强制执行期望状态和合规性

• 创建关联来安装代理、配置操作系统设置，并在需要时应用 Ansible playbook。结合使用 Patch Manager 和维护窗口（Maintenance Window）进行非工作时间的补丁更新，并通过 Resource Data Sync 聚合合规性仪表板。
• 为什么选择 State Manager：基于代理的收敛机制，跨 EC2 和本地环境工作，提供持续的合规性报告和规模化的修复能力。

7. 通过 EC2 Image Builder 采用不可变基础设施

• 使用组件构建加固的 AMI，这些组件包含 CIS 基线、SSM/Inspector 代理和应用程序运行时依赖。运行测试，将 AMI ID 发布到 Parameter Store，并将 Auto Scaling 启动模板连接到版本化的参数。通过滚动更新进行部署；在 AMI 更新时触发实例刷新。
• 为什么选择 Image Builder：可复现、可测试的镜像，能消除漂移，并通过快速回滚缩短平均恢复时间（MTTR）。

8. 管道编排与治理

• 实现一个多阶段管道，该管道运行 cdk synth/diff、创建变更集、暂停以待批准，然后执行。使用 EventBridge 在存储库变更时触发 StackSet 更新。每晚添加漂移检测扫描，并对发现的差异创建 OpsCenter 事件。
• 为什么选择这种方法：通过可审计的晋级、主动的漂移检测以及基于明确服务职责的自动化修复，实现持续交付。

← CI · 所有领域 · 监控、日志记录和可观测性 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →