治理和合规性（Governance & Compliance）

📋 本章概览

信息	详情
考试领域	Manage Azure identities and governance
考试权重	与 Ch1 合计 20%
建议时长	150 分钟
难度	⭐⭐ 中等
前置知识	Ch1 Entra ID 基础（用户、角色概念）

📢 本章定位：Ch1 讲的是"谁能登录"（身份），本章讲的是"登录后能做什么 + 资源必须符合什么规则"（权限 + 合规）。两章合在一起构成 Azure 治理的完整闭环。

---

🎯 学习目标

完成本章后，你将能够：

• ✅ 理解 Azure 资源层级（管理组 → 订阅 → 资源组 → 资源），以及继承关系
• ✅ 配置 Azure Policy 强制资源合规（Deny / Audit / DeployIfNotExists）
• ✅ 使用 RBAC 实现最小权限访问控制
• ✅ 区分 Policy、RBAC、Lock 三者的职责边界——考试最爱考的混淆点
• ✅ 配置资源锁、标签和成本管理

本章知识地图

治理与合规 Governance & Compliance
│
├── 资源层级 ─────────── Management Group（集团总部）
│   │                   └── Subscription（子公司）
│   │                       └── Resource Group（部门）
│   │                           └── Resource（员工/设备）
│   └── 继承规则 ────── Policy + RBAC 从上往下继承
│
├── Azure Policy ────── "资源必须满足什么规则"
│   ├── 效果：Deny / Audit / Append / DeployIfNotExists / Modify
│   └── Initiative：多条策略打包
│
├── RBAC ─────────────── "谁能对资源做什么"
│   └── 角色分配 = 安全主体 + 角色定义 + 范围
│       └── Owner / Contributor / Reader / User Access Admin
│
├── Resource Lock ───── "即使有权限也防手滑"
│   ├── CanNotDelete（防删除）
│   └── ReadOnly（防修改+防删除）
│
├── Tags ─────────────── "给资源贴标签，方便分账和管理"
│
└── Cost Management ─── Budget + Cost Analysis + Alerts

---

🖼️ 治理控制全景图

📌 图解说明：

1. 这张图在讲什么：从管理组到资源的四级治理链路——Policy、RBAC、Lock 分别在哪一层生效。
2. 你应该先看哪里：先看层级关系（从上到下），再看每层可以附加哪些治理工具。Policy 和 RBAC 可以在任意层分配并向下继承，Lock 通常在资源组或资源级别设置。
3. 考试常见问法："一条策略要覆盖多个订阅应该放在哪？"——Management Group。"最小权限应该在哪层赋权？"——尽量低的层级（资源组甚至资源级别）。

---

🏗️ Azure 资源层级

理解资源层级是本章的地基。Azure 里的所有治理动作（Policy、RBAC、Lock）都依赖这个四级结构。

术语：资源层级（Resource Hierarchy）

• 一句话解释：Azure 用四级树形结构组织所有资源：管理组 → 订阅 → 资源组 → 资源。
• 形象比喻：像一个跨国集团的架构——集团总部（Management Group）→ 子公司（Subscription）→ 部门（Resource Group）→ 员工/设备（Resource）。总部定的规矩，所有子公司都要遵守。
• 考试怎么考：题目描述一个治理需求，问你应该在哪一层操作。层级选错 = 送分题丢分。
• 最易混淆：管理组和订阅的关系。管理组是订阅的"上级容器"，不是订阅的替代品。

Root Management Group（根管理组，每个租户自动有一个）
├── Management Group: "Production"
│   ├── Subscription: "Prod-App1"
│   │   ├── Resource Group: "rg-webapp"
│   │   │   ├── App Service
│   │   │   └── SQL Database
│   │   └── Resource Group: "rg-networking"
│   │       ├── VNet
│   │       └── NSG
│   └── Subscription: "Prod-App2"
│       └── ...
└── Management Group: "Development"
    └── Subscription: "Dev-Team"
        └── ...

继承规则（非常重要）

治理工具	是否向下继承	举例
Azure Policy	✅ 是	在管理组设 Deny 策略 → 所有子订阅、RG、资源都受影响
RBAC 角色分配	✅ 是	在订阅级别给 Contributor → 该订阅下所有 RG 和资源都有 Contributor
Resource Lock	✅ 是	在 RG 上设 CanNotDelete → RG 内所有资源都不能删
Tags	❌ 不继承	在 RG 上贴 Tag → 里面的资源不会自动有这个 Tag

⚠️ 考试陷阱：Tags 不继承！这是最常考的坑。如果需要子资源也有 Tag，必须用 Azure Policy 的 Inherit a tag from the resource group 策略强制继承。

---

📦 Azure 订阅（Subscription）

术语：Subscription（订阅）

• 一句话解释：Azure 资源的计费边界和访问控制边界。
• 形象比喻：像公司的独立账本——每个订阅有自己的费用、有自己的权限设置，互相独立结算。
• 考试怎么考：问"如何隔离不同环境的费用和权限"——答案通常是分多个订阅（Dev、UAT、Prod）。
• 最易混淆：Subscription vs Resource Group。订阅是计费+权限的大边界；RG 是资源的逻辑分组，没有独立计费。

订阅的三个用途

用途	含义	场景
账单边界 (Billing Boundary)	每个订阅独立计费	按部门分账
访问控制边界 (Access Control Boundary)	每个订阅独立配权限	开发团队只能访问 Dev 订阅
环境分离	不同订阅放不同环境	Prod / UAT / Dev 各一个订阅

一个租户可以有多个订阅

Tenant: contoso.com
├── Subscription: "Production"     → 生产环境，预算 $10,000/月
├── Subscription: "Development"    → 开发环境，预算 $2,000/月
└── Subscription: "Sandbox"        → 实验环境，预算 $500/月

💡 为什么要多个订阅？ 不是因为技术限制，而是为了成本隔离 + 权限隔离 + 策略隔离。每个订阅可以有不同的 RBAC、不同的 Policy、不同的预算。

---

🏛️ 管理组（Management Group）

术语：Management Group（管理组）

• 一句话解释：订阅之上的容器，用来对多个订阅统一施加治理策略。
• 形象比喻：跨国集团的总部规章——总部（管理组）定的规矩，所有子公司（订阅）都得遵守。你不用一家一家去改。
• 考试怎么考：题干出现"across multiple subscriptions"或"governance at scale"——答案几乎都涉及管理组。
• 最易混淆：管理组不是资源容器（不能直接放 VM、Storage），它只管订阅。

管理组关键特性

特性	说明
最大嵌套深度	6 层（不含根管理组）
根管理组	每个租户自动有一个，不能删除
继承	Policy 和 RBAC 向下继承到所有子管理组和订阅
默认行为	新订阅自动归入根管理组

什么时候用管理组

需要统一治理多个订阅？
├── 是 → Management Group（在管理组上设 Policy / RBAC）
└── 否 → 直接在订阅级别配置就行

⚠️ 考试重点：给管理组分配 RBAC 角色时，该角色会自动继承到所有子订阅和资源。这意味着在管理组级别给 Contributor 会让用户拥有所有子订阅的 Contributor 权限——通常权限太大了。

---

📜 Azure Policy

术语：Azure Policy（Azure 策略）

• 一句话解释：给 Azure 资源定规矩——"不合规的资源不让创建"或"已有资源标记为不合规"。
• 形象比喻：公司的合规审计部门——不是管"谁能进办公室"（那是 RBAC），而是管"办公室里的设备必须符合什么标准"。比如：所有电脑必须装杀毒软件，不符合的标记违规。
• 考试怎么考：AZ-104 的 Policy 题非常多。核心是理解不同 Effect 的区别，以及 Policy 和 RBAC 的分工。
• 最易混淆：Policy vs RBAC。Policy 管资源合规，RBAC 管人的权限。 即使你有 Owner 权限，如果 Policy 设了 Deny，你也创建不了不合规的资源。

Policy Effect（效果类型）

这是本章最核心的考点。必须能区分每个 Effect 的行为：

效果	行为	适用场景	一句话记忆
Deny	阻止不合规资源的创建或修改	强制合规（如只允许特定 Region）	不让干
Audit	允许创建，但标记为不合规	可视化合规状态，不强制	只记录不拦
AuditIfNotExists	如果关联资源不存在，标记不合规	检查是否启用了诊断日志	查关联是否存在
DeployIfNotExists	如果关联资源不存在，自动部署	自动给 VM 装扩展	缺什么补什么
Append	在创建/更新时添加字段	自动加标签、加 IP 限制	自动补信息
Modify	修改现有资源的属性或标签	修改标签、修改网络配置	自动改属性
Disabled	不执行任何操作	暂时关闭策略	策略休眠

⚠️ 考试陷阱：Deny 和 Audit 的区别是最高频考点。"prevent creation" = Deny；"detect non-compliance" = Audit。看到 prevent/enforce → Deny；看到 detect/report/identify → Audit。

自定义策略示例

场景：强制所有存储账户必须启用 HTTPS

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
          "notEquals": "true"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

逐字段解读：

• mode: "All" — 对所有资源类型生效
• if 块 — 条件判断：如果是存储账户且没开 HTTPS
• then 块 — 执行动作：Deny（阻止创建）

Policy Initiative（策略计划）

术语：Initiative（策略计划 / 策略集）

• 一句话解释：把多条 Policy 打包成一个"合规套餐"，一次性分配。
• 形象比喻：像超市的套餐组合——你不用一个一个买单品（Policy），直接买套餐（Initiative）更方便。
• 考试怎么考：题目问"如何高效管理多条策略"或"规模化治理"——答案是 Initiative。
• 最易混淆：Initiative 不是新的策略类型，只是策略的打包方式。里面的每条 Policy 仍然独立生效。

Initiative: "生产环境安全基线"
├── Policy 1: 存储账户必须 HTTPS (Deny)
├── Policy 2: VM 必须启用备份 (AuditIfNotExists)
├── Policy 3: 所有资源必须有 CostCenter 标签 (Deny)
└── Policy 4: SQL 必须启用审计 (DeployIfNotExists)

Policy 分配和作用域

Policy 可以分配到任何层级，并向下继承：

分配层级	影响范围	适用场景
Management Group	所有子订阅和资源	全公司统一规则
Subscription	该订阅下所有 RG 和资源	环境级规则
Resource Group	该 RG 内所有资源	项目级规则

💡 实际工作中：大多数企业在管理组级别分配 Initiative（如安全基线），在订阅级别做环境特定策略（如 Dev 环境允许公共 IP，Prod 不允许）。

Policy 合规性查看

# 查看策略合规状态
az policy state list --resource-group myRG --output table

# 触发合规性评估（默认每 24 小时自动评估一次）
az policy state trigger-scan --resource-group myRG

⚠️ 考试重点：新建的 Policy 不会立即评估所有现有资源。默认的评估周期是 24 小时一次。可以手动触发扫描。

---

🔑 RBAC（基于角色的访问控制）

术语：RBAC (Role-Based Access Control)

• 一句话解释：通过"角色分配"控制谁能对哪些 Azure 资源做什么操作。
• 形象比喻：公司的岗位权限卡——前台（Reader）只能看不能改；技术员（Contributor）能操作设备但不能改门禁；安全主管（Owner）什么都能做。
• 考试怎么考：题目给一个权限需求，问你分配哪个角色、在哪个层级。
• 最易混淆：RBAC 角色（管 Azure 资源）vs Entra ID 角色（管目录对象）。第一章已经讲过区别，这里专注 RBAC。

RBAC 的三个组件

每个角色分配由三个要素组成：

角色分配 (Role Assignment) = 谁 + 能做什么 + 在哪里

  谁：Security Principal（安全主体）
  ├── User（用户）
  ├── Group（组）
  ├── Service Principal（服务主体 / 应用）
  └── Managed Identity（托管标识）

  能做什么：Role Definition（角色定义）
  ├── Actions（允许的操作）
  └── NotActions（排除的操作）

  在哪里：Scope（范围）
  ├── Management Group
  ├── Subscription
  ├── Resource Group
  └── Resource

内置角色

角色	权限	能否分配权限	一句话记忆
Owner	完全控制	✅ 能	什么都能做，包括改权限
Contributor	管理所有资源	❌ 不能	能操作资源，但不能管权限
Reader	只读	❌ 不能	只能看，不能动
User Access Administrator	管理用户权限	✅ 能	专门管"谁有什么权限"

⚠️ 考试高频题：Contributor 和 Owner 的区别——Contributor 不能分配角色给其他用户。如果题目问"needs to manage resources but should NOT be able to grant access to others"——答案是 Contributor。

角色分配示例

# 给用户在资源组级别分配 Contributor 角色
az role assignment create \
    --assignee user@contoso.com \
    --role "Contributor" \
    --scope /subscriptions/xxx/resourceGroups/myRG

# 给组在订阅级别分配 Reader 角色
az role assignment create \
    --assignee-object-id <group-object-id> \
    --role "Reader" \
    --scope /subscriptions/xxx

自定义角色

当内置角色太宽或太窄时，创建自定义角色：

{
  "Name": "Virtual Machine Operator",
  "Description": "Can start, stop, and restart VMs, but cannot create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/xxx"
  ]
}

• Actions：允许做什么（用 * 表示全部）
• NotActions：从 Actions 中排除什么
• DataActions：数据层面的操作（如读写 Blob 数据）
• AssignableScopes：这个角色能在哪些范围被分配

💡 Actions vs DataActions：Actions 控制管理平面操作（创建 VM、配置网络）；DataActions 控制数据平面操作（读写 Blob 内容、发送队列消息）。考试会问这个区别。

RBAC 的作用域和继承

Management Group（在这里分配 = 所有子订阅都有）
  └── Subscription（在这里分配 = 该订阅所有 RG 都有）
      └── Resource Group（在这里分配 = 该 RG 所有资源都有）
          └── Resource（在这里分配 = 只对这个资源有效）

最小权限原则：角色应该分配在尽可能低的层级。如果用户只需要管一个 RG，就在 RG 级别分配，不要在订阅级别。

Deny Assignment（拒绝分配）

术语：Deny Assignment（拒绝分配）

• 一句话解释：即使角色允许，也可以显式拒绝某些操作。和 Policy 的 Deny 不同，这是 RBAC 层面的拒绝。
• 考试怎么考：问"RBAC 中如何阻止特定操作"——Deny Assignment 优先级高于任何允许。
• 重要提示：Deny Assignment 不能通过 Portal 或 CLI 直接创建，只能由 Azure Blueprints 和 Managed Apps 创建。考试可能会问这一点。

---

🔒 资源锁（Resource Lock）

术语：Resource Lock（资源锁）

• 一句话解释：给资源加一把锁，防止意外删除或修改——即使你有 Owner 权限也会被锁拦住。
• 形象比喻：贵重文件上的封条——有权限打开柜子的人也得先撕封条才能动里面的东西。Lock 就是那道额外的保护。
• 考试怎么考：题干出现"prevent accidental deletion"→ CanNotDelete Lock。题干出现"prevent any changes"→ ReadOnly Lock。
• 最易混淆：Lock 和 RBAC 的关系。Lock 不管你有没有权限，它是额外的保护层。你有 Owner 权限 + CanNotDelete Lock = 能改但不能删。

两种锁类型

锁类型	能读	能改	能删	一句话记忆
CanNotDelete	✅	✅	❌	啥都能干，就是不能删
ReadOnly	✅	❌	❌	只能看，不能改也不能删

# 创建 CanNotDelete 锁
az lock create \
    --name "PreventDelete" \
    --lock-type CanNotDelete \
    --resource-group myRG

# 创建 ReadOnly 锁
az lock create \
    --name "PreventChanges" \
    --lock-type ReadOnly \
    --resource-group myRG

Lock 的继承和删除

• Lock 在 RG 上设置 → RG 内所有资源都被锁定
• 删除锁需要 Microsoft.Authorization/locks/* 权限（Owner 或 User Access Administrator 有）
• 必须先删除锁，才能删除/修改被锁定的资源

⚠️ 考试陷阱：ReadOnly Lock 比你想的更严格。在存储账户上设 ReadOnly Lock 后，连列出存储密钥都不行——因为列出密钥是一个 POST 操作，不是 GET。

---

🏷️ Tags（资源标签）

术语：Tags（资源标签）

• 一句话解释：给资源贴键值对标签，用于分类、分账和自动化管理。
• 形象比喻：快递包裹上的面单——标注收件部门、成本中心、环境类型，方便分拣和结算。
• 考试怎么考：问"如何按部门分账"或"如何标识资源归属"——答案是 Tags。
• 最易混淆：Tags 不会自动从 RG 继承到子资源！

Tag 的规则

规则	说明
格式	Key-Value 键值对
每个资源最多	50 个 Tag
Key 最大长度	512 字符
Value 最大长度	256 字符
继承	❌ 不自动继承
强制继承方法	用 Azure Policy（Inherit tag from RG）

常用 Tag 示例

Environment = Production
CostCenter = CC-12345
Owner = team-platform
Project = webapp-v2
CreatedBy = terraform

# 给资源组添加 Tag
az group update --name myRG --set tags.Environment=Production tags.CostCenter=CC-12345

# 给资源添加 Tag
az resource tag --tags Environment=Production --ids /subscriptions/xxx/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM

💡 实际工作中：大多数企业要求所有资源必须带 CostCenter 和 Environment 标签。通过 Azure Policy Deny 效果强制执行：没有标签的资源不能创建。

---

📋 Azure Blueprints

术语：Azure Blueprints（蓝图）

• 一句话解释：把 Policy、RBAC 角色分配、ARM 模板和资源组打包成一个可重复使用的环境模板。
• 形象比喻：新店开业的标准化装修包——每开一家新店（新订阅），按同一套蓝图部署，保证每家店的安全策略、权限结构、基础设施都一致。
• 考试怎么考：题干出现"standardize environment deployment"或"repeatable governance"——答案是 Blueprints。
• 最易混淆：Blueprints vs ARM Templates。ARM Template 只部署资源；Blueprints 可以同时设置 Policy、RBAC 和资源。

Blueprints 包含什么

组件	含义
Policy Assignment	自动分配策略
Role Assignment	自动分配角色
ARM Template	自动部署资源
Resource Group	自动创建资源组

Blueprints 的版本管理

Blueprints 支持版本控制——每次修改都是一个新版本，可以追踪"谁在什么时候改了什么"。ARM Template 没有内置版本管理。

📢 注意：微软已宣布 Azure Blueprints 将被 Deployment Stacks 和 Azure Landing Zones 逐步替代。考试可能仍然考 Blueprints 基础概念，但新项目建议用 Deployment Stacks。

---

💰 成本管理（Cost Management）

成本管理不属于"安全治理"，但它是 AZ-104 治理领域的一部分——管理资源不只是管权限和合规，还要管花销。

三大成本管理工具

工具	用途	一句话记忆
Cost Analysis	查看和分析当前花费	"我花了多少"——事后看
Budget	设置预算上限和告警	"花到多少提醒我"——预设警戒线
Cost Alerts	预算超标时发通知	"超了就喊我"——自动报警

# 查看成本
az consumption usage list --subscription "MySubscription"

# 设置月度预算
az consumption budget create \
    --budget-name "MonthlyBudget" \
    --amount 1000 \
    --time-grain Monthly

Budget Alert 配置

预算告警可以设置多个阈值：

Budget: $1,000/月
├── 50% ($500)  → 发邮件给团队
├── 80% ($800)  → 发邮件给经理
├── 100% ($1000) → 发邮件给 Owner + 触发 Action Group
└── 120% ($1200) → 实际超支告警

⚠️ 注意：Budget 告警不会自动停止服务。即使超预算了，资源仍然运行（费用继续产生）。告警只是通知，不是自动关停。如果要自动关停，需要配合 Automation Runbook 或 Logic App。

---

🧠 核心概念辨析（考试必考）

Policy vs RBAC vs Lock 的职责边界

这三者经常被混淆，用一个表格彻底搞清楚：

维度	Azure Policy	RBAC	Resource Lock
管什么	资源合规性	人的权限	资源保护
核心问题	"资源是否符合规则？"	"谁能对资源做什么？"	"即使有权限也不能动"
比喻	合规审计部门	门禁权限卡	贵重品封条
作用对象	资源属性	用户/组/SP	资源实体
示例	"VM 必须用特定 SKU"	"张三能创建 VM"	"这个 VM 不能删"
和权限的关系	不管你有没有权限	管权限	即使 Owner 也被拦

场景举例：张三是 Production RG 的 Owner（RBAC），但该 RG 有 ReadOnly Lock（Lock），且公司策略禁止创建没有 Tag 的资源（Policy）。

结果：

• 张三能登录并查看资源（RBAC Owner 允许读写）
• 张三不能修改或删除已有资源（ReadOnly Lock 拦截）
• 张三不能创建没有 CostCenter Tag 的新资源（Policy Deny 拦截）
• 如果要操作，张三需要先联系管理员删除 Lock，然后创建资源时带上 Tag

RBAC 角色 vs Entra ID 角色（回顾 Ch1）

问自己	答案	用哪套
管的是用户/组/应用（目录对象）？	是	Entra ID 角色
管的是 VM/VNet/Storage（Azure 资源）？	是	Azure RBAC 角色

---

⚡ 30 秒答题框架

拿到一道治理题，按这个顺序判断：

Step 1: 问题是"权限不足"还是"资源不合规"？
        ├── 权限 → RBAC（先看角色和 Scope）
        └── 合规 → Policy（先看 Effect 类型）

Step 2: 是"防止误删误改"？
        └── 是 → Resource Lock

Step 3: 需要"跨多个订阅统一"？
        └── 是 → Management Group

Step 4: 需要"多条策略一起推"？
        └── 是 → Initiative

Step 5: 需要"按部门分账"？
        └── 是 → Tags + Cost Analysis

---

🔍 高频关键词速配

题干关键词	秒选方向	常见干扰项
prevent creation of non-compliant	Policy Deny	Audit（只记录不拦）
detect non-compliant resources	Policy Audit	Deny（太强了）
accidental deletion	CanNotDelete Lock	ReadOnly（太严了）
prevent any changes	ReadOnly Lock	CanNotDelete（能改）
across multiple subscriptions	Management Group	每个订阅单独配
cannot grant access to others	Contributor（非 Owner）	Owner
manage user permissions	User Access Administrator	Contributor
standardize environment setup	Blueprints	手动配置
track spending by department	Tags + Cost Analysis	每个部门一个订阅
auto-deploy missing extension	DeployIfNotExists	Deny
group multiple policies	Initiative	单独分配每条

---

🧪 场景加练（秒选版）

场景 1：强制 HTTPS

公司要求所有存储账户必须启用 HTTPS，否则不能创建。

秒选思路： 资源合规强制 → Azure Policy + Deny 效果。作用域设到管理组或订阅级别，覆盖所有环境。

场景 2：运维可管理但不能改权限

运维团队可以管理生产资源，但不能把权限给其他人。

秒选思路： 能管资源但不能分配权限 → Contributor 角色（不是 Owner）。Owner 和 Contributor 的唯一区别就是能不能分配角色。

场景 3：按部门分账

CFO 需要看到每个部门的月度 Azure 花费。

秒选思路： 给资源贴 Department Tag → 在 Cost Analysis 中按 Tag 筛选。用 Policy Deny 强制所有资源必须有 Department Tag。

场景 4：防止生产数据库被删

生产 SQL Database 绝对不能被误删，但 DBA 需要正常维护。

秒选思路： CanNotDelete Lock。不选 ReadOnly（DBA 还要维护=修改配置）。

场景 5：新订阅自动合规

公司每季度新建订阅，要求每个新订阅自动符合安全基线（必须开审计日志、必须用特定 Region、必须有 Tag）。

秒选思路： 在 Management Group 上分配 Initiative（含多条 Policy），所有新建的子订阅自动继承。

场景 6：限制可用 VM SKU

开发环境只允许使用 Standard_B1s 和 Standard_B2s，防止开发人员开大机器浪费钱。

秒选思路： Azure Policy + 内置策略 "Allowed virtual machine size SKUs" + Deny 效果。分配到 Dev 订阅。

---

🚨 常见陷阱

陷阱	正确理解
"Tags 自动继承到子资源"	❌ 不继承，需要 Policy 强制
"Owner 不受 Lock 限制"	❌ Lock 拦所有人，包括 Owner
"Budget 超标会自动停服务"	❌ 只发告警，不停服务
"Policy 新建后立即生效"	❌ 默认 24 小时评估一次，可手动触发
"Contributor = Owner 减去删除权"	❌ Contributor 和 Owner 的区别是能不能分配角色，不是能不能删除
"ReadOnly Lock 只影响修改"	❌ ReadOnly Lock 会拦截任何写操作，包括列出密钥等 POST 操作
"Deny Assignment 可以在 Portal 创建"	❌ 只能由 Blueprints 或 Managed Apps 创建

---

📚 官方资源

资源	链接
Azure Policy 文档	learn.microsoft.com/azure/governance/policy
Azure RBAC 文档	learn.microsoft.com/azure/role-based-access-control
Cost Management 文档	learn.microsoft.com/azure/cost-management-billing
AZ-104 考试大纲	learn.microsoft.com/certifications/exams/az-104

---

开始本章测验

完成学习后，建议先做章节练习题，重点关注 Policy Effect 辨析和 RBAC 角色分配层级题。