💡 先搞懂問題
虛構公司「晴空食品」的資訊室訂了三條規定：所有資源只能放在東亞與東南亞，每個資源群組都要填成本中心標籤 costcenter，正式環境的共用資源不能被刪。規定寫在內部文件裡，也開了教育訓練。半年後盤點，仍然有十幾個儲存體帳戶開在日本東部，一半的資源群組沒有 costcenter，財務月底只能用猜的分攤帳單；更糟的是，一位有 Owner 權限的工程師清理測試環境時，把正式環境的虛擬網路也一起刪了。
很多人第一個想到的是收權限，但 Azure 角色型存取控制（Azure RBAC）回答的是「誰能做什麼」，它沒辦法表達「建立可以，但只能建在東亞」「建立可以，但一定要有 costcenter」；而且 Owner 本來就該有刪除權限，收掉反而影響正常維運。新手最常卡在這裡：把「誰能做」和「做出來要長什麼樣」混成同一件事，或以為加了鎖定、寫了標籤規範就能自動生效。
Azure 把這幾件事拆給不同的工具。Azure Policy 把規則寫成原則定義（policy definition），指派（assignment）到管理群組、訂用帳戶或資源群組後，Azure Resource Manager 會在資源建立或更新時評估，也會定期掃描既有資源，依效果（effect）決定要拒絕、只記錄，還是自動補上設定。標籤（tags）是貼在資源上的名稱與值，用來分類與彙總成本。資源鎖定（resource locks）則是在權限之上加一道封條，連 Owner 要刪除或修改都得先解鎖。
生活比喻：社區管委會的規約、門禁與封條
一棟社區大樓要維持秩序，靠的不是同一套辦法。管委會規約寫明陽台不能外推、冷氣室外機要裝在指定位置、外牆不能改色，不管是屋主自己裝修還是請包商，都要照規約；規約不在乎是誰動工，只在乎做出來的結果。門禁卡則決定誰能進大門、誰能進地下室機房，是另一套系統。消防設備和總電源箱上貼了封條，主委手上有鑰匙，但要打開也得先撕封條，這個動作會被看見。最後，每戶信箱貼著門牌，管理費、水電分攤都靠門牌對帳。
規約還分寫法：有的條文是「施工申請不符合就不准開工」，有的是「先登記列管、限期改善」，有的是「發現沒裝防墜網，管委會直接派人裝好」。這三種寫法，對應的正是 Azure Policy 的不同效果。
比喻有三個地方和實際不同。第一，社區規約多半靠鄰居檢舉、事後處理；Azure Policy 的 Deny 是在請求送到資源提供者之前就直接拒絕，但它對已經存在的不合規資源不會拆掉，只會在合規性結果標成「不符合」，要修正得靠補救工作或自己動手。第二，封條貼在設備外面，管不到從背後小門拿東西的人；資源鎖定也只作用在控制平面，透過資料平面刪除 Blob、修改資料庫資料，都不會被鎖定擋下。第三，大樓的門牌一戶一個，整層也不會自動幫每戶貼好；Azure 的標籤也一樣，資源群組上的標籤不會自動被裡面的資源繼承，要靠 Azure Policy 來補。
🎮 互動實驗室一：Policy 效果模擬器
晴空食品在訂用帳戶 sub-qingkong 上指派了一條原則。先在 ① 選規則與效果，再到 ② 組一個建立或更新儲存體帳戶的請求，按「送出請求」，③ 會一步步顯示 Azure Resource Manager 怎麼處理：被擋下、通過但標成不符合、自動補上標籤，或在資源建立後才補部署。下方的表格是訂用帳戶裡既有的儲存體帳戶，按「執行合規掃描」看定期評估會怎麼標記它們，再試試「建立補救工作」對哪些效果有用。有些規則和效果的組合寫不出來，模擬器會說明原因。
① 原則指派（範圍：訂用帳戶 sub-qingkong）
② 送出請求
③ 處理過程與結果
- 還沒有送出請求。
既有儲存體帳戶與合規狀態
| 名稱 | 區域 | SKU | costcenter | 診斷設定 | 合規狀態 |
|---|
🎮 互動實驗室二：治理需求分類台
上方每張卡是一個治理需求。先點一張卡，再點下方對應的工具；電腦上也可以直接把卡片拖進去。分對了，卡片會留在那一欄並說明理由；分錯了，會告訴你那個工具為什麼做不到。注意幾張陷阱卡：資源鎖定只管控制平面，ReadOnly 鎖定也會擋掉一些看起來無害的操作。
🛠️ 操作教學：指派標籤原則、補標籤、加刪除鎖定
情境：晴空食品要求每個資源群組都必須有成本中心標籤，並保護正式環境的資源群組 rg-qingkong-web 不被誤刪。左邊是簡化的入口網站：先把內建原則指派到訂用帳戶，再替既有的資源群組補上標籤，最後建立刪除鎖定。右邊的 Azure CLI 與 Bicep 會跟著你填的標籤名稱、指派名稱與鎖定類型即時更新，目前步驟對應的那幾行會用底色標出來。
自己動手時要注意
權限：建立或修改原則指派需要 Microsoft.Authorization 底下的原則權限，內建角色中 Resource Policy Contributor 涵蓋大部分原則操作，Owner 有完整權限；Contributor 與 Reader 只能讀取原則，不能建立指派。建立或刪除資源鎖定需要 Microsoft.Authorization/locks/*，內建角色是 Owner 與 User Access Administrator。修改資源群組的標籤，Contributor 就可以。
影響範圍：Deny 原則指派到訂用帳戶後，同一個訂用帳戶裡所有人建立沒有標籤的資源群組都會被拒絕，包括同事的自動化腳本。建議先在練習用的訂用帳戶操作，或先把「原則強制執行」設為已停用，觀察合規結果後再啟用。原則指派、標籤與鎖定本身不是會計費的資源，但練習中若建立了其他資源，會依用量計費。
清理：有刪除鎖定的資源群組無法刪除，要先移除鎖定；也記得刪掉練習用的原則指派，以免之後建立資源群組一直被拒絕。
# 1. 先移除鎖定（否則資源群組刪不掉）
az lock delete --name lock-no-delete --resource-group rg-qingkong-web
# 2. 刪除練習用的原則指派
az policy assignment delete --name require-costcenter-on-rg --scope "/subscriptions/<your-subscription-id>"
# 3. 若資源群組是為了練習而建立的，最後再整個刪除
az group delete --name rg-qingkong-web --yes --no-wait不要寫進範例的東西：本頁所有指令都用 <your-subscription-id> 這類佔位字。標籤是明文儲存、很多人都看得到，不要把密碼、金鑰、連接字串或個人資料放進標籤值；成本中心代碼、環境名稱、負責團隊這類分類資訊才適合。
📘 原理補完
原則定義、方案、指派：規則怎麼落到範圍上
Azure Policy 有三層物件。原則定義是一份 JSON 規則：if 寫條件（例如「資源類型是資源群組，而且沒有某個標籤」），then 寫效果；可以宣告參數，讓同一份定義在不同指派裡填不同的值。方案（initiative，也稱 policy set）把多個定義打包成一組，例如某個法規框架的全部控制項，Defender for Cloud 的法規合規就是以方案為基礎。指派把定義或方案套到管理群組、訂用帳戶或資源群組，並填入參數值；下層範圍會繼承，可以用排除（not scopes）拿掉某些子範圍，或對個別資源建立豁免（exemption）。內建原則有數百條，例如本頁操作教學用的「資源群組必須有標籤」（英文顯示名稱 Require a tag on resource groups）。
七種常用效果：什麼時候生效、對既有資源做什麼
效果決定規則被觸發時 Azure 怎麼處理。請求進到 Azure Resource Manager 時，評估順序是 Disabled 先檢查要不要評估，接著 Append 與 Modify 可能修改請求內容，然後才是 Deny、Audit 等；AuditIfNotExists 與 DeployIfNotExists 在資源提供者回傳成功之後才評估，因為它們看的是「相關資源」是否存在，例如診斷設定或擴充功能，預設延遲是 10 分鐘（evaluationDelay，可以調整）。官方的完整清單還有 DenyAction（擋下特定動作，例如刪除）、Manual 等效果，這裡先聚焦在最常考的七種。以下行為查證於 2026 年 10 月的 Microsoft Learn。
| 效果 | 建立或更新時 | 既有資源（合規掃描） | 補救工作 | 典型用途 |
|---|---|---|---|---|
| Deny | 在送到資源提供者之前拒絕，回 403（Forbidden） | 標成不符合，不會刪除或修改 | 不支援，要自己修正 | 禁止的區域、SKU、必填標籤 |
| Audit | 放行，活動記錄寫入 audit 警告事件，資源標成不符合 | 只更新合規狀態 | 不支援 | 先觀察影響、不想打斷部署 |
| Append | 在請求裡加上欄位；若會把請求中的值改成不同的值，就當作 Deny 拒絕 | 標成不符合，不修改 | 不支援 | 非標籤屬性，例如替儲存體加允許的 IP；標籤建議改用 Modify |
| Modify | 在請求處理前新增、取代或移除標籤與可修改的屬性 | 標成不符合，不自動修改 | 支援，需要受控識別 | 補標籤、從資源群組繼承標籤 |
| DeployIfNotExists | 成功後（預設約 10 分鐘）缺少相關資源就部署範本 | 標成不符合，不自動部署 | 支援，需要受控識別 | 自動加上診斷設定、監視代理程式 |
| AuditIfNotExists | 成功後（預設約 10 分鐘）缺少相關資源就記錄並標成不符合 | 標成不符合 | 不支援 | 檢查是否有診斷設定、特定擴充功能 |
| Disabled | 不評估 | 不評估 | — | 暫時關掉一條規則，或在方案裡停用其中一條 |
原則指派還有一個強制執行模式（enforcementMode）：預設是 Default（入口網站顯示「已啟用」），設成 DoNotEnforce（「已停用」）時，建立或更新資源不會執行效果，也不寫活動記錄，但合規性結果照樣產生，DeployIfNotExists 的補救工作也仍然可以手動啟動。這很適合新規則上線前先「試跑」：先看有多少資源不符合、會擋到誰，再切回已啟用。
標籤：分類靠它，但它不會自己長出來
標籤是名稱與值的配對，可以加在資源、資源群組與訂用帳戶上，每個最多 50 組；名稱上限 512 字元（儲存體帳戶為 128），值上限 256 字元，名稱不能包含 < > % & \ ? / 這些字元；名稱比對不分大小寫，值會區分大小寫。管理群組與傳統（classic）資源不能加標籤，也不是每種資源類型都支援。最常被考的一點是不繼承：資源群組或訂用帳戶上的標籤，不會自動套到裡面的資源。要讓資源帶上標籤，常見做法是指派 Modify 效果的原則，從資源群組繼承或補上預設值；Cost Management 另有只影響成本資料的標籤繼承設定。標籤以明文儲存，不能放機密。以上數字查證於 2026 年 10 月。
資源鎖定：在權限之上再加一道封條
資源鎖定可以加在訂用帳戶、資源群組或單一資源上，有兩種等級：CanNotDelete（入口網站顯示為「刪除」），授權的使用者可以讀取與修改，但不能刪除；ReadOnly（「唯讀」），只能讀取，不能修改也不能刪除。鎖定會往下繼承，之後新增的資源也一樣，繼承鏈上限制最嚴格的鎖定優先；它對所有使用者與角色都有效，包括 Owner，要操作得先移除鎖定。建立或刪除鎖定需要 Microsoft.Authorization/locks/*，內建角色中只有 Owner 與 User Access Administrator 具備，所以 Contributor 無法自己解鎖，這也正是鎖定能擋住手滑的原因。
鎖定只作用在控制平面（送到 management.azure.com 的操作）。對 SQL 邏輯伺服器加 ReadOnly 鎖定，可以防止伺服器被刪除或修改，但資料庫裡的資料照樣能新增、修改、刪除；對儲存體帳戶加鎖，也擋不住透過 Blob 端點刪除檔案。要保護資料，靠的是資料角色的最小權限、虛刪除與版本控制、備份。
鎖定也有副作用，尤其是 ReadOnly。很多看起來只是「讀」的操作，在 API 上其實是 POST 請求，而 ReadOnly 會擋下所有 POST：儲存體帳戶加 ReadOnly 後無法列出存取金鑰；資源群組加 ReadOnly 後，裡面的 VM 不能啟動或重新啟動，App Service 方案不能擴充；訂用帳戶加 ReadOnly 會讓 Azure Advisor 無法儲存結果。CanNotDelete 也不是零副作用：資源群組上的 CanNotDelete 會讓 Resource Manager 無法自動清理部署歷程，累積到 800 筆時新的部署會失敗；也會擋下刪除該範圍的角色指派。正式環境最常見的做法是在關鍵資源群組加 CanNotDelete，ReadOnly 只用在真的要凍結設定的短期情境。
Azure Blueprints 已在退役中
Azure Blueprints 曾經用來把原則指派、角色指派、ARM 範本和資源群組打包成藍圖，一次套到訂用帳戶，並用藍圖鎖定保護部署出的資源。它已分階段退役：2026 年 7 月 31 日起不能建立新的定義與版本；10 月 31 日起不能修改既有定義、不能建立新指派；12 月 31 日起不能修改既有指派；2027 年 1 月 31 日完全退役，API 停止回應，未匯出的資料會被刪除，藍圖鎖定也會失效。官方的替代方案是用Template Specs（存放範本的版本化資源）存放與版本化範本，用部署堆疊（deployment stacks）部署、管理生命週期，並以拒絕設定保護資源；原則與角色指派直接寫進 Bicep 一起部署。新專案不要再選 Blueprints。
判斷步驟
- 先看需求在問什麼：「誰可以做」交給 RBAC；「做出來的資源必須長什麼樣」交給 Policy；「有權限的人也不能刪或改」交給資源鎖定；「標示歸屬、分帳、讓自動化分辨」交給標籤。
- 選了 Policy，再看要多強硬：不符合就不准建立用 Deny；先觀察不打斷部署用 Audit（或指派時把強制執行設為已停用）；要自動補上標籤或屬性用 Modify；要自動補一個相關資源（例如診斷設定）用 DeployIfNotExists；只要檢查相關資源存不存在用 AuditIfNotExists。
- 題目提到「既有資源」時，記得掃描只會標記，修正要靠補救工作，而且只有 Modify 與 DeployIfNotExists 能用，指派時要有受控識別。
- 選了鎖定，再看要不要允許修改：日常還要調整設定就用 CanNotDelete；連設定都要凍結才用 ReadOnly，並先確認副作用（列出金鑰、啟動 VM、擴充）能不能接受。
- 選了標籤，記得它不繼承、有 50 組上限、不能放機密；要「每個資源都一定有」就再搭一條 Policy。
- 要一次套用一整套治理設定到新的訂用帳戶：現在用 Bicep 加部署堆疊與 Template Specs，不要選已退役中的 Blueprints。
容易考錯的地方
Policy 和 RBAC 對調：「禁止任何人在美國區域建立資源」是 Policy，因為它管的是資源的狀態，不論誰操作；「只有網路組可以建立虛擬網路」是 RBAC，因為它管的是誰。干擾選項常把兩者互換。
以為 Deny 會清掉既有資源：Deny 只擋新的建立與更新，既有不合規資源只會被標成不符合，資源照常運作。
補標籤選 Append：Append 能在請求裡加標籤，但官方建議標籤用 Modify，因為 Modify 支援更多操作，還能用補救工作修正既有資源。
以為鎖定保護資料：鎖定只管控制平面，擋不住透過資料平面刪除 Blob 或資料表裡的資料。
以為 Owner 不受鎖定限制：鎖定對所有人都有效，Owner 也要先移除鎖定；差別在 Owner 有權限移除鎖定，Contributor 沒有。
以為標籤會繼承：資源群組的標籤不會自動套到資源上，要靠 Modify 原則或另外設定。
選 Blueprints：需要一次部署整套治理設定時，現行答案是部署堆疊加 Template Specs；Blueprints 已在退役中。
Azure Policy、資源鎖定與標籤同時出現在 AZ-900 與 AZ-104 的技能大綱；SC-500 考 Azure Policy 與資源鎖定在安全治理上的用法；SC-100 與 SC-200 的大綱也點名 Azure Policy。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6