【Day 6】Azure Advisor & Service Health：系統健康、智慧顧問與跨雲監控 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★☆☆☆
核心考點：Azure Advisor (五大面向支柱：Cost, Security, Reliability, Performance, Operational Excellence), Azure Service Health (三層架構：Azure Status vs Service Health vs Resource Health), 服務健康警報 (Health Alerts), Azure Monitor (Metrics, Logs, Application Insights, Activity Log), Azure Arc (混合雲與多雲治理延伸), AWS Trusted Advisor ↔ Azure Advisor 深度對照, AWS Health Dashboard ↔ Azure Service Health 對照, AWS CloudWatch / CloudTrail ↔ Azure Monitor 對照, AWS SAA-C03 / CLF-C02 考題概念連動

🎯 前言與今日目標

今天在antigravity2.0 裡面，新增了兩個gemini notebook,大部分是 aws saa clf的參考資料。使用3.7 medium整理

在 Day 5 中，我們深入掌握了基礎架構即程式碼 (IaC) 的核心武器——ARM Templates 與 Azure Bicep，建立了標準化、可版控且具備冪等性的自動化發布管線。

然而，當系統成功上線並運行在雲端後，身為首席雲端架構師，你將面臨另一波更嚴峻的維運挑戰：

1. 「微軟底層資料中心發生光纖挖斷或電力故障時，我們能否在客戶客訴前第一時間掌握，而不是像盲人摸象般盲目重啟伺服器？」
2. 「系統上線半年後，內部堆積了大量過度配置 (Over-provisioned) 的閒置虛擬機器與未掛載的受控磁碟，每個月都在燃燒預算，該由誰自動抓出這些浪費？」
3. 「如何確保跨多個雲端環境（Azure、AWS、地端機房）的伺服器，都能遵循統一的安全性原則與合規監控？」

在 AWS 架構體系中，我們倚賴 AWS Trusted Advisor 獲取架構建議，透過 AWS Health Dashboard 追蹤平台與帳戶事故，並使用 Amazon CloudWatch 與 AWS Systems Manager 進行即時監控與跨地端治理。

在 Azure 生態中，微軟設計了兩大原廠核心利器：Azure Advisor（雲端架構顧問） 與 Azure Service Health（服務健康狀態防護網），並搭配 Azure Monitor 與 Azure Arc 構建全方位的雲端守護體系。

今天 Day 6，我們將帶你徹底拆解 Azure 系統健康監控與架構優化的核心機制，搞懂考試必考的「Advisor 五大支柱」與「Service Health 三層邊界」，並適時引入 AWS SAA-C03 / CLF-C02 的經典架構考題，讓你一次打通雙雲架構師的維運心法！

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

🔄 1. 雲端維運痛點與兩大核心守護神：為什麼需要「主動健康」與「架構顧問」？

在傳統地端機房維運中，伺服器故障通常伴隨著機房警報器聲響；但在公有雲環境中，底層硬體被完全抽象化。當應用程式回應變慢或中斷時，問題可能來自兩個完全不同的維度：

• 平台端問題（Microsoft 的責任）：Azure 特定區域的儲存叢集降級、硬體叢集進行韌體更新、底層網路骨幹中斷。
• 租戶端問題（客戶自己的責任）：架構設計未採用多可用區 (AZ)、虛擬機器 CPU 滿載、未設定備份原則、防火牆規則誤擋。

如果維運團隊無法快速釐清是「微軟出事」還是「自己設定錯誤」，往往會白白浪費數小時排查甚至造成更大的爆炸半徑 (Blast Radius)。

為此，Azure 將主動維護與架構洞察劃分為兩大核心服務：

• Azure Service Health：專注於**「雲端平台基礎設施的即時狀態」**（回答：Azure 今天健康嗎？我的訂用帳戶有沒有被微軟故障波及？）。
• Azure Advisor：專注於**「客戶資源的架構最佳實踐」**（回答：我的架構設計合不合規？有沒有多花冤枉錢？）。

🛡️ 2. Azure Advisor (Azure 顧問)：五大支柱與智慧優化引擎

Azure Advisor 是一項完全免費的內建個人化雲端顧問服務。它會持續在背景分析你在 Azure 上部署的所有資源組態與使用量遙測資料，並依據 Microsoft Azure Well-Architected Framework（架構完善框架） 提供具體、可立即執行的最佳化建議。

┌─────────────────────────────────────────────────────────────────────────┐
│                     💡 Azure Advisor 五大面向支柱                       │
├──────────────┬──────────────┬──────────────┬──────────────┬─────────────┤
│ 💰 成本優化  │ 🔒 安全防護  │ 🛡️ 可靠性/HA │ ⚡ 效能表現  │ 🎯 卓越營運 │
│   (Cost)     │  (Security)  │(Reliability) │(Performance) │(Operational)│
├──────────────┼──────────────┼──────────────┼──────────────┼─────────────┤
│• 抓出閒置 VM │• 整合 Defender│• 啟用備份機制│• 升級受控磁碟│• 服務配額限制│
│• 降規節省費用│• 補齊安全漏洞│• 跨 AZ 高可用│• 修復 DB 索引│• 訂用帳戶治理│
│• 保留執行個體│• 限制開放 Port│• 啟用容錯移轉│• 消除網路延遲│• 範本語法驗證│
└──────────────┴──────────────┴──────────────┴──────────────┴─────────────┘

💡 五大支柱詳細解析與考點對齊：

1. 成本 (Cost)：
   • 核心功能：主動偵測 CPU/記憶體長期低於 5% 的閒置或低使用率虛擬機器 (VMs)，建議降規 (Right-sizing) 或關閉；找出未掛載的孤兒磁碟 (Unattached Disks)；推薦購買 Azure Reserved VM Instances (RI，保留執行個體) 或 Savings Plans 以獲取最高 72% 的折扣。
   • AZ-900 必考關鍵字：“Reduce costs”, “Find underutilized resources”, “Cost recommendations”。
2. 安全性 (Security)：
   • 核心功能：深度整合 Microsoft Defender for Cloud，列出未加密的資料庫、開放外網 SSH (Port 22) / RDP (Port 3389) 的虛擬機器、未啟用 MFA 的特權帳號等資安風險。
3. 可靠性 / 高可用性 (Reliability / High Availability)：
   • 核心功能：檢查生產環境虛擬機器是否未配置 Availability Zones (AZ)；檢查 Azure SQL Database 是否未啟用異地備份 (Geo-redundant Backup)；提醒關鍵工作負載啟用 Azure Backup。
4. 效能 (Performance)：
   • 核心功能：分析儲存體讀寫瓶頸，建議將 Standard HDD 升級為 Premium SSD；偵測資料庫缺乏索引的慢查詢；最佳化 Traffic Manager 與 CDN 快取路由。
5. 卓越營運 (Operational Excellence)：
   • 核心功能：追蹤訂用帳戶即將達到服務配額限制 (Service Limits / Quotas)；驗證 ARM 範本部署完整性；提供 Azure Policy 標籤與資源治理建議。

⚠️ 架構師必備觀念（雙雲框架差異 ＆ 考試陷阱）：

• 🌐 AWS 六大支柱 vs Azure 五大支柱：
  • AWS Well-Architected Framework (WAF) 原先為五大支柱，在 2021 年底 (re:Invent 2021) 正式加入了第 6 根支柱——【Sustainability 永續性 / 永續發展】（專注於減少雲端工作負載的能源消耗與碳足跡）。
  • Azure Well-Architected Framework 與 Azure Advisor 目前官方考綱定義仍維持為**【五大支柱】**（Cost, Security, Reliability, Performance, Operational Excellence）。微軟在永續層面主要透過獨立的 Microsoft Cloud for Sustainability 與 Emissions Impact Dashboard 提供碳排放分析，並未列為 Advisor 的獨立主分類。
• 🚫 建議 vs 強制：Azure Advisor 只提供「建議 (Recommendations)」，不會「強制阻擋」或「未經授權自動刪除資源」！ 如果你需要強制限制只能在特定區域建立資源、或強制所有資源必須掛 Tag，必須使用 Azure Policy（Day 26 詳解），千萬不要選 Advisor！

🔍 雙雲 Well-Architected Framework（架構完善框架）支柱對比

🏥 3. Azure Service Health：三層健康狀態防護網

在 Azure 中，「健康狀態」並非只有單一儀表板，而是精確劃分為由廣至窄的三個層級 (Three Layers of Scope)。這是 AZ-900 與進階認證中最常出現的精細觀念題！

┌─────────────────────────────────────────────────────────────────────────┐
│                      🌐 Azure Status (全域公用狀態)                     │
│    • 公開網頁 (status.azure.com)，全球所有人皆可見                      │
│    • 顯示全球所有 Azure 區域與主要服務的大規模中斷 (Major Outages)      │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 篩選出「我有使用的服務與區域」
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                   🏥 Azure Service Health (訂用帳戶專屬)                │
│    • 需要登入 Azure Portal，完全個人化 (Personalized View)              │
│    • 包含四大板塊：Service issues (突發事故)、Planned maintenance       │
│      (計畫性維護)、Health advisories (功能淘汰/配額)、Security advisories │
│    • 支援主動設定 Health Alerts (Webhook/Email/SMS/PagerDuty/Teams)    │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ 下鑽至「特定單一資源」
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                    🩺 Azure Resource Health (個別資源診斷)              │
│    • 查看「特定某一特定虛擬機器 / SQL 資料庫 / App Service」的健康狀況  │
│    • 狀態燈號：Available (可用)、Degraded (降級)、Unavailable (無法使用)│
│    • 能區分是「平台底層事件 (Platform Event)」還是「使用者自己操作」    │
└─────────────────────────────────────────────────────────────────────────┘

🔍 三層架構精準對照：

📊 4. 延伸進階架構：Azure Monitor 遙測全景與 Azure Arc 跨雲治理

為了讓架構師對雲端監控有全貌視角，AZ-900 考綱與官方培訓課程亦涵蓋了監控資料收集引擎 Azure Monitor 與混合雲治理骨幹 Azure Arc：

1. Azure Monitor（全方位監控與日誌平台）

• 核心定位：收集、分析並回應來自雲端與內部部署環境的遙測資料（Telemetry）。
• 兩大數據基石 (Data Stores)：
  1. 計量 (Metrics)：輕量、數值型即時時間序列資料（如 VM CPU 使用率 85%、記憶體剩餘 10%），支援近即時觸發 Autoscale (自動縮放) 與警報。
  2. 記錄 (Logs)：高度結構化與半結構化文字日誌，存放在 Log Analytics Workspace 中，使用強大的 KQL (Kusto Query Language) 進行複雜查詢與鑑識。
• 關鍵元件：
  • Application Insights：專門針對 AP 應用程式層級的效能監控 (APM)，追蹤 HTTP 請求延遲、例外崩潰堆疊、分散式追蹤 (Distributed Tracing)。
  • Activity Log（活動記錄）：訂用帳戶層級的控制平面稽核日誌，記錄**「誰在什麼時候建立、修改或刪除了哪項 Azure 資源」**（對照 AWS CloudTrail）。

2. Azure Arc（跨越邊界的混合雲與多雲控制平面）

• 核心定位：將 Azure Resource Manager (ARM) 控制平面的管理能力，延伸至外部環境。
• 管理範疇：
  • 運行在地端機房 (On-Premises)、AWS (如 EC2)、Google Cloud (GCP) 上的 Windows/Linux 實體機與虛擬機器。
  • 外部 Kubernetes 叢集 (EKS, GKE, 地端 k8s)。
  • 在任何基礎架構上運行 Azure 數據服務（如 Azure Arc-enabled SQL Managed Instance）。
• 價值：跨多雲統一使用 Azure Portal、Azure Policy、Defender for Cloud 進行集中合規與資安盤點！

📐 雙雲監控與架構優化架構對比圖

┌───────────────────────────────────┬───────────────────────────────────┐
│        🟠 AWS 監控與健康生態系    │       🔵 Azure 監控與健康生態系   │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【架構與最佳實踐顧問】            │ 【架構與最佳實踐顧問】            │
│  AWS Trusted Advisor              │  Azure Advisor (五大支柱)         │
│  • 成本、安全、容錯、效能、配額   │  • Cost, Security, Reliability,   │
│  • AWS Compute Optimizer (規格)   │    Performance, Operational Ex.   │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【雲端平台與資源健康狀態】        │ 【雲端平台與資源健康狀態】        │
│  AWS Health Dashboard             │  Azure Service Health             │
│  • Service Health (全域公用狀態)  │  • Azure Status (全域公用狀態網)  │
│  • Your Account Health (個人化)   │  • Service Health (訂用帳戶專屬)  │
│                                   │  • Resource Health (單一資源診斷) │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【指標、日誌與維運遙測】          │ 【指標、日誌與維運遙測】          │
│  Amazon CloudWatch (Metrics/Logs) │  Azure Monitor                    │
│  AWS CloudTrail (API 稽核軌跡)    │  • Metrics, Log Analytics         │
│                                   │  • Activity Log (訂用帳戶操作)    │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【跨雲與混合地端治理延伸】        │ 【跨雲與混合地端治理延伸】        │
│  AWS Systems Manager              │  Azure Arc                        │
│  • 管理地端伺服器與混合雲資源     │  • 將 ARM 控制平面延伸至地端/AWS  │
└───────────────────────────────────┴───────────────────────────────────┘

💡 架構師重點筆記：
雙雲在監控哲學上的核心差異在於：AWS 的 Trusted Advisor 依據商業支援等級（Basic/Developer vs Business/Enterprise）嚴格限制檢查項目數量（免費版僅有少數檢查）；而 Azure Advisor 則是全功能完全免費向所有訂用帳戶開放，是微軟推動架構完善度的主力推手！

📊 雙雲健康、監控與架構優化全維度對照表

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

1. Azure Advisor (Azure 顧問)
   • 定義：一項免費且個人化的雲端架構顧問服務，依據 Well-Architected 框架，在成本 (Cost)、安全性 (Security)、可靠性 (Reliability)、效能 (Performance) 與卓越營運 (Operational Excellence) 五大面向提供主動優化建議。
   • AWS 對照：AWS Trusted Advisor ＋ AWS Compute Optimizer。
   • 考點：尋找「如何找出低使用率資源以降低 Azure 成本」的解答永遠是 Azure Advisor。
2. Azure Service Health (服務健康狀態)
   • 定義：提供與使用者特定訂用帳戶與資源相關的個人化健康儀表板，涵蓋突發事故 (Service Issues)、計畫性維護 (Planned Maintenance) 與健康公告 (Health Advisories)。
   • AWS 對照：AWS Health Dashboard (Personal Health Dashboard)。
   • 考點：當需要「在官方進行基礎設施計畫性維護前收到通知」時，使用 Service Health Alerts。
3. Azure Resource Health (資源健康狀態)
   • 定義：下鑽至單一 Azure 實體資源（如個別 VM）的健康診斷視窗，提供即時可用性狀態與過去中斷的根本原因診斷。
   • AWS 對照：EC2 Status Checks / CloudWatch Resource Health。
4. Azure Monitor (Azure 監視器)
   • 定義：Azure 原生的全方位遙測數據收集與分析平台，以 Metrics（計量）與 Logs（記錄，Log Analytics）為核心基石。
   • AWS 對照：Amazon CloudWatch。
5. Azure Arc
   • 定義：將 Azure Resource Manager 的管理功能、治理原則與安全防護，延伸至內部部署資料中心、邊緣裝置以及 AWS / GCP 等其他公有雲環境的橋樑。
   • AWS 對照：AWS Systems Manager ＋ AWS Outposts / ECS Anywhere。

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

🏛️ 情境背景：Titan 科技黑色星期五促銷前的「零停機」大考驗

Titan 科技即將迎來一年一度的黑色星期五全球購物節，預估線上流量將比平日暴增 10 倍。

作為首席雲端架構師，你在大促銷前兩週被 CTO 召進作戰會議室：

CTO：「架構師，去年黑五我們在另一個雲端平台因為沒收到主機硬體維護通知，導致促銷前夕核心結帳伺服器突然重啟中斷！另外，財務長今早對我咆哮，說上個月的雲端帳單超標了 30%，裡面堆滿了測試時期留下來的高規格 VM。

在這次 Azure 的部署中，我需要你立刻執行三項任務：

1. 主動成本瘦身：在不影響核心架構的前提下，找出所有閒置、過度配置的資源並提出降規方案。
2. 建立中斷預警：只要微軟對我們使用的 East US 與 East Asia 區域發布任何基礎設施事件或排程維護，維運團隊必須在 1 分鐘內透過 Webhook / PagerDuty 收到即時告警。
3. 跨雲混合稽核：我們在本地機房還有 50 台舊款資料庫伺服器，必須與 Azure 上的主機套用一模一樣的合規標準。

請問你的架構決策是什麼？」

                             【Titan 科技雲端作戰室】
                                        │
             ┌──────────────────────────┼──────────────────────────┐
             ▼                          ▼                          ▼
   【任務 1：成本健檢】       【任務 2：中斷與維護預警】     【任務 3：跨雲地端治理】
  尋找低使用率閒置資源         訂閱區域計畫性維護告警       將地端主機納入統一合規
             │                          │                          │
      [選型決策考驗]             [選型決策考驗]             [選型決策考驗]

🧩 決策任務

針對上述 Titan 科技的維運與成本挑戰，以下四個架構實施方案中，哪一個是最符合 Azure 原生架構最佳實踐且最具成本效益的組合？

• 方案 A：
  • 使用 Azure Pricing Calculator 進行資源盤點與降規建議。
  • 透過瀏覽公開的 Azure Status 網頁手動更新維護行事曆。
  • 在地端伺服器上安裝自建的開源 Prometheus 與 Grafana 進行獨立監控。
• 方案 B：
  • 使用 Azure Advisor 讀取 Cost 面向建議，識別低使用率 VM 與保留執行個體採購清單。
  • 在 Azure Service Health 中建立針對特定 Subscriptions 與 Regions 的 Health Alerts，自動串接 Webhook 與 PagerDuty。
  • 部署 Azure Arc 連線代理程式至地端伺服器，將地端主機註冊至 Azure 控制平面並統一套用 Azure Policy。
• 方案 C：
  • 使用 Azure Cost Management 設定每日自動刪除低於 10% CPU 使用率的虛擬機器。
  • 在個別 VM 的 Azure Resource Health 頁面逐一手動設定每台機器的維護通知。
  • 要求地端機房工程師每週手動匯出伺服器清單與 Azure 進行 Excel 比對。
• 方案 D：
  • 撰寫 PowerShell 腳本每天定時呼叫 ARM API 檢查每台機器的 CPU 歷史圖表。
  • 使用 Azure Monitor Activity Log 查詢微軟底層資料中心未來的硬體維護排程。
  • 購買昂貴的專用硬體 Azure Stack Hub 替換地端所有伺服器。

🎯 解題拆解與解析

✅ 正確解答：方案 B

🏆 架構師深度剖析：

1. 任務 1（成本瘦身）：
   • Azure Advisor 的「Cost」面盤會自動分析過去 7 天的 CPU、記憶體與網路使用率，直接產出精確的降規建議（如：將 Standard_D8s_v5 降為 Standard_D2s_v5）並預估每月可節省的金額。完全符合自動化、免開發、高精準度的架構要求。
2. 任務 2（中斷與維護預警）：
   • Azure Service Health 是唯一具備「個人化訂用帳戶感知」與「計畫性維護排程」的服務。透過設定 Service Health Alerts，可以在微軟排定主機更新或發生區域中斷時，即刻觸發 Action Group 發送 Webhook 訊息至 PagerDuty 或維運 Teams 頻道。
3. 任務 3（跨雲混合稽核）：
   • Azure Arc 專門為混合雲設計，只需在外部伺服器安裝 Connected Machine Agent，即可將該機器視為 Azure 資源（Microsoft.HybridCompute/machines），直接套用 Azure Policy 與 Defender 安全基準，達成單一窗格治理。

❌ 陷阱選項深度覆盤：

• 方案 A 陷阱：
  • Azure Pricing Calculator 是事前評估新架構費用的線上試算工具，它根本無法連線到你現有的 Azure 訂用帳戶，更不可能產出降規建議！
  • Azure Status 是全域公開網站，只顯示全球大規模災難，不會顯示你的訂用帳戶何時會被安排計畫性維護，靠人工看網頁無法達成自動化告警。
• 方案 C 陷阱：
  • Azure Cost Management 具備預算警示 (Budgets) 與費用分析，但絕對沒有自動刪除低使用率 VM 的功能。
  • Azure Resource Health 是針對單一特定資源的即時診斷，維護告警應在 Service Health 層級全域設定，而非逐台機器手動配置。
• 方案 D 陷阱：
  • 耗費工程人力重造輪子寫腳本排查 CPU 是低效益的做法（Advisor 已經內建免費提供）。
  • Activity Log 記錄的是**「過去已經發生的管理操作」**，根本無法預測微軟底層硬體「未來的計畫性維護排程」。
  • 僅為了合規而直接採購 Azure Stack Hub 硬體替換地端機房，成本極其高昂且違反最小可行性原則（Azure Arc 軟體代理即可解決）。

🎯 Part 3：AZ-900 精選高頻真題解析 ＋ AWS SAA / CLF 雙雲概念連動

📝 AZ-900 高頻真題 1：成本優化工具選型（ExamTopics Q474 改編）

題目情境：

Titan 科技的財務團隊希望獲得一份分析報告，指出目前 Azure 環境中哪些執行中的資源存在過度配置 (Over-provisioned) 或閒置狀況，並提供具體可降低每月費用的調整建議。請問架構師應推薦使用哪一項服務？

• A. Azure Cost Management + Billing 的 Invoices 頁面
• B. Azure Advisor
• C. Azure Service Health
• D. Azure Pricing Calculator

考點拆解與解析：

• 正確答案：B. Azure Advisor
• 深度解析：
  • Azure Advisor (B) 的 Cost 標籤頁專門提供主動式的成本優化建議，包含找出閒置虛擬機器、未掛載磁碟以及購買 Reserved Instances 的節省估算。
  • 選項 A 錯誤：Invoices（發票）僅顯示過去週期的實際帳單金額，不提供架構調整與優化建議。
  • 選項 C 錯誤：Azure Service Health 專注於雲端基礎設施健康與維護事件，與成本無關。
  • 選項 D 錯誤：Azure Pricing Calculator 是用來「預估未來新架構支出」的試算表工具，無法分析現有資源的使用率。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題 Q474 社群票數 Azure Advisor 26 票、無其他有效票，最高讚同留言明確指向 Advisor）；並經 Microsoft Learn：Advisor 成本建議 交叉驗證確認。

📝 AZ-900 高頻真題 2：雲端基礎設施中斷與計畫性維護警報（ExamTopics Q123 改編）

題目情境：

Titan 科技的維運團隊需要建立一套自動化通知機制：當微軟預計在 Titan 資源所在的 Azure 區域進行「底層硬體計畫性維護 (Planned Maintenance)」時，團隊必須在維護發生前收到 Email 與簡訊通知，以便提前進行流量切換。請問應使用下列哪一項功能？

• A. 在 Azure Status 網頁訂閱全域 RSS Feed
• B. 在 Azure Service Health 建立 Health Alert
• C. 在 Azure Monitor Metrics 設定 CPU 使用率警報
• D. 在 Azure Advisor 啟用 Security 警報

考點拆解與解析：

• 正確答案：B. 在 Azure Service Health 建立 Health Alert
• 深度解析：
  • Azure Service Health (B) 提供「計畫性維護 (Planned Maintenance)」的專屬視圖，並允許管理員設定 Health Alerts，當微軟針對你的訂用帳戶所屬區域排定硬體更新或停機維護時，自動發送 Email、SMS 或觸發 Webhook。
  • 選項 A 錯誤：Azure Status 僅提供全域重大事件，不包含特定租戶的計畫性維護排程細節。
  • 選項 C 錯誤：Azure Monitor Metrics 監控的是 VM 資源本身的運行效能數值，無法預知底層硬體未來的維護計畫。
  • 選項 D 錯誤：Azure Advisor Security 針對的是資安弱點配置，與硬體維護排程無關。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題社群票數 Service Health 壓倒性領先，最高讚同留言 43 票明確指向 Azure Service Health）；並經 Microsoft Learn：Service Health 計畫性維護總覽 交叉驗證確認為現行正解。

📝 AZ-900 高頻真題 3：多雲與內部部署基礎架構統一監控（ExamTopics Q435/Q436 改編，Azure Arc 核心考點）

題目情境：

Titan 科技正在推行混合雲架構，目前有數百台 Linux 虛擬機器分散在本地 VMware 機房以及 AWS EC2 上。公司希望將 Azure 原生的安全評估、合規原則 (Azure Policy) 與集中監控能力延伸到這些非 Azure 伺服器上，且不需將工作負載遷移至 Azure。請問應採用哪項解決方案？

• A. Azure Arc
• B. Azure ExpressRoute
• C. Azure Migrate
• D. Azure Resource Mover

考點拆解與解析：

• 正確答案：A. Azure Arc
• 深度解析：
  • Azure Arc (A) 專為延伸 Azure 控制平面而設計，能夠將地端實體機/VM、AWS EC2、GCP 執行個體註冊為 Azure 管理資源，進而套用 Azure Policy、Microsoft Defender for Cloud 與 Azure Monitor。
  • 選項 B 錯誤：ExpressRoute 是專屬私有網路連線通道（專線），只負責網路連線，不提供伺服器管理與合規功能。
  • 選項 C 錯誤：Azure Migrate 是用於將地端機器「搬遷遷移 (Lift-and-Shift)」至 Azure 的遷移評估與搬遷工具，題幹明確要求「不遷移工作負載」。
  • 選項 D 錯誤：Azure Resource Mover 用於在「不同的 Azure 區域之間」移動現有的 Azure 資源。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題為 HOTSPOT 圖片作答型，社群最高讚同留言一致指向 Azure Arc 管理 Azure 外的實體機、VM、Kubernetes 與資料庫）；並經 Microsoft Learn：Azure Arc 總覽 交叉驗證確認。

📝 AZ-900 真題 4：成本告警工具的經典陷阱（2020 題庫 Q109 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q109），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，考點至今仍然有效。

題目情境：

Titan 科技的財務長要求：當某個訂用帳戶「當期實際花費」超過預先設定的金額門檻時，系統要主動寄出 Email 告警。有工程師主張「用 Azure Advisor 的建議來設定這個費用門檻告警」。請問這個說法是否正確？若不正確，正確的機制應該是什麼？

• A. 正確，Azure Advisor 建議即可設定費用門檻告警
• B. Azure Cost Management 的預算告警 (Budget Alerts)
• C. Access control (IAM)
• D. Azure Policy 合規性 (Compliance)

考點拆解與解析：

• 正確答案：B. 預算告警 (Budget Alerts)
• 深度解析：
  • 陷阱核心：這題專門測驗考生是否混淆 Azure Advisor 與 Azure Cost Management。Advisor 只會**「建議」你關閉閒置資源以省錢，它不會**依「花費金額門檻」觸發告警。
  • 選項 B 正解：依花費或用量達到／超過門檻時主動通知，是 Cost Management 的 Budget Alerts 職責（Day 27 詳解）。
  • 選項 A 錯誤：Advisor 提供的是最佳化建議，沒有「當花費超過 X 元就寄信」這種預算門檻告警功能。
  • 選項 C / D 錯誤：IAM 管的是存取權限、Policy 管的是資源合規規則，兩者都與費用門檻告警無關。
• 架構師記憶點：Advisor = 給省錢建議；Budget Alerts = 花費超標時報警。 考題只要出現「金額門檻 / 超過預算 / 寄送費用告警」，答案永遠是 Cost Management 的預算告警，不是 Advisor。
• 來源與驗證：經 Microsoft Learn：以預算監控使用量與花費 交叉驗證確認為現行正解。

📝 AZ-900 真題 5：稽核「誰關掉了 VM」用哪個服務（2020 題庫 Q80 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q80），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，考點至今仍然有效。

題目情境：

Titan 科技資安團隊要調查一起事故：「過去 14 天內，是哪一位使用者把某台生產環境虛擬機器關機的？」有人主張直接打開 Azure Monitor 就能查到操作者。請問這個說法是否正確？若不正確，正確的來源應該是什麼？

• A. 正確，直接用 Azure Monitor 即可查到是誰關機
• B. Azure Event Hubs
• C. Azure Activity Log（活動記錄）
• D. Azure Service Health

考點拆解與解析：

• 正確答案：C. Azure Activity Log（活動記錄）
• 深度解析：
  • 陷阱核心：Azure Monitor 是總平台（涵蓋 Metrics、Logs、Application Insights 等），但要查「誰在何時對某資源做了建立／修改／刪除／關機」這種控制平面操作紀錄，精確的答案是其中的 Activity Log。
  • 選項 C 正解：Activity Log 是訂用帳戶層級的控制平面稽核日誌，保留 90 天，可篩選出特定 VM 在過去 14 天的關機 (deallocate) 操作與操作者身分（對照 AWS CloudTrail）。
  • 選項 A 錯誤：直接說「Azure Monitor」太籠統；考題要的是精確到 Activity Log 這個元件。
  • 選項 B 錯誤：Event Hubs 是大規模事件串流擷取服務，不是稽核操作紀錄的查詢介面。
  • 選項 D 錯誤：Service Health 報的是「Azure 平台端」的事故與維護，不記錄「租戶內使用者的操作行為」。
• 架構師記憶點：「誰、在何時、對哪個資源做了什麼管理操作」→ Activity Log；資源效能數值 → Metrics；平台故障 → Service Health。
• 來源與驗證：經 Microsoft Learn：Azure Monitor 活動記錄 交叉驗證確認為現行正解。

🏆 核心加碼：Azure Advisor「五大支柱」1 對 1 經典考題全解析

在 AZ-900 / AZ-104 與架構師考試中，考官非常喜歡給定具體的架構維運痛點，要求考生判斷屬於 Azure Advisor 的哪一根支柱 (Category / Pillar)。以下為五大支柱的一對一高頻考題矩陣：

💰 支柱 1：成本 (Cost Optimization)

考題情境：
Titan 科技發現過去三個月的雲端帳單持續上升。維運主管希望自動找出哪些虛擬機器 (VM) 的 CPU 使用率連續 14 天低於 5%，以及哪些受控磁碟 (Managed Disks) 處於未連結 (Unattached) 狀態。在 Azure Advisor 中，主管應該查看哪一個面向的儀表板？
A. Performance
B. Operational Excellence
C. Cost
D. Reliability

• 正確答案：C. Cost
• 考點解析：Cost 支柱專注於消除浪費，包含：閒置/低使用率 VM 降規 (Right-sizing)、關閉孤兒磁碟 (Unattached Disks)、購買 Reserved Instances (RI) 或 Savings Plans。

🔒 支柱 2：安全性 (Security)

考題情境：
資安稽核團隊要求檢查所有 Azure 資源是否符合最低安全基準。系統管理員登入 Azure Advisor 後，在某個分頁中看到了「建議啟用儲存體帳戶傳輸中加密」、「建議關閉直接暴露於 Internet 的 RDP 3389 連接埠」等改善措施。請問這些建議是由哪個支柱整合提供的？
A. Security（整合 Microsoft Defender for Cloud）
B. Reliability
C. Operational Excellence
D. Cost

• 正確答案：A. Security
• 考點解析：Security 支柱深度整合 Microsoft Defender for Cloud 的安全評估引擎，主動提示身分驗證弱點 (如未啟用 MFA)、網路邊界風險 (開放 Management Ports) 與資料未加密風險。

🛡️ 支柱 3：可靠性 / 高可用性 (Reliability / High Availability)

考題情境：
Titan 科技在單一 Azure Region 部署了核心 ERP 系統的虛擬機器，但未設定可用性區域 (Availability Zones)，且後端的 Azure SQL Database 尚未配置異地容錯移轉群組 (Failover Groups)。Azure Advisor 會在哪個分頁發出警示，提醒若發生機房級故障將導致服務中斷？
A. Performance
B. Reliability
C. Security
D. Operational Excellence

• 正確答案：B. Reliability
• 考點解析：Reliability 支柱（在舊版或部分考卷中亦稱 High Availability）專門檢查架構單點故障 (SPOF)，例如：未加入可用性區域 (AZ)、未設定 Azure Backup 備份原則、未配置跨區域異地備援。

⚡ 支柱 4：效能 (Performance)

考題情境：
某電商查詢 API 在促銷期間回應時間急遽變慢。架構師檢視 Azure Advisor 時，系統建議將虛擬機器掛載的 Standard HDD 升級為 Premium SSD，並提示資料庫快取 (Azure Cache for Redis) 命中率過低。這些提升系統吞吐量與降低延遲的建議屬於哪一面向？
A. Cost
B. Operational Excellence
C. Reliability
D. Performance

• 正確答案：D. Performance
• 考點解析：Performance 支柱專注於消除資源瓶頸，包含：儲存體 IOPS/吞吐量升級、資料庫索引與查詢最佳化、網路路由與 Traffic Manager / CDN 加速配置。

🎯 支柱 5：卓越營運 (Operational Excellence)

考題情境：
開發團隊即將在一週內於單一訂用帳戶中大規模建立 200 台 GPU 運算執行個體。Azure Advisor 主動跳出警告，指出目前訂用帳戶的「虛擬機器 vCPU 核心配額限制 (Service Quotas / Limits)」即將用盡，可能導致後續範本部署失敗。請問此項配額預警屬於哪一面向？
A. Performance
B. Operational Excellence
C. Cost
D. Security

• 正確答案：B. Operational Excellence
• 考點解析：Operational Excellence 支柱專注於提升流程與部署效率，包含：服務配額與限制 (Service Limits / Quotas) 監控、ARM / Bicep 範本最佳實踐驗證、Azure Resource Manager 標籤與治理規範。

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

為了幫助具備 AWS 背景的架構師建立雙向知識遷移，我們精選 2 題在 AWS Solutions Architect Associate (SAA-C03) 與 Cloud Practitioner (CLF-C02) 中的高頻經典題，對比雙雲在設計哲學上的異同：

📌 【AWS 經典考題 1】AWS Trusted Advisor vs AWS Health Dashboard（CLF/SAA 高頻題）

AWS 考題情境：
一家企業想要自動檢查其 AWS 帳戶中是否有「未受保護且開放 0.0.0.0/0 的 Security Group 連接埠」，以及是否有「使用率過低的 Amazon EC2 執行個體」以節省成本。企業應使用哪項 AWS 服務？
A. AWS Health Dashboard
B. AWS Trusted Advisor
C. Amazon CloudWatch Logs
D. AWS Budgets

• AWS 解題思維：正確答案為 B (AWS Trusted Advisor)。AWS Well-Architected Framework 包含「六大支柱」（含 Sustainability 永續性），而 Trusted Advisor 的檢查領域（Cost Optimization, Security, Fault Tolerance, Performance, Service Quotas）則涵蓋了開放連接埠檢查與低使用率 EC2 檢查。
• 🔄 Azure 知識映射：這在 Azure 中 100% 精準對應到 Azure Advisor！Advisor 同樣在 Security 面向整合 Defender 提示開放 Port，並在 Cost 面向提示閒置 VM。

📌 【AWS 經典考題 2】AWS Personal Health Dashboard 告警整合（SAA-C03 經典架構題）

AWS 考題情境：
解決方案架構師需要確保：當 AWS 底層基礎設施發生影響該公司 EC2 執行個體的事件時，維運團隊能夠自動透過 Amazon SNS 收到即時電子郵件通知。架構師應該如何設計？
A. 建立 Amazon EventBridge 規則，擷取 AWS Health 事件並目標導向 Amazon SNS
B. 在 Amazon CloudWatch 設定 EC2 CPUUtilization 警報並觸發 SNS
C. 每天定時執行 AWS CLI aws ec2 describe-instance-status 腳本
D. 訂閱 AWS Service Health Dashboard 公開 RSS Feed

• AWS 解題思維：正確答案為 A。AWS Health（舊稱 Personal Health Dashboard）專門發布影響特定帳戶的基礎設施事件，透過 EventBridge 串接 SNS 是標準架構。
• 🔄 Azure 知識映射：在 Azure 中，這等同於在 Azure Service Health 中建立 Service Health Alert，並將 Action Group 綁定至 Email、SMS 或 Azure Function/Webhook！

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

🚀 今日總結與明日預告

🎓 今日核心收穫速記：

1. Azure Advisor 是架構優化金牌顧問：涵蓋 Cost、Security、Reliability、Performance、Operational Excellence 五大支柱。它只給建議、不強制執行，是找出低使用率資源與節省雲端預算的第一選擇（完全免費）。
2. Service Health 掌握平台三層健康脈動：
   • Azure Status：全域公開網頁，看全球大中斷。
   • Azure Service Health：個人化訂用帳戶，看所屬區域事故與計畫性硬體維護排程。
   • Azure Resource Health：個別資源診斷，看單一 VM/DB 當前健康與歷史根因。
3. Azure Arc 延伸控制平面邊界：免搬遷、免改寫，直接將地端機房、AWS EC2 等跨雲機器納入 ARM 統一管理、監控與 Azure Policy 合規盤點。

🔮 明日預告：Phase 1 終局總複習！

恭喜你！在過去 6 天中，我們已經完整打通了 Azure 的核心管理層級、全球基礎設施、主權雲、管理工具鏈、IaC 範本引擎，以及今天的系統健康與智慧顧問。

明天 【Day 7】，我們將迎來 Phase 1 的期末大考驗——【Phase 1 階段總複習 ✕ 核心架構 15 題情境刷題大作戰】！
我們將一口氣串聯雲端三大服務型態 (IaaS/PaaS/SaaS)、共同責任模型 (Shared Responsibility Model)、雲端部署模型，並以 15 道精選高頻情境題進行全方位地基驗收，為即將到來的 Phase 2 運算與網路攻防戰做好萬全準備！我們明天見！