【Day 8】Virtual Machines & VM Scale Sets：控制權、擴展維度與 SLA 階梯的三角權衡 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★☆☆
核心考點：Azure Virtual Machines (IaaS 控制權與責任邊界)、VM 尺寸六大類型 (General purpose / Compute / Memory / Storage optimized / GPU / FPGA accelerated)、垂直擴展 Vertical Scaling (Scale Up / Down) vs 水平擴展 Horizontal Scaling (Scale Out / In)、可擴展性 Scalability vs 彈性 Elasticity、Virtual Machine Scale Sets (VMSS) 與 Autoscale 規則、Orchestration Mode (Flexible vs Uniform)、Availability Set 與容錯網域 Fault Domain / 更新網域 Update Domain、Availability Set (99.95%) vs Availability Zone (99.99%) 的 SLA 階梯、Azure Spot VM、Azure Virtual Desktop、Amazon EC2 ↔ Azure VM 對照、AWS Auto Scaling Group ↔ VMSS 對照、AWS SAA-C03 / CLF-C02 考題概念連動

🎯 前言與今日目標

本文使用了 kiro-cli (chatgpt 5.6 soul),gemini-3.6 flash,copilot cli ,進行，在openab 使用

Day 7 我們完成了 Phase 1 的地基驗收：責任邊界、管理範圍、故障粒度、工具定位四步排除法已經刻進反射動作。今天正式踏入 Phase 2：核心運算與網路要塞，而 Phase 2 的第一場戰役，就是雲端最古老、也最容易被輕視的服務——虛擬機器 (Virtual Machine)。

輕視它的代價通常出現在三個地方，這也是今天必須先建立的問題意識：

1. 「單台 VM 上生產環境」的爆炸半徑：一台孤立的 VM，Azure 官方文件寫得很明白——你仍然要自己負責 OS 修補、防毒與組態安全（VM 總覽："you still need to maintain the virtual machine by performing tasks, such as configuring, patching, and installing the software that runs on it"）。而它的可用性承諾，是整個 SLA 階梯的最底層。單一執行個體壞了，就是服務歸零。
2. 「加規格」與「加台數」被當成同一件事：這是 AZ-900 最高頻的送分／送命題。垂直擴展 (Vertical Scaling) 需要重啟機器、且受限於硬體上限；水平擴展 (Horizontal Scaling) 不中斷服務、且能近乎無限延伸。更關鍵的是：Azure Autoscale 根本不支援垂直擴展。答錯這題，架構設計就會從第一天起走上死路。
3. 「Availability Set 和 Availability Zone 差一個字」的組態漂移：兩者只差一個單字，但一個防的是機櫃／電源／網路交換器層級的故障（99.95% SLA），另一個防的是整座資料中心層級的故障（99.99% SLA）。手動 ClickOps 建 VM 時勾錯一個下拉選單，帳單一樣付，但災難來時的結果完全不同。

在 AWS 體系中，這三題你早就有答案：Amazon EC2 提供執行個體、EC2 Auto Scaling Group (ASG) 負責水平擴展、Multi-AZ 部署 負責資料中心級容錯、Placement Group 負責實體擺放策略。

今天 Day 8，我們要把這套 AWS 肌肉記憶精準地映射到 Azure：Virtual Machine ↔ EC2 Instance、VM Scale Sets ↔ Auto Scaling Group、Availability Set ↔ Spread Placement Group、Availability Zone ↔ Availability Zone，並且逐一用 Microsoft Learn 官方原文校正每一個 SLA 數字與名詞邊界。

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

🧭 1. Compute 選型的第一問：「你想管理多少底層？」

以戰代訓課程在 Compute 章節開頭就下了一個非常好的定調（p74）：Compute 服務都在回答同一件事——你的程式要在哪裡跑，以及你願意管理多少底層細節。 VM、App Service、Containers、Functions 不是誰比較高級，而是責任邊界畫在哪裡。

   控制權 ▲                                        管理負擔 ▲
          │                                                 │
  ┌───────┴──────────┬──────────────┬───────────────┬───────┴──────┐
  │ Virtual Machine  │  Containers  │  App Service  │  Functions   │
  │  (IaaS)          │  (ACI / AKS) │   (PaaS)      │ (Serverless) │
  ├──────────────────┼──────────────┼───────────────┼──────────────┤
  │ 自選 OS 與版本   │ 打包執行環境 │ 平台代管 OS   │ 事件才執行   │
  │ 自裝任何軟體     │ 環境一致性   │ 只部署程式碼  │ 無流量零成本 │
  │ 自負修補與防毒   │ 需懂映像管理 │ 不能改底層 OS │ 有執行時間限 │
  ├──────────────────┼──────────────┼───────────────┼──────────────┤
  │ Azure: VM        │ Azure: ACI / │ Azure: App    │ Azure:       │
  │                  │        AKS   │      Service  │  Functions   │
  ├──────────────────┼──────────────┼───────────────┼──────────────┤
  │ AWS: EC2         │ AWS: ECS/EKS │ AWS: App      │ AWS: Lambda  │
  │                  │              │      Runner   │              │
  └──────────────────┴──────────────┴───────────────┴──────────────┘
        ◀───── 控制越多、責任越多      管理越少、彈性越受限 ─────▶

💡 架構師重點筆記：這張圖的判斷邏輯只有一句話——先讀題目要控制什麼，再選服務。課程 p76 給的關鍵字對照非常精準：看到 install software、manage server、custom OS、lift and shift、legacy application → Virtual Machine；看到 host website、REST API、deploy code、managed hosting → App Service（Day 9）；看到 package app with dependencies → Containers（Day 10）；看到 event-driven、只在觸發時執行 → Functions（Day 9）。而看到 autoscale identical VMs、大量相同伺服器承接尖峰流量 → Virtual Machine Scale Sets，這正是今天的主角之一。

🖥️ 2. Azure Virtual Machine 解構：不只是一台機器，而是一整組資源

從 AWS 過來的架構師最容易低估的一點：在 Azure 建一台 VM，實際上是一次建立一整組互相關聯的資源，而每一個都有自己的計費與安全含意。Microsoft Learn 的 VM 總覽 明確列出這組「支援資源」：

🔢 VM 尺寸的六大類型（考點：依工作負載選型，不是背型號）

Learn：Azure VM 尺寸總覽 將所有尺寸依 Type（工作負載意圖） 分成六類，官方原文列舉為："General purpose、Compute optimized、Memory optimized、Storage optimized、GPU accelerated、FPGA accelerated"。

💡 架構師重點筆記（雙雲命名哲學差異）：AWS 的執行個體型號是 家族 + 世代 + 大小（如 m6i.2xlarge），型號本身就是規格；Azure 則是 Standard_ ＋ 家族字母 ＋ vCPU 數 ＋ 特性字母 ＋ 版本（如 Standard_D8s_v5，其中 s = Premium Storage 支援、a = AMD、p = ARM 架構）。考試不會考型號，但會考「題目描述的工作負載該落在哪一類」——看到「記憶體內分析」選 Memory optimized，看到「深度學習訓練」選 GPU。

📈 3. 今日最高頻考點：垂直擴展 vs 水平擴展、可擴展性 vs 彈性

這四個名詞是 AZ-900 Describe Cloud Concepts 領域（占比 25–30%）的必考題，而且考法極為固定。先看官方逐字定義，再看記憶法。

Microsoft Learn 官方原文（Azure Monitor Autoscale 總覽）：

"Autoscale scales in and out, or horizontally. Scaling horizontally is an increase or decrease of the number of resource instances. For example, for a virtual machine scale set, scaling out means adding more virtual machines. Scaling in means removing virtual machines."

"Autoscale does not support vertical scaling. In contrast, scaling up and down, or vertical scaling, keeps the same number of resource instances constant but gives them more capacity in terms of memory, CPU speed, disk space, and network. Vertical scaling is limited by the availability of larger hardware, which eventually reaches an upper limit... Vertical scaling might also require a restart of the VM during the scaling process."

繁體中文官方用詞也一併核實過（同頁 zh-tw 版）：官方譯為「水平調整／水平擴展」「垂直調整」「向外／向內調整」「向上／向下調整」，並明寫「自動調整不支援垂直調整」。本文使用的中文名詞皆為官方翻譯，非自行意譯。

┌────────────────────────────────────────────────────────────────┐
│     可擴展性 Scalability：容量能不能跟著需求長大（不一定自動） │
└────────────────────────────────────────────────────────────────┘
              │                                    │
              ▼                                    ▼
┌───────────────────────────┐        ┌───────────────────────────┐
│ 垂直擴展 Vertical Scaling │        │ 水平擴展 Horizontal       │
│ ＝ Scale Up / Scale Down  │        │ ＝ Scale Out / Scale In   │
├───────────────────────────┤        ├───────────────────────────┤
│ 同「一台」變強／變弱      │        │ 「台數」變多／變少        │
│ D2s_v5 ──▶ D8s_v5         │        │ 2 台 ──▶ 20 台            │
│ 需重新部署，可能要重啟    │        │ 佈建新執行個體，不中斷    │
│ 受最大硬體規格上限限制    │        │ 可近乎無限延伸            │
│ ❌ Autoscale 不支援       │        │ ✅ Autoscale 原生支援     │
│ AWS：改 instance type     │        │ AWS：Auto Scaling Group   │
└───────────────────────────┘        └───────────────────────────┘
              │                                    │
              └────────────────┬───────────────────┘
                               ▼
┌────────────────────────────────────────────────────────────────┐
│  彈性 Elasticity：依「短期」需求自動增減資源（核心是「自動」） │
│  → 在 Azure 上的具體實作 = Autoscale ＋ VM Scale Sets          │
└────────────────────────────────────────────────────────────────┘

💡 架構師重點筆記（Why / Risk）：為什麼官方特別強調「Autoscale 不支援垂直擴展」？因為 Azure Architecture Center：Autoscaling 講清了底層機制——"Vertical scaling often requires making the system temporarily unavailable while it's being redeployed. Therefore, it's less common to automate vertical scaling."；而水平擴展則是 "The application continues running without interruption as new resources are provisioned." 把自動化建立在「需要停機」的機制上，等於把服務中斷寫進自動化腳本，爆炸半徑會隨著觸發次數累積。這就是為什麼雲端原生架構一律優先設計成無狀態 ＋ 水平擴展。

🔍 四個名詞的一句話判斷規則（考場用）

⚠️ 高頻陷阱：題目問「increase the computing capacity of a virtual machine by adding memory or CPUs」時，答案是 Vertical Scaling，不是 Elasticity（Elasticity 強調「自動」）、也不是 Agility（Agility 指「快速回應變化的能力」，是雲端效益而非擴展術語）。這正是 Part 3 真題 1 的原題設計。

🛡️ 4. 三種 VM 高可用機制的精準邊界：Availability Set / Availability Zone / Scale Sets

這是今天最容易失分的一段。三個名詞都含「Availability」或「Set」，但解決的問題完全不同。以下每一項都附 Microsoft Learn 逐字原文。

(1) Availability Set（可用性設定組）：對抗機櫃層級的硬體故障與平台維護

Learn：可用性設定組總覽 官方原文：

"Availability sets are logical groupings of VMs that reduce the chance of correlated failures bringing down related VMs at the same time. Availability sets distribute VMs across multiple fault domains, improving reliability."

"The underlying Azure platform assigns an update domain and a fault domain to each virtual machine in your availability set. Each availability set can have up to 3 fault domains and 20 update domains. These settings can't be changed after the availability set is created."

"Fault domains define the group of virtual machines that share a common power source and network switch."
"Update domains indicate groups of virtual machines and underlying physical hardware that can be restarted at the same time."

"Using two or more VMs in an availability set helps keep applications highly available and meets the 99.95% Azure service-level agreement (SLA)."

關鍵限制（考題陷阱來源），同一頁官方原文寫得毫不含糊：

"Availability sets are still susceptible to certain shared infrastructure failures, such as datacenter-level network outages, which can affect multiple fault domains."
"Availability sets provide high availability but don't offer the same level of resiliency as availability zones."

繁體中文官方頁面（zh-tw 版）使用的正式譯名為「可用性設定組」「容錯網域」「更新網域」，並同樣寫明「每個可用性設定組最多可以有 3 個容錯網域和 20 個更新網域」。

(2) Availability Zone（可用性區域，Day 2 已介紹）：對抗整座資料中心故障

Learn：VM 可用性選項 官方原文：

"An Availability Zone is a physically separate zone, within an Azure region. There are three Availability Zones per supported Azure region. Each Availability Zone has a distinct power source, network, and cooling. By designing your solutions to use replicated VMs in zones, you can protect your apps and data from the loss of a data center."

而 SLA 的關鍵條件寫在 Learn：VM 總覽：

"Availability Zones are physically separated zones within an Azure region. Availability zones guarantee virtual machine connectivity to at least one instance at least 99.99% of the time when you have two or more instances deployed across two or more Availability Zones in the same Azure region."

⚠️ 極重要的反向陷阱：Learn：VM 可靠性 明確指出——"An individual VM can be deployed in a zonal configuration, which means that it's pinned to a single availability zone that you select. By itself, a zonal VM isn't resilient to zone outages." 以及 "If you don't configure a VM to be zonal, it's considered nonzonal or regional. Nonzonal VMs might be placed in any availability zone within the region." 「放進一個 AZ」不等於高可用；必須是「跨兩個以上 AZ、兩台以上執行個體」才拿得到 99.99%。

(3) Virtual Machine Scale Sets（VMSS）：解決管理規模與自動擴展，不自動等於跨資料中心容錯

Learn：VMSS 總覽 官方原文：

"Azure Virtual Machine Scale Sets let you create and manage a group of load balanced virtual machine (VM) instances. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule."

四大官方列舉效益："Easy to create and manage multiple VMs / Provides high availability and application resiliency by distributing VMs across availability zones or fault domains / Allows your application to automatically scale as resource demand changes / Works at large-scale"

而 Learn：VM 可用性選項 加了那句決定考題答案的話：

"Virtual machines in a scale set can also be deployed into multiple availability zones, a single availability zone, or regionally."

💡 架構師重點筆記（這句話就是 Part 3 真題 2 的答案來源）：既然 Scale Set 可以部署成單一 AZ 或 regional，那麼題目只說「我把 VM 部署到一個（或兩個）Scale Set」而沒有指定跨 AZ時，就不能保證單一資料中心故障後服務存活。Scale Set 本身是「管理與擴展」機制，區域級容錯來自它「被設定成跨 AZ」這件事，不是來自 Scale Set 這個名詞。 這是最容易被 AWS 背景架構師誤判的地方——因為 AWS ASG 幾乎總是被教成要橫跨多個 Subnet（即多個 AZ），久了會誤以為「ASG 天生就是 Multi-AZ」。

🪜 SLA 階梯：把三種機制換算成可用性承諾

💡 雙雲 SLA 哲學對照（已逐字核實）：AWS Compute SLA 原文寫明 "a Region-Level SLA that governs Amazon EC2 deployed across multiple AZs or regions"，其中 "For Amazon EC2 with all running instances deployed concurrently across two or more AZs in the same region... a Monthly Uptime Percentage of at least 99.99%"，而 "For each individual Amazon EC2 instance... an Instance-Level Uptime Percentage of at least 99.5%"。結論：兩朵雲的設計語言完全一致——可用性不是買來的，是「部署拓撲」換來的。 差別只在 Azure 多了一層 Availability Set（99.95%）這個「同資料中心內分散」的中間階梯，AWS 則以 Placement Group 策略處理相同問題但不給獨立 SLA 數字。

⚙️ 5. VMSS 深入：Orchestration Mode 與 Autoscale 規則邏輯

Flexible vs Uniform：AZ-900 不會考細節，但架構決策一定要知道

Learn：VMSS Orchestration Modes 官方原文：

"Flexible Orchestration is the recommended orchestration mode when deploying scale sets in Azure."（官方標題直接寫 Scale Sets with Flexible Orchestration (Recommended)）

⚠️ "The orchestration mode is defined when you create the scale set and cannot be changed or updated later."

💡 架構師重點筆記（重要的官方立場轉向）：可用性設定組頁面現在掛著這段官方建議——"We recommend that customers choose Virtual Machine Scale Sets with flexible orchestration mode for high availability with the widest range of features."，而 Autoscale 頁面更直白："Availability sets are an older scaling feature for virtual machines with limited support. We recommend migrating to Azure Virtual Machine Scale Sets for faster and more reliable autoscale support." 但請注意：Availability Set 仍是 AZ-900 現行考點（課程 p78 明列），且 99.95% SLA 仍然有效。「官方建議改用 VMSS」與「考試仍會考 Availability Set」兩件事同時為真，不要因為看到這句話就在考場上排除 Availability Set 選項。

Autoscale 規則的布林邏輯（AZ-104 常考、AZ-900 值得知道）

Learn：Autoscale 總覽 有一組非常反直覺、但設計上完全合理的規則：

"Autoscale scales out if any of the rules are met. Autoscale scales in only if all the rules are met. In terms of logic operators, the OR operator is used for scaling out with multiple rules. The AND operator is used for scaling in with multiple rules."

💡 架構師重點筆記（Why）：向外擴展用 OR（任一指標告急就加機器）、向內縮減用 AND（所有指標都閒置才敢減機器）——這是刻意設計的非對稱保守策略：加機器的代價只是錢，減錯機器的代價是服務中斷。AWS ASG 的 Target Tracking / Step Scaling 政策背後是同一套保守哲學，只是暴露的參數不同。官方另補一句可對照 AWS Predictive Scaling 的功能："Predictive autoscale uses machine learning to help manage and scale Virtual Machine Scale Sets with cyclical workload patterns."

💰 計費關鍵：Scale Set 本身不收費

Learn：VM 可用性選項 原文："There is no cost for the scale set itself, you only pay for each VM instance that you create."，同頁也寫 Availability Set "There is no cost for the Availability Set itself"。這兩個「編制容器」都免費，收費的永遠是實際跑起來的 VM 執行個體——與 AWS ASG 不收費、只收 EC2 費用完全一致。

🧩 6. VM 相關服務全家桶（課程 p78 考點）

課程把「以 VM 為基礎的相關服務」放在一起考，因為它們的差別是**「你要一台 VM、很多台自動擴展的 VM，還是要讓 VM 更可靠」**：

⚠️ Spot VM 的爆炸半徑（Risk）：官方原文明寫 "An Azure Spot Virtual Machine offers no high availability guarantees"，且驅逐原則可設為 Deallocate（預設）或 Delete——選 Delete 會連同底層磁碟一起刪除。把 Spot 放進有狀態的生產工作負載，等於在架構裡埋一顆 30 秒引信的炸彈。官方建議的適用場景是 "batch processing jobs, dev/test environments, large compute workloads"。

🔐 7. 防禦性設計：VM 架構的三個必修安全動作

AZ-900 不會直接考實作，但這三點是「原廠最佳實踐」層級的必備知識，且每一項在考題中都以「哪個選項最安全」的形式出現過：

1. 絕不硬編碼憑證（Never hardcode credentials）
   自訂映像、Custom Script Extension、cloud-init 檔案裡塞連線字串或存取金鑰，是雲端最經典的資安破口。Azure 的正解是 Managed Identity ＋ Azure Key Vault。Learn：Managed identities 總覽 原文：

   "A common challenge for developers is the management of secrets, credentials, certificates, and keys... Manual handling of secrets and certificates are a known source of security issues and outages. Managed identities eliminate the need for developers to manage these credentials." 且 "A managed identity is an identity that can be assigned to an Azure compute resource (Azure Virtual Machine, Azure Virtual Machine Scale Set, ...)"、"You don't need to manage credentials. Credentials aren't even accessible to you."

   • AWS 對照：Managed Identity ↔ EC2 Instance Profile / IAM Role for EC2；Key Vault ↔ AWS Secrets Manager / SSM Parameter Store。兩者的抽象哲學一致：讓運算資源自己有身分，而不是讓它保管密碼。

2. 管理連接埠不要暴露到 Internet（0.0.0.0/0 的 3389 / 22）
   正解是 Azure Bastion。Learn：Bastion 總覽 原文："Azure Bastion is a fully managed PaaS service that provides secure and seamless RDP/SSH connectivity to your virtual machines directly over TLS... When you connect via Azure Bastion, your virtual machines don't need a public IP address, agent, or special client software."

   • AWS 對照：Azure Bastion ↔ AWS Systems Manager Session Manager（同樣免公有 IP、免開 22/3389）。

3. 一致性靠 IaC，不靠 ClickOps
   Day 5 已建立的觀念在這裡有具體代價：手動建 VM 最容易漏掉的就是「加入 Availability Set / 指定 Availability Zone」這個下拉選單——建完了看起來一切正常，帳單照付，但 SLA 從 99.99% 掉到 99.9% 而沒有任何錯誤訊息。用 Bicep / ARM Template 宣告 zones: ['1','2','3'] 或 Scale Set 的 zones 屬性，把可用性設計變成可被 Code Review 的一行程式碼，才是防止組態漂移 (Configuration Drift) 的唯一方法。

📄 Side-by-Side：Bicep VMSS 與 AWS Auto Scaling Group 的結構解構

// Azure：Bicep — 跨 3 個 AZ 的 Flexible Scale Set（結構節錄）
param adminUsername string
@secure()                                     // ← 機密一律用 @secure()
param adminPasswordOrKey string               //   絕不硬編碼、不寫預設值

resource vmss 'Microsoft.Compute/virtualMachineScaleSets@2024-07-01' = {
  name: 'vmss-titan-web-prod'
  location: resourceGroup().location
  zones: ['1', '2', '3']                      // ← 跨 3 AZ ⇒ 99.99% SLA 前提
  sku: { name: 'Standard_D2s_v5', capacity: 3 }
  identity: { type: 'SystemAssigned' }        // ← Managed Identity 取代帳密
  properties: {
    orchestrationMode: 'Flexible'             // ← 官方建議，且建立後不可改
    platformFaultDomainCount: 1               // ← 最大分散 (max spreading)
    virtualMachineProfile: { /* OS 映像、NIC、磁碟、擴充功能 */ }
  }
}

# AWS：CloudFormation — 等價的 Auto Scaling Group（結構節錄）
Resources:
  TitanWebASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: '3'
      MaxSize: '20'
      VPCZoneIdentifier:                      # ← 多個 Subnet ＝ 多個 AZ
        - !Ref PrivateSubnetAZa
        - !Ref PrivateSubnetAZb
        - !Ref PrivateSubnetAZc
      LaunchTemplate:                   # ← 對照 VMSS virtualMachineProfile
        LaunchTemplateId: !Ref TitanWebLaunchTemplate
        Version: !GetAtt TitanWebLaunchTemplate.LatestVersionNumber
      # IAM Role 透過 Launch Template 的 IamInstanceProfile 掛入（不放金鑰）

💡 架構師重點筆記（雙雲抽象機制的對稱與不對稱）：

• 對稱處：兩邊都是「一份執行個體範本（virtualMachineProfile ↔ LaunchTemplate）＋ 一組容量參數 ＋ 一組放置位置」。AZ 分散在 Azure 是 zones 陣列（直接宣告 AZ 編號），在 AWS 是 VPCZoneIdentifier 的 Subnet 清單（透過 Subnet 間接綁 AZ）——這就是 AWS 架構師最常在 Azure 踩空的地方：Azure 的 AZ 是 VM 的直接屬性，不是透過 Subnet 決定的。Azure 的 Subnet 不綁 AZ。（Day 11 詳解）
• 不對稱處：VMSS 的 orchestrationMode 建立後不可變更，這是 AWS ASG 沒有的一次性決策；反過來 AWS ASG 的 MinSize/MaxSize 直接寫在 ASG 上，Azure 則把容量上下限放在獨立的 Microsoft.Insights/autoscalesettings 資源裡。
• 變更審查：部署前一律先跑 az deployment group what-if（對照 AWS Change Sets / terraform plan），確認不會意外把 capacity 降到 0 或替換掉整組執行個體。

📐 雙雲運算與擴展架構全景對比圖

┌───────────────────────────────────┬───────────────────────────────────┐
│      🟠 AWS 運算與擴展生態系      │     🔵 Azure 運算與擴展生態系     │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【IaaS 運算執行個體】             │ 【IaaS 運算執行個體】             │
│  Amazon EC2 Instance              │  Azure Virtual Machine            │
│  • AMI（映像）                    │  • Marketplace Image / 自訂映像   │
│  • m6i.2xlarge（型號即規格）      │  • Standard_D8s_v5（家族+特性碼） │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【水平擴展與群組管理】            │ 【水平擴展與群組管理】            │
│  EC2 Auto Scaling Group (ASG)     │  VM Scale Sets (VMSS)             │
│  • Launch Template                │  • virtualMachineProfile          │
│  • Target Tracking / Step Scaling │  • Autoscale rules（OR 出/AND 入）│
│  • Predictive Scaling             │  • Predictive autoscale           │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【同機房內的實體分散】            │ 【同機房內的實體分散】            │
│  Spread Placement Group           │  Availability Set                 │
│  • 分散到不同機架                 │  • 3 Fault Domains（電源/交換器） │
│  • 無獨立 SLA 數字                │  • 20 Update Domains（維護重啟）  │
│                                   │  • 2 台以上 ⇒ 99.95% SLA          │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【跨資料中心容錯】                │ 【跨資料中心容錯】                │
│  Multi-AZ（靠 Subnet 綁 AZ）      │  Availability Zones（VM 直接屬性）│
│  • 跨 2 AZ ⇒ Region SLA 99.99%    │  • 2 台跨 2 AZ ⇒ 99.99% SLA       │
│  • 單一執行個體 ⇒ 99.5%           │  • 單一 VM(Premium SSD) ⇒ 99.9%   │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【折扣型可中斷容量】              │ 【折扣型可中斷容量】              │
│  EC2 Spot Instances               │  Azure Spot VM                    │
│  • 2 分鐘中斷通知                 │  • 30 秒驅逐通知、無 SLA          │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【免公有 IP 的安全管理通道】      │ 【免公有 IP 的安全管理通道】      │
│  SSM Session Manager              │  Azure Bastion（RDP/SSH over TLS）│
├───────────────────────────────────┼───────────────────────────────────┤
│ 【運算資源的身分憑證】            │ 【運算資源的身分憑證】            │
│  EC2 Instance Profile / IAM Role  │  Managed Identity                 │
│  Secrets Manager / Parameter Store│  Azure Key Vault                  │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【雲端虛擬桌面 VDI】              │ 【雲端虛擬桌面 VDI】              │
│  Amazon WorkSpaces                │  Azure Virtual Desktop (AVD)      │
└───────────────────────────────────┴───────────────────────────────────┘

💡 架構師重點筆記（三個最容易搞錯的映射）：

1. AZ 綁定方式不同：AWS 的 EC2 落在哪個 AZ，是由你選的 Subnet 決定的；Azure 的 VM 落在哪個 AZ，是 VM 自己的 zones 屬性決定的，Azure Subnet 不綁 AZ。從 AWS 過來若沿用「選 Subnet 就等於選 AZ」的直覺，會建出一整組全部落在同一個 AZ（甚至 nonzonal）的 VM。
2. Availability Set 在 AWS 沒有完全等價物：它是 Azure 特有的「同資料中心內、由平台自動分配 FD / UD」的抽象層，最接近的是 Spread Placement Group，但 AWS 不為它提供獨立的 SLA 數字。
3. VMSS ≠ ASG 的完全複製：VMSS 多了一個 AWS 沒有的一次性不可變決策（orchestrationMode），且 Uniform 模式的執行個體不支援標準 VM API、ARM Tag、RBAC、Azure Backup 與 Site Recovery——這在成本分攤與備份治理上是實質限制。

📊 雙雲運算選型全維度對照表

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

只列 Day 8 新出現的名詞。Availability Zone / Region / Region Pair 已於 Day 2 介紹、共同責任模型與 IaaS 定義已於 Day 7 介紹、ARM Template / Bicep 已於 Day 5 介紹，此處不重複。

1. Virtual Machine (VM，虛擬機器)
   • 定義：Azure 的 IaaS 運算服務，提供最接近傳統伺服器的控制權——可自選作業系統、CPU、記憶體、磁碟與網路，並自行安裝任何軟體。
   • AWS 對照：Amazon EC2 Instance。
   • 考點：看到 full control、custom OS、install software、lift and shift 就選 VM；但同時代表 OS 修補、防火牆設定與安全維護的責任仍在客戶身上。
2. VM Size / Series（VM 尺寸與系列）
   • 定義：Azure 依工作負載意圖將尺寸分為六種 Type——General purpose、Compute optimized、Memory optimized、Storage optimized、GPU accelerated、FPGA accelerated。
   • AWS 對照：EC2 Instance Family（T/M、C、R/X、I/D、P/G、F1）。
   • 考點：考「工作負載該落在哪一類」，不考型號。記憶體內資料庫 → Memory optimized；深度學習 → GPU accelerated。
3. Virtual Machine Scale Sets (VMSS，虛擬機器擴展集)
   • 定義：一組負載平衡的 VM 執行個體，數量可依需求或排程自動增減，並可跨可用性區域或容錯網域分散。
   • AWS 對照：EC2 Auto Scaling Group。
   • 考點：解決的是「管理規模 ＋ 自動水平擴展」。Scale Set 本身免費，只付 VM 執行個體的錢；且它不會自動提供跨資料中心容錯，除非明確設定跨 AZ。
4. Orchestration Mode（協調模式：Flexible / Uniform）
   • 定義：Scale Set 管理執行個體的方式。Flexible 為官方建議模式（支援混合 VM 尺寸、可用標準 VM API、最多 1,000 台）；Uniform 針對大規模同質執行個體最佳化。
   • 考點：建立後不可變更。Uniform 模式不支援標準 VM API、ARM Tag、RBAC、Azure Backup 與 Site Recovery。
5. Availability Set（可用性設定組）
   • 定義：VM 的邏輯分組，由 Azure 平台自動把 VM 分散到最多 3 個容錯網域與 20 個更新網域，降低相互關聯的故障同時擊倒所有 VM 的機率。
   • AWS 對照：Spread Placement Group（概念相近，無等價 SLA）。
   • 考點：2 台以上 ⇒ 99.95% SLA。防的是機櫃／電源／維護重啟，擋不住資料中心級網路中斷。
6. Fault Domain (FD，容錯網域)
   • 定義：官方原文——共用同一組電源與網路交換器的 VM 群組。預設分散到最多 3 個。
   • 考點：關鍵字是「實體硬體故障」「電源」「網路交換器」。
7. Update Domain (UD，更新網域)
   • 定義：官方原文——可以同時被重新啟動的 VM 與底層實體硬體群組。計畫性維護時一次只重啟一個 UD，且重啟後有 30 分鐘復原時間才會動下一個。
   • 考點：關鍵字是「平台計畫性維護」「不要所有機器同時重開」。
8. Vertical Scaling（垂直擴展）／Scale Up / Down
   • 定義：維持相同的執行個體數量，但給予單一執行個體更多記憶體、CPU 速度、磁碟空間與網路容量。
   • AWS 對照：更改 EC2 instance type。
   • 考點：adding memory or CPUs 的標準答案。需重啟、有硬體上限、Azure Autoscale 不支援。
9. Horizontal Scaling（水平擴展）／Scale Out / In
   • 定義：增加或減少執行個體的數量。新資源佈建期間應用程式持續運行、不中斷。
   • AWS 對照：EC2 Auto Scaling Group 的 Desired Capacity 調整。
   • 考點：add more VMs 的標準答案，也是 Autoscale 唯一支援的維度。
10. Elasticity（彈性）
    • 定義：依短期需求自動增加或減少資源，離峰時自動縮減以避免長時間保留不需要的容量。
    • AWS 對照：Auto Scaling ＋ On-Demand 計費模型。
    • 考點：與 Scalability 的分界就是「自動」與「短期」。看到「流量突然暴增後自動增加、下降後自動縮減」一律選 Elasticity。
11. Autoscale（自動調整）
    • 定義：Azure Monitor 的功能，依 CPU、佇列長度、可用記憶體等指標或排程自動增減資源。
    • 考點：向外擴展用 OR（任一規則成立就擴），向內縮減用 AND（所有規則成立才縮）。不支援垂直擴展。
12. Azure Spot Virtual Machine
    • 定義：使用 Azure 未使用容量以取得大幅折扣的 VM，Azure 需要容量時會以 30 秒通知驅逐，無 SLA、無高可用保證。
    • AWS 對照：EC2 Spot Instances。
    • 考點：只適合可中斷的批次運算、開發測試與大型計算工作負載。
13. Azure Virtual Desktop (AVD)
    • 定義：將 Windows 桌面與應用程式放在 Azure 執行，使用者可從不同裝置連線使用的虛擬桌面服務。
    • AWS 對照：Amazon WorkSpaces。
    • 考點：題幹出現「使用者要從任何裝置存取 Windows 桌面／集中管理桌面環境」時選 AVD，不要選 VM。
14. Azure DevTest Labs
    • 定義：讓開發與測試人員快速建立、管理 Azure VM 的服務，內建自助式模型、成本控管（如自動關機原則）與自動化功能。
    • 考點：題幹出現「每週大量建立又刪除自訂開發測試 VM，要最小化管理工作」時選它，不要誤選 Scale Sets（Scale Sets 是為承接流量的同質生產機群設計的）。
15. Managed Identity（受控識別）
    • 定義：指派給 Azure 運算資源（VM、VMSS 等）的身分，讓應用程式取得 Microsoft Entra 權杖而完全不需要管理任何憑證。
    • AWS 對照：EC2 Instance Profile / IAM Role for EC2。
    • 考點：任何「如何避免在程式碼或範本中硬編碼帳密」的題目，Azure 的答案是 Managed Identity（＋ Key Vault）。
16. Azure Bastion
    • 定義：完全受控的 PaaS 服務，透過 TLS 提供對 VM 的 RDP / SSH 連線，VM 不需要公有 IP、不需代理程式或特殊客戶端軟體。
    • AWS 對照：AWS Systems Manager Session Manager。
    • 考點：關鍵字是「安全存取 VM 但不想開放 3389 / 22 到 Internet」。

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

🏛️ 情境背景：Titan 科技「雙十一」電商主戰場的兵團編制

Day 6 我們幫 Titan 科技建立了健康監控與成本顧問機制，Day 7 完成了地基驗收。現在真正的戰役來了：Titan 科技的全球電商平台要在三週後迎接雙十一，這次要從零設計運算層。

CTO 把你叫進作戰室，攤開四張需求卡：

CTO：「架構師，這次我要一次把運算層做對，不要再讓我半夜接電話。四個需求，一次交清：

1. 前端 Web 層：平日只需要 3 台機器，雙十一當天預估要 20 台以上，而且要自動增減，不要有人守著 Portal 手動點。活動結束後必須自己縮回去，我不想付一整個月的 20 台費用。
2. 可用性硬要求：Web 層必須拿到 99.99% 的 VM SLA，而且要用最少的機器數與最少的區域數達成——我不想為了漂亮的數字多付錢。
3. 交易資料庫叢集：因為叢集節點間的同步有嚴格的低延遲要求，法務與 DBA 都堅持必須留在同一座資料中心內。但我還是要求：那座資料中心裡某個機櫃跳電、或微軟排定平台維護重啟時，叢集不能整組同時掛掉。
4. 資安鐵律：資安長剛被稽核釘過。所有機器不准有對外的 3389 / RDP 連接埠，維運人員要能安全登入；而且應用程式連資料庫與儲存體時，不准在任何映像、腳本或範本裡出現帳號密碼或存取金鑰。

給我方案，並且告訴我為什麼其他做法不行。」

                    【Titan 科技雙十一運算層作戰圖】
                                  │
      ┌──────────────┬────────────┴─────────┬──────────────────┐
      ▼              ▼                      ▼                  ▼
 【需求 1】      【需求 2】             【需求 3】          【需求 4】
 3 ⇄ 20 台      99.99% SLA            低延遲同機房        零公開 RDP
 自動增減       最少機器/區域          但要抗機櫃故障      零硬編碼憑證
      │              │                      │                  │
  [水平擴展]    [跨 AZ 拓撲]          [FD / UD 分散]      [身分與通道]

🧩 決策任務

以下四個方案，哪一個同時滿足全部四項需求，且符合 Azure 原生最佳實踐與最小成本原則？

• 方案 A：

  • Web 層建 1 台超大規格 VM（Standard_E64s_v5），雙十一前一天用腳本把它 Scale Up 到更大尺寸，活動後再降規。
  • 為了拿 99.99% SLA，把這台 VM 放進一個 Availability Zone。
  • 資料庫叢集節點全部建在同一個 Availability Zone、不加任何設定組。
  • 維運人員登入方式：給每台 VM 一個 Public IP 並開放 3389，用強密碼保護；連線字串直接寫在 Custom Script Extension 裡。

• 方案 B：

  • Web 層建 Virtual Machine Scale Set（Flexible orchestration），zones: ['1','2'] 跨兩個可用性區域，初始 3 台、Autoscale 規則依 CPU 在 3–20 台之間自動 Scale Out / In。
  • 99.99% SLA 由「2 台以上執行個體 ＋ 跨 2 個以上 Availability Zones」達成，恰好是最小配置。
  • 資料庫叢集節點放進同一個 Availability Set，由平台自動分散到不同 Fault Domain（電源／網路交換器） 與 Update Domain（維護重啟批次）。
  • 部署 Azure Bastion 提供 RDP over TLS，VM 不配置 Public IP；VM / VMSS 啟用 System-assigned Managed Identity，機密改由 Azure Key Vault 提供，範本中的密碼參數標記 @secure()。

• 方案 C：

  • Web 層建 Virtual Machine Scale Set，但不指定 zones（使用預設 regional 部署），靠 Scale Set 本身取得高可用。
  • 為了同時「保險」，再開一個 Availability Set 把同一批 Scale Set 執行個體也加進去。
  • 資料庫叢集用 Proximity Placement Group 讓節點盡可能靠近，以取得最低延遲並兼顧容錯。
  • 為省成本，Web 層與資料庫叢集全部改用 Azure Spot VM，並用 Azure Advisor 監控是否被驅逐。

• 方案 D：

  • Web 層用 20 台單獨建立的 VM，全部放在同一個 Availability Set，平日手動關機 17 台、活動前手動開機。
  • 99.99% SLA 靠「Availability Set 內有 20 台機器」達成，數量夠多就一定夠可靠。
  • 資料庫叢集跨 Region Pair 部署到兩個地理區域以取得最高可靠性。
  • 維運登入使用 VPN Gateway 連進 VNet；憑證統一寫進一份共用的自訂 VM 映像，方便所有機器一致使用。

🎯 解題拆解與解析

✅ 正確解答：方案 B

🏆 架構師深度剖析（逐需求對應）

1. 需求 1（3 ⇄ 20 台自動增減）→ VMSS ＋ Autoscale
   這是教科書級的水平擴展 (Scale Out / In) 情境。Learn 官方對 VMSS 的定義正是 "The number of VM instances can automatically increase or decrease in response to demand or a defined schedule"。而選 Flexible orchestration 的理由有三：官方明訂它是建議模式、支援標準 VM API（Tag / RBAC / Backup 都能用，成本分攤與備份治理不會被卡）、且未來若要混用 Spot 與隨需執行個體也留有餘地。
   Scale Set 本身不收費（"There is no cost for the scale set itself"），活動結束自動縮回 3 台就只付 3 台的錢，完全命中 CTO「不想付一整月 20 台」的要求。

2. 需求 2（99.99% ＋ 最少機器與區域）→ 2 台 × 2 個 AZ
   Learn 原文的條件是 "two or more instances deployed across two or more Availability Zones in the same Azure region"。注意 CTO 說的是「最少」——所以答案是 2 台 ＋ 2 個 AZ，不是 3 台或 3 個 AZ。方案 B 的初始容量 3 台跨 2 個 AZ 已經滿足並超過門檻，SLA 條件在 Autoscale 縮到最低 3 台時依然成立。

   ⚠️ 這裡有個常被忽略的維運陷阱：如果你把 Autoscale 的 minimum 設成 1，那麼在離峰時段這套架構會掉出 99.99% SLA 的適用條件。SLA 條件是「持續」的，不是「曾經部署過」。設定最小容量時，下限必須 ≥ 2 且橫跨 ≥ 2 個 AZ。

3. 需求 3（同機房低延遲 ＋ 抗機櫃故障）→ Availability Set
   這題的限制條件（必須同一座資料中心）直接排除了 Availability Zone。Availability Set 正是為此設計：平台自動把 VM 分散到最多 3 個 Fault Domain（"share a common power source and network switch"，防機櫃跳電）與 20 個 Update Domain（"can be restarted at the same time"，且*"only one update domain is restarted at a time"*，防維護重啟全滅）。額外好處是 Learn 明載 "Availability sets provide lower VM-to-VM latency than availability zones because the VMs are placed in closer physical proximity"——低延遲需求也一併滿足。
   誠實揭露此設計的殘餘風險：官方同時警告 "Availability sets are still susceptible to certain shared infrastructure failures, such as datacenter-level network outages"。所以正確的架構師行為是——採用方案 B，但在架構決策紀錄 (ADR) 中明確標註「資料庫層的殘餘風險是資料中心級故障，此風險由低延遲需求換來，需以跨區域備份／Azure Site Recovery 補位」，而不是假裝這個風險不存在。

4. 需求 4（零公開 RDP ＋ 零硬編碼憑證）→ Bastion ＋ Managed Identity ＋ Key Vault
   Bastion 官方原文："your virtual machines don't need a public IP address"；Managed Identity 官方原文："You don't need to manage credentials. Credentials aren't even accessible to you." 兩者合起來把「攻擊面」與「機密外洩面」同時歸零。範本中的密碼參數標記 @secure() 則確保值不會被寫進部署歷史記錄。

❌ 陷阱選項深度覆盤

• 方案 A 陷阱（四個錯誤全中）：

  • 擴展維度錯：用 Scale Up 應對流量尖峰是垂直擴展，官方明載它 "might also require a restart of the VM" 且 "is limited by the availability of larger hardware"——雙十一當天重啟前端服務，等於自己製造中斷；而且 Azure Autoscale 根本不支援垂直擴展，只能自己寫腳本，把中斷寫進自動化。
  • SLA 認知錯：「把 1 台 VM 放進一個 AZ」拿不到 99.99%。Learn 原文毫不留情："By itself, a zonal VM isn't resilient to zone outages." 單一 VM（Premium SSD）的承諾是 99.9%，差了兩個數量級的年度停機時間。
  • 容錯設計缺失：資料庫叢集「同一個 AZ、不加設定組」＝ 完全沒有 FD / UD 分散，一個機櫃跳電或一次平台維護就可能全滅。
  • 資安全面失守：Public IP ＋ 開放 3389 是最經典的暴力破解與勒索軟體入口；連線字串寫進 Custom Script Extension 屬於硬編碼憑證，官方明指這是 "a known source of security issues and outages"。

• 方案 C 陷阱（每一項都是似是而非的「常見誤解」）：

  • 「Scale Set 本身就有跨機房高可用」是錯的：Learn 原文 "Virtual machines in a scale set can also be deployed into multiple availability zones, a single availability zone, or regionally" ——不指定 zones 就是 regional，Learn 另處補刀："Nonzonal VMs might be placed in any availability zone within the region. If any availability zone in the region experiences an outage, nonzonal VMs might be in the affected zone and can experience downtime." 這正是 Part 3 真題 2 的考點。
  • 「Scale Set 再加一個 Availability Set 更保險」是架構上的錯：Scale Set 與 Availability Set 是兩種互斥的編制機制，Scale Set 內部已由平台管理容錯／更新網域（Flexible 模式以 platformFaultDomainCount 控制），不存在「把 Scale Set 執行個體塞進 Availability Set」這種疊加操作。這是把兩個相似名詞誤當成可堆疊功能的典型症狀。
  • Proximity Placement Group 是反向操作：它是為了降低延遲而把 VM 擺得更近，Learn 明確警告 "proximity placement means that an outage of the datacenter can affect all of the VMs in the group"——它減少而非增加容錯，不能同時宣稱「兼顧容錯」。
  • 生產環境用 Spot VM 是致命錯誤：官方原文 "there's no SLA for these VMs. An Azure Spot Virtual Machine offers no high availability guarantees"，且 30 秒通知就驅逐。把雙十一的前端與交易資料庫放在 Spot 上，是把營收押在 Azure 當下的閒置容量上。Advisor 也不是驅逐監控工具（Day 6 已釐清：Advisor 只給建議）。

• 方案 D 陷阱：

  • 「機器夠多就有 99.99%」是錯的：SLA 是拓撲條件，不是數量條件。20 台全在同一個 Availability Set，上限就是 99.95%，多加 100 台也不會變成 99.99%——因為它們仍然共享同一座資料中心的基礎設施。
  • 手動開關機 ＝ ClickOps ＋ 組態漂移：需求明寫「不要有人守著 Portal」。手動維運 20 台機器，除了人力成本，最大的風險是 17 台機器在多次開關後組態逐漸不一致（Configuration Drift），尖峰當天才發現其中幾台的應用程式版本是舊的。
  • Region Pair 誤用：Region Pair 的定位是災難復原（Day 2 已釐清），跨地理區域部署與需求 3「必須同一座資料中心的低延遲」直接衝突，DBA 的同步延遲要求會立刻破功。
  • 憑證寫進共用自訂映像是最糟的硬編碼形式：一份映像複製到 N 台機器，等於把同一組長期憑證散佈到 N 個攻擊點，且輪替時必須重建映像並重新部署所有機器——爆炸半徑隨機器數線性放大。

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

本段共 5 題：真題 1–3 透過 examtopics-az900-search skill 定位並以 headless 瀏覽器讀取討論頁的 data-answers-tally 真實票數（不採用頁面上的靜態百分比樣板），再逐一與 Microsoft Learn 交叉驗證；真題 4–5 取自 2020 年 gratisexam 111 題歷史題庫，已過「已知過期考點」篩檢。全部改寫為 Titan 科技情境，引用來源一律指向 Microsoft Learn。

📝 AZ-900 高頻真題 1：加記憶體與 CPU 的正確術語（ExamTopics Q90 改編）

題目情境：

Titan 科技的財報結算系統跑在一台 Azure 虛擬機器上。每季結算時，DBA 發現該 VM 的記憶體與 CPU 全部滿載，於是把它的尺寸從 Standard_D2s_v5 調整為 Standard_D16s_v5，讓同一台機器獲得更多記憶體與 vCPU。請問這個動作對應的正確術語是什麼？

• A. 敏捷性 (agility)
• B. 垂直擴展 (vertical scaling)
• C. 水平擴展 (horizontal scaling)
• D. 彈性 (elasticity)

考點拆解與解析（架構師推理鏈）

• 正確答案：B. 垂直擴展 (vertical scaling)
• 步驟 1 — 關鍵字識別：題幹兩個決定性線索是「同一台機器」與「更多記憶體與 vCPU」。維持執行個體數量不變、增加單一執行個體的容量 → 這在官方定義中只有一個名字。
• 步驟 2 — 核心考點定位：屬於 Describe Cloud Concepts（占比 25–30%）領域的擴展術語辨識題。一句話規則：動「規格」是垂直，動「台數」是水平。
• 步驟 3 — 陷阱識破（逐選項排除）：
  • A. agility（敏捷性）錯：Agility 指的是「快速回應變化、快速佈建資源的能力」，是雲端的效益而非擴展術語。它不描述「加記憶體或 CPU」這個具體動作。
  • C. horizontal scaling 錯：官方定義為 "an increase or decrease of the number of resource instances"，題幹明確是同一台機器，台數沒變。
  • D. elasticity（彈性）錯：Elasticity 的核心是「自動」依短期需求增減。題幹是 DBA 手動調整尺寸，且 Azure Autoscale 官方明載 "does not support vertical scaling"——所以這個動作在 Azure 上根本不可能是自動彈性的產物。
• 步驟 4 — 關聯官方最佳實踐：垂直擴展的代價寫在官方文件裡（"might also require a restart of the VM"、"limited by the availability of larger hardware"）。因此生產環境的正確做法是：能改成無狀態 ＋ 水平擴展的，就不要靠垂直擴展硬撐；財報結算這類短期批次型尖峰，更適合排程式 Autoscale 或改用 PaaS。
• ⚠️ 社群分歧誠實揭露：原題措辭為「Which term represents the ability to increase the computing capacity of a virtual machine by adding memory or CPUs?」。社群票數為 B 39 票（唯一有效選項，data-answers-tally 實測），最高讚同留言（rrfatesingh，37 upvotes）與次高（phuctran，24 upvotes，Selected Answer: B）、Stasheck（11 upvotes）都明確支持 B。但確實存在反對意見：留言者 petebear55 主張答案應為 A (agility)，理由是題目問的是「WHICH TERM（哪一個術語）」而非「哪一種擴展方式」，認為這是刻意誤導的紅鯡魚；另一名 aramosme 附議「Agility is correct」。兩者各僅 1 upvote，論據薄弱且與官方定義衝突，但由於原題英文措辭確實不夠精確，這