Microsoft AZ-400: 基础架构即代码与配置管理 — 学习指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

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

概述

Azure 上的基础设施即代码 (IaC) 和配置管理让您能够重复且安全地定义、预配和强制执行基础设施及应用程序的设置。Azure 原生支持 ARM JSON 和 Bicep，并与 Terraform 和 Ansible 良好集成。配置状态可以通过 PowerShell Desired State Configuration (DSC)、Azure Automation DSC、Chef 和 Puppet 进行声明。应用程序功能发布和密钥管理通过 Azure App Configuration 和 Key Vault 进行集中化。使用 Packer 构建的不可变镜像可以减少偏差。治理通过 Azure Policy 以及用于 Kubernetes 的 OPA/Gatekeeper 以策略即代码的形式强制执行。

Azure 原生 IaC：ARM 模板和 Bicep

ARM 模板是 Azure Resource Manager 用来创建和更新资源的声明式 JSON 文档。其顶层结构包括 $schema、contentVersion、parameters、variables、resources 和 outputs。Parameters 允许特定于环境的输入；variables 帮助派生计算值；resources 声明所需状态；outputs 发布结果，如资源 ID。模板支持模板表达式和运行时函数（例如，resourceId、reference、concat、uniqueString），因此您可以组合名称和检索属性。

要将大型部署分解为可维护的单元，您可以使用嵌套或链接模板。嵌套模板在 Microsoft.Resources/deployments 资源的 template 属性中内联 JSON。链接模板通过 templateLink.uri 引用远程模板，该模板通常存储在 Azure Storage 中，并使用有时间范围的 SAS 以确保完整性。当所有内容都可以存在于单个构件中，并且您希望跨部分进行事务性部署时，请使用嵌套模板。对于非常大的拓扑或在跨存储库或团队重用模板时，请使用链接模板。通过在 deployments 资源上设置部署范围，根据需要将部署范围限定为资源组、订阅、管理组或租户。

ARM 支持两种部署模式。增量模式 (Incremental，默认) 会创建或更新模板中存在的资源，而不会删除任何未声明的资源。完全模式 (Complete) 会删除目标范围内未在模板中指定的资源，这对于保证最小偏差很有用，但如果模板对该范围不具权威性，则风险也更大。验证 (Validate) 和 What-If 操作有助于在执行前预览变更，以降低风险。

Bicep 是一种领域特定语言，可编译为 ARM JSON，并提供一流的编写体验。资源声明使用符号名称，强制执行类型，并支持 existing 关键字来引用预先存在的资源而无需重新部署。Parameters、variables、outputs 和资源声明都很简洁，父子关系和范围也很明确。模块 (Modules) 支持组合和重用；每个模块都是一个 Bicep 文件，通过 module 关键字引用，并且可以发布到模板规范 (template spec) 或 OCI 构件注册表中使用。条件通过在资源或模块上使用 if 内联表示，循环使用 for 表达式来声明多个实例，并提供清晰的依赖处理。从 ARM JSON 迁移很简单：az bicep decompile (或 bicep decompile) 将 JSON 转换为 Bicep；然后您可以将其重构为模块并采用符号名称。Bicep 与 ARM 无损兼容，并支持完整的平台功能；bicep build 会生成标准的 ARM JSON 用于部署。

使用 Terraform 在 Azure 上实现跨平台 IaC

当需要多云或提供商无关的工作流时，Terraform 补充了 Azure 原生 IaC。azurerm 提供商管理 Azure Resource Manager 资源，应将其版本固定；即使为空，也应包含 features {} 以启用提供商功能。其他常用提供商包括用于 AAD 对象的 azuread 和用于实用程序值的 random。通过服务主体、托管代理上的托管标识 (Managed Identity) 或 Azure CLI 进行身份验证。为每个环境采用清晰的提供商配置策略，并集中管理带有输入变量和输出的可重用模块。

状态管理至关重要。使用 azurerm 后端将远程状态存储在 Azure Storage 中：配置 resource_group_name、storage_account_name、container_name 和 key；使用托管标识或 SAS 进行身份验证；并在 blob 容器上启用软删除和版本控制。后端使用 blob 租约来锁定状态，防止并发修改。对存储帐户的访问应通过 RBAC 进行控制，并可选择使用私有终结点 (Private Endpoints) 进行限制。保持状态文件环境隔离，并且根据设计，绝不将机密存储在状态中——必要时使用 Key Vault 和数据源进行机密检索。

工作区 (Workspaces) 在同一配置中为环境分支（如 dev、test 和 prod）提供状态的逻辑隔离。使用 terraform workspace select 并确保后端 key 对工作区进行编码以避免冲突（例如，myapp-${terraform.workspace}.tfstate）。工作区非常适合差异不大的环境对等；当拓扑结构差异很大时，应使用单独的配置或模块以避免偏差和条件复杂性。通过服务连接和 Terraform CLI 任务与 Azure Pipelines 集成，以标准化跨阶段的 init/plan/apply，并基于审批和策略检查来控制 apply 操作。

大规模配置管理：DSC、Azure Automation DSC、Ansible、Chef 和 Puppet

PowerShell Desired State Configuration (DSC) 通过资源来声明 Windows 和跨平台的状态。存在两种交付模式：推送 (push) 模式将 MOF 文件直接发送到节点；拉取 (pull) 模式则让节点按计划从拉取服务 (pull service) 获取其 MOF 文件。本地配置管理器 (Local Configuration Manager, LCM) 负责强制执行策略。关键的 LCM 设置包括：

ConfigurationMode：ApplyOnly (仅配置一次，不纠正漂移)、ApplyAndMonitor (检测漂移，但不纠正)、ApplyAndAutoCorrect (检测并修复漂移)。
ConfigurationModeFrequencyMins 和 RefreshFrequencyMins：用于调整强制执行和拉取操作的频率。
RebootNodeIfNeeded 和 ActionAfterReboot：用于处理重启。
部分配置 (Partial configurations)：允许通过多个 MOF 文件组合节点状态，这些文件可独立地针对不同功能（例如，基础操作系统加固和应用程序角色）。

Azure Automation State Configuration (Azure Automation DSC) 是一种托管的拉取服务。您可以在 PowerShell 中编写配置，将其导入到 Automation Account，然后启动编译作业以生成节点配置 (MOF)。节点使用注册密钥/端点通过 Register-AzAutomationDscNode 进行注册，并且可以进行分组，并为每个节点分配带有不同参数值的配置。合规性报告会显示上次应用的配置和漂移状态；处于 ApplyAndAutoCorrect 模式的节点将在下次签入时自动修复。编译作业是可审计的构建产物，而基于角色的访问控制则限制了配置的编写和节点的分配。

Ansible 是无代理 (agentless) 的，非常适合 Linux 集群配置和即席编排 (ad-hoc orchestration)。在 Azure 上，请使用 azure.azcollection，它为计算、网络、Key Vault 等提供了模块。使用 azure_rm 插件的动态清单 (dynamic inventory) 功能可以从您的订阅或特定的资源组和标签中发现主机；凭据获取可以使用服务主体 (service principal)、Azure CLI 或托管标识 (managed identity)。要与 Azure Pipelines 集成，可以在 Linux 代理上安装 Ansible，通过 AzureCLI@2 或 Azure Resource Manager 服务连接登录，然后运行引用动态清单、变量组和安全文件的 playbook。Ansible 擅长执行幂等的、可读性强的任务，在以 Windows 为主的环境中，可以通过处理跨平台工作流和编排来与 DSC 互补。

Chef 和 Puppet 提供了成熟的策略即代码 (policy-as-code) 模型和合规性报告功能。在 Azure VM 上，Chef 和 Puppet VM 扩展会在预配时引导代理，确保早期收敛。Chef Infra 使用 cookbook 和 Policyfile 来锁定依赖项并确保可复现的运行；Chef InSpec 以代码形式表达合规性 (compliance-as-code)，并将报告提供给 Chef Automate 以展示漂移和控制状况。Puppet 的 manifest 和 module 用于编码所需状态，而 Code Manager 和环境 (environments) 则提供晋升流程；Puppet Enterprise 提供集中的报告、基于角色的分类和修复功能。这两种工具都通过模块和资源提供程序与 Azure 集成，并且在迁移或混合环境需要时，可以与 Azure 原生的 DSC 共存。

应用程序配置、不可变镜像与策略即代码

Azure App Configuration 集中管理应用程序设置和功能标志。功能标志可以实现渐进式发布：你先定义标志，如果需要，可以附加筛选器，例如通过 Feature Manager 库实现基于百分比的发布或用户定向。标签 (Label) 可让你按环境或发布环 (ring) 分隔值。配置快照 (Configuration snapshot) 捕获一组键和标签在某个时间点的不可变视图，从而在多个服务间实现一致、可复现的发布，避免因并发密钥更改而导致的竞争条件。Key Vault 引用让你能够将机密保留在 Key Vault 中，而在 App Configuration 中仅存储其引用；应用程序的托管标识必须拥有对该机密的 get 权限，客户端库会解析并缓存机密，并提供可选的动态刷新功能。请对这两种服务都使用 RBAC 和网络隔离来保护访问。

不可变基础设施通过从已知镜像重建来代替修改主机，从而消除配置漂移。Packer 的 azure-arm (现为 azure) 构建器从基础操作系统创建镜像，运行预配程序 (provisioner) (如 shell、PowerShell、Ansible)，并将其发布到具有区域复制和语义化版本控制的 Shared Image Gallery。一个黄金镜像管道通常会执行以下步骤：对 Packer 模板进行 lint 检查，构建镜像，运行漏洞和合规性扫描 (例如 InSpec)，对其进行集成测试，将其提升 (promote) 到库中，然后更新 VM Scale Sets 或主机池。借助 VM Scale Sets、滚动升级或基于健康的升级以及操作系统镜像自动升级，你可以获得安全、一致的发布和简便的回滚（只需选择一个先前的镜像版本）。

策略即代码 (Policy as code) 强制实施护栏 (guardrail)。Azure Policy 定义是 JSON 对象，其中包含一个 policyRule，用于评估资源属性并执行效果 (effect)，例如 deny、audit、append、modify 或 deployIfNotExists 以实现自动修复。将定义参数化以供重用；将它们与计划 (initiative) (策略集定义) 分组，以实现一致的分配和集中的合规性跟踪。在管理组、订阅或资源组范围分配策略；为 modify 和 deployIfNotExists 策略启用修复任务，以使现有资源达到合规状态。将策略构件存储在源代码控制中，通过拉取请求 (pull request) 进行审查，并使用 Bicep、ARM 或 Terraform 进行部署，以实现在不同环境间的一致提升。

对于 Kubernetes，OPA/Gatekeeper 强制实施准入时 (admission-time) 约束。ConstraintTemplate 定义 Rego 策略及其模式 (schema)；Constraint 则在集群中实例化这些策略。常见的控制措施包括将镜像限制在受信任的注册表中、要求必须有标签/注解或阻止特权 Pod。Gatekeeper 与 GitOps 工具 (Flux/Argo CD) 集成，并通过 conftest 进行 CI 测试。Azure Policy for Kubernetes 构建于 Gatekeeper 之上，可跨 AKS 集群提供 Azure 原生的分配和合规性视图，从而将云和集群的治理统一到一个状态仪表板下。

实践问题场景

Spotify 必须标准化 Azure 基础设施，减少配置漂移，并加速其跨 Windows 和 Linux、AKS 以及基于 VM 的工作负载的微服务的安全功能发布。

按领域 (networking, data, compute) 使用 Bicep 模块对云资源进行建模，并通过限定在管理组范围内的订阅进行部署。这能产出类型化、可维护的声明，具有清晰的作用域和重用性，且避免了 ARM JSON 的冗长性。
对于由多个团队消费的共享平台服务，使用少量链接的 ARM 模板规范 (template spec)。托管为模板规范的链接模板提供了版本化的不可变构件，并将平台节奏与应用团队解耦。
为跨云的边缘和 CDN 依赖选择 Terraform，并使用 azurerm 后端，将远程状态按工作区 (dev/test/prod) 存储在 Azure Storage 中，同时使用 blob 租约进行锁定。这在安全隔离状态的同时，保留了单一的管道模式，并实现了环境间的一致提升。
在 Azure App Configuration 中集中管理应用程序配置和功能标志。带有百分比筛选器和标签的功能标志可实现基于发布环 (ring) 的发布；配置快照确保每个部署阶段都消费一个不可变的、经过审计的密钥集。
将机密存储在 Azure Key Vault 中，并从 App Configuration 引用它们。在运行时使用托管标识解析引用，可以在无需重新部署的情况下进行密钥轮换，并将机密从应用程序配置和管道中移除。
对基于 VM 的工作负载采用不可变镜像，使用 Packer 构建黄金镜像并发布到 Shared Image Gallery。一个管道会运行加固脚本和 InSpec 扫描，为镜像打上标签，并只提升通过测试的版本。VM Scale Sets 消费库中的镜像以进行蓝/绿部署和滚动升级，从而消除漂移。
通过 Azure Policy 计划 (initiative) 强制实施护栏，例如拒绝私有子网上的公共 IP 暴露、要求将诊断设置发送到 Log Analytics 以及自动部署备份策略。在管理组级别进行分配以实现广泛覆盖，并为现有资源创建修复任务以快速收敛状态。
通过应用阻止不合规镜像和特权 Pod 的约束来保护 AKS。策略存储在 Git 中并进行版本控制，在 CI 中使用 conftest 进行验证，并通过 GitOps 应用，以确保集群状态始终与策略匹配。
使用 Azure Automation DSC 管理 Windows 服务器配置。节点通过 Register-AzAutomationDscNode 进行注册，并使用 ConfigurationMode=ApplyAndAutoCorrect 来检测并修复漂移；编译作业为每个角色生成 MOF 文件，合规性仪表板会呈现漂移以供调查。
使用 Ansible 的 azure_rm 动态清单和 azure.azcollection 模块来管理 Linux 配置和编排。Azure Pipelines 使用托管标识进行身份验证，以幂等方式运行 playbook，并协调跨服务的更新，与 Windows 上的 DSC 形成互补。
利用 Chef InSpec 配置文件在镜像和运行中的主机上实现跨平台的合规性即代码，并将数据提供给 Chef Automate 用于报告。这将可审计、可测试的控制措施引入到管道和生产环境中，确保持续验证监管要求。

这种组合提供了类型化、模块化的 IaC (Bicep/Terraform)、不可变主机 (Packer)、集中的应用配置 (App Configuration/Key Vault)、持续的配置强制执行 (Azure Automation DSC, Ansible) 和强有力的治理 (Azure Policy, Gatekeeper)。它减少了漂移，缩短了恢复和发布时间，并使合规性变得可证明。

← 使用 Azure Pipelines 的 CI · 所有领域 · 容器化与 Kubernetes →

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