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 以 policy-as-code 的方式強制執行。

Azure 原生 IaC：ARM 範本與 Bicep

ARM 範本是宣告式的 JSON 文件，Azure Resource Manager 用它來建立和更新資源。其頂層結構包含 $schema、contentVersion、parameters、variables、resources 和 outputs。Parameters 允許環境特定的輸入；variables 協助衍生計算值；resources 宣告期望的狀態；outputs 則發布如資源 ID 等結果。範本支援範本表達式和執行階段函式 (例如 resourceId、reference、concat、uniqueString)，讓您可以組合名稱並擷取屬性。

為了將大型部署拆解成可維護的單元，您可以使用巢狀或連結範本。巢狀範本是將 JSON 內嵌於 Microsoft.Resources/deployments 資源的 template 屬性中。連結範本則是透過 templateLink.uri 參考遠端範本，通常儲存在 Azure Storage 中，並使用有時效性的 SAS 來確保完整性。當所有東西都可以存在於單一產物中，且您希望跨部分進行交易式部署時，請使用巢狀範本。當拓撲非常龐大，或需要在不同儲存庫或團隊之間重用範本時，請使用連結範本。根據需求，透過在 deployments 資源上設定部署範圍，將您的部署範疇限定在資源群組、訂閱、管理群組或租用戶。

ARM 支援兩種部署模式。Incremental (預設) 會建立或更新範本中存在的資源，但不會刪除任何未宣告的資源。Complete 則會刪除目標範圍內未在範本中指定的資源，這對於保證最小程度的漂移很有用，但如果範本對於該範圍並非權威來源，風險也較高。Validate 和 What-If 操作有助於在執行前預覽變更，以降低風險。

Bicep 是一種領域特定語言 (DSL)，可編譯成 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 以供部署。

在 Azure 上使用 Terraform 進行跨平台 IaC

當需要多雲或與提供者無關 (provider-agnostic) 的工作流程時，Terraform 可作為 Azure 原生 IaC 的補充。azurerm provider 用於管理 Azure Resource Manager 資源，且應鎖定版本；即使 features {} 為空，也應包含它以啟用提供者功能。其他常見的 provider 包括用於 AAD 物件的 azuread 和用於工具值的 random。透過服務主體、託管代理程式上的 Managed Identity 或 Azure CLI 進行驗證。為每個環境採用清晰的 provider 組態策略，並將可重用的模組與其輸入變數和輸出進行集中管理。

狀態 (State) 管理至關重要。使用 azurerm 後端將遠端狀態儲存在 Azure Storage 中：設定 resource_group_name、storage_account_name、container_name 和 key；使用 managed identity 或 SAS 進行驗證；並在 blob 容器上啟用軟刪除和版本控制。後端使用 blob 租用 (leases) 來鎖定狀態，以防止並行修改。對儲存體帳戶的存取應透過 RBAC 進行閘道控制，並可選擇性地使用 Private Endpoints 加以限制。保持狀態檔案在環境之間隔離，並且根據設計絕不將機敏資訊儲存在狀態中——必要時使用 Key Vault 和 data sources 來擷取機敏資訊。

Workspaces 在相同的組態內提供狀態的邏輯隔離，用於環境分支，例如 dev、test 和 prod。使用 terraform workspace select，並確保後端 key 中包含 workspace 名稱以避免衝突 (例如 myapp-${terraform.workspace}.tfstate)。對於差異不大的環境對等性，Workspaces 是絕佳的選擇；但當拓撲差異顯著時，應使用獨立的組態或模組，以避免漂移和條件式的複雜性。使用服務連線和 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 組成節點狀態，這些 MOF 各自獨立地針對不同功能 (例如：基礎作業系統強化與應用程式角色)。

Azure Automation State Configuration (Azure Automation DSC) 是一個受控的拉取服務 (managed pull service)。您在 PowerShell 中編寫組態，將其匯入至 Automation Account，然後啟動編譯作業以產生節點組態 (MOF)。節點使用註冊金鑰/端點透過

undefined

註冊，並且可以被分組、指派組態，以及設定每個節點的參數值。合規性報告會顯示最後套用的組態與偏移狀態；處於 ApplyAndAutoCorrect 模式的節點會在下次回報 (check-in) 時自動修復。編譯作業是可供稽核的建置產物，而角色型存取控制則限制了組態的編寫權限與節點的指派。

Ansible 是無代理程式 (agentless) 的，非常適合 Linux 機群組態與臨時性的協調作業。在 Azure 上，請使用

undefined

，它提供了用於運算、網路、Key Vault 等的模組。使用

undefined

外掛程式的動態清單 (Dynamic inventory) 能從您的訂閱或特定的資源群組與標籤中探索主機；憑證獲取可以使用服務主體、Azure CLI 或受控識別。若要與 Azure Pipelines 整合，可在 Linux 代理程式上安裝 Ansible，透過

undefined

或 Azure Resource Manager 服務連線登入，然後執行參考動態清單、變數群組與安全檔案的 playbook。Ansible 擅長於冪等且易讀的任務，並且可以補充 DSC，在以 Windows 為主的大量環境中處理跨平台工作流程與協調作業。

Chef 與 Puppet 提供了成熟的「原則即程式碼」模型與合規性報告。在 Azure VM 上，Chef 與 Puppet VM 擴充功能會在佈建時啟動代理程式，確保早期收斂。Chef Infra 使用 cookbook 與 Policyfile 來鎖定相依性並確保可重現的執行；Chef InSpec 將「合規性即程式碼」具體化，並將報告饋送至 Chef Automate 以了解偏移與控制態勢。Puppet 的 manifest 與模組用來編碼所需的狀態，並由 Code Manager 與環境提供晉升流程；Puppet Enterprise 提供集中式報告、角色型分類與修復功能。這兩種工具都透過模組與資源提供者與 Azure 整合，並且在需要遷移或混合式環境時，可以與 Azure 原生的 DSC 共存。

應用程式組態、不可變映像檔與政策即程式碼

Azure App Configuration 集中管理應用程式設定與功能旗標。功能旗標能夠實現漸進式推出：您定義旗標，並在需要時附加篩選條件，例如透過 Feature Manager 函式庫實現基於百分比的推出或使用者目標設定。標籤讓您可以依據環境或部署環 (ring) 來區分值。組態快照會擷取一組特定時間點、不可變的金鑰與標籤視圖，允許在多個服務間進行一致且可重現的推出，而不會因並行的金鑰變更而產生競爭條件 (race condition)。Key Vault 參考讓您可以將祕密保留在 Key Vault 中，同時在 App Configuration 中僅儲存參考；應用程式的受控識別必須對該祕密擁有 get 權限，而用戶端函式庫會解析並快取祕密，並提供可選的動態重新整理功能。請對這兩項服務使用 RBAC 和網路隔離來保護存取。

不可變基礎架構透過從已知的映像檔重建來取代修改主機，從而消除組態漂移。Packer 的 azure-arm (現為 azure) builder 會從基礎作業系統建立映像檔，執行 provisioner (如 shell、PowerShell、Ansible)，並將其發布到具有複寫區域和語意化版本控制的 Shared Image Gallery。一個黃金映像檔管線通常會對 Packer 範本進行 lint 檢查、建置映像檔、執行弱點與合規性掃描 (例如 InSpec)、對其進行整合測試、將其推廣至 gallery，然後更新 VM Scale Sets 或主機集區。透過 VM Scale Sets、滾動式或基於健康狀態的升級，以及自動作業系統映像檔升級，您可以獲得安全、一致的推出，並可透過選擇先前的映像檔版本來輕鬆回滾。

政策即程式碼 (Policy as code) 強制執行護欄 (guardrails)。Azure Policy 定義是包含一個 policyRule 的 JSON 物件，該規則會評估資源屬性並產生效果，例如 deny、audit、append、modify 或 deployIfNotExists 以進行自動修復。將定義參數化以便重複使用；將它們與方案 (initiatives) (即政策集定義) 分組，以實現一致的指派和集中的合規性追蹤。在管理群組、訂閱或資源群組範圍指派政策；為 modify 和 deployIfNotExists 政策啟用修復任務，以使現有資源符合規範。將政策產物儲存在原始碼控制中，透過 pull request 進行審查，並透過 Bicep、ARM 或 Terraform 部署，以在不同環境間達成一致的晉升。

對於 Kubernetes，OPA/Gatekeeper 強制執行准入時的約束。ConstraintTemplates 定義 Rego 政策及其結構描述 (schema)；Constraints 則將這些政策實例化到叢集上。常見的控制措施包括將映像檔限制在受信任的登錄檔庫、要求必須有標籤/註釋，或防止特權 pod。Gatekeeper 與 GitOps 工具 (Flux/Argo CD) 以及透過 conftest 進行的 CI 測試整合。Azure Policy for Kubernetes 建構於 Gatekeeper 之上，提供跨 AKS 叢集的 Azure 原生指派與合規性視圖，將雲端與叢集的治理統一在單一的態勢儀表板下。

實務問題情境

Spotify 必須標準化 Azure 基礎架構、減少組態漂移，並加速在橫跨 Windows 與 Linux、AKS 以及基於 VM 的工作負載的微服務中安全地推出功能。

依據領域 (網路、資料、運算) 使用 Bicep 模組來模型化雲端資源，並透過範圍設定在管理群組下的訂閱來部署它們。這會產生具類型、可維護的宣告，清晰的範圍界定，且無須忍受 ARM JSON 的冗長即可重複使用。
對於由多個團隊使用的共享平台服務，使用少量連結的 ARM 範本規格 (template specs)。託管為範本規格的連結範本提供了版本化、不可變的產物，並將平台團隊的步調與應用程式團隊脫鉤。
對於跨雲的邊緣與 CDN 相依性，選擇 Terraform，並使用 azurerm 後端將遠端狀態儲存在每個工作區 (開發/測試/生產) 的 Azure Storage 中，並使用 blob 租用來進行鎖定。這在安全隔離狀態的同時，保留了單一的管線模式，並實現了一致的晉升。
將應用程式組態與功能旗標集中在 Azure App Configuration 中。帶有百分比篩選器和標籤的功能旗標可實現環形部署 (ring-based rollouts)；組態快照確保每個部署階段都使用一組不可變且經過稽核的金鑰。
將祕密儲存在 Azure Key Vault 中，並從 App Configuration 參考它們。在執行時期使用受控識別解析參考，使得金鑰輪替無需重新部署，並將祕密從應用程式組態與管線中移除。
針對 VM 工作負載採用不可變映像檔，使用 Packer 來建置黃金映像檔並發布到 Shared Image Gallery。一條管線會執行強化腳本與 InSpec 掃描、為映像檔加上標籤，並且只晉升通過的版本。VM Scale Sets 使用 gallery 中的映像檔來進行藍/綠部署與滾動式升級，從而消除漂移。
使用 Azure Policy 方案來強制執行護欄，例如拒絕私有子網上的公用 IP 暴露、要求將診斷設定傳送到 Log Analytics，以及自動部署備份政策。在管理群組層級進行指派以獲得廣泛的覆蓋範圍，並為現有資源建立修復任務，以快速收斂態勢。
透過應用約束來使用 OPA/Gatekeeper 保護 AKS，以封鎖不合規的映像檔與特權 pod。政策儲存於 Git 並進行版本控制，在 CI 中使用 conftest 進行驗證，並透過 GitOps 應用，以確保叢集狀態始終與政策保持一致。
使用 Azure Automation DSC 管理 Windows 伺服器組態。節點使用 Register-AzAutomationDscNode 進行註冊，並使用 ConfigurationMode=ApplyAndAutoCorrect 來偵測並修復漂移；編譯作業會為每個角色產生 MOF 檔案，而合規性儀表板會呈現漂移以供調查。
使用 Ansible 的 azure_rm 動態庫存清單與 azure.azcollection 模組來管理 Linux 組態與協調作業。Azure Pipelines 使用受控識別進行驗證，以冪等 (idempotently) 方式執行 playbook，並協調跨服務的更新，與 Windows 上的 DSC 互補。
利用 Chef InSpec 設定檔 (profile) 在映像檔與執行中的主機上實現跨平台的合規性即程式碼，並將結果饋送至 Chef Automate 以產生報告。這將可稽核、可測試的控制措施帶入管線與生產環境，確保法規要求得到持續驗證。

這個組合提供了具類型、模組化的 IaC (Bicep/Terraform)、不可變的主機 (Packer)、集中的應用程式組態 (App Configuration/Key Vault)、持續的組態強制執行 (Azure Automation DSC, Ansible) 以及強大的治理 (Azure Policy, Gatekeeper)。它減少了漂移、縮短了復原與推出的時間，並使合規性變得可證明。

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

練習這些題目 → · 在 ExamRoll.io 上限時練習 →