【Day 26】Azure Policy & Blueprints：合規治理與資源防呆實戰 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
核心考點：Azure Policy、Policy Definition、Assignment、Initiative、Scope、Compliance、Remediation、Resource Locks、Microsoft Purview、Azure Blueprints 退休與 Deployment Stacks、AWS Organizations / SCP 雙雲治理對照。

🎯 前言與今日目標

Day 25 我們把「秘密」與「告警」裝進 Azure Key Vault 與 Microsoft Sentinel：前者保護 Secrets / Keys / Certificates，後者負責 SIEM / SOAR。今天則往上一層，把問題從「單一資源怎麼保護」提升到「整個組織怎麼訂規則」。

Titan 科技目前最大的治理風險，不是沒有安全工具，而是每個團隊都知道最佳實務，卻沒有人能保證所有資源真的遵守最佳實務：

1. 開發人員可能把 VM 建在未核准的 Azure Region。
2. 部門可能忘記替資源加上 Environment、CostCenter 等必要 Tags。
3. 生產資料庫可能被具有足夠權限的管理員誤刪。
4. 資料治理團隊需要知道企業有哪些資料資產、資料從哪裡來，以及誰負責治理。

這時候要先分清楚三種不同問題：

「規則有沒有被遵守？」→ Azure Policy
「資源能不能被刪除或修改？」→ Resource Locks
「資料資產與中繼資料怎麼治理？」→ Microsoft Purview

而本日標題中的 Azure Blueprints 還有一個非常重要的 2026 年更新：它不是「現在應該開始學的新治理方案」，而是正在分階段退役的舊服務。Microsoft 官方文件指出，Azure Blueprints 將於 2027 年 1 月 31 日退休，並已自 2026 年 7 月 31 日開始分階段退役；新的 Blueprint 定義與版本已不能建立。Microsoft 建議將既有內容遷移至 Azure Deployment Stacks 與 Template Specs。因此，今天我們會保留 Blueprints 的歷史定位，但不把它當成現行 AZ-900 實作答案。

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 Titan 治理長城：Policy、Lock、Purview 三層分工

┌────────────────────────────────────────────────────────────┐
│                 Titan 雲端治理長城                         │
├────────────────────────────────────────────────────────────┤
│  組織規則                                                  │
│      │                                                     │
│      ▼                                                     │
│  Azure Policy ──「哪些資源符合組織規範？」                 │
│      │                                                     │
│      ├── Audit / Deny / Modify / DeployIfNotExists         │
│      │                                                     │
│      ▼                                                     │
│  Resource Lock ──「避免資源被誤刪或誤修改」                │
│      │                                                     │
│      ▼                                                     │
│  Microsoft Purview ──「資料資產與中繼資料怎麼治理？」      │
└────────────────────────────────────────────────────────────┘

💡 架構師重點筆記：Azure Policy 是「規則與合規」；Resource Lock 是「刪除／修改防呆」；Purview 是「資料治理與資料資產可見性」。三者不能互相替代。

📐 Azure Policy 的治理流程

┌────────────────────────────────────────────────────────────┐
│ Azure Policy 治理生命週期                                  │
├────────────────────────────────────────────────────────────┤
│ Policy Definition（定義規則）                              │
│          │                                                 │
│          ▼                                                 │
│ Assignment（指派到 Scope）                                 │
│          │                                                 │
│          ▼                                                 │
│ Evaluate（評估資源是否符合）                               │
│          │                                                 │
│      ┌───┴───────────┐                                     │
│      ▼               ▼                                     │
│  Compliant       Non-compliant                             │
│                      │                                     │
│                      ▼                                     │
│              Remediation（修復）                           │
└────────────────────────────────────────────────────────────┘

Azure Policy 的核心不是「幫你登入 Azure」，也不是「授予使用者權限」，而是建立並強制組織標準。Microsoft 官方說明中，Policy 可用於大規模執行組織標準與評估合規狀態，並能透過合規性儀表板檢視環境狀態，以及對既有資源進行大量修復、對新資源進行自動修復。

📖 AZ-900 核心名詞解釋與速查

1. Azure Policy（Azure 原則）

   • 定義：用來建立、指派與評估資源治理規則的服務。
   • 考點：例如限制可使用的 Region、要求特定 Tags、稽核不符合規範的資源。
   • AWS 對照：最接近 AWS Organizations 的 SCP 治理思維，但兩者不是一對一服務替換。

2. Policy Definition（原則定義）

   • 定義：描述「什麼條件下算違規」以及要採取什麼 Effect 的規則。
   • 考點：Definition 是規則本身，不等於已套用到環境。

3. Policy Assignment（原則指派）

   • 定義：把 Policy Definition 或 Initiative 套用到特定 Scope。
   • 考點：常見 Scope 包括 Management Group、Subscription、Resource Group，以及在支援的情況下更細的資源範圍。

4. Initiative（方案）

   • 定義：將多個 Policy Definitions 集合成一組治理方案。
   • 考點：當企業需要一次管理多條相關規則時使用。

5. Effect（效果）

   • 定義：政策符合或不符合條件後要採取的行為，例如 Audit、Deny、Modify、DeployIfNotExists。
   • 考點：Audit 偏向「記錄違規」；Deny 可阻止不符合規則的建立／更新；Modify 與 DeployIfNotExists 可用於修正或部署相關組態，但實際效果取決於 Policy Definition 與權限設定。

6. Resource Lock（資源鎖）

   • 定義：保護 Subscription、Resource Group 或 Resource，避免意外刪除或修改。
   • 考點：常見兩種鎖定層級為 CanNotDelete 與 ReadOnly。鎖可以從父層繼承到子資源。

7. Microsoft Purview

   • 定義：Microsoft 的資料治理、資料安全性與合規性產品組合。
   • 考點：目前資料治理體驗包含 Data Map 與 Unified Catalog；重點是資料資產、中繼資料、資料探索與治理，而不是 Azure Resource Manager 資源的建立／刪除規則。

8. Azure Blueprints（藍圖）

   • 定義：舊有的治理與部署封裝機制，可把政策、角色、ARM Template 等治理構件組合後指派。
   • 現況：正在退休；2026/7/31 起分階段退役，2027/1/31 正式退休。不要把它當成新的 AZ-900 現行架構答案。

9. Azure Deployment Stacks（部署堆疊）

   • 定義：用於將一組 Azure 資源作為單位進行部署、生命週期管理與保護的現代治理能力。
   • 考點：Microsoft 建議用 Deployment Stacks 搭配 Template Specs 取代 Blueprints 的相關能力。

1. Azure Policy：從「規則」到「合規」

Policy Definition 不等於 Policy Assignment

這是 AZ-900 很容易混淆的觀念。

可以把它想成公司法規：

• Definition = 公司寫好的「法條」。
• Assignment = 把法條正式公布給某個管理範圍。
• Scope = 法條適用的疆域。
• Compliance = 檢查目前資源是否遵守法規。
• Remediation = 找到違規後，依政策能力執行修復。

例如 Titan 科技規定「正式環境 VM 只能部署在 Japan East 或 Southeast Asia」。可以建立一條 Location Policy，再把它指派到 Subscription 或 Management Group。這樣就不必靠每位工程師自己記住規則。

Audit vs Deny：考場最重要的分水嶺

┌────────────────────────────────────────────────────────────┐
│ Audit vs Deny 治理決策分歧                                 │
├────────────────────────────────────────────────────────────┤
│ 需求：「我要知道誰違規」                                   │
│         │                                                  │
│         ▼                                                  │
│      Audit ── 不符合規則 → 記錄為 Non-compliant            │
│                                                            │
│ 需求：「違規資源根本不能建立」                             │
│         │                                                  │
│         ▼                                                  │
│       Deny ── 不符合規則 → 阻止 ARM 請求                   │
└────────────────────────────────────────────────────────────┘

💡 Why：Audit 適合「先盤點、後治理」的導入階段；Deny 適合規範已成熟、不能允許例外的安全邊界。直接全面 Deny 的風險，是把合法但尚未完成標籤或設定的既有部署流程一起擋住。

Tags：不要把「要求 Tag」誤認成「Tag 自動繼承」

Azure Resource Manager 的 Tags 並不是因為你在 Resource Group 或 Subscription 上加了 Tag，就自然讓所有子資源取得相同 Tag。企業若要求每個資源都具備 Environment、CostCenter 等欄位，可以使用 Azure Policy 來稽核、拒絕或在符合條件的情況下透過 Modify 效果修正 Tag。

這就是為什麼「我要強制所有資源有 CostCenter Tag」通常想到 Azure Policy，而不是 Resource Lock。

2. Resource Lock：權限很大，也可能仍然刪不掉

Resource Lock 解決的是另一個問題：防止意外修改或刪除。

Microsoft 官方文件指出，可以在 Subscription、Resource Group 或 Resource 層級建立鎖；父層的鎖可以由子資源繼承。Management Group 本身不能直接加 Resource Lock。

兩種常見鎖定：

⚠️ 高頻陷阱：Resource Lock 與 RBAC 是兩件事。RBAC 決定「誰有什麼權限」，Lock 則是在資源管理操作上增加保護。即使使用者具有足夠的 RBAC 權限，仍可能受到 Lock 的限制；要進行被鎖住的操作，通常必須先移除相應鎖定。

3. 企業治理四劍客：Locks vs RBAC vs Policy vs Purview 三維邊界解耦

在 AZ-900 考題中，考生最常在治理工具的選擇題中失分，原因在於未能釐清「防呆」、「權限」、「合規」與「資料治理」的本質邊界：

💡 秒殺排他法口訣：

• 問「防止資料庫被維運人員誤刪」➜ Resource Locks（不能選 RBAC 或 Policy）。
• 問「限制開發人員僅能指派為唯讀人員」➜ Azure RBAC（身分授權）。
• 問「強制所有新增的 VM 必須套用 CostCenter 標籤」➜ Azure Policy（合規規則）。
• 問「掃描並盤點全公司有哪些敏感客戶個資資料資產」➜ Microsoft Purview（資料探索治理）。

4. Microsoft Purview：不要和 Azure Policy 混在一起

Microsoft Purview 現代資料治理體驗包含 Data Map 與 Unified Catalog。Data Map 偏向技術層的資料資產與中繼資料地圖；Unified Catalog 則提供更偏商務與治理使用者的資料探索、資料產品與治理能力。

┌────────────────────────────────────────────────────────────┐
│ Microsoft Purview 資料治理                                 │
├────────────────────────────────────────────────────────────┤
│ Data Sources                                               │
│   │                                                        │
│   ▼                                                        │
│ Data Map ── 掃描 / 分類 / 建立資料資產中繼資料             │
│   │                                                        │
│   ▼                                                        │
│ Unified Catalog ── 治理網域 / 資料產品 / 探索與治理        │
└────────────────────────────────────────────────────────────┘

💡 考場判斷：題目問「限制 VM Region、強制 Tag、稽核資源設定」→ Azure Policy；問「保護資料庫避免刪除」→ Resource Lock；問「探索資料資產、資料目錄、中繼資料、資料治理」→ Microsoft Purview。

5. Azure Blueprints：2026 年一定要知道的「歷史考點」

Blueprints 是本日最特殊的部分，因為它曾經是很多 AZ-900 題庫的標準答案，但現在不能再直接當成現行治理服務推薦。

Microsoft 官方目前的退休時程為：

因此，舊題庫如果問「哪個服務可以自動重新套用 Blueprint Lock？」在歷史題庫語境中可能會得到 Azure Blueprints；但在今天的架構決策中，應該辨識這是退役中的歷史答案，並改用 Microsoft 建議的 Deployment Stacks + Template Specs 方向。

⚠️ 考綱變更：本系列 Day 1 已公開的 30 天標題不能任意修改，所以仍保留「Azure Policy & Blueprints」。但本文將 Blueprints 定位為「歷史考點＋退役遷移知識」，現行治理主軸改為 Azure Policy、Resource Locks、Microsoft Purview，以及 Deployment Stacks。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的治理失控危機

Titan 科技目前擁有 12 個 Azure Subscriptions。稽核團隊發現：

• 有些 VM 被部署到未核准 Region。
• 部分資源缺少 CostCenter 與 Environment Tag。
• 開發人員在測試環境誤刪了一個 Resource Group。
• 資料治理團隊則需要建立全企業資料資產清單。

CTO 問 Chief Cloud Architect：

「我要的是一套能從組織層級往下治理的方案，但不要把 RBAC、資源鎖、資料治理全部混成同一個工具。你會怎麼設計？」

🧩 決策任務

• A：在每台 VM 上建立 Resource Lock，並要求所有工程師自行檢查 Region 與 Tags；資料資產則以 Resource Group 名稱管理。
• B：在適當的 Management Group / Subscription Scope 指派 Azure Policy，治理 Region、Tags 與資源組態；對不可誤刪的生產資源使用 Resource Lock；資料資產治理則導入 Microsoft Purview。對舊有 Blueprints 逐步規劃遷移至 Deployment Stacks / Template Specs。
• C：使用 Microsoft Purview 阻止 VM 建立在錯誤 Region，並使用 Azure Policy 取代所有 Resource Locks。
• D：使用 Azure RBAC 限制所有 VM 只能建立在特定 Region，並以 Tags 取代 Resource Locks。

🎯 解題拆解與解析

✅ 正解：B

• Policy 解決規則問題：Region、Tags、組態標準屬於治理規則與合規性，應由 Azure Policy 統一管理。
• Lock 解決資源防呆問題：生產資料庫或關鍵 Resource Group 需要避免誤刪時，Resource Lock 是直接的保護機制。
• Purview 解決資料治理問題：資料資產探索、中繼資料與資料治理不等於 Azure Resource Manager 資源政策。
• Blueprints 不再是新架構的首選：現行 Microsoft 官方方向是規劃從 Blueprints 遷移到 Deployment Stacks 與 Template Specs。

❌ 陷阱分析：

• A：把 Policy 的組織級治理責任丟回人工流程，會產生組態漂移；而 Resource Group 名稱也不能取代真正的資料治理平台。
• C：Purview 不是用來限制 VM Region 建立的 Azure Resource Manager 治理工具；Policy 才是這類資源合規規則的核心。
• D：RBAC 控制「誰可以做什麼」，不等於「資源必須符合什麼組織規則」；Tags 也不是刪除防護機制。

🧠 架構師推理鏈：組織規則 → Azure Policy；防止誤刪 → Resource Lock；資料資產治理 → Purview；舊 Blueprints → 遷移 Deployment Stacks / Template Specs。

🎯 Part 3：AZ-900 精選高頻真題解析

📍 真題 1｜限制特定 Resource Group 建立 VM（ExamTopics Q277 改編）

題目：Titan 科技希望禁止 RG-Production 建立任何 VM，但允許團隊繼續在該 Resource Group 建立其他類型資源。應該採用哪一項？

• (A) Resource Lock
• (B) Azure RBAC Role
• (C) Tag
• (D) Azure Policy

正解：D — Azure Policy

解題推理：關鍵字是「只禁止某一類資源建立，但其他資源仍可建立」。這是治理規則，不是整個 Resource Group 的刪除／修改鎖定。Azure Policy 可以透過資源類型條件與 Deny Effect 達成這類限制。

❌ 陷阱：Resource Lock 不是用來精準禁止「只建立 VM」；RBAC 是身分與權限模型；Tag 本身只是分類資訊。

來源與驗證：改寫自 ExamTopics AZ-900 Question #277；該討論串的高票留言支持 D，並以 Microsoft Learn Azure Policy 官方文件交叉驗證。原題與社群討論可見：ExamTopics Q277。

📍 真題 2｜限制資源只能建立在核准 Region（ExamTopics Q145 改編）

題目：Titan 科技有一個 Subscription，現有資源分布於數個核准 Region。公司要求管理員未來只能在這些核准 Region 建立 Azure 資源。應該使用哪項服務？

• (A) Read-only Resource Lock
• (B) Azure Policy
• (C) Management Group
• (D) Reservation

正解：B — Azure Policy

解題推理：題目要求的是「建立資源時的治理規則」。Management Group 是治理 Scope 的容器，不是規則本身；Reservation 是成本／容量承諾方案；Resource Lock 則是防止修改或刪除。

來源與驗證：改寫自 ExamTopics AZ-900 Question #145；該討論串的社群回報與 Microsoft Learn 的 Azure Policy Scope / Compliance 說明一致。原題：ExamTopics Q145。

📍 真題 3｜Resource Lock 的範圍與繼承（ExamTopics Q303 改編）

題目：Titan 科技將 RG-Payments 設定為 CanNotDelete。下列敘述何者最符合 Azure Resource Lock 的行為？

• (A) Resource Group 的鎖只保護當時已存在的資源，新加入的資源不受影響。
• (B) Resource Group 的鎖可以由其中的資源繼承，之後新增的資源也會受到父層鎖定影響。
• (C) Resource Lock 只能套用到單一 Resource，不能套用到 Resource Group。
• (D) 具有 Owner RBAC 角色就一定可以忽略 Resource Lock。

正解：B

解題推理：Resource Lock 可以套用在 Subscription、Resource Group 或 Resource；父層的鎖可以由子資源繼承。這正是把鎖放在 Resource Group 層級來保護整批生產資源的原因。

來源與驗證：改寫自 ExamTopics AZ-900 Question #303 的 Resource Lock 考點；該討論串高票討論與 Microsoft Learn「Lock your Azure resources to protect your infrastructure」交叉驗證。原題討論：ExamTopics Q303。

📍 真題 4｜gratisexam 2020 題庫改編：治理規則與 Resource Group

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫中的 Azure 治理／合規類考點。該題庫屬歷史資料，本文不照錄原題，並以現行 Microsoft Learn 重新驗證。

題目：Titan 科技希望跨多個 Subscription 統一套用「只允許在核准 Region 建立資源」的規則。下列哪項最適合？

• (A) 為每個 Resource Group 建立不同名稱
• (B) 建立 Resource Lock
• (C) 使用 Azure Policy，並在適當的治理 Scope 指派
• (D) 使用 Reservation

正解：C

解題思路：跨多個 Subscription 的規則治理應考慮 Management Group 等上層 Scope，再由 Policy Assignment 套用治理規則。Resource Group 是資源生命週期容器，不是跨 Subscription 的治理規則引擎。

來源與驗證：2020 年題庫僅作題型與考點來源；現行答案以 Microsoft Learn Azure Policy 官方文件重新驗證。Microsoft 官方文件說明 Policy 可用來大規模執行組織標準與評估合規狀態：https://learn.microsoft.com/en-us/azure/governance/policy/overview。

📍 真題 5｜gratisexam 2020 題庫改編：Resource Lock 與治理政策的分工

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫中的 Resource Lock / Azure governance 類考點。舊題庫可能包含已退役或改名服務，本文僅保留仍適用的核心概念。

題目：Titan 科技要同時完成兩件事：

1. 禁止管理員把 VM 建立在未核准 Region。
2. 防止生產 Resource Group 被意外刪除。

下列哪個配對最合理？

• (A) 兩者都使用 Resource Lock
• (B) 兩者都使用 Azure Policy
• (C) Region 使用 Azure Policy；生產 Resource Group 使用 Resource Lock
• (D) Region 使用 Microsoft Purview；生產 Resource Group 使用 Tag

正解：C

解題推理：第一個需求是「規則合規」→ Policy；第二個需求是「防止刪除」→ Lock。這正是 AZ-900 最重要的治理服務分工題型。

來源與驗證：2020 年題庫僅作歷史題型參考；現行 Resource Lock 行為依 Microsoft Learn 官方文件重新驗證：https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources。

⚠️ 特別提醒：若舊題庫出現 Azure Blueprints 作為現行答案，必須先檢查題目版本。Azure Blueprints 正在 2026–2027 年分階段退休，不能直接當成今天的新架構推薦。

📐 Part 4：以戰代訓課程對照

⚠️ 考綱變更：本系列 Day 1 綱要保留「Azure Policy & Blueprints」標題，但 Azure Blueprints 已進入分階段退休流程。現行學習重點應放在 Azure Policy + Resource Locks + Microsoft Purview，Blueprints 只需理解歷史定位與退休遷移。

🚀 今日總結與明日預告

🎯 今日 3 分鐘精華速記

1. Azure Policy = 規則治理：限制 Region、要求 Tags、稽核／拒絕不合規資源，核心流程是 Definition → Assignment → Evaluation → Compliance / Remediation。
2. Resource Lock = 防誤操作：CanNotDelete 防刪除、ReadOnly 防修改與刪除；可套用在 Subscription、Resource Group、Resource，父層鎖可由子資源繼承。
3. Policy ≠ Lock ≠ Purview：Policy 管規則、Lock 管資源防呆、Purview 管資料治理；而 Azure Blueprints 正在退役，現行遷移方向是 Deployment Stacks + Template Specs。

🔮 明日預告

完成治理規則與資源防呆後，明天 Day 27 我們將進入【雲端國庫】：Azure Cost Management & Pricing Calculator（成本控制與 TCO 計算機）。

我們會拆解 Titan 科技如何從「不知道錢花去哪裡」進化到「能預算、能分析、能追蹤、能治理」，並特別釐清 Pricing Calculator、Cost Management、Tags 與已從考綱移除的 TCO Calculator 之間的差異。