【Day 28】AZ-900 題型與情境實戰：互動介面 × 限制條件 × AWS 雙雲對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★★
核心考點：Microsoft Exam Sandbox、Drag & Drop、Build List、Hot Area、介面操作與題幹陷阱、關鍵字陷阱、過期題庫辨識、ExamTopics／gratisexam 題庫使用邊界、Microsoft Learn 官方考綱。

🎯 前言與今日目標

Day 27 我們完成了「成本治理」：Pricing Calculator 負責估算、Cost Management 負責實際成本分析、Budget 負責門檻追蹤。

今天不再增加一個 Azure 服務。

Day 28 要練的是另一種能力：看到題目介面與題幹，就知道「怎麼作答、哪裡容易被騙、哪些舊題不能照抄」。

這一天很容易被誤解成 Day 7 的「總複習」。兩者其實完全不同：

🧠 今天的核心不是背更多答案，而是建立一個考場演算法：先判斷題型 → 找限制條件 → 找關鍵字 → 判斷 Scope／服務定位 → 再作答。

Microsoft 目前的 AZ-900 Study Guide（技能測量日期：2026-07-20）仍將考試分為 Cloud Concepts 25–30%、Azure Architecture and Services 35–40%、Azure Management and Governance 30–35%。因此 Day 28 不應該自行創造新的「第四大考綱」，而是把前三大領域的知識轉化成穩定的解題流程。

來源：Microsoft Learn — Study guide for Exam AZ-900

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

📐 考場解題架構圖：不要一看到 Drag & Drop 就慌

┌─────────────────────────────────────────────────────────────┐
│                  AZ-900 題型解題 Pipeline                   │
├─────────────────────────────────────────────────────────────┤
│  ① 先看題型                                                 │
│      │                                                      │
│      ├── Multiple Choice → 找唯一最佳答案                   │
│      ├── Drag & Drop     → 找「配對關係」                   │
│      ├── Build List      → 找「正確順序」                   │
│      └── Hot Area        → 找「正確位置」                   │
│      │                                                      │
│      ▼                                                      │
│  ② 再讀限制條件                                             │
│      │                                                      │
│      ├── Scope？                                            │
│      ├── Security / Cost / Availability？                   │
│      ├── Managed responsibility？                           │
│      └── 「最小／唯一／必須／直接／最少管理」？             │
│      │                                                      │
│      ▼                                                      │
│  ③ 最後才選 Azure 服務                                      │
│      │                                                      │
│      ├── Identity → Entra ID / RBAC                         │
│      ├── Governance → Policy / Locks / Purview              │
│      ├── Compute → VM / Functions / Containers              │
│      └── Networking → VNet / VPN / ExpressRoute / NSG       │
└─────────────────────────────────────────────────────────────┘

Microsoft 官方不會在考前公開指定固定題型；官方提供 Exam Sandbox 讓考生熟悉可能遇到的互動介面與導覽方式。

來源：Microsoft Learn — Prepare for an exam、Microsoft Learn — Exam duration and exam experience

⚖️ AWS ↔ Azure 考場介面與作答機制深度對照表

熟悉 AWS 雲端證照（CLF-C02 / SAA-C03）的考生，在首次進入 Azure AZ-900 考場時常因「題型交互方式」與「作答不可逆性」感到不適應。兩者在作答體驗與設計哲學上有著本質差異：

🗺️ AZ-900 題型：官方已知資訊 vs 本專案訓練分類

重要校正：Microsoft 明確表示不會事先公開固定的考試格式或題型。因此，以下 10 種是本專案訓練模式，不是 AZ-900 官方固定清單。

Microsoft 官方考試體驗頁目前展示的範例包含 Active screen、Build list、Case studies、Drag and drop、Hot area、Multiple choice，並另外展示 Labs、Mark review、Review screen、Navigation and timer。這些是熟悉考場介面的示例，不代表每次 AZ-900 都會全部出現。

⏱️ 考試時間與題數：不要再寫死

Microsoft 目前的說明是：

• Fundamentals exams：45 分鐘 exam duration、65 分鐘 seat duration
• Microsoft 認證考試通常約 40–60 題，但題數可能因更新而變動。
• AZ-900 Study Guide 明確列出通過標準為 700 分以上。
• Microsoft 不公開保證某一次考試一定包含哪些特定題型。

因此：

本專案的 Day 29／30 可以設計 50 題模考，但 50 題是訓練設計，不是宣稱 AZ-900 正式考試固定 50 題。

🧮 計分規則：不要把社群推測當官方規則

上一版把 Partial Credit、每個拖曳點各自計分、Repeated Scenario 不可回頭等內容寫成固定規則，證據不足。

本專案改採：

以題目本身明確指定的作答要求為準；不要從題型名稱推導正式考試計分。

如果要熟悉實際介面，直接使用 Microsoft Exam Sandbox，比背網路流傳的「題型規則」可靠。

🧠 Day 28 的真正任務：從「題型訓練」升級成「情境推理」

上一版雖然有 Drag & Drop、Build List 等內容，但真正的情境判斷比例不足。

Day 28 現在新增一條硬規則：

情境題不能只是在名詞前面加上「Titan 科技」。

真正的情境題至少要有一個決策限制

例如：

• least management
• no public Internet
• private connectivity
• specific scope
• budget threshold
• availability requirement
• OS control
• identity / authorization requirement
• compliance requirement
• migration assessment
• offline data transfer

情境題的標準結構

Azure 工作背景
      ↓
Business requirement
      ↓
Technical constraint
      ↓
Security / Cost / Availability constraint
      ↓
候選服務
      ↓
排除違反限制的選項
      ↓
答案

核心不是「看到關鍵字就配服務」，而是：

Constraint → Scope → Service → Answer

🎮 重新設計的 Boss Fight

情境：Migration Assessment

Titan 有 200 台地端伺服器。團隊準備移轉至 Azure，但在正式移轉前，需要先盤點伺服器、評估移轉準備程度，並分析應用程式相依性。

A. Azure Data Box
B. Azure Migrate
C. AzCopy
D. Azure Storage Explorer

答案：B — Azure Migrate

為什麼？

題目的核心需求是：

• discovery
• assessment
• dependency analysis
• migration planning

不是單純「把資料搬到 Azure」。

如果題目改成：

網路頻寬不足，需要使用 Microsoft 提供的實體裝置，把大量資料離線送入 Azure。

才應該考慮 Azure Data Box。

情境：Private Connectivity

Titan 的 Azure VM 必須存取 Azure Storage。公司規定資料流量不能經過公開 Internet，而且架構必須維持在 Azure VNet 的私有網路設計內。

不要看到「網路」就直接選 VPN Gateway。

先拆：

1. Azure VM
2. Azure Storage
3. VNet
4. no public Internet
5. private connectivity

接著才判斷題目是在問 Private Endpoint、VPN Gateway、ExpressRoute 或其他網路能力。

這類題目故意要求你先辨識「能力」，再選「服務」。

情境：Cost

財務部門在部署前，希望估算 20 台 VM、Storage 與 Networking 的預期費用。

→ Pricing Calculator

如果改成：

資源已經部署，財務部門希望分析目前實際支出。

→ Cost Management

情境：Governance

公司要求所有新建立的 Azure 資源只能位於核准的 regions。

→ Azure Policy

如果改成：

Production 資料庫不能被管理員意外刪除。

→ Resource Lock（若題目要求即使具備刪除權限也要增加資源刪除保護，則 Lock 是關鍵線索。）

🧪 Day 28 多角色 Review：四種角色各自問一遍

角色 1｜AZ-900 Examiner

問：

「這題是不是在測現行 AZ-900 Study Guide？」

檢查：

• [ ] 屬於三大官方技能領域
• [ ] 服務名稱為現行名稱
• [ ] 沒有把歷史題庫答案當成官方答案
• [ ] 沒有虛構固定題型

角色 2｜Azure Solution Architect

問：

「如果真的遇到這個需求，選項的差異是否成立？」

檢查：

• [ ] Service boundary 正確
• [ ] Scope 正確
• [ ] Network path 正確
• [ ] Management responsibility 正確
• [ ] Security／cost／availability constraint 沒被忽略

角色 3｜AWS SAA/CLF 考生

問：

「是不是把 AWS 服務名稱直接套到 Azure？」

例如：

角色 4｜教材 QA

問：

「學生看完後，會不會把推測當成官方規則？」

所以所有內容分三層：

• 官方事實：Microsoft Learn 有明確文件支持
• 本專案訓練設計：我們為了練習而建立
• 社群／歷史題庫資訊：只作為線索，不作技術裁決

🚨 四大陷阱重新校正

Trap 1：絕對化

「Microsoft 負責全部安全」通常需要重新檢查責任邊界。

正確方法不是背一句「Data 永遠是客戶責任」，而是：

先確認服務模型，再判斷客戶與 Microsoft 各自管理哪些層。

Trap 2：Policy vs Lock

Trap 3：Tags

Tags 是中繼資料／分類工具。

不要把：

DoNotDelete

這種 Tag 名稱誤認成真正的防刪機制。

Trap 4：能做到 ≠ 最符合

如果 A、B 都能完成工作：

不要問「誰能做到？」

要問：

「誰同時滿足題目全部限制？」

🏁 Day 28 → Day 29／30 的硬性規格

Day 29／30 後續產生 50 題模考時，必須：

1. 10 種訓練模式隨機交錯，而不是按類型分組。
2. 三大 AZ-900 領域隨機混合。
3. 題型、Domain、Service context 都要打散。
4. 提高真正情境題比例。
5. 每個情境題至少有一個可驗證的決策限制。
6. 不用「公司名稱＋一句定義」假裝情境題。
7. Case Study 類題目必須有真正的背景與多項需求。
8. Q1～Q50 完成後才公布答案與解析。
9. Day 30 增加跨領域、多限制條件題。
10. AWS ↔ Azure 題目只做「能力映射」，不能把兩邊產品當成完全等價。

🧠 最終解題演算法

① 看題型
   ↓
② 讀完整情境
   ↓
③ 找限制條件
   ↓
④ 判斷 Scope
   ↓
⑤ 判斷管理責任
   ↓
⑥ 列候選服務
   ↓
⑦ 找最容易混淆的兩個選項
   ↓
⑧ 用限制條件淘汰
   ↓
⑨ 最後操作介面
   ↓
⑩ 提交答案

五句終極口訣

1. 題型不是答案。
2. 關鍵字不是答案。
3. 能做到不代表最符合。
4. 先解限制，再選服務。
5. Constraint → Scope → Service → Answer。

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

🧒 ELI13 國中生秒懂：10 種本專案訓練模式與高頻架構白話速記法

如果把考場上的抽象技術名詞換成日常國中生活經驗，所有複雜題型與陷阱瞬間變得無比直覺：

💡 cxcxc-io 雲端架構筆記與考綱思維借鑑：借鑑 cxcxc-io/cloud-arch-notes-felo-key1.md 的實務哲學：「雲端架構師的核心價值在於權衡（Trade-offs）與邊界控制」。AWS 考試體系（Skill Builder / SAA-C03 / CLF-C02）多透過長篇情境題檢驗架構取捨；而 Azure AZ-900 則透過豐富的富交互題型（Drag & Drop、Build List、Hot Area、情境練習）檢驗考生對平台階層、治理防呆與責任邊界的精確掌握。兩者出題哲學雖異，底層的雲端治理心法完全相通。

🧠 五個考場關鍵字

1. 「最少管理」 → 優先想到更高層的託管服務
不要因為 VM 功能最多就選 VM。若題目強調降低作業系統、硬體或基礎設施管理，通常要往 PaaS／Serverless 思考。

2. 「誰負責？」 → 先判斷雲端服務模型
IaaS、PaaS、SaaS 的責任邊界不同。不要把「雲端供應商管理」理解成「客戶什麼都不用管」。

3. 「哪一層？」 → 先判斷 Scope
Management Group、Subscription、Resource Group、Resource 的層級不同；RBAC 與 Policy 的作用方式也不能混為一談。

4. 「防止建立／強制符合規範」 → Policy
題目如果問的是治理規則，例如限制區域、要求 Tag、限制特定 SKU，第一個要想到的是 Azure Policy，而不是 Resource Lock。

5. 「防止刪除／唯讀」 → Resource Lock
Lock 的核心不是合規評估，而是保護資源免於意外刪除或修改。看到 CanNotDelete／ReadOnly 類語意，就要立即聯想到 Lock。

📐 AWS ↔ Azure 考場架構拓撲對照

AZ-900 的出題設計哲學與 AWS CLF-C02 / SAA-C03 存在本質差異。下圖從「題型結構、作答機制、評分維度」三個層面進行跨雲拓撲映射，幫助具備 AWS 背景的架構師快速建立考場心智模型：

┌──────────────────────────────────────────────────────────────┐
│      AWS ↔ Azure 考場題型架構拓撲對照（Day 28 核心）         │
├──────────────────────────────────────────────────────────────┤
│ [AWS 考場拓撲]                   [Azure AZ-900 考場拓撲]     │
│                                                              │
│ AWS Skill Builder / Pearson VUE   Microsoft Exam Sandbox     │
│   │── 題型：Multiple Choice (MC)    │── 題型：MC + 多種互動範例  │
│   │   └── Multiple Response (MR)   │   ├── Drag & Drop       │
│   │                                │   ├── Build List        │
│   │                                │   ├── Hot Area (UI截圖) │
│   │                                │   ├── Active Screen     │
│   │                                │   └── Repeated Scenario │
│   │── 作答：全卷隨時可回頭修改     │── 作答：分類不同！      │
│   │         Mark for Review 旗標  │   ├── 一般題：可回頭     │
│   │                                │   └── Repeated：依當次介面規則 │
│   │── 計分：全對 or 全錯 (MC)      │── 計分：不預設正式配分  │
│   │         部分給分 (MR)          │   配對題的正式配分不預設    │
│   │                                │                         │
│   └── 哲學：Well-Architected 取捨  └── 哲學：邊界定義精確    │
│             長篇架構情境             短幹關鍵字排他          │
│   ┌────────────────────────────┐   ┌───────────────────────┐ │
│   │  考場口訣：Mark for Review │   │ 考場口訣：先辨題型    │ │
│   │  全卷最後一刻可修改        │   │ Repeated Next ≠ 回頭  │ │
│   └────────────────────────────┘   └───────────────────────┘ │
└──────────────────────────────────────────────────────────────┘

💡 來源：改編自 cxcxc-io/cloud-arch-notes-felo-key1.md 雙雲考場架構對比筆記，已對照 Microsoft Exam Sandbox 與 Pearson VUE 實際作答機制調整。
💡 架構師拓撲解讀：

1. 題型複雜度層：AWS 考試以文字為主（MC/MR），考生只需點選；Azure AZ-900 引入 多種互動題型，其中 Hot Area（截圖熱點）與 Drag & Drop 需要對 Azure Portal 介面佈局有直覺認識，純靠背書無法應對。
2. 作答可逆性層：AWS 全卷隨時可回頭是架構師的「後悔藥」；Azure AZ-900 的正式題型與導覽規則不應由本專案自訂的 Repeated Scenario 練習推導；每題仍應依當次介面與題目要求作答。
3. 計分機制層：Microsoft 未公開 AZ-900 各互動題型的逐項配分，因此本專案不從題型推導「不留白」或逐項得分策略。

🕷️ AZ-900 四大陷阱穿越拓撲（Trap Traversal）

四大高頻陷阱並非孤立存在，而是沿著「考綱 → 題幹關鍵字 → 干擾選項 → 失分節點」形成可預測的穿越路徑。掌握路徑結構，就能在毫秒內識破陷阱：

┌──────────────────────────────────────────────────────────────┐
│          AZ-900 四大高頻陷阱穿越路徑圖（Trap Map）           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ ⚠ Trap 1：關鍵字絕對化（Always / Never / Only / All）        │
│   題幹觸發字 ──▶ "always the customer's responsibility"      │
│   陷阱節點  ──✗▶ 誤選「雲端提供商全管」(SaaS ≠ 完全免責)     │
│   正解路徑  ──✓▶ Data & Identity 任何模型下恆為客戶責任      │
│                                                              │
│ ⚠ Trap 2：服務名稱重組與相近詞混淆                           │
│   題幹觸發字 ──▶ "compliance audit / enforce standard"       │
│   陷阱節點  ──✗▶ 誤選 Resource Lock（防刪，不是合規）        │
│   正解路徑  ──✓▶ Azure Policy（規則審核 Audit / Deny）       │
│                  └── 反向陷阱：問「防誤刪」卻選 Policy       │
│                      ✓ 正解應為 Resource Lock (CanNotDelete) │
│                                                              │
│ ⚠ Trap 3：Tags 權限與安全性誤解                              │
│   題幹觸發字 ──▶ "tag DoNotDelete / organize / cost center"  │
│   陷阱節點  ──✗▶ 誤以為 Tag 可防刪或限制存取                 │
│   正解路徑  ──✓▶ Tags = 中繼資料標籤，無權限無防護           │
│                  防誤刪 ──▶ Resource Lock                    │
│                  限存取 ──▶ Azure RBAC                       │
│                                                              │
│ ⚠ Trap 4：SLA 複合計算遞減陷阱                               │
│   題幹觸發字 ──▶ "two services in series / both required"    │
│   陷阱節點  ──✗▶ 誤選較高的單一服務 SLA（如 99.99%）         │
│   正解路徑  ──✓▶ 複合 SLA = SLA_A × SLA_B                    │
│                  99.99% × 99.9% = 99.89%（低於最低值！）     │
│                                                              │
│ 🔑 通用防禦口訣：                                            │
│   絕對字 → 找例外；名稱像 → 查職責邊界                       │
│   Tag    → 零權限；多服務串聯 → 乘法計算                     │
└──────────────────────────────────────────────────────────────┘

💡 來源：整合 refs/gemini_deep_research_report.md 四大高頻陷阱分析（第 6 節）與 ExamTopics AZ-900 社群討論高頻錯誤報告，已對照 Microsoft Learn 官方文件交叉驗證。
💡 拓撲解讀：

1. Trap 1（絕對化）：AWS CLF-C02 考場亦有相同陷阱；雙雲共同防守口訣是「資料（Data）是客戶永久責任，任何模型皆然」。
2. Trap 2（名稱重組）：Policy vs Lock 是 AZ-900 史上最高頻配對干擾項——enforce/audit/deny → Policy；CanNotDelete/ReadOnly → Lock，兩者職責完全不重疊。
3. Trap 3（Tags 誤解）：AZ-900 考題習慣將「打上 DoNotDelete Tag」作為防誤刪干擾選項，正解永遠是 Resource Lock；AWS 亦同，User-Defined Tags 無法賦予任何 IAM 權限。
4. Trap 4（SLA 遞減）：兩服務「串聯」依賴時，複合 SLA 必定低於最低單一值；若改為「主備冗餘（Active-Passive）」，可用性則會相應提升。

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

🏛️ 情境背景：Titan 科技的最後一場考前演習

Titan 科技的架構師候選人已經完成 Day 1–27。

CTO 今天不再問：「Azure Policy 是什麼？」

而是丟給你一組混合題：

「你知道 Azure 服務，但如果題目換成拖曳、排序、點擊圖形，而且故意把『最小管理』、『直接連線』、『強制』、『防止刪除』這些字放在一起，你還能不能穩定答對？」

這就是今天的 Boss：題型本身不是知識點，但錯誤的作答流程會讓你把已經會的知識答錯。

🧩 決策任務

請為 Titan 建立一套「遇到非單選題時」的標準作答流程。

• A：看到 Drag & Drop 就先把所有選項拖到看起來最像的位置，再慢慢閱讀題目。
• B：先辨識題型，再讀題幹與限制條件，建立「描述 → Azure 概念」映射，最後才操作介面。
• C：直接記 ExamTopics 的答案位置；只要看到相同關鍵字就照排。
• D：所有題型都先猜 Azure 服務名稱，因為題型不影響答案。

🎯 解題拆解與解析

✅ 正解：B

這是今天最重要的一題。

第一步：辨識題型。
Drag & Drop 的核心不是「拖」，而是建立正確的關係；Build List 的核心不是「選」，而是建立順序；Hot Area 的核心則是辨識正確位置。

第二步：讀限制條件。
例如：

• least management → 管理責任是關鍵。
• enforce → 治理規則可能是 Policy。
• prevent deletion → Resource Lock。
• highest parent → 這是階層排序問題。
• public Internet → 連線路徑問題，不要只看到「Azure networking」就亂選。

第三步：才操作介面。
先在腦中完成配對，再用滑鼠／鍵盤執行，可以降低「拖錯一個之後連鎖污染」的風險。

❌ 陷阱分析

• A：把操作介面當成猜題工具，容易因第一個錯誤配對而造成後續判斷混亂。
• C：題庫答案不是現行官方考綱。尤其 2020 年題庫存在服務更名與考綱調整，不能當作答案資料庫。
• D：題型會改變「你必須如何提交答案」，也會改變你應該採用的思考方式；但不代表知識本身改變。

🧠 Boss Fight 口訣：先辨題型 → 再抓限制 → 建立關係 → 最後操作。

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

題庫使用聲明：以下不是 Microsoft 官方公開真題原文，而是依 GEMINI.md 規範，將 ExamTopics／gratisexam 的題型與考點改寫成 Titan 科技原創情境。ExamTopics 題目僅作為題型與社群回報線索，Microsoft Learn 才是技術驗證依據。

📝 真題 1：Drag & Drop 不是「看起來像」就配（ExamTopics Q461 改編）

題目情境

Titan 要替不同工作負載選擇 Azure 運算服務。請將「服務」與「最符合的用途」建立配對。

服務池：

• Azure Virtual Machines
• Azure Virtual Machine Scale Sets
• Azure Functions
• Azure Container Instances

描述：

1. 需要完整控制虛擬機器作業系統與基礎環境。
2. 需要管理一組 VM 執行個體，並能依需求調整執行個體數量。
3. 希望以事件驅動方式執行程式碼，降低基礎設施管理。
4. 希望快速執行容器工作負載，而不需要自己管理完整 Kubernetes 叢集。

考點拆解與解析

建議配對：

這類題目真正的陷阱，是把 ACI 與 AKS、VM 與 VM Scale Sets 混成同一層級。AZ-900 官方考綱目前明確要求比較 containers、virtual machines、functions，以及 VM Scale Sets。

來源與驗證：改寫自 ExamTopics Q461 的 Drag & Drop「Azure compute services 配對」高頻題型；題型為 DRAG DROP，社群討論高票支持上述配對（社群實際票數待以 examtopics-az900-search skill 覆核，本文不杜撰百分比數據）。經 Microsoft Learn 官方考綱交叉核對，Compute 類型與 VM Scale Sets／Functions 均屬現行 AZ-900 正式技能評測範圍。

📝 真題 2：Build List／排序題最怕「順序方向」搞反（ExamTopics Q467 改編）

題目情境

Titan 要建立 Azure 治理階層。請由最高父層 → 最低子層排列：

• Resource
• Subscription
• Management Group
• Resource Group

答案：

Management Group → Subscription → Resource Group → Resource

為什麼？

這題不是在問「哪個服務比較重要」，而是在問 Azure 資源階層的父子關係。

Management Group
        │
        ▼
   Subscription
        │
        ▼
   Resource Group
        │
        ▼
      Resource

考場陷阱：

• 把 Resource Group 當成 Subscription 的上一層。
• 把 Resource 直接放到 Subscription 下，忽略 Resource Group。
• 把「治理範圍」與「資源父子階層」混成同一件事。

Microsoft 官方 AZ-900 Study Guide 明確列出 Management Groups、Subscriptions、Resource Groups，以及三者的階層關係。

來源與驗證：改寫自 ExamTopics Q467 的 Drag & Drop 階層排序題；社群討論高票將順序整理為 Management Groups → Subscriptions → Resource Groups → Resources，並對應 Microsoft Learn 官方資源組織架構（社群實際票數待以 examtopics-az900-search skill 覆核，本文不杜撰百分比數據）。

📝 真題 3：服務模型配對，不要被「雲端」兩個字騙走（ExamTopics Q472 改編）

題目情境

Titan 要把下列描述配到最適合的雲端服務模型：

• IaaS
• PaaS
• SaaS

描述：

1. 企業租用虛擬化運算資源，仍需要管理 Guest OS 與應用程式。
2. 企業部署應用程式，但不希望自己管理底層 OS 與硬體。
3. 使用者直接使用由供應商提供的完整應用程式。

答案：

關鍵不是背三個英文縮寫，而是問：誰負責管理哪一層？

AZ-900 目前仍把 IaaS、PaaS、SaaS 與各自適用情境列在 Cloud Concepts 的正式技能範圍。

來源與驗證：改寫自 ExamTopics Q472 的 Drag & Drop「cloud service → description」題型；討論頁確認該題為 DRAG DROP 配對題（社群實際票數待以 examtopics-az900-search skill 覆核，本文不杜撰百分比數據）。本文依 Microsoft Learn 現行考綱重新驗證三大服務模型的管理邊界。

📝 真題 4：2020 題庫的 Drag & Drop，可以學「邏輯」，不能照抄答案

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q16 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證。原題涉及 Public／Private／Hybrid Cloud 的優勢配對；本文只取考點與陷阱邏輯，不重製原題。

Titan 情境

請將下列雲端模型與最符合的特徵配對：

**陷阱：**不要把「Private Cloud = 一定最安全」或「Public Cloud = 沒有安全性」當成考試規則。模型本身描述的是部署與資源使用方式，不等於自動保證某個安全結果。

Microsoft Learn 現行考綱仍要求考生理解 public、private、hybrid cloud 與其適用情境，因此這個概念仍有價值；但 2020 題庫的敘述、產品名稱與細節不能直接視為現行考題。

來源與驗證：改寫自 2020 年 gratisexam Q16 的 Drag & Drop 雲端模型配對題；屬歷史題庫層，已進行過期考點篩檢，現行技術範圍以 Microsoft Learn AZ-900 官方考綱為準。

📝 真題 5：共同責任模型的「誰負責」陷阱（gratisexam Q13 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q13 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證。原題要求判斷移轉至 Azure VM 後，哪些實體基礎設施管理責任由雲端供應商承擔；本文重新設計成 Titan 情境。

Titan 情境

Titan 將部分地端伺服器搬到 Azure Virtual Machines。下列哪些工作屬於 Azure 基礎設施層的責任，而不是 Titan 自己直接管理？

A. 實體伺服器硬體故障處理
B. Guest OS 更新
C. 應用程式權限設定
D. 應用程式資料備份策略

答案：A

陷阱拆解

• A 正確：Azure 客戶不直接管理 Azure 資料中心的實體伺服器硬體。
• B 錯誤：使用 Azure VM 時，Guest OS 的管理責任仍在客戶側。
• C 錯誤：應用程式與權限設定不是 Azure 替你自動承擔的全部責任。
• D 錯誤：備份策略與資料保護仍需要客戶設計與管理；不能因為使用 Azure 就推論「所有資料保護都由 Microsoft 負責」。

🧠 考試判斷法：看到「誰負責？」先問：這是在談 physical infrastructure、OS、application、data 哪一層？不要用「上雲＝全部交給 Microsoft」的錯誤心智模型。

來源與驗證：改寫自 2020 年 gratisexam Q13；屬歷史題庫層，已進行過期考點篩檢，原始責任邏輯已重新以現行共同責任模型概念檢視。Microsoft Learn AZ-900 官方考綱確認 Shared Responsibility Model 仍為 Cloud Concepts 核心考點。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

為了幫助具備 AWS 背景（CLF-C02 / SAA-C03）的架構師建立扎實的雙向思維映射，我們整合 cxcxc-io 雲端架構庫（cxcxc-io/cloud-arch-notes-felo-key1.md 的架構權衡筆記）與 AWS Well-Architected Framework，精選 2 題雙雲考點連動演練：

📌 【AWS 經典考題 1】AWS Skill Builder / SAA-C03 題型思維 vs AZ-900 考點對照（基於 cxcxc-io 架構筆記）

AWS 考題情境：
參考 cxcxc-io 雲端架構筆記中的核心架構原則：「高可用性與管理成本的取捨權衡」。在 AWS SAA-C03 考題中，常見情境為：某企業需要部署可動態伸縮的運算叢集，且要求在流量驟增時秒級自動擴展，同時要求管理負擔最小化（least administrative effort）。在 AWS 中架構師通常優先選擇 Serverless（如 AWS Lambda 或 Fargate）。
若將相同的需求遷移至 Azure，並在 AZ-900 考場遇到 Drag & Drop 配對題，面對 Virtual Machines、VM Scale Sets、Azure Functions 與 Azure Container Instances (ACI) 四個選項，應如何快速拆解？

• AWS 解題思維：在 AWS SAA 中，關鍵字 least administrative effort + event-driven 必對標 AWS Lambda；若為容器化短暫任務則對標 AWS Fargate。
• 🔄 Azure 知識映射：
  • AWS Lambda ➔ Azure Functions（事件驅動 Serverless，極致降低底層維運負擔）
  • AWS Fargate / ECS ➔ Azure Container Instances (ACI)（快速執行容器，免維護完整 K8s 叢集）
  • AWS EC2 Auto Scaling Group ➔ Azure Virtual Machine Scale Sets (VMSS)（跨多個 VM 執行個體自動擴展）
  • AWS EC2 ➔ Azure Virtual Machines（全功能 IaaS，OS 與安全修補全部由用戶自管）

📌 【AWS 經典考題 2】CLF-C02 服務責任邊界 vs AZ-900 Repeated Scenario 情境練習

AWS 考題情境：
某企業評估將自建資料中心遷移至雲端。CTO 要求架構師指出「在 PaaS 模式下，哪項工作仍由客戶全權負責？」在 AWS CLF-C02 考題中，答案通常是「應用程式代碼與資料保護（Data Protection & Application Code）」。

到了 Azure AZ-900 考場，這類題目常以最具殺傷力的 本專案 Repeated Scenario 情境練習 現身：

• 連續題 1：「Titan 科技採用 Azure App Service 託管 Web 應用。Microsoft 負責作業系統的安全修補與硬體維護。請問這段敘述是否正確？（Yes / No）」➔ Yes。

• 連續題 2：「Titan 科技採用 Azure App Service 託管 Web 應用。Titan 無需為存儲在應用中的客戶個資與資料加密負責，該責任完全由 Microsoft 承擔。請問這段敘述是否正確？（Yes / No）」➔ No。

• 考場殺手警語：這類題組在畫面頂端會有顯著黃色警告標籤。按下 [Next] 之後，[Previous] 鍵完全失效，且在考卷最後的 Review 總結畫面中亦不會出現！ 每一題必須當下做出斷然決策，切忌指望寫完再回頭檢查。

┌────────────────────────────────────────────────────────────┐
│ 雙雲考場思維映射：AWS SAA/CLF vs Azure AZ-900 (cxcxc-io)   │
├────────────────────────────────────────────────────────────┤
│ AWS 考場模式 (Skill Builder / SAA-C03 / CLF-C02)           │
│   • 題型型態：長情境題幹、單選 / 複選（Radio / Checkbox）  │
│   • 核心哲學：Well-Architected 六大支柱權衡（成本 vs 彈性）│
│   • 作答自由：全卷隨時可 Mark for Review，隨意前後跳題     │
│                                                            │
│ Azure 考場模式 (Exam Sandbox / AZ-900 實戰)                │
│   • 題型型態：拖曳連線、排序、熱點下拉、情境判斷練習   │
│   • 核心哲學：平台階層、管理責任邊界、排他性關鍵字定義     │
│   • 致命殺手：Repeated Scenario 按 Next 後永久存檔不可改！ │
└────────────────────────────────────────────────────────────┘

💡 來源：改編自 cxcxc-io/cloud-arch-notes-felo-key1.md 雙雲架構權衡與責任劃分筆記，已對照 Azure 考場實戰機制調整。

🚨 Day 28 真正的 Boss：官方認證四大高頻命題陷阱全破解

結合 Microsoft Learn 技能評估與 Gemini 深度研究報告，考場失分率最高的並非純名詞記憶，而是以下四種設計精密的命題陷阱：

Trap 1：關鍵字絕對化干擾（Always / Never / Only / All）

題幹中若出現「絕對化修飾詞」，通常就是陷阱觸發點：

• 經典考題情境：「企業採用 PaaS 服務（如 Azure App Service），是否完全不需要承擔任何資訊安全責任？」
• 陷阱拆解：考生容易直覺認為「PaaS 由雲端廠商全託管」而選 Yes。
• 共同責任模型：雲端服務不代表客戶完全免除安全責任；責任會隨 IaaS／PaaS／SaaS 等服務模型改變。資料、身分與存取管理等責任應依具體服務與控制項判斷，不應用「永遠 100% 客戶責任」概括。

Trap 2：服務名稱重組與相近詞混淆

微軟特別喜歡用字面上極為相似的服務名稱混淆考生：

• 經典考題情境：「地端舊版 Legacy 應用程式需要透過傳統 LDAP 或 Kerberos 協定進行網域加入（Domain Join），應採用哪項身分服務？」
• 陷阱拆解：許多考生看到身分驗證就直接選 Microsoft Entra ID。
• 官方真相：Microsoft Entra ID（原 Azure AD） 是現代雲端 HTTP/REST 原生身分服務（使用 OAuth 2.0 / OIDC / SAML），不支援傳統 LDAP/Kerberos！要支援傳統網域加入，必須選擇 Microsoft Entra Domain Services。
• 歷史考點篩檢：舊題庫常出現過期稱呼，需辨識：Microsoft Entra ID（原 Azure AD）、Microsoft Defender for Cloud（原 Security Center）、Azure Synapse Analytics（原 SQL Data Warehouse）；而 Blueprints 與 TCO Calculator 則已自 2026 現行考綱正式移除。

Trap 3：Tags 的權限與安全性誤解

• 經典考題情境：「如何確保生產環境資源不會被工程師誤刪，且標記為機密的資料庫無法被未經授權人員修改？」干擾選項常出現「為資源套用 Confidential: True 或 DoNotDelete: Yes 標籤（Tags）」。
• 陷阱拆解：考生容易望文生義，以為標籤具有存取控制力。
• 官方真相：Tags 僅為 Key-Value Metadata（中繼資料），主要用於分類與成本分攤，絕無任何安全性控制、權限限制或防刪除能力！
  • 防止誤刪 ➜ 必須配置 Resource Locks (CanNotDelete)。
  • 限制修改與讀取 ➜ 必須配置 Azure RBAC。
  • 強制套用標籤 ➜ 必須配置 Azure Policy。

Trap 4：SLA 複合計算遞減陷阱

• 經典考題情境：「某應用架構前端採用 Web App（SLA 99.9%），後端連接 Azure SQL Database（SLA 99.9%），系統無額外備援機制。請問該端對端系統的整體可用性 SLA 為何？」
• 陷阱拆解：考生常直覺以為整體系統 SLA 等於兩者中最低者（99.9%），甚至以為有兩個 99.9% 加成會更高。
• 官方真相：若兩個元件都必須同時可用，且題目明確假設可用性事件彼此獨立，可用度可用近似乘法理解：
  $$99.9% \times 99.9% = 0.999 \times 0.999 \approx 99.8%$$

但這是條件式的可用性模型，不應把它寫成所有 Azure 服務組合的官方 SLA 計算規則。
整體系統的可用性必然低於單一組件的可用性！要提升複合 SLA，必須在架構中引進平行備援（如跨 AZ 多活部署或容錯移轉）。

🧭 考場實戰演算法：先判斷題型，再鎖定意圖

題型
 ↓
需求
 ↓
限制條件
 ↓
關鍵字
 ↓
Azure 概念
 ↓
候選答案
 ↓
排除干擾項
 ↓
提交

🧪 10 分鐘考場自測：看到題目先回答「它在考什麼？」

🕸️ AZ-900 知識圖譜拓撲：用 Graph RAG 思維串聯 30 天考點

💡 設計靈感：借鏡 Building Graph RAG on AWS with Neptune Analytics 的知識圖譜拓撲——將非結構化知識萃取為實體（Nodes）與關係（Edges），透過**多跳推理（Multi-hop Traversal）**連結散落在 Day 1–30 的考點。

🧬 為什麼考前需要知識圖譜？

Graph RAG 的核心洞察：單一文件的向量搜尋只能找到「語意相似」的片段，但知識圖譜的邊（Edge）能找到「結構相關」的概念。

一個節點觸發，沿著邊走 2–3 跳，整條知識鏈全部活化。

📊 Graph Schema：節點與邊的定義

┌─────────────────────────────────────────────────────────────────────┐
│                   AZ-900 Knowledge Graph Schema                     │
├──────────────────────────┬──────────────────────────────────────────┤
│  Node Types (實體節點)   │  Edge Types (關係與路徑)                 │
│                          │                                          │
│  ◆ [Concept] 雲端基本概念│  ───PREREQUISITE──▶  先懂 A 才能理解 B   │
│  ■ [Azure]   Azure 核心  │  ───BELONGS_TO────▶  A 屬於 B 的層級範疇 │
│  ▲ [Tool]    管理與監控  │  ═══CONTRASTS═════▶  A 與 B 核心易混淆   │
│  ● [Govern]  治理合規防線│  ···TESTED_WITH···▶  A 與 B 常在同題出現 │
│  ⚠ [Trap]    高頻失分陷阱│  ──×TRAPS_VIA──×──▶  考題透過 A 設下陷阱 │
│  ◇ [QType]   考場四類題型│  ⇄ AWS_MAPS_TO ⇄     AWS 與 Azure 對照   │
└──────────────────────────┴──────────────────────────────────────────┘

🗺️ Domain 1：雲端概念知識子圖（25–30%）

┌─────────────────────────────────────────────────────────────────────┐
│    【Domain 1】Azure 雲端概念核心架構與知識子圖 (占比 25–30%)       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│                  ◆ Azure 雲端八大核心效益 (八大支柱)                │
│    ┌────────────────┬───────────────────┬──────────────────┐        │
│    │  可用與可靠性  │   容量與彈性擴展  │  營運與災難復原  │        │
│    ├────────────────┼───────────────────┼──────────────────┤        │
│    │• High Avail(HA)│• Scalability 垂直 │• Disaster Recov  │        │
│    │• Fault Tolerant│  (Up) 與 水平(Out)│  (DR 跨區備援)   │        │
│    │• Reliability   │• Elasticity (自動)│• Agility (敏捷)  │        │
│    │• SLA 服務承諾  │• Geo-distribution │• 降低全域延遲    │        │
│    └────────────────┴───────────────────┴──────────────────┘        │
│                               │                                     │
│                               ▼                                     │
│              ◆ Azure 共同責任模型 (Shared Responsibility)           │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │ 資源層級與責任範疇      SaaS(M365)   PaaS(AppSvc)   IaaS(VM)  │  │
│  ├───────────────────────────────────────────────────────────────┤  │
│  │ 資料與資訊 (Data)         ● 客戶       ● 客戶        ● 客戶   │  │
│  │ 端點與設備 (Devices)      ● 客戶       ● 客戶        ● 客戶   │  │
│  │ 帳戶與身分 (Identity)     ● 客戶       ● 客戶        ● 客戶   │  │
│  │ 應用程式 (Application)    ■ 微軟       ● 客戶        ● 客戶   │  │
│  │ 作業系統 (OS & Runtime)   ■ 微軟       ■ 微軟        ● 客戶   │  │
│  │ 網路控制 (Network Config) ■ 微軟       ▲ 共享責任    ● 客戶   │  │
│  │ 實體基礎設施 (DC/Hard)    ■ 微軟       ■ 微軟        ■ 微軟   │  │
│  ├───────────────────────────────────────────────────────────────┤  │
│  │ 🔴 考場口訣：Data、Devices、Identity 任何模式下皆為客戶全責   │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                               │                                     │
│               ┌───────────────┴───────────────┐                     │
│               ▼                               ▼                     │
│     ◆ Azure 雲端部署模型              ◆ 雲端財務與計費模型          │
│  ┌─────────────────────────────┐   ┌─────────────────────────────┐  │
│  │• Public Cloud (公有雲)      │   │• CapEx (資本支出)           │  │
│  │  硬體由微軟全權維運與擁有   │   │  前期投入硬體，需折舊攤提   │  │
│  │• Private Cloud (私有雲)     │   │              │ 轉型上雲     │  │
│  │  企業專屬 (地端機房/Stack)  │   │              ▼              │  │
│  │• Hybrid Cloud (混合雲)      │   │• OpEx (營運支出)            │  │
│  │  公私互通 (ExpressRoute/Arc)│   │  隨用隨付 (Pay-as-you-go)   │  │
│  └─────────────────────────────┘   └─────────────────────────────┘  │
│                                                                     │
│  ⇄ AWS 概念對照：                                                   │
│    • AWS Well-Architected 支柱    ⇄  Azure 雲端八大效益             │
│    • AWS Shared Responsibility    ⇄  Azure 共同責任模型 (本質完全同)│
│    • AWS CapEx ➔ OpEx (CLF-C02)   ⇄  Azure Consumption Model (Day 7)│
└─────────────────────────────────────────────────────────────────────┘

🔑 Multi-hop 範例：題目問「降低前期硬體投資，同時保持自動擴展」→ 沿邊走：CapEx → OpEx → Elasticity → PaaS/Serverless。答案在路徑上，不在單一節點。

🗺️ Domain 2：架構與服務知識子圖（35–40%）

┌─────────────────────────────────────────────────────────────────────┐
│  【Domain 2-1】Azure 資源階層組織與全球地理架構 (Day 1–3)           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  === 1. Azure 資源組織 4 級架構 (Build List 高頻考點) ===           │
│                                                                     │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │ ● Root Management Group (根管理群組)                          │  │
│  │   └── ● Management Groups (管理群組，最高支援 6 層巢狀深度)   │  │
│  │         ├── 作用：跨多個訂用帳戶統一套用 Azure Policy 與 RBAC │  │
│  │         └── 繼承：所有子群組與訂用帳戶【自動向下繼承】規則    │  │
│  │                                                               │  │
│  │   └── ● Subscriptions (訂用帳戶)                              │  │
│  │         ├── 邊界：【計費邊界】(Billing) 與【存取與配額邊界】  │  │
│  │         └── 對應：每張獨立帳單，可設獨立預算 (Azure Budget)   │  │
│  │                                                               │  │
│  │   └── ● Resource Groups (資源群組，邏輯容器)                  │  │
│  │         ├── 邊界：【生命週期邊界】(同生共死資源放在同個 RG)   │  │
│  │         └── 特性：資源只能屬於 1 個 RG，可跨不同區域部署資源  │  │
│  │                                                               │  │
│  │   └── ■ Resources (Azure 實體資源)                            │  │
│  │         └── 範例：Azure VM、Storage Account、Virtual Network  │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                                                                     │
│  === 2. Azure 全球地理基礎設施 (High Availability 物理邊界) ===     │
│                                                                     │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │ Geography (地緣政治區域，如 Asia Pacific)                     │  │
│  │   │                                                           │  │
│  │   ▼                                                           │  │
│  │ ■ Azure Region (區域，全球 60+ 個，以低延遲網路相連 DC 集群)  │  │
│  │   │                                                           │  │
│  │   ├─── 包含 ──▶ ■ Availability Zones (AZ 1, AZ 2, AZ 3)       │  │
│  │   │               ├── 每個 AZ 具備【獨立電力、冷卻與網路】    │  │
│  │   │               ├── 彼此相隔數公里，光纖直連 (延遲 <2ms)    │  │
│  │   │               └── 跨 AZ 部署可抵禦單一資料中心火災/斷電   │  │
│  │   │                                                           │  │
│  │   └─── 配對 ──▶ ■ Region Pair (區域對)                        │  │
│  │                   ├── 同一地理區內相距【至少 300 英里】       │  │
│  │                   ├── 微軟平台循序更新 (不同時重開機)         │  │
│  │                   └── 災難復原優先權 (保證關鍵服務迅速拉起)   │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                                                                     │
│  === 3. 特殊合規雲 (Sovereign Clouds) ===                           │
│  • Azure Government (美軍與政府專用，具嚴格合規實體隔離)            │
│  • Azure China 21Vianet (世紀互聯營運，與微軟全球主幹實體完全切斷)  │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│  【Domain 2-2】Azure 運算與無伺服器選型拓撲 (Day 8–10)              │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  === 核心運算服務決策樹 (Drag & Drop 拖曳配對題高頻考點) ===        │
│                                                                     │
│  你要部署什麼樣的工作負載？                                         │
│  │                                                                  │
│  ├── 需要「完整 OS 存取權限」或特定舊版系統軟體？                   │
│  │   └── ▶ ■ Azure Virtua