【Day 7】Phase 1 階段總複習：核心架構 15 題情境刷題大作戰 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★☆☆
核心考點：IaaS / PaaS / SaaS、Shared Responsibility Model、Public / Private / Hybrid Cloud、Management Groups、Subscriptions、Resource Groups、Regions、Availability Zones、Sovereign Clouds、Azure 管理工具、ARM / Bicep、Azure Advisor、Service Health

🎯 前言與今日目標

本文多參照了gemini 3.6 flash 對AZ-900做的deepresearch，更新使用microsoft learn 去validate，恭喜你抵達 Phase 1 的最終城門！前 6 天，我們從 Azure 的資源階層一路打到全球基礎設施、主權雲、管理工具、IaC 與維運健康監控，已經蒐集完建立雲端帝國所需的核心裝備。

但真正的 AZ-900 不會只問「這個服務叫什麼」，而是把多個概念塞進同一個情境：哪一層是計費邊界？資料中心故障該用 AZ 還是跨區域設計？團隊不想維護 OS 時該選 IaaS 還是 PaaS？微軟平台維護通知又該去哪裡看？

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

1. 補齊官方考綱占比 25–30% 的雲端概念：IaaS / PaaS / SaaS、共同責任模型、公有雲 / 私有雲 / 混合雲。
2. 以 15 題情境題 串聯 Day 1–6，練習「抓關鍵字 ➔ 判斷責任與範圍 ➔ 排除相似服務」的作答節奏。

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

🧭 Phase 1 六日戰利品總盤點

☁️ 雲端服務模型與共同責任

💡 架構師重點筆記：服務從 IaaS 走向 SaaS，客戶的維運負擔會下降，但責任不會歸零。資料、帳號與身分、存取管理、端點裝置仍需要客戶妥善治理。把 SaaS 誤解成「安全全部由 Microsoft 負責」，是共同責任模型最危險的陷阱。

🔬 官方十層責任分界細部拆解（逐層對照，依 Microsoft Learn 現行矩陣校正）

上面的三分類表格只回答「大概歸誰」，但 AZ-900 的情境題常在分界線正上方或正下方設陷阱，因此需要更細的拆解。以下已依 Microsoft Learn：共同責任模型 現行官方矩陣校正——注意官方矩陣不是單純的「客戶／微軟」二元對立，中間有「共同管理」這個第三種狀態，這正是最容易被過度簡化、也最容易出考題的地帶：

💡 架構師重點筆記（校正版）：最上面三層（資料、組態、身分）永遠是客戶的責任，永遠不會轉移；最下面三層（實體主機、實體網路、實體資料中心）永遠是微軟的責任。中間的「應用程式」「網路控制」「裝置端點」則會出現共同管理——例如 SaaS 情境下，Microsoft 可能提供部分裝置管理能力，但端點防護與合規仍是客戶責任；PaaS/SaaS 的應用程式層，Microsoft 管理平台本身，但應用程式設定、程式碼安全與存取控制仍是客戶責任。考題常見陷阱是把「共同管理」的層級簡化成「完全交給微軟」，這正是本節開頭提到的「SaaS 誤解成安全全部由 Microsoft 負責」陷阱的精確發生位置。

🏰 雲端部署模型快速判斷

📐 服務模型與責任轉移架構圖

┌────────────────────────────────────────────────────────────┐
│ 客戶控制多                                                 │
│ IaaS ─────────────► PaaS ─────────────► SaaS               │
│ VM / OS 自管          平台代管 OS          完整軟體服務    │
│ 客戶責任大                                                 │
└────────────────────────────────────────────────────────────┘
                         │
                         ▼
┌────────────────────────────────────────────────────────────┐
│ 永不完全移交：資料、帳號與身分、存取控制、端點裝置         │
└────────────────────────────────────────────────────────────┘
                         │
                         ▼
┌────────────────────────────────────────────────────────────┐
│ 選型順序：控制需求 ➔ 維運能力 ➔ 法遵 ➔ 上線速度與成本      │
└────────────────────────────────────────────────────────────┘

💡 架構師重點筆記：選服務模型不是比較「誰比較高級」，而是決定責任邊界。需要自行安裝特殊驅動與控制 OS，選 IaaS；只想部署程式碼，優先評估 PaaS；需求可由成熟套裝軟體滿足，才選 SaaS。選錯模型的爆炸半徑，不只是成本，而是未被團隊察覺的修補、備份與權限責任。

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

1. Infrastructure as a Service (IaaS，基礎架構即服務)
   • 定義：供應商提供運算、儲存、網路與虛擬化，客戶管理作業系統以上的軟體層。
   • AWS 對照：Amazon EC2。
   • 考點：控制權最高，但客戶也必須承擔 OS 修補、防毒與設定安全。
2. Platform as a Service (PaaS，平台即服務)
   • 定義：供應商連 OS 與執行平台一併管理，客戶專注應用程式與資料。
   • AWS 對照：AWS Elastic Beanstalk / Amazon RDS。
   • 考點：題目出現「不想管理 OS，只想部署程式碼」時優先選 PaaS。
3. Software as a Service (SaaS，軟體即服務)
   • 定義：供應商交付可直接使用的完整應用程式，通常以訂閱方式存取。
   • AWS 對照：AWS Marketplace 中的第三方 SaaS。
   • 考點：客戶仍須管理資料、帳號、身分與存取權限。
4. Shared Responsibility Model (共同責任模型)
   • 定義：雲端供應商負責雲端本身的安全，客戶負責其放入雲端的資料、身分、設定與依服務模型保留的管理層。
   • 考點：IaaS ➔ PaaS ➔ SaaS，責任逐步移轉給供應商，但不會全部移轉。
5. Public / Private / Hybrid Cloud (公有雲 / 私有雲 / 混合雲)
   • 定義：依基礎設施所有權、專用範圍與環境是否互連，區分三種部署模型。
   • 考點：資料必須留地端、又要使用公有雲彈性與統一治理，通常是 Hybrid Cloud。

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

🏛️ 情境背景：Titan 科技的帝國地基驗收

Titan 科技準備推出跨國訂單平台。CTO 在 Phase 1 驗收會議中提出五項要求：

CTO：「研發與營運必須分開計費；Web 團隊只想部署程式碼，不想修補 OS；法規要求核心客戶資料暫時保留在地端；Dev / Test / Prod 必須可重複部署；最後，Azure 若要維護我們使用的區域，值班人員必須先收到通知。請你一次交出完整方案。」

這不是單一服務選型，而是管理邊界、服務模型、部署模型、自動化與維運通知的綜合架構題。

🧩 決策任務

• A：所有資源放進同一個 Subscription 與 Resource Group；Web 系統使用 VM 手動建置；地端資料立即搬上雲端；維運人員每天查看 Azure Status 公開頁面。
• B：以 Management Group 統整治理，研發與營運使用不同 Subscriptions；Web 系統採 Azure App Service (PaaS)；地端資料庫與 Azure 組成 Hybrid Cloud，並用 Azure Arc 納管；環境以 Bicep / ARM Template 部署；在 Azure Service Health 建立通知。
• C：每位員工建立一個 Subscription；所有系統改買 Microsoft 365；以 Portal 手動複製三套環境；用 Azure Advisor 接收平台維護警報。
• D：建立三個不同 Azure China 帳號來隔離 Dev / Test / Prod；所有資源使用 SaaS；用 Resource Health 預測整個 Region 未來的維護排程。

🎯 解題拆解與解析

✅ 正解：B

• 管理與計費：Management Group 提供跨 Subscription 的治理範圍；不同 Subscriptions 可形成清楚的計費與資源邊界。
• 服務模型：App Service 是 PaaS，Microsoft 管理 OS 與平台，團隊專注程式碼與資料。
• 部署模型：資料保留地端、應用使用 Azure，且兩邊互連與統一治理，符合 Hybrid Cloud；Azure Arc 可把外部伺服器帶入 Azure 管理平面。
• 一致部署：Bicep / ARM Template 以宣告式 IaC 降低 Dev / Test / Prod 組態漂移。
• 維運通知：Azure Service Health 提供與訂用帳戶相關的服務事件、健康公告與計畫性維護資訊，並可建立警示。

❌ 陷阱分析

• 選項 A：Resource Group 不是獨立付款邊界；VM 會把 OS 維運責任留給團隊；忽視資料落地法規會造成合規事故；Azure Status 也不是個人化訂用帳戶通知工具。
• 選項 C：每人一個 Subscription 會讓治理失控；Microsoft 365 是完整 SaaS，不能取代客製訂單平台；Portal 手動複製容易產生 Configuration Drift；Advisor 提供最佳化建議，不負責平台維護通知。
• 選項 D：Azure China 是由世紀互聯營運的獨立主權雲，不是一般環境隔離工具；SaaS 並非所有客製需求的答案；Resource Health 聚焦單一資源健康，不預告整個 Region 的維護。

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

本日共 15 題。第 1–5 題依專案規範取自兩層歷史題庫並改寫、再以 Microsoft Learn 覆核；第 6–15 題為跨章整合演練。先遮住解析作答，再檢查自己抓到的是「責任、範圍、故障層級，還是工具定位」。

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

📝 真題 1：跨多個訂用帳戶的治理容器（ExamTopics Q101 改編）

Titan 科技要把研發、營運與資安共 6 個 Subscriptions 放進同一個父層，以便從上層套用治理設定。哪一項是直接位於 Subscription 上方的階層容器？

• A. Resource Group
• B. Management Group
• C. Azure Policy
• D. Azure Region

• 正確答案：B. Management Group
• 關鍵字識別：「多個 Subscriptions」＋「父層容器」。Management Group 能組織多個訂用帳戶，並讓 RBAC / Policy 從該範圍向下繼承。
• 陷阱識破（逐選項查證）：
  • A. Resource Group：官方文件同樣稱其為 container（「resource group - A container that holds related resources for an Azure solution」），但明確落在 Subscription 之內（"all resource groups and resources in your subscription"），方向不符「上方」要求，是刻意設計的優質干擾項。
  • C. Azure Policy：官方定義是「evaluates resources and actions… by comparing… to business rules」，是在某個範疇內執行的規則引擎，本身不是範疇或容器。
  • D. Azure Region：官方文件把 Region 歸類在「實體基礎設施」（physical facilities：datacenters + networking），跟「管理基礎設施」（MG 所屬類別）完全是兩個分類，不會出現在四層管理範疇（MG > Subscription > Resource Group > Resource）清單裡。
• 「階層容器」措辭依據：Microsoft Learn 繁體中文版原文——「您可將訂閱組織成稱為『管理群組』的容器，並將治理條件套用到管理群組」（管理群組管理文件），證實「容器」與「階層」是官方文件自己搭配使用的詞彙，非本文自創。
• ⚠️ 社群分歧說明（誠實揭露，非乾淨共識）：原題實際描述為「Resource Group 能否讓組織跨多個 Subscription 管理 Azure 資源合規性」，真實票數為 B 67 / C 42 / A 1，B 只是多數票、並非壓倒性共識——最高讚同留言（273 讚）支持 B（Management Group 才是階層容器），但另有一則 65 讚的留言主張 C（Azure Policy 才是實際執行合規評估的工具）。兩派論點都站得住腳：Management Group 是「範圍容器」，Azure Policy 是「範圍內執行的規則」，差別在於題目問的是「容器」還是「執行機制」。本文為聚焦 Day7 主題（治理階層），已將情境改寫收斂為明確問「父層容器」，故答案明確為 B；但讀者遇到原題模糊措辭時，應留意這組 B/C 之爭仍是社群討論的活躍焦點。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題 Q101，data-answers-tally 實測 B 67 / C 42 / A 1，經 Playwright 直接讀取討論頁確認，非靜態樣板百分比）；並經 Microsoft Learn：管理群組總覽、管理群組管理文件、Azure Resource Manager 概觀（四層範疇）、Azure Policy 總覽 與 Azure 區域可靠性總覽 五份官方文件逐選項交叉驗證確認（含四個選項的正反面查證，非僅驗證正確答案）。

📝 真題 2：依部門切分管理範圍（ExamTopics Q102 改編）

Titan 科技希望讓不同部門各自管理 Azure 資源。下列哪兩種方式可以形成清楚的資源管理範圍？（選兩項）

• A. 為部門建立不同 Subscriptions
• B. 為每個部門建立不同 Azure Regions
• C. 為每名員工建立不同 Microsoft Entra ID 租戶
• D. 在 Subscription 內為部門建立不同 Resource Groups

• 正確答案：A、D
• 關鍵字識別：「依部門切分管理」。Subscription 可提供較強的計費與資源邊界；Resource Group 可在訂用帳戶內依部門、應用或生命週期分組並指派 RBAC。
• 陷阱識破：Region 是部署位置，不是部門管理邊界；為一般部門拆成多個身分租戶通常徒增複雜度。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題 Q102，data-answers-tally 實測 AD 19 / AB 1，AD 組合明顯領先，經 Playwright 直接讀取討論頁確認）；並經 Microsoft Learn：組織 Azure 資源 交叉驗證確認。

📝 真題 3：找出閒置資源的最佳工具（ExamTopics Q474 改編）

財務長要求找出長期低使用率 VM、未掛載磁碟，並取得具體的成本最佳化建議。應使用哪一項服務？

• A. Azure Advisor
• B. Azure Service Health
• C. Azure Pricing Calculator
• D. Azure Activity Log

• 正確答案：A. Azure Advisor
• 關鍵字識別：「現有資源」＋「低使用率」＋「最佳化建議」。這正是 Advisor 的 Cost 建議類別。
• 陷阱識破：Pricing Calculator 用於部署前估價；Service Health 回報平台事件；Activity Log 稽核控制平面操作。
• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（原題 Q474，真實 data-answers-tally 為 A 26 / 無效票 U 1，最高讚同留言 11 upvotes 支持 A）；並經 Microsoft Learn：Advisor 成本建議 交叉驗證確認。

📝 真題 4：Availability Zone 防護哪種故障？（2020 題庫 Q27 改編）

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

Titan 科技要讓應用在單一 Azure Region 內，即使其中一座資料中心故障仍可繼續服務。應把工作負載分散到哪裡？

• A. 多個 Resource Groups
• B. 多個 Availability Zones
• C. 多個 Management Groups
• D. 同一個 Availability Zone 的同一台 VM

• 正確答案：B. 多個 Availability Zones
• 關鍵字識別：「單一 Region」＋「資料中心故障」。Availability Zones 具獨立電力、冷卻與網路，是區域內的實體故障隔離單元。
• 陷阱識破：Resource Group 與 Management Group 都是邏輯管理範圍，無法隔離實體資料中心故障；單一 AZ 仍有區域單點風險。
• 來源與驗證：經 Microsoft Learn：可用性區域總覽 交叉驗證確認。

📝 真題 5：調查誰停止了生產 VM（2020 題庫 Q80 改編）

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

資安團隊要查出過去 14 天內「誰在何時停止了某台生產 VM」。最精確的資料來源是什麼？

• A. Azure Activity Log
• B. Azure Advisor
• C. Azure Status
• D. Azure Pricing Calculator

• 正確答案：A. Azure Activity Log
• 關鍵字識別：「誰」＋「何時」＋「對資源做了管理操作」。Activity Log 記錄訂用帳戶層級的控制平面事件。
• 陷阱識破：Advisor 不做操作稽核；Azure Status 顯示公開平台狀態；Pricing Calculator 只負責估價。
• 來源與驗證：經 Microsoft Learn：Azure Monitor 活動記錄 交叉驗證確認。

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

📝 情境題 6：不管理 OS 的客製網站

開發團隊要部署自行撰寫的 Web API，但不想管理 OS 修補與 Web Server 執行環境。最佳服務模型是？

• A. IaaS VM
• B. PaaS App Service
• C. SaaS Microsoft 365
• D. Private Cloud 實體主機

• 正確答案：B
• 解題鏈：自行撰寫應用 ➔ 不是現成 SaaS；不管理 OS ➔ 排除 IaaS；因此選 PaaS。
• 官方依據：Microsoft Learn：描述雲端服務類型。

📝 情境題 7：SaaS 下仍不能移交的責任

Titan 科技全面採用 Microsoft 365 後，下列哪一項仍主要由 Titan 科技負責？

• A. Microsoft 資料中心的供電
• B. 實體伺服器與 Hypervisor 修補
• C. 使用者帳號、資料分類與存取權限
• D. SaaS 平台程式碼維護

• 正確答案：C
• 解題鏈：SaaS 將基礎設施與應用平台交由供應商管理，但客戶仍須保護資料、帳號、身分、存取權限與端點。
• 官方依據：Microsoft Learn：雲端共同責任。

📝 情境題 8：資料留地端、應用上雲

因法規要求，資料庫留在自有機房，Web 應用部署於 Azure，兩邊以私有連線互通並接受一致治理。這是哪種部署模型？

• A. Public Cloud only
• B. Private Cloud only
• C. Hybrid Cloud
• D. SaaS

• 正確答案：C. Hybrid Cloud
• 解題鏈：地端私有環境＋公有雲＋互連協作，就是混合雲。SaaS 是服務模型，不是部署模型。
• 官方依據：Microsoft Learn：描述雲端運算。

📝 情境題 9：資料中心故障與整區災難不要混用

若需求是防止同一 Region 內單一資料中心故障，而不是整個 Region 的大規模災難，首要設計是？

• A. 跨 Availability Zones 部署
• B. 建立另一個 Resource Group
• C. 改用另一個 Subscription
• D. 只啟用 Azure Advisor

• 正確答案：A
• 解題鏈：先判斷故障粒度。資料中心級 ➔ AZ；Region 級 ➔ 跨區域災難復原。管理容器無法提供實體容錯。
• 官方依據：Microsoft Learn：Azure 區域與可用性區域。

📝 情境題 10：中國境內獨立營運需求

Titan 科技要在中國大陸提供符合當地法規、由中國境內持照業者營運的 Azure 服務。應選哪個環境？

• A. Global Azure 的 East Asia
• B. Azure China（由世紀互聯 21Vianet 營運）
• C. Azure Government
• D. 任意 Region 加上一個 Resource Group

• 正確答案：B
• 解題鏈：East Asia 是香港的商業 Azure Region，不等於中國境內的獨立 Azure China；Azure Government 則服務美國政府相關客戶。
• 官方依據：Microsoft Learn：Azure China 總覽。

📝 情境題 11：跨平台 CI/CD 指令工具

Windows、macOS 與 Linux 團隊要共用一套命令列腳本，在 CI/CD 中自動建立 Azure 資源。最直接的選擇是？

• A. Azure Portal
• B. Azure CLI
• C. Azure Mobile App
• D. Azure Status

• 正確答案：B. Azure CLI
• 解題鏈：「命令列」＋「跨平台」＋「CI/CD」直接指向 Azure CLI。Portal 與 Mobile App 適合互動操作，不適合管線腳本。
• 官方依據：Microsoft Learn：安裝 Azure CLI。

📝 情境題 12：消除 Dev / Test / Prod 組態漂移

團隊要用同一份定義重複建立 Dev、Test、Prod，並讓變更可進 Git 審查。最佳方案是？

• A. 三次 Portal 手動操作
• B. ARM Template 或 Bicep
• C. 三份 Excel Checklist
• D. Azure Advisor

• 正確答案：B
• 解題鏈：「重複部署」＋「版本控制」＋「一致性」就是 IaC。Bicep 會轉譯為 ARM Template，交由 ARM 執行宣告式部署。
• 風險提醒：正式部署前應使用 What-If 檢視變更，機密則以安全參數或 Key Vault 引用，禁止硬編碼。
• 官方依據：Microsoft Learn：Bicep 總覽。

📝 情境題 13：平台計畫性維護通知

維運團隊希望在 Microsoft 對其使用的 Azure 區域安排計畫性維護時收到 Email 與 Webhook。應使用？

• A. Azure Service Health Alert
• B. Azure Advisor Cost 建議
• C. Resource Group Tag
• D. Azure Pricing Calculator

• 正確答案：A
• 解題鏈：「平台事件」＋「與我的訂用帳戶相關」＋「主動通知」就是 Service Health Alert。
• 官方依據：Microsoft Learn：Azure Service Health 總覽。

📝 情境題 14：單一 VM 為何無法使用

只有 vm-prod-07 無法連線，團隊想確認它目前是 Available、Degraded 還是 Unavailable，並判斷是否為平台事件。先查看哪裡？

• A. Azure Status
• B. Azure Resource Health
• C. Management Group
• D. Azure Pricing Calculator

• 正確答案：B. Azure Resource Health
• 解題鏈：「單一具名資源」是關鍵。Azure Status 看公開全域狀態；Service Health 看訂用帳戶受影響事件；Resource Health 下鑽個別資源。
• 官方依據：Microsoft Learn：Resource Health 總覽。

📝 情境題 15：只有瀏覽器的裝置也要緊急管理 Azure

架構師出差時只有一台能使用現代瀏覽器的平板，需要登入後執行 Bash 或 PowerShell 指令檢查 Azure 資源，而且不想在本機安裝 CLI。最佳工具是？

• A. Azure Cloud Shell
• B. ARM Template Complete mode
• C. Azure Advisor
• D. Azure Region Pair

• 正確答案：A. Azure Cloud Shell
• 解題鏈：「瀏覽器」＋「免安裝」＋「Bash / PowerShell」三個關鍵字鎖定 Cloud Shell。它提供已驗證的瀏覽器終端環境，適合臨時管理與診斷。
• 官方依據：Microsoft Learn：Azure Cloud Shell 總覽。

🕵️ Part 3.5：四大高頻審題陷阱（Phase 1 收尾必練）

15 題刷完後，回頭抽出四種真正讓考生扣分的審題陷阱模式，而不是服務名稱本身。這四種陷阱橫跨 Day 1–7 所有主題，Phase 2 之後的每一天都會再遇到，值得現在就刻進反射動作裡：

1. 關鍵字絕對化干擾：題目出現 Always / Only / Never 這類絕對用詞時要提高警覺。例如「PaaS 是否完全不需要擔心資安？」答案是否——資料與身分存取仍是客戶責任，PaaS 只是把 OS 與 Runtime 交出去，不是把責任歸零。
2. 名稱重組陷阱：Microsoft Entra ID 是雲端原生身分識別服務，不是傳統網域控制器；如果題目描述的是舊系統需要 LDAP / Kerberos / Domain Join，正確答案要跳去 Microsoft Entra Domain Services，選 Entra ID 本身就是誤入陷阱。
3. Tags 的權限誤解：Tags 只是鍵值對詮釋資料，用來做成本分攤與邏輯分類，不具備任何權限繼承或阻擋刪除的能力。題目問「如何防止資源被誤刪」，答案永遠是 Resource Locks，不是 Tags。
4. SLA 複合計算陷阱：若一個架構由兩個 SLA 皆為 99.9% 的服務串聯組成，整體複合可用度是 99.9% × 99.9% ≈ 99.8%，會低於任一單一服務的 SLA，不是直接沿用 99.9%。串聯越多層，複合 SLA 只會越低，這是高可用性設計必須抓的成本與可靠性平衡點。

💡 架構師重點筆記：這四種陷阱不是知識缺口，是閱讀習慣問題——考試會用一個看似無害的形容詞或動詞（Always / 串聯 / 標籤 / 網域）把你導向錯誤選項。拿到題目先圈出這四類關鍵字，再回頭看選項，通常能直接刪掉 1–2 個明顯錯的干擾項。

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

🚀 今日總結與明日預告

🏆 今日 3 點速記精華

1. 先判斷責任，再選服務模型：IaaS 控制最多、責任也最多；PaaS 讓團隊專注程式碼；SaaS 提供完整軟體，但資料、身分與存取仍是客戶責任。
2. 先判斷範圍與故障粒度：Management Group 管多個 Subscriptions，Subscription 是計費與資源邊界，Resource Group 管生命週期；資料中心級故障用 AZ，單一資源診斷看 Resource Health。
3. 不要讓工具名稱騙走分數：Advisor 給最佳化建議，Service Health 回報與訂用帳戶相關的平台事件，Activity Log 查誰做了管理操作，ARM / Bicep 解決一致部署。

🔮 明日預告

Phase 1 地基驗收完成，帝國終於可以正式部署運算兵團！明天 Day 8，我們將進入 Phase 2「核心運算與網路要塞」，深入拆解 Azure Virtual Machines 與 Virtual Machine Scale Sets (VMSS)，並對照 Amazon EC2 與 Auto Scaling Group，學會在控制權、可用性與自動擴展之間做出正確架構決策。

(如果你完成 15 題後仍能清楚說出每個選項錯在哪裡，恭喜你已通過 Phase 1 地基驗收！歡迎分享分數與最容易混淆的陷阱。)