【Day 21】Phase 3 階段總複習：運算與資料 15 題情境刷題大作戰 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
核心考點：VM / VMSS、App Service Plan 層級、Azure Functions、ACI / AKS、VNet / NSG、ExpressRoute / VPN Gateway、Load Balancer / Application Gateway、Blob Storage 四層存取、Azure Files / Managed Disks、AzCopy / Data Box、SQL Database / Managed Instance、Cosmos DB 五層一致性、Synapse Analytics / Databricks、Application Insights、Azure 成本影響因素、儲存備援模式

🎯 前言與今日目標

恭喜你完成 Phase 2 與 Phase 3 的所有副本！十三天裡，我們從虛擬機器一路打到全球分散式資料庫與巨量分析引擎，裝備欄已經塞滿運算、網路、儲存與資料服務的各式武器。

但 AZ-900 不會按照 Day 編號出題。一道情境題可能同時牽涉「Web API 部署在哪個運算服務、靜態檔案放在哪個儲存層、資料庫選 SQL 還是 NoSQL、分析報表走 Synapse 還是 Databricks、以及監控頁面載入速度的工具是什麼」——五個服務選型塞進同一段題幹，你必須在 90 秒內依關鍵字判斷每一層的正確答案。

因此，今天不開新地圖，而是進行兩項驗收：

1. 以 Phase 2–3 戰利品總盤點 將十三天的服務整理成一張選型地圖，補齊儲存與資料服務的快速判斷框架。
2. 以 15 題情境題 串聯 Day 8–20，練習「抓關鍵字 ➔ 判斷服務類別 ➔ 對照選型條件 ➔ 排除相似干擾項」的作答節奏。

但考試只是最低門檻——真正的驗收是「你能不能在混用多種服務時，預判每個選擇的爆炸半徑」：

• 儲存帳戶共用備援的 Blast Radius：把 Hot 營運資料和 Archive 法遵歸檔放在同一個 Storage Account，備援設定是帳戶層級，若誤操作把帳戶從 GRS 降為 LRS，兩批資料的跨區域保護同時消失。正確做法是依故障容忍需求拆帳戶。
• Serverless 成本失控的 Blast Radius：Azure Functions Consumption Plan 看似「不用就不收費」，但 Event Hub 爆量觸發百萬次 invocation，或 Synapse serverless SQL pool 對未整理的 Parquet 做全資料湖掃描，帳單可能在數小時內暴增。這不是假設場景——對標 cxcxc-io 筆記的原則：「任何 demo、測試或 AI job 都要有終止條件」。
• SQL Database ↔ Managed Instance 選錯的遷移風險：選了 SQL Database 但既有系統依賴 SQL Server Agent 和跨資料庫查詢，上線後才發現不支援，回滾成本遠高於前期評估——這就是「名稱暗示的功能比實際功能更強」陷阱的真實維運代價。

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

🧭 Phase 2–3 十三日戰利品總盤點

🔄 雙雲架構演進路徑對照

對照表只列出「誰等於誰」，但 AWS 和 Azure 的底層架構抽象層級不同。以下展開五個維度的演進路徑，幫你理解雙雲在設計哲學上的分歧：

💡 架構師重點筆記：AWS 的 S3 是「一個 Bucket 搞定所有物件」，Lifecycle 規則在物件層級操作；Azure 的 Storage Account 是帳戶層級命名空間，備援綁定帳戶，Access Tier 可在 Blob 層級覆寫——這意味著 Azure 的「帳戶拆分策略」比 AWS 更重要（見前言的備援爆炸半徑討論）。

📐 Phase 2–3 全端請求鏈：AWS ↔ Azure 並排圖

Day 8–20 涵蓋的服務串起來，就是一條完整的端到端請求處理鏈。以下將 AWS 典型的高並發架構（cxcxc-io 圖 7 + 圖 17）翻譯為 Azure 等價路徑：

┌─────────────────────────────────┐
│  AWS 請求鏈路                   │
├─────────────────────────────────┤
│  Internet                       │
│     │                           │
│     v                           │
│  Route53 → CloudFront           │
│     │                           │
│     v                           │
│  ALB / NLB                      │
│     │                           │
│     +→ EC2 ASG (web)            │
│     │    +→ ElastiCache Redis   │
│     │    +→ RDS / DynamoDB      │
│     │    +→ SQS → Worker EC2   │
│     │                           │
│     +→ S3 (static / OAI)       │
│     +→ CloudWatch / CloudTrail │
└─────────────────────────────────┘
       ⇕ Azure 等價服務 ⇕
┌─────────────────────────────────┐
│  Azure 請求鏈路                 │
├─────────────────────────────────┤
│  Internet                       │
│     │                           │
│     v                           │
│  Azure DNS → Front Door / CDN   │
│     │                           │
│     v                           │
│  App Gateway (L7) / LB (L4)    │
│     │                           │
│     +→ App Service / VM (web)   │
│     │    +→ Azure Cache Redis   │
│     │    +→ SQL DB / Cosmos DB  │
│     │    +→ Queue → Functions   │
│     │                           │
│     +→ Blob Storage (static)    │
│     +→ Monitor / Log Analytics │
└─────────────────────────────────┘

💡 來源：改編自 cxcxc-io diagram_07 + diagram_17（AWS 全端高並發架構圖），已對照 Azure 服務調整。兩條鏈路的設計哲學相同——邊緣加速 → 負載分發 → 應用運算 → 快取 → 資料層 → 非同步佇列 → 觀測治理——差異在於 Azure 的 PaaS（App Service / Functions）比 AWS 的 EC2 ASG 更常作為預設選擇。

🗄️ 儲存服務快速選型決策

Phase 3 涵蓋五種主要儲存服務，AZ-900 常見陷阱是把它們當成可互換的「存東西的地方」。實際上每種服務的存取模式、協定與適用場景完全不同：

┌──────────────────────────────────────┐
│       「要存什麼？」                 │
├──────────┬──────────┬────────────────┤
│非結構化  │檔案共用  │ VM 磁碟        │
│物件(圖片/│(SMB/NFS) │(OS/應用程式)   │
│影片/日誌)│          │                │
│    ▼     │    ▼     │      ▼         │
│  Blob    │ Azure    │  Managed       │
│ Storage  │  Files   │   Disks        │
├──────────┴──────────┴────────────────┤
│ 訊息佇列？ → Queue Storage          │
│ Key-Value？→ Table Storage           │
└──────────────────────────────────────┘

💡 架構師重點筆記：題目出現「大量非結構化物件」選 Blob；「SMB 共用磁碟機」選 Files；「VM 作業系統磁碟」選 Managed Disks；「非同步訊息傳遞」選 Queue；「key-value 簡單查詢」選 Table。不要讓「Storage」這個共用字根騙你選錯服務。

🗃️ 資料服務選型矩陣

Day 18–20 涵蓋三種資料服務角色，但考試常把它們混在一起。核心判斷鏈是：

┌──────────────────────────────────────┐
│    先判斷工作負載型態                 │
├──────────┬──────────┬────────────────┤
│OLTP      │OLTP      │ OLAP 分析      │
│關聯式 SQL│NoSQL     │ 資料倉儲/BI    │
│    ▼     │    ▼     │      ▼         │
│SQL DB 或 │Cosmos DB │ Synapse 或     │
│Managed   │          │ Databricks     │
│Instance  │          │                │
├──────────┴──────────┴────────────────┤
│ 新專案→SQL DB；遷移→MI              │
│ SQL BI→Synapse；Spark→Databricks    │
└──────────────────────────────────────┘

💡 架構師重點筆記：SQL Database 與 Managed Instance 都是關聯式，但 MI 保留 SQL Server Agent、cross-database query 等傳統功能；Synapse 與 Databricks 都能處理大數據，但 Synapse 以 SQL 分析為核心，Databricks 以 Apache Spark 與 Notebook 協作為核心。題目出現「不想改程式碼、近乎 100% SQL Server 相容」就指向 MI；出現「Spark、Notebook、資料工程」就指向 Databricks。

💰 Azure 資源成本三大影響因素

AZ-900 常考「哪些因素影響 Azure 資源成本」，核心答案是三項：

1. 出站資料量 (Outbound data transfer)：資料「進」Azure 免費，資料「出」Azure 按量計費。這是雲端定價的「加州旅館原則」——進來免費，出去收費。
2. 服務層級 (Service tier)：同一服務的 Free / Basic / Standard / Premium 層，功能與價格完全不同。
3. Azure 區域 (Region)：不同區域的運算與儲存定價不同，受當地電力成本、土地與資料中心密度影響。

不影響成本的陷阱選項：入站資料量（免費）、資料的「類型」（Azure 按容量計費，不管是影片還是文字）。

📐 App Service Plan 層級比較

Day 9 的 App Service 在實際考試中常以「選最便宜但滿足需求的 Plan」出現。以下是快速比較：

💡 架構師重點筆記：考題常設的陷阱是「12 GB 儲存需求」——Basic 只有 10 GB 上限，所以即使其他需求 Basic 都能滿足，仍需升級至 Standard。先比對所有需求再選最低滿足的層級，不要只看其中一項就下結論。

🛡️ 備援層級與故障爆炸半徑 (Blast Radius)

儲存備援選型的判斷鏈是「先問最大可接受的故障邊界，再看是否需要次要端讀取」：

┌──────────────────────────────────────┐
│ 故障爆炸半徑 (Blast Radius)          │
├──────────────────────────────────────┤
│                                      │
│  LRS ──── 單一資料中心內 ────────→  │
│           磁碟/機架故障              │
│                                      │
│  ZRS ──── 同區域跨 3 AZ ─────────→  │
│           單一 AZ/DC 故障            │
│                                      │
│  GRS ──── 跨配對 Region ─────────→  │
│           整區域故障(次要不可讀)      │
│                                      │
│  RA-GRS ─ 跨 Region + 唯讀副本 ──→  │
│           區域故障 + 立即可讀         │
│                                      │
│  GZRS ─── ZRS + GRS ─────────────→  │
│           Zone + Region 複合故障     │
└──────────────────────────────────────┘

💡 架構師重點筆記：LRS 最便宜但爆炸半徑最大（整個 DC 失效即全失）；RA-GRS 爆炸半徑最小但成本最高。不要只比較名稱——GRS 的「異地」聽起來很安全，但次要端預設不可讀。

🛡️ 防禦性設計與原廠最佳實踐（Phase 2–3 跨章）

1. 機密防護 (Secret Management)：Storage Account 的連接字串、SQL Database 的連線密碼絕不可硬編碼在程式碼或 ARM 範本中。正確做法是存入 Azure Key Vault，再用 Managed Identity 取用（對照 AWS Secrets Manager + IAM Role）。
2. 最小權限 (Least Privilege)：Blob Container 的存取不要使用 Account Key（等同 root 權限），應改用 Microsoft Entra ID + RBAC，將讀取/寫入/刪除權限分開授予。
3. 變更審查 (Change Review)：儲存帳戶的備援模式變更（如從 GRS 降為 LRS）是高風險操作——建議先用 Azure What-If（ARM 部署預覽）或 Terraform Plan 確認影響範圍，再執行變更。
4. 成本止血 (Cost Guardrails)：對標 cxcxc-io 筆記的 Budget Alert 三門檻，Azure Cost Management 可設定 50%/80%/100% 預算警示，串接 Action Group 發送通知。Synapse serverless SQL pool 和 Functions Consumption Plan 特別需要這層防禦。

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

(註：本日為 Phase 3 階段總複習日，特此精選四個最常混淆的核心名詞進行觀念回顧與跨服務速查)

1. Application Insights

   • 定義：Azure Monitor 的子功能，專供即時 Web 應用效能監控 (APM)，可追蹤頁面載入時間、例外偵測、相依性呼叫等。
   • AWS 對照：AWS X-Ray（方向性對照，功能範圍不完全相同）。
   • 考點：看到「監控 Web 應用回應時間」「追蹤使用者瀏覽器載入速度」就選 Application Insights，不選 Azure Monitor Alerts（通知機制）或 Log Analytics（查詢引擎）。

2. Azure Data Box

   • 定義：實體裝置離線資料搬遷服務，適合數十 TB 以上的大量資料遷移，避免長時間佔用網路頻寬。
   • AWS 對照：AWS Snowball。
   • 考點：看到「離線」「實體裝置」「80 TB」「頻寬有限」就選 Data Box，而非 AzCopy 或 Storage Explorer。

3. App Service Plan 層級 (Tier)

   • 定義：定義 App Service 的運算資源配置、功能集與價格，從 Free 到 Isolated 分為多個層級。
   • 考點：選最低滿足所有需求的層級；注意 Basic 的 10 GB 儲存上限與手動擴展限制。

4. RA-GRS（讀取存取異地備援儲存）

   • 定義：在 GRS 基礎上，額外提供次要區域的唯讀端點，讓應用在正常狀態下也能從次要區域讀取資料。
   • AWS 對照：S3 Cross-Region Replication + S3 Multi-Region Access Points（方向性對照）。
   • 考點：題目問「區域故障時仍能讀取」，GRS 在故障轉移前次要端點不可讀，只有 RA-GRS 在正常狀態即提供次要區域讀取。

📊 雲端筆記：監控工具四兄弟比較

四個名字很像的監控與建議工具，是 Phase 3 之後每一天都可能重複出現的高頻混淆點：

💡 速記口訣：Monitor 是總管、Insights 是前線斥候（收集 APM 數據）、Log Analytics 是後方情報室（查資料）、Advisor 是顧問（給建議不盯場）。

🚚 雲端筆記：資料搬遷三兄弟比較

💡 速記口訣：能用滑鼠點的用 Explorer；能寫腳本跑的用 AzCopy；網路傳不動、要用貨車搬的用 Data Box。

🕵️ 四大高頻審題陷阱（Phase 2–3 收尾必練）

刷題之前，先抽出四種讓考生在運算與資料題型上扣分的審題陷阱模式。這四種陷阱橫跨 Day 8–20 所有主題，Phase 4 之後每一天都會再遇到：

1. 「Serverless = 免費」陷阱：Azure Functions 的 Consumption Plan 按執行次數與時間計費，不是「不用就完全免費」。同理，Synapse serverless SQL pool 按掃描資料量計費。題目問「如何最小化成本」時，不能只看「serverless」就覺得沒成本——未整理的原始資料被反覆全表掃描，帳單可能比預期高出數倍。

2. 儲存層級轉換限制陷阱：Blob 四個存取層不是隨時免費切換的。Archive 層有最低 180 天保留期限與數小時取回延遲；Cool 有 30 天最低保留；Cold 有 90 天最低保留。提前刪除或轉換會收取差額費用。看到「成本最低」不能只比儲存單價，還要考慮存取頻率與轉換代價。

3. SQL Database ≠ SQL Managed Instance 陷阱：兩者都姓「Azure SQL」，但 SQL Database 針對雲原生新開發最佳化（更簡單、更便宜），而 Managed Instance 保留 SQL Server Agent、跨資料庫查詢、CLR 等傳統功能。題目出現「遷移既有 SQL Server、改動最少」就選 MI；出現「全新雲端應用」就優先評估 SQL Database。

4. 備援模式名稱陷阱：LRS / ZRS / GRS / RA-GRS 四種備援，容易混淆「跨 AZ」與「跨區域」。ZRS 跨三個 AZ 但仍在同一區域；GRS 跨區域但預設次要端點不可讀；只有 RA-GRS 在正常狀態下就提供次要區域的唯讀存取。題目問「區域故障時仍能讀取」，GRS 不夠——要 RA-GRS。

💡 架構師重點筆記：這四種陷阱的共同模式是「名稱暗示的功能比實際功能更強」。Serverless 不是免費、Archive 不是隨取隨用、SQL Database 不是完整 SQL Server、GRS 不是隨時可從次要區域讀取。拿到題目先問「這個名詞的實際限制是什麼」，通常就能刪掉 1–2 個干擾項。

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

🏛️ 情境背景：Titan 科技的全棧資料平台驗收

Titan 科技的跨國遊戲平台已完成 Phase 2 的運算與網路部署，現在 CTO 在 Phase 3 驗收會議提出六項需求：

CTO：「遊戲 Web API 團隊不想管 OS，只管程式碼部署；玩家個人資料需要全球低延遲讀寫；財務報表必須用 SQL 關聯式查詢且保留既有 SQL Server Agent 排程；歷年遊戲錄影（50 TB）要以最低成本歸檔保存、每年最多取回一次；營運團隊每天要用 SQL 查看資料湖裡的 BI 指標；最後，我要看到每個頁面在使用者瀏覽器端的載入時間。六項需求，一次交出完整方案。」

🧩 決策任務

• A：所有服務統一使用 VM 手動建置；資料全存 Cosmos DB；錄影放 Blob Hot 層；分析直接對 Cosmos DB 跑 Power BI；用 Azure Advisor 看頁面載入速度。
• B：Web API 用 Azure App Service (PaaS)；玩家個人資料用 Cosmos DB；財務系統用 SQL Managed Instance；錄影存 Blob Archive 層；資料湖分析用 Synapse SQL；頁面載入時間用 Application Insights。
• C：所有系統部署在 Azure Functions；資料全存 Azure Files；錄影用 Azure Queue Storage；分析用 Azure DNS；監控用 Resource Group Tag。
• D：Web API 用 AKS 叢集；所有資料存 Azure Table Storage；錄影放 Managed Disks；分析用 Azure Databricks Notebook；監控用 Azure ExpressRoute。

🎯 解題拆解與解析

✅ 正解：B

• 運算選型：App Service 是 PaaS，Microsoft 管理 OS 與執行環境，團隊只管程式碼與資料，符合「不想管 OS」。
• NoSQL 選型：Cosmos DB 提供全球分散式個位數毫秒讀寫，適合玩家個人資料的低延遲需求。
• 關聯式選型：SQL Managed Instance 保留 SQL Server Agent 排程與跨資料庫查詢，近乎 100% 相容傳統 SQL Server，符合「保留既有排程」。
• 儲存選型：每年最多取回一次的 50 TB 錄影，Archive 層儲存成本最低，且題目已確認可接受數小時取回延遲。
• 分析選型：Synapse SQL 可直接查詢資料湖的已整理資料，符合「SQL 查看 BI 指標」。
• 監控選型：Application Insights 追蹤使用者瀏覽器端載入時間，是 APM 的核心功能。

┌─────────────────────────────────────────────────────────────┐
│ Titan 科技 Phase 3 驗收 — 正解 B 全棧服務架構拓樸           │
├─────────────────────────────────────────────────────────────┤
│  🎮 玩家瀏覽器 / App ──── (HTTPS) ────→ [ App Service ]     │
│        │                                  (PaaS Web API)    │
│        │ (載入時間 APM 追蹤)                  │             │
│        ▼                                      ├──→ Cosmos DB│
│  [ Application Insights ] ───────────────────┤    (全球NoSQL)
│                                               ├──→ SQL MI   │
│                                               │    (SQLAgent)
│                                               └──→ Archive  │
│                                                    (50TB錄影)
│                                                       │     │
│                                                       ▼     │
│                                               [ Synapse SQL]│
│                                               (資料湖 BI)   │
└─────────────────────────────────────────────────────────────┘

❌ 陷阱分析

• 選項 A：所有服務用 VM 等於把 OS 維運責任全留給團隊，違反「不管 OS」需求；Cosmos DB 適合低延遲操作型讀寫，不適合大範圍 BI 分析（資源競爭與成本爆炸風險）；Blob Hot 層的儲存成本遠高於 Archive；Azure Advisor 提供最佳化建議，不監控頁面載入速度。
• 選項 C：Azure Functions 適合事件驅動短暫執行，不適合持續性 Web API 服務；Azure Files 以 SMB/NFS 為設計目標，不是物件儲存也不是關聯式資料庫；Queue Storage 是訊息佇列，不能用來歸檔影片；Azure DNS 是名稱解析服務，不做資料分析；Tag 是詮釋資料標籤，不是監控工具。
• 選項 D：AKS 對「不想管 OS」的團隊引入過多容器編排與叢集管理複雜度；Table Storage 是簡單 key-value，不是關聯式資料庫也不是全球分散式 NoSQL；Managed Disks 綁定 VM，不適合獨立歸檔大量影片；ExpressRoute 是混合雲私有連線，不是應用效能監控工具。

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

本日共 15 題。第 1–3 題取自 ExamTopics 並以社群 data-answers-tally 驗證、再經 Microsoft Learn 覆核；第 4–5 題改寫自 2020 年 gratisexam 題庫；第 6–15 題為跨章整合演練。先遮住解析作答，再檢查自己抓到的是「服務類別、存取模式、成本因素，還是工具定位」。

第一回合：5 題來源驗證真題

📝 真題 1：App Service Plan 層級選型（ExamTopics Q9 改編）

Titan 科技要在 Azure 上架設一個公開 Web 應用，需求如下：使用自訂網域 miami.titan.com、部署到兩個執行個體、必須支援 SSL、需要 12 GB 儲存空間、成本最小化。應選擇哪個 App Service Plan 層級？

• A. Standard
• B. Basic
• C. Free
• D. Shared

• 正確答案：A. Standard
• 關鍵字識別：「自訂網域」＋「兩個執行個體」＋「SSL」＋「12 GB」＋「成本最小化」。需逐項比對各層級功能上限。
• 陷阱識破（逐選項查證）：
  • B. Basic：支援自訂網域與 SSL，也能手動擴展至 3 個執行個體，但儲存上限為 10 GB，不足 12 GB 需求。這是最強干擾項——若忽略儲存條件會誤選。
  • C. Free：不支援自訂網域、不支援 SSL、僅 1 個執行個體、1 GB 儲存，四項需求全部不滿足。
  • D. Shared：支援自訂網域但不支援 SSL，且僅 1 GB 儲存、無法擴展至多個執行個體。
• Standard 為何正確：自訂網域 ✅、SSL ✅、最多 10 個自動擴展執行個體（滿足 2 個） ✅、50 GB 儲存（滿足 12 GB） ✅。是滿足所有需求的最低層級。
• ⚠️ 社群分歧說明：原題有 4 票選 B (Basic)，認為 Basic 已足夠。但最高票 30 票明確指出 Basic 的 10 GB 儲存上限不符 12 GB 需求，且最高讚留言（24 讚）逐項列出 Standard 滿足所有條件。B/A 之爭的關鍵就是「Basic 到底有幾 GB」——官方文件確認 Basic 為 10 GB。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題 Q9，data-answers-tally 實測 A 30 / B 4 / U 1，經 Playwright 直接讀取討論頁確認，非靜態樣板百分比）；並經 Microsoft Learn：App Service 定價層概觀 交叉驗證確認（含四個選項的正反面查證）。

📝 真題 2：Azure 資源成本三因素（ExamTopics Q411 改編）

Titan 科技財務長要求降低 Azure 持續性支出。你需要找出影響資源成本的三項因素。（每個正確選項各計一分）

• A. 出站資料量
• B. 入站資料量
• C. 服務層級
• D. Azure 區域
• E. 處理的資料類型

• 正確答案：A、C、D
• 關鍵字識別：「影響成本的因素」，必須從五個選項中選三個正確答案。
• 陷阱識破：
  • B. 入站資料量：Azure 對入站資料（ingress）不收費，這是雲端定價的常見模式——「進來免費，出去收費」（Hotel California 原則）。
  • E. 處理的資料類型：Azure 按資料容量計費，不區分影片、文字或日誌的「內容類型」。1 TB 影片與 1 TB 日誌的傳輸與儲存成本相同。
• 正確三項解析：出站資料（egress）按量計費（A）；服務層級（Free / Basic / Standard / Premium）直接決定功能與單價（C）；不同 Azure 區域的運算與儲存定價因當地營運成本而異（D）。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題 Q411，data-answers-tally 實測 ACD 58 票為壓倒性共識、無任何其他組合票數，經 Playwright 直接讀取討論頁確認）；並經 Microsoft Learn：Azure 定價概觀 交叉驗證確認。

📝 真題 3：監控 Web 頁面載入速度（ExamTopics Q423 改編）

Titan 科技的 Web 應用在 Azure 上運行。你需要量測網頁在使用者瀏覽器中的載入時間。應使用什麼？

• A. Azure Monitor 警示
• B. Azure Monitor 中的 Application Insights
• C. Log Analytics
• D. Azure Network Watcher

• 正確答案：B. Application Insights in Azure Monitor
• 關鍵字識別：「Web 應用」＋「使用者瀏覽器端」＋「載入時間」。這是標準的應用程式效能監控 (APM) 需求。
• 陷阱識破（逐選項查證）：
  • A. Azure Monitor 警示：警示 (Alerts) 是通知機制——當指標超過閾值時發出通知，它本身不負責收集頁面載入效能資料。
  • C. Log Analytics：Log Analytics 是查詢與分析 Azure Monitor 日誌資料的工具，用 KQL 做互動式分析，但不直接收集前端瀏覽器效能。
  • D. Azure Network Watcher：Network Watcher 監控與修復 IaaS 網路健康（VM、VNet、Load Balancer），不設計給 PaaS Web 應用或前端瀏覽器效能分析。
• 為何選 Application Insights：它是 Azure Monitor 的 APM 子功能，可在使用者瀏覽器端注入追蹤碼，收集頁面載入時間、例外、相依性呼叫等前端與後端效能數據。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題 Q423，data-answers-tally 實測 B 13 票為唯一選項，經 Playwright 直接讀取討論頁確認）；並經 Microsoft Learn：Application Insights 概觀 交叉驗證確認（含四個選項的逐一排除查證）。

📝 真題 4：Archive 層的取回代價（2020 題庫 Q44 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q44 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，核心觀念仍有效。

Titan 科技要長期保留法遵所需的歷史紀錄，平時幾乎不存取，但一旦需要取回可以接受數小時等待。哪個 Blob 存取層級最省成本？

• A. Hot
• B. Cool
• C. Cold
• D. Archive

• 正確答案：D. Archive
• 關鍵字識別：「幾乎不存取」＋「接受數小時等待」＋「法遵長期保留」。三個關鍵字同時出現，鎖定 Archive 層。
• 陷阱識破：
  • A. Hot：適合頻繁存取，儲存成本最高——法遵歸檔根本不需要這種存取速度，純浪費預算。
  • B. Cool：適合至少 30 天保留、偶爾存取，儲存成本中等，但對「幾乎不存取」的場景仍偏高。
  • C. Cold：適合至少 90 天保留、罕見存取，是 2023 新增的層級，填補 Cool 與 Archive 的間隙。但題目說「接受數小時等待」，代表 Archive 的取回延遲可接受，不需停留在 Cold。
• Archive 的代價提醒：Archive 層儲存成本最低，但取回（rehydrate）需要數小時（標準最多 15 小時，高優先最多 1 小時），且有最低 180 天保留要求。未到期提前刪除會收取差額費用。

┌─────────────────────────────────────────────────────────────┐
│ Blob 存取層生命週期與 Rehydrate (取回) 流程                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [ Hot (熱) ] ─── (30天+ 偶爾存取) ───→ [ Cool (冷) ]       │
│        ▲                                    │               │
│        │                               (90天+ 罕見存取)     │
│        │                                    ▼               │
│  Rehydrate (取回)                       [ Cold (極冷) ]     │
│  (標準最多15hr / 高優先1hr)                 │               │
│        │                               (180天+ 歸檔)        │
│        │                                    ▼               │
│        └─────────────────────────────── [ Archive (封存) ]  │
│                                         (最低保留 180 天)   │
└─────────────────────────────────────────────────────────────┘

• 來源與驗證：經 Microsoft Learn：Blob 存取層級 交叉驗證確認。

📝 真題 5：SQL Server 遷移的最大相容性（2020 題庫 Q73 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q73 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，核心觀念仍有效。

Titan 科技既有系統大量依賴 SQL Server Agent 排程、跨資料庫查詢與 CLR 整合。搬遷至 Azure 時希望程式碼改動最少。應選哪個服務？

• A. Azure SQL Database
• B. Azure SQL Managed Instance
• C. Azure Cosmos DB
• D. Azure Table Storage

• 正確答案：B. Azure SQL Managed Instance
• 關鍵字識別：「SQL Server Agent」＋「跨資料庫查詢」＋「CLR」＋「改動最少」。這些都是傳統 SQL Server 的進階功能，在 Azure SQL Database 中不完全支援。
• 陷阱識破：
  • A. Azure SQL Database：是雲原生 PaaS 關聯式資料庫，針對新開發最佳化，但不支援 SQL Server Agent、跨資料庫查詢等傳統功能。若題目只說「需要關聯式資料庫」且無遷移相容需求，SQL Database 是好選擇——但本題有明確的遷移需求。
  • C. Azure Cosmos DB：NoSQL 資料庫，不支援 T-SQL 原生查詢語法、SQL Server Agent 或 CLR，與題目的 SQL Server 遷移完全不相關。
  • D. Azure Table Storage：簡單 key-value 儲存，無關聯式查詢能力，也不是資料庫遷移選項。
• 來源與驗證：經 Microsoft Learn：Azure SQL Managed Instance 概觀 交叉驗證確認。

第二回合：10 題跨章情境演練

⚠️ 來源說明：本區塊 10 題為 Phase 2–3（Day 8–20）全章觀念整合與核心架構情境延伸演練題，依跨服務選型考點精心設計，並經 Microsoft Learn 官方文件進行技術覆核與交叉驗證。

📝 情境題 6：非結構化物件的正確歸屬

Titan 科技要儲存數百萬張玩家上傳的遊戲截圖，每張 2–5 MB，需透過 REST API 大量讀取。最適合的儲存服務是？

• A. Azure Blob Storage
• B. Azure Files
• C. Azure Managed Disks
• D. Azure Queue Storage

• 正確答案：A. Azure Blob Storage
• 關鍵字識別：「非結構化物件 (截圖)」＋「REST API 讀取」＋「數百萬張小檔案」。
• 核心考點定位：Azure 儲存服務的型態與存取協定邊界。
• 陷阱識破：Azure Files 主打 SMB/NFS 檔案共用協定而非 REST API；Managed Disks 綁定單一 VM 作業系統或資料磁碟。
• 逐一排除干擾項：
  • B. Azure Files：提供 SMB/NFS 網路磁碟共用，非 REST 存取的非結構化物件儲存 ❌
  • C. Azure Managed Disks：專屬 VM 磁碟，無法獨立提供網頁 API 物件存取 ❌
  • D. Azure Queue Storage：非同步訊息傳遞佇列，單一訊息最大 64 KB，無法存 2–5 MB 截圖 ❌
• 最佳實踐與驗證：巨量圖片、影片等非結構化物件應使用 Blob Storage，配合 Hot/Cool 存取層優化費用；經 Microsoft Learn：Blob Storage 總覽 交叉驗證確認。

📝 情境題 7：VM 未受管理磁碟的儲存形式

Titan 科技有一批舊 VM 使用 unmanaged data disks。這些未受管理的磁碟以什麼形式儲存在 Azure 中？

• A. Page Blobs（在 Blob Storage 容器中）
• B. Azure Files 的 SMB 共用
• C. Azure Queue Storage 訊息
• D. Azure Table Storage 實體

• 正確答案：A. Page Blobs
• 關鍵字識別：「unmanaged data disks (未受管理磁碟)」＋「儲存形式」。
• 核心考點定位：VHD 虛擬硬碟檔在 Azure Blob Storage 中的實體 Blob 類別 (Block / Page / Append)。
• 陷阱識破：一般檔案用 Block Blob，但 VHD 隨機讀寫磁碟映像檔必須使用 Page Blob (頁面 Blob)；未受管理磁碟需自建 Storage Account 存放。
• 逐一排除干擾項：
  • B. Azure Files 的 SMB 共用：SMB 共用主要用於一般檔案共享，非 VHD 未受管磁碟儲存底座 ❌
  • C. Azure Queue Storage 訊息：僅存放文字訊息，與磁碟映像檔無關 ❌
  • D. Azure Table Storage 實體：NoSQL key-value 表格，無法存放二進位磁碟檔 ❌
• 最佳實踐與驗證：現行架構最佳實踐應升級為 Managed Disks（由 Azure 自動託管 Storage Account），避免 Unmanaged Disks 的 Storage Account IOPS 瓶頸；經 Microsoft Learn：Azure Managed Disks 簡介 交叉驗證確認。

📝 情境題 8：全球低延遲的多模型資料庫

Titan 科技的手遊需要在亞洲、歐洲與北美同時提供個位數毫秒的讀取延遲，且資料模型可能隨版本調整（文件型、key-value、圖形）。最適合的資料庫服務是？

• A. Azure SQL Database
• B. Azure Cosmos DB
• C. Azure Table Storage
• D. Azure Synapse Analytics

• 正確答案：B. Azure Cosmos DB
• 關鍵字識別：「全球分散」＋「個位數毫秒延遲」＋「多模型 (Document, Key-Value, Graph)」。
• 核心考點定位：全球分佈式 NoSQL 資料庫選型。
• 陷阱識破：Azure SQL Database 為單一區域為主的關聯式資料庫（主要寫入端在單一區域）；Table Storage 為基礎 key-value，無多模型 API 與毫秒級全球多寫能力。
• 逐一排除干擾項：
  • A. Azure SQL Database：關聯式 OLTP 資料庫，不具備原生多 API 模型與全球多區域即時寫入能力 ❌
  • C. Azure Table Storage：單一 Key-Value 儲存，功能簡陋且無法提供 Cosmos DB 等級的 SLA 保證 ❌
  • D. Azure Synapse Analytics：巨量資料倉儲 (OLAP) 分析引擎，非高併發操作型資料庫 ❌
• 最佳實踐與驗證：高併發、全球化手遊玩家資料庫首選 Cosmos DB，可自選 5 種一致性層級平衡延遲與精確度；經 Microsoft Learn：Azure Cosmos DB 總覽 交叉驗證確認。

📝 情境題 9：大量離線資料遷移

Titan 科技要將地端 80 TB 歷史遊戲錄影遷移至 Azure Blob Storage，網路頻寬有限，線上上傳預估需要數個月。最適合的遷移方式是？

• A. AzCopy CLI
• B. Azure Storage Explorer
• C. Azure Data Box
• D. Azure VPN Gateway

• 正確答案：C. Azure Data Box
• 關鍵字識別：「80 TB 龐大資料」＋「網路頻寬有限」＋「線上耗時數月」。
• 核心考點定位：離線實體裝置搬遷 vs 線上網路搬遷工具。
• 陷阱識破：AzCopy 為極速命令列工具，但受限於實體網路頻寬上限；當資料量高達數十 TB 且網路狹窄時，實體硬體寄送是最快且最省頻寬的方案。
• 逐一排除干擾項：
  • A. AzCopy CLI：線上網路傳輸工具，頻寬不足時無法解決耗時數月的痛點 ❌
  • B. Azure Storage Explorer：GUI 桌面端工具，底層同樣走公用網路，適合小批次手動操作 ❌
  • D. Azure VPN Gateway：建立加密網路通道，仍會吃滿專線與網際網路頻寬 ❌
• 最佳實踐與驗證：80 TB 等級的離線遷移首選 Data Box 實體裝置（提供 80 TB 可用容量與硬體 AES 256 位元加密）；經 Microsoft Learn：Azure Data Box 總覽 交叉驗證確認。

📝 情境題 10：SMB 共用給多台 VM

Titan 科技有五台 Windows VM 需要共用同一組設定檔，使用 SMB 協定掛載為網路磁碟機。最適合的儲存服務是？

• A. Azure Blob Storage
• B. Azure Files
• C. Azure Managed Disks
• D. Azure Queue Storage

• 正確答案：B. Azure Files
• 關鍵字識別：「SMB 協定」＋「多台 VM 共用」＋「網路磁碟機 (Drive Mounting)」。
• 核心考點定位：共享檔案系統服務選型。
• 陷阱識破：Managed Disks 預設是一對一綁定單一 VM；Blob Storage 走 HTTP REST API，無法透過標準 Windows net use 或 SMB 直接掛載為本地磁碟機。
• 逐一排除干擾項：
  • A. Azure Blob Storage：物件儲存，採用 REST API，非原生 SMB/NFS 檔案共用 ❌
  • C. Azure Managed Disks：區塊儲存，為單一 VM 的專屬磁碟 ❌
  • D. Azure Queue Storage：非同步解耦佇列，非檔案系統 ❌
• 最佳實踐與驗證：跨 VM 共享磁碟與傳統地端 NAS 搬遷至雲端首選 Azure Files (SMB/NFS)；經 Microsoft Learn：Azure Files 總覽 交叉驗證確認。

📝 情境題 11：不想管理 OS 的 Web API 部署

Titan 科技的後端團隊要部署自行撰寫的 Node.js Web API，不想管理 VM 的 OS 修補、防毒或執行環境更新。最佳服務是？

• A. Azure Virtual Machines
• B. Azure App Service
• C. Azure Kubernetes Service (AKS)
• D. Azure Data Box

• 正確答案：B. Azure App Service
• 關鍵字識別：「自寫 Node.js Web API」＋「不想管理 OS 修補與維護」。
• 核心考點定位：PaaS 平台即服務 vs IaaS 基礎設施即服務選型。
• 陷阱識破：VM 屬於 IaaS，團隊必須完全負責 OS 層級的安全修補與維護；AKS 雖為容器託管，但仍需維運叢集節點與升級。
• 逐一排除干擾項：
  • A. Azure Virtual Machines：IaaS 服務，需自行負責 OS 安裝、防毒與 Patch 補丁 ❌
  • C. Azure Kubernetes Service (AKS)：微服務容器編排，需管理 Pod、Ingress 與 K8s 升級，營運複雜度高 ❌
  • D. Azure Data Box：實體資料搬遷裝置，非運算部署服務 ❌
• 最佳實踐與驗證：純 Web/API 應用首選 PaaS Azure App Service，享受微軟自動管理的底層 OS 與 Runtime Auto-patching；經 Microsoft Learn：App Service 總覽 交叉驗證確認。

📝 情境題 12：NSG 規則處理順序

Titan 科技的 NSG 有以下兩條入站規則：

• 規則 100：允許來自 10.0.0.0/24 的 TCP 443
• 規則 200：拒絕所有入站流量

來自 10.0.0.5 的 HTTPS 請求會被允許還是拒絕？

• A. 拒絕，因為規則 200 拒絕所有流量
• B. 允許，因為規則 100 的優先序數字較低、先匹配
• C. 取決於 Azure Region 設定
• D. 無法判斷，需要 Azure Advisor 分析

• 正確答案：B. 允許，因為規則 100 優先序較高
• 關鍵字識別：「NSG 規則」＋「優先序數字 100 vs 200」＋「符合條件 10.0.0.5:443」。
• 核心考點定位：Network Security Group (NSG) 的規則優先順序 (Priority) 評估機制。
• 陷阱識破：NSG 規則數字越小，優先權越高（100 優於 200）。當流量匹配到第一個符合條件的規則時，即執行該動作並停止繼續往下匹配。
• 逐一排除干擾項：
  • A. 拒絕：誤以為拒絕規則權限大於允許規則；實際上 NSG 按優先序數字從小到大求值，規則 100 已優先匹配成功 ❌
  • C. 取決於 Region：NSG 求值邏輯全域統一，與 Region 無關 ❌
  • D. 需要 Advisor：Advisor 是優化建議工具，不參與網路封包的實時評估 ❌
• 最佳實踐與驗證：設定 NSG 規則時應留出數字間隔（如 100, 200, 300），以便日後插載新規則；經 Microsoft Learn：NSG 安全規則 交叉驗證確認。

┌─────────────────────────────────────────────────────────────┐
│ Network Security Group (NSG) 規則評估流程 (數字小優先度高)  │
├─────────────────────────────────────────────────────────────┤
│  請求進入 (例如 10.0.0.5:443)                               │
│     │                                                       │
│     v                                                       │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ 規則 100 (優先序數字 100 最先評估)                    │  │
│  │ 條件: 允許來自 10.0.0.0/24 的 TCP 443 流量            │  │
│  └───────────────────────────┬───────────────────────────┘  │
│                              │                              │
│             ┌────────────────┴────────────────┐             │
│        (符合條件)                        (不符合條件)       │
│             │                                 │             │
│             v                                 v             │
│      ✅ 允許通過流量                  ┌─────────────┐       │
│  (匹配成功即停止比對後續)             │ 規則 200... │       │
│                                       └─────────────┘       │
└─────────────────────────────────────────────────────────────┘

📝 情境題 13：ExpressRoute 與 VPN 的選擇

Titan 科技正式營運環境每天要在地端機房與 Azure 之間傳輸大量敏感資料，需要穩定、低延遲且不走公用網際網路的私有連線。應優先選擇？

• A. Azure VPN Gateway (Site-to-Site)
• B. Azure ExpressRoute
• C. Azure CDN
• D. Azure DNS

• 正確答案：B. Azure ExpressRoute
• 關鍵字識別：「不走公用網際網路 (Private Connection)」＋「大量資料」＋「穩定低延遲」。
• 核心考點定位：混合雲專線 ExpressRoute vs 公網加密 VPN Gateway。
• 陷阱識破：Site-to-Site VPN 雖然會在封包進行 IPSec 加密，但傳輸路徑依然經過「公用網際網路 (Public Internet)」，延遲波動大且無法提供實體專線頻寬保證。
• 逐一排除干擾項：
  • A. Azure VPN Gateway：雖然加密但走網際網路公網，不符合「不走公用網際網路」的需求 ❌
  • C. Azure CDN：內容分發網路，用於加速靜態網頁與內容下載，非地端與雲端連線 ❌
  • D. Azure DNS：域名解析服務，不傳輸業務數據 ❌
• 最佳實踐與驗證：企業級高合規、大流量私有專線首選 ExpressRoute，亦可搭配 S2S VPN 作為 ExpressRoute 的備援線路；經 Microsoft Learn：ExpressRoute 總覽 交叉驗證確認。

📝 情境題 14：Synapse 與 Databricks 的選型邊界

Titan 科技的分析師只需要用 SQL 查詢資料湖中已整理的 Parquet 資料來產出 BI 報表。團隊沒有 Spark、Notebook 或機器學習的需求。最精確的判斷是？

• A. 先評估 Synapse SQL；不應只因為是大數據就強制導入 Databricks
• B. 一定要用 Cosmos DB，因為它是所有 Azure 資料服務的共同底座
• C. Databricks 是 Blob 儲存服務，Synapse 是網路服務
• D. 必須把資料搬回 SQL Database 才能使用 SQL

• 正確答案：A. 先評估 Synapse SQL
• 關鍵字識別：「用 SQL 查詢資料湖 Parquet」＋「無 Spark / Notebook / ML 需求」。
• 核心考點定位：Synapse Analytics (SQL 分析引擎) 與 Azure Databricks (Spark 生態) 的選型邊界。
• 陷阱識破：Databricks 以 Apache Spark 為核心，適合複雜的資料工程與機器學習；若僅需對資料湖執行 SQL 查詢與 BI 報表，Synapse Serverless SQL pool 是更簡單、成本更低且無運維負擔的選擇。
• 逐一排除干擾項：
  • B. Cosmos DB：分散式 NoSQL 交易型資料庫，非資料湖大數據 OLAP 分析服務 ❌
  • C. 服務定位錯誤：Databricks 是 Spark 分析平台而非 Blob 儲存，Synapse 是分析引擎而非網路服務 ❌
  • D. 必須搬回 SQL DB：Synapse SQL 能透過 Serverless SQL 直接查詢 Data Lake 上原生 Parquet 檔案，無需預先載入 SQL DB ❌
• 最佳實踐與驗證：遵循「選用最簡單符合需求的工具」原則，純 SQL BI 需求優先選擇 Synapse SQL；經 Microsoft Learn：Synapse SQL 總覽 交叉驗證確認。

📝 情境題 15：儲存帳戶備援與跨區域讀取

Titan 科技的財務資料必須在主要區域故障時仍能立即從次要區域讀取，且在正常狀態下也希望提供次要區域唯讀端點。應選擇哪種備援選項？

• A. LRS（本地備援儲存）
• B. ZRS（區域備援儲存）
• C. GRS（異地備援儲存）
• D. RA-GRS（讀取存取異地備援儲存）

• 正確答案：D. RA-GRS
• 關鍵字識別：「主要區域故障備援」＋「正常狀態下提供次要區域唯讀 (Read-Access)」。
• 核心考點定位：Azure Storage 異地備援模式的存取權限。
• 陷阱識破：GRS 雖然會把資料非同步複製到配對區域，但在主要區域未發起 Failover 之前，次要區域的端點是完全無法進行讀取的；只有啟用 Read-Access 的 RA-GRS / RA-GZRS 才能在平時即開啟次要區域讀取端點。
• 逐一排除干擾項：
  • A. LRS：僅在單一 Data Center 複製三份，無法抵禦整區域故障 ❌
  • B. ZRS：跨同一 Region 的 3 個 AZ 複製，無法抵禦整區域災害 ❌
  • C. GRS：具備跨區域複製，但平時次要端點不可讀，不符「正常狀態下提供次要區域唯讀端點」之需求 ❌
• 最佳實踐與驗證：高可用讀取與跨區災備推薦 RA-GRS / RA-GZRS，應用程式需考慮跨區非同步複寫造成的微小資料延遲；經 Microsoft Learn：Azure 儲存體備援 交叉驗證確認。

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

🚀 今日總結與明日預告

🏆 今日 3 點速記精華

1. 先判斷存取模式，再選儲存服務：非結構化物件選 Blob；SMB/NFS 共用選 Files；VM 專屬磁碟選 Managed Disks；訊息佇列選 Queue。不要讓「Storage」這個共用字根騙你選錯。
2. 先判斷工作負載型態，再選資料服務：雲原生 SQL 選 SQL Database；遷移既有 SQL Server 選 Managed Instance；全球低延遲 NoSQL 選 Cosmos DB；SQL BI 分析選 Synapse；Spark 資料工程選 Databricks。
3. 成本三因素牢記、名稱陷阱警覺：出站資料、服務層級、Azure 區域影響成本；Serverless ≠ 免費、Archive 有取回等待、GRS ≠ 隨時可從次要區域讀取。

🔮 明日預告

Phase 2–3 驗收完成，Titan 科技的運算與資料金庫已就緒！明天 Day 22，我們將進入 Phase 4「資安防禦與財務治理」，深入拆解 Microsoft Entra ID（原 Azure AD）與條件式存取，並對照 AWS IAM，學會在身分驗證、授權與多因素認證之間做出正確架構決策。

(如果你完成 15 題後仍能清楚說出每個選項錯在哪裡，恭喜你已通過 Phase 2–3 驗收！歡迎分享分數與最容易混淆的儲存或資料服務陷阱。)