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) 以宣告方式或透過可合成 (synthesize) 為 CloudFormation 的程式碼來描述資源。諸如 AWS OpsWorks 和 AWS Systems Manager 等組態層，會在 EC2 和混合型機群的執行個體上強制執行並回報其期望狀態。Secrets、參數和映像檔烘焙 (image-baking) 完整了整個生命週期，實現了大規模、不可變且安全的部署。

CloudFormation 堆疊、變更控制與治理

CloudFormation 堆疊 (stack) 是部署的單位。圍繞生命週期邊界和所有權來設計堆疊，以最小化爆炸半徑。謹慎使用參數，並偏好使用帶有主見的預設值，搭配對應 (mapping) 或 SSM 查詢。僅透過 Outputs 和 Fn::ImportValue 匯出和匯入穩定、共享的值，以避免緊密耦合。

巢狀堆疊 (Nested stack) 封裝了可重複使用的元件，並保持父範本的精簡。父堆疊可以將參數傳遞給子堆疊並取用其輸出，從而實現模組化架構（例如，一個共享網路的巢狀堆疊被一個應用程式堆疊所取用）。保持巢狀堆疊專注於單一職責（VPC、資料層、應用層），並對其進行獨立的版本控制。

StackSets 可將單一範本部署到多個帳戶和區域。搭配 AWS Organizations 使用服務管理的權限模型，以自動部署到 OU (組織單位) 並自動納入新帳戶。設定操作偏好（最大並行帳戶/區域數、容錯能力）以控制部署的推出。針對每個帳戶或區域的參數覆寫，可讓您根據本地限制來調整標準範本。監控 StackSet 和堆疊執行個體的漂移，以偵測帶外變更。

變更集 (Change set) 提供了安全、可供人為審查的更新。在執行 ExecuteChangeSet 之前，務必先 CreateChangeSet 並逐一檢查資源的影響、替換情況以及潛在的資料遺失。將變更集整合到自動化管線中，以進行閘道式核准。

漂移偵測會驗證堆疊資源是否與範本相符。定期對關鍵的堆疊和 StackSets 執行漂移偵測；並理解並非所有資源類型的所有屬性都會被評估（不支援的屬性會回報為「未檢查」）。將漂移視為一個事件：進行調查、擷取情境，並透過更新堆疊或將漂移程式碼化後重新套用的方式來修正。

堆疊政策是 JSON 文件，可在更新期間保護關鍵資源。拒絕更新不可替代的資源（例如，生產環境的資料庫、Route 53 區域），並使用 StackPolicyDuringUpdateBody 為特定變更暫時開闢一條精準的途徑，然後再恢復更嚴格的政策。結合終止保護和 DeletionPolicy (Retain/Snapshot) 作為護欄。對於具有外部狀態的資源（如 S3 儲存貯體），需規劃其刪除行為。如果儲存貯體在刪除前必須被清空，請實作一個自訂資源，以便在堆疊刪除時清除物件。

AWS CDK 與 CloudFormation 的擴充性

AWS CDK 使用熟悉的語言（TypeScript、Python、Java、.NET、Go）來建立基礎設施模型。建構 (construct) 是 CDK 的基本建構區塊：

• L1 建構 (CfnXxx) 是從 CloudFormation 規範中產生，並與資源一對一對應。
• L2 建構增加了高階的意圖和合理的預設值（例如，ApplicationLoadBalancedFargateService）。
• L3 「模式」(pattern) 組合了多個 L2，以形成可立即使用的架構。

一個 CDK 應用程式包含一個或多個堆疊。在 cdk synth 期間，應用程式會解析情境查詢（例如，VPC ID）、渲染資產，並產生一個 CloudFormation 範本。在部署之前，cdk bootstrap 會建立環境所需的資產儲存貯體和角色。使用 cdk diff 預覽變更，然後用 cdk deploy 提交範本和資產；CDK 內部會使用變更集，並會顯示及確認安全敏感性變更（IAM 或資源替換）。透過 Aspects 為堆疊和資源加上標籤，以強制執行全組織的標籤策略。當 L2 抽象化不足時，可使用逃生口 (escape hatch) (node.defaultChild) 或降級使用 L1 建構。

CloudFormation 自訂資源可將 IaC 擴展至任何可透過 API 存取的東西。一個由 Lambda 支援的自訂資源會接收帶有 RequestId、PhysicalResourceId 和屬性的 Create、Update 和 Delete 事件。該函式必須：

• 具備冪等性，並在逾時期間內將成功/失敗的結果回傳到預先簽章的 ResponseURL。
• 設定一個穩定的 PhysicalResourceId 來追蹤更新，並在 Delete 事件時驅動清理作業。
• 處理重試和穩定性等待，以應對最終一致性的下游服務。

為 Lambda 使用最小權限的 IAM 執行角色，在 API 呼叫中加入指數退避機制，並透過 RequestId 進行日誌關聯。對於大型或長時間執行的操作，可考慮使用 Step Functions 搭配一個等待執行權杖 (token) 的自訂資源。在適用情況下，優先使用 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 的範圍限定在需要存取的主體上。

Parameter Store 非常適合用於非密鑰的組態（例如功能旗標、AMI ID、端點）。使用具備版本控制的 SSM 參數，以在不同環境之間建立安全的回滾和原子性的升級。在 CDK 中，使用 ssm.StringParameter.fromStringParameterName 匯入值，或使用 fromSecureStringParameterAttributes 匯入安全值，並將參數讀取串接到使用者資料或應用程式的啟動程序中。

Secrets Manager 專為生命週期控制、輪換和稽核而設計。將輪換功能與支援的引擎（RDS、Aurora）或自訂的 Lambdas 整合。在執行期參考密鑰，而不是將其烘焙到 AMI 中，以避免過時資料的擴散。對於容器化或無伺服器的工作負載，可透過由 Secrets Manager 參考支援的環境變數來注入密鑰，或透過 ECS/TaskDefinition secrets 來掛載；並透過使用短 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 透過「關聯 (Associations)」來強制執行期望狀態，這些關聯會依排程、事件或執行個體啟動時執行 SSM 文件 (YAML/JSON)。使用 AWS-RunShellScript、AWS-ApplyAnsiblePlaybooks、AWS-ConfigureDocker 和自訂文件來收斂組態。將關聯參數化並依標籤指定目標，以進行整個機群的變更。
• 組態合規性會呈現關聯狀態和 Patch Manager 的結果。使用修補基準來定義核准的分類，並與維護時段 (Maintenance Windows) 綁定，以及依執行個體標籤、修補群組或資源群組來追蹤合規性。混合式啟用 (Hybrid Activations) 將地端節點註冊為受管執行個體，以實現一致的治理。
• Inventory 會記錄套件、檔案和 Windows 更新；Resource Data Sync 會將資料匯出至 S3 和 Athena 以進行企業級報告。將 SSM 合規性與 AWS Config 規則和自動修復 (Systems Manager Automation runbooks) 結合，以完成從偵測到修正的閉環。

不可變基礎設施可消除漂移並加速復原。EC2 Image Builder 透過以下方式將映像檔管道程式碼化：

• 元件 (Components) (安裝、強化、驗證步驟) 以文件形式表示。
• 映像檔配方 (Image recipes) 組合了元件和基礎映像檔。
• 基礎設施組態 (Infrastructure configurations) 定義了子網路、安全群組、執行個體描述檔和日誌記錄。
• 分發組態 (Distribution configurations) 將 AMI 複製到不同區域並分享給其他帳戶。

新增測試元件以驗證 CIS 基準、代理程式健康狀態 (SSM/CloudWatch) 和應用程式冒煙測試。對映像檔進行版本控制並標上語意化標籤。將 AMI ID 發布到 Parameter Store (例如 /app/frontend/ami)，並在 Auto Scaling 啟動範本中參考。使用滾動式或藍綠部署策略進行部署；替換執行個體而非原地修補，以維持不可變性。將弱點掃描 (Amazon Inspector) 的結果饋入管道的晉升閘門。不要將機密資訊烘焙到映像檔中；在開機時透過 Instance Metadata Service v2 和 SSM/Secrets Manager 參考來擷取。

實務問題情境

Capital One 需要為一個面向客戶的平台標準化多帳戶、多區域的部署，同時強制執行嚴格的治理、機密管理，並消除組態漂移。該環境橫跨 AWS Organizations 中的數百個帳戶，並對資料庫存取和作業系統強化有嚴格的控制。

1. 使用 AWS CDK 建立基礎設施模型，並合成為 CloudFormation

• 實作 L2/L3 建構體 (constructs) 來建立 VPC、ALB、Auto Scaling 群組和 Aurora。在 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 Windows) 進行離峰時間修補，並使用由 Resource Data Sync 匯總的合規性儀表板。
• 為何選擇 State Manager：基於代理程式的收斂，橫跨 EC2 和地端環境，具備持續的合規性報告與規模化的修復能力。

7. 採用 EC2 Image Builder 實現不可變基礎設施

• 使用元件建構強化的 AMI，包含 CIS 基準、SSM/Inspector 代理程式和應用程式執行期的相依套件。執行測試，將 AMI ID 發布到 Parameter Store，並將 Auto Scaling 啟動範本連結到版本化的參數。透過滾動式更新進行部署；在 AMI 更新時觸發執行個體刷新。
• 為何選擇 Image Builder：可重現、可測試的映像檔，可消除漂移並透過快速復原縮短平均復原時間。

8. 管道的協同運作與治理

• 實作一個多階段管道，執行 cdk synth/diff、建立變更集、暫停以待核准，然後執行。使用 EventBridge 在儲存庫變更時觸發 StackSet 更新。每晚執行漂移偵測掃描，並針對差異開啟 OpsCenter 項目。
• 為何採用此方法：具備可稽核晉升的持續交付、主動的漂移偵測，以及透過權責分明的服務職責實現的自動化修復。

← CI · 所有領域 · 監控、日誌記錄與可觀測性 →

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

瀏覽 Amazon →