Google PCA: DevOps、交付工程與基礎設施即程式碼 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

屬於 Google Professional Cloud Architect — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

基礎設施即程式碼與組態管理

Terraform
- 模組 (Modules)：擷取可重複使用的模式 (例如 VPC、GKE 叢集、服務帳戶、IAM 綁定)。對模組發行版進行版本控制與鎖定；發布內部模組登錄檔庫。
- 遠端狀態 (Remote state)：將狀態儲存在啟用版本控管、保留政策和 CMEK 的 Cloud Storage 中；啟用鎖定功能；透過 IAM 和統一的值區層級存取權來限制存取；備份狀態。
- 計畫與政策檢查：在 CI 中執行

undefined

；要求人工審查計畫；強制執行政策即程式碼 (OPA/Conftest、Sentinel 或 Policy Controller) 以阻擋違規行為 (例如，公開的 bucket、過於寬鬆的 IAM 綁定)。

環境晉升：每個環境使用獨立的工作區 (workspaces) 或獨立的狀態/後端；透過相同的模組版本和變數來晉升變更；絕不手動編輯雲端資源。敏感輸入應來自 Secret Manager 或自動化流程，絕不寫死在程式碼中。
失敗模式：將密鑰洩漏到狀態中、未鎖定狀態下進行並行變更、因帶外編輯 (out-of-band edits) 造成的漂移，以及會破壞 destroy/replace 操作的隱性依賴。
Google Cloud 部署範本與宣告式組態
- 使用宣告式工具 (Terraform、Google Cloud Deployment Manager 或 Kubernetes Configuration as Code) 來定義期望狀態，而非使用指令式步驟的腳本。
- 偏好不可變基礎設施 (immutable infrastructure)：替換執行個體範本並滾動更新 MIGs；推出新的 GKE Deployments，而不是就地修補 pod。不可變模式讓回滾和稽核變得簡單。
- Deployment Manager 支援用於 Google Cloud 資源的 Jinja/Python 範本，但僅限於 Google Cloud；Terraform 提供更廣泛的生態系和政策工具。應根據組織的標準化和團隊技能來選擇。
Kubernetes manifest、Helm、Kustomize 與 GitOps
- Manifests：保留基礎範本，並搭配環境疊加層 (overlays)；僅將因環境而異的部分參數化 (例如，副本數、資源限制、端點)。
- Helm：使用 chart 來打包、樣板化服務並進行版本控制；鎖定依賴項；鎖定映像檔摘要 (digest)。失敗模式：過度樣板化會模糊意圖並使審查複雜化。
- Kustomize：管理疊加層 (基礎 + 環境補丁)；當純 Kubernetes 已足夠時，它比 Helm 更簡單。
- GitOps：由一個控制器 (例如 Config Sync、Argo CD、Flux) 持續將叢集調諧 (reconcile) 至 Git 中定義的期望狀態；每個變更都是一個帶有審查和稽核軌跡的 PR。自動偵測並修正漂移。

漸進式交付、供應鏈、測試與驗證

功能旗標與流量管理
- 功能旗標 (Feature flags) 將部署與發布解耦；用於逐步揭露功能、A/B 測試和緊急關閉開關。確保旗標狀態有版本控制且可稽核；淘汰過時的旗標。
- 流量分割：在 Cloud Run 上，跨不同修訂版本使用基於百分比的路由；在 GKE 上，使用支援加權路由的服務網格 (service mesh) 或 ingress 控制器。對於在單一主機名稱/TLS 下的 API，在 HTTP(S) Load Balancer 後方為每個路徑保留獨立的後端服務；路徑路由能乾淨地隔離新舊版本，同時保留單一 URL 和憑證。
- 藍綠部署 (Blue-green)：運行兩套可隨時上線的生產環境堆疊；透過負載平衡器、服務選擇器 (service selectors) 或 Cloud Run 修訂版本的流量，以原子性操作切換流量。這能實現即時回滾，但會使穩定狀態的成本加倍。
- 金絲雀與漸進式推出：從一小部分流量開始逐步增加，同時衡量黃金指標 (golden signals) 和業務 KPI；若發生效能衰退 (regression) 則自動回滾。
軟體供應鏈控制
- 映像檔掃描：啟用 Artifact Analysis 漏洞掃描；當發現嚴重漏洞或已知的有問題基礎映像檔時，讓建置失敗；維持固定的修補節奏。
- 來源證明與簽署：在 Cloud Build 中產生符合 SLSA 規範的建置來源證明 (provenance)；使用 Cosign 簽署產物 (artifacts)；強制執行 Binary Authorization 政策，要求在部署前必須有證明 (attestations)。
- 依賴項管理：鎖定版本和摘要 (digest)，維護 SBOMs，將關鍵依賴項納入版本控制 (vendor)，並驗證校驗和 (checksums)。失敗模式包括傳遞性依賴漂移和受損的登錄檔庫。
測試金字塔、部署閘門與部署後驗證
- 金字塔：強調快速的單元測試；增加整合測試和合約測試；執行有針對性的端到端測試。保持測試資料的真實性並進行去識別化 (使用 Cloud DLP 移除 PII)。
- 部署閘門：在晉升前，強制執行測試通過率、漏洞狀態、政策合規性和程式碼審查的閾值；當風險較高時，要求對生產環境的部署進行手動批准。
- 部署後驗證：使用 Cloud Monitoring、Error Reporting 和 Trace 執行煙霧測試、綜合性檢查和金絲雀分析。如果 KPI 下降，觸發自動回滾，並開啟一個附帶捕獲上下文資訊的事件。
- 維運診斷：在需要的地方部署 Cloud Logging 代理程式，並對服務進行檢測 (instrument) 以便使用 Trace 和 Debugger。保留操作手冊 (runbooks) 以進行安全的修復 (例如，線上調整永久磁碟大小並執行