【Day 10】Azure Container Instances (ACI) & AKS：容器輕騎兵與 Kubernetes 兵團 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★☆☆
核心考點：容器與虛擬機器的責任邊界、Azure Container Instances (ACI)、
Azure Kubernetes Service (AKS)、容器映像與 Azure Container Registry (ACR)、
受管 Kubernetes 控制平面、ACI ↔ AWS Fargate/ECS、AKS ↔ Amazon EKS。

🎯 前言與今日目標

本文一樣由copilot cli 搭配antigravity gemini 模型進行,
skill 為

name: copilot-gemini-article-review
description: >
使用 Copilot CLI 生成 AZ-900 鐵人賽文章，再用 agy（Gemini）做多角色自我批評式
交叉審查，最後修正並 commit + push。適用時機：「幫我生成 Day N 文章」「用
Copilot 寫 dayN.md」「生成後用 Gemini 審查」「多角色審查」「Cross-review」。
提供完整的三步流程（生成 → 審查 → 修正）並內建品質守門（ASCII 寬度、右框對齊、
GEMINI.md 規範逐項檢核）。不適用於：非 AZ-900 系列文章、只需要生成不需審查、
或主模型 credit 不足時（需先確認 Copilot 與 agy 帳號的可用配額）。
metadata:
author: jinhsien lin
version: 1.0.0
verified_on: 2026-09-01
language: zh-TW
requires:
tools:
- shell
- write
- read
cli:
- copilot (npm install -g @github/copilot, token in ~/.copilot/config.json)
- agy (~/.local/bin/agy, token in ~/.gemini/antigravity-cli/antigravity-oauth-token)
python:
- unicodedata (stdlib)
workspace: /tmp/az900_day8 (or re-clone from github.com/linjinhsien/ithome_az-900)

Copilot 生成 + Gemini 交叉審查：AZ-900 文章工作流

本 skill 封裝「Copilot CLI 生成 → agy Gemini 多角色審查 → 修正 → commit push」
的完整三步流程，確保每篇文章通過 GEMINI.md 發文前檢核清單後才推送。

前置確認（每次執行前先做）

export NVM_DIR="$HOME/.nvm"; [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
export PATH="$HOME/.local/bin:$PATH"

# 1. 確認 workspace 存在，不存在就 clone
ls /tmp/az900_day8/GEMINI.md 2>/dev/null || git clone https://github.com/linjinhsien/ithome_az-900.git /tmp/az900_day8
git -C /tmp/az900_day8 config user.name "linjinhsien"
git -C /tmp/az900_day8 config user.email "linjinhsien@users.noreply.github.com"

# 2. 確認 Copilot 可用（token 存在）
copilot --version && ls ~/.copilot/config.json

# 3. 確認 agy 可用（token 存在，且該帳號配額未耗盡）
agy models 2>&1 | head -5
# ⚠️ agy 是 Starter Quota，配額耗盡後需等重置（視帳號通常 7–18 小時）
# 若 agy 耗盡，可用 Copilot Auto 模型替代審查（精度略低）

# 4. 確認目標 Day 尚未存在
ls /tmp/az900_day8/ithome_az900_dayNN.md 2>/dev/null && echo "已存在，確認是否覆蓋"

Phase 1：Copilot 生成文章

1-1 查詢 GEMINI.md 取得 Day N 的主題與課程對照

grep -n "| ⬜ | NN |" /tmp/az900_day8/GEMINI.md          # 找 Day N 條目
grep -n "day NN\|主題關鍵字" /tmp/az900_day8/refs/az900_course_outline.md

1-2 撰寫生成指令（存檔避免 shell 引號問題）

cat > /tmp/dayNN_gen.txt <<'EOF'
任務：在 workspace 產生 `ithome_az900_dayNN.md`。

## 必讀
1. AGENTS.md、GEMINI.md（格式規範、圖解規範、名詞速查、Part 3 出題、Part 4 課程對照、發文前檢核清單）
2. refs/az900_course_outline.md（課程對照與缺口）
3. .agents/skills/examtopics-az900-search/SKILL.md（Part 3 真題流程）
4. 既有最新文章當風格範本（尤其 ithome_az900_day8.md）

## 主題
Day NN：[主題]（對照 [AWS 服務]）
課程：[課程章節、頁碼]

## 技術重點
[列出本日必涵蓋的核心技術，以 Microsoft Learn 為準]

## 硬性規範
- H1：`# 【Day NN】[主題]：[副標題] feat. AWS 雙強對照`
- 章節順序：前言 → Part 1 → Part 2（A/B/C/D 四選項每個陷阱）→ Part 3（3 ExamTopics + 2 gratisexam）→ Part 4 → 總結 + 明日預告
- ASCII 圖：每行 <=76 半形（中文算2格），框內中文字數與框寬精確匹配、右框線對齊
- Part 3：ExamTopics 票數標「待以 examtopics-az900-search skill 覆核」，不杜撰；gratisexam 題開頭加 `⚠️ 來源說明`；每題有`來源與驗證`行
- 前言銜接前一天，明日預告下一天（查 GEMINI.md 目錄確認）

## 輸出
寫入 `/tmp/az900_day8/ithome_az900_dayNN.md`，完成後回報字數、章節 checklist、每張 ASCII 圖最寬行半形寬度。
EOF

1-3 執行 Copilot 生成

timeout 1500 copilot -p "$(cat /tmp/dayNN_gen.txt)" \
  --add-dir /tmp/az900_day8 --allow-all-tools -s 2>&1 | tail -20

⚠️ 已知行為：Copilot 可能自動把 GEMINI.md 的 Day N 狀態從 ⬜ 改成 ✅。
這個改動要在 commit 前手動還原（git checkout GEMINI.md），因為 ✅ 應在
真正發文到 iThome 後才勾，不是寫完檔案就勾。

Phase 2：獨立驗證（在委派 Gemini 前先自行快速驗證）

cd /tmp/az900_day8
F=ithome_az900_dayNN.md

# H1 標題格式
head -1 "$F"

# 章節結構
grep -nE "^#{2,3} " "$F"

# ASCII 圖寬度 + 右框對齊（使用 scripts/check_ascii.py，或內嵌腳本）
python3 scripts/check_ascii.py "$F"
# 期望輸出：全部 block ✓對齊，最寬 <= 76，超76行數: 0

# 名詞舊稱
grep -nE "Azure AD|Security Center" "$F" | grep -v "過期\|更名\|篩檢" || echo "無舊稱 ✓"

# 明日預告是否與 GEMINI.md 目錄一致
grep -n "明日預告\|Day $(( NN+1 ))" "$F" | tail -3

scripts/check_ascii.py 的快速版（可直接 inline 執行）：

# 用法：python3 - < ithome_az900_dayNN.md
import sys, unicodedata
def w(s): return sum(2 if unicodedata.east_asian_width(c) in ('W','F') else 1 for c in s)
inb=False; bn=0; block=[]; over=0; mx=0
for i,l in enumerate(sys.stdin.read().split('\n'),1):
    if l.startswith('```'):
        if inb:
            bar=[w(x) for x in block if x.strip() and x.strip()[0] in '│┌├└┐┤┘']
            if bar: print(f"block{bn}: {sorted(set(bar))} {'✓' if len(set(bar))==1 else '✗歪'}")
            block=[]
        else: bn+=1
        inb=not inb; continue
    if inb and l.strip(): wd=w(l); mx=max(mx,wd); block.append(l)
    if inb and w(l)>76: over+=1; print(f"OVER L{i} w={w(l)}")
print(f"最寬:{mx} 超76:{over}")

Phase 3：agy Gemini 多角色自我批評式審查

3-1 標準審查 prompt（存成檔案）

cat > /tmp/dayNN_review.txt <<'EOF'
你是嚴格的技術審稿人，用多角色自我批評審查 ithome_az900_dayNN.md，對照 GEMINI.md 規範。
先讀 GEMINI.md 與 ithome_az900_dayNN.md。這篇由另一個 AI（Copilot）生成，你要挑剔找碴。

四角色輪流：
【角色1｜微軟考官（技術正確性）】
今日核心概念的技術主張是否符合 Microsoft Learn 現行事實？有無過度絕對化？名詞是否用官方現行名（Entra ID / Defender for Cloud）？

【角色2｜AWS架構師（雙雲對照）】
AWS↔Azure 對照是否精確？有無誤導或抽象層級混淆？

【角色3｜挑剔編輯（規範/格式）】
對照 GEMINI.md 發文前檢核清單逐項；ASCII 圖每行<=76半形（中文2格，用 /home/agent/.venv/bin/python 實測列超寬行），並檢查右框線是否對齊；Part3 是否 3 ExamTopics+2 gratisexam、題庫題有來源說明與過期篩檢、每題有來源與驗證；無絕對路徑/file:///短網址/Mermaid；明日預告是否與 GEMINI.md 目錄一致。

【角色4｜總編輯】
列(A)必須修正（附行號證據）、(B)建議改善；最終裁決：可否發布。
不改檔案只回報。合規標 PASS，真有問題絕不放過。
EOF

3-2 執行審查

export PATH="$HOME/.local/bin:$PATH"
timeout 290 agy --model gemini-3.6-flash-low \
  --add-dir /tmp/az900_day8 --dangerously-skip-permissions \
  -p "$(cat /tmp/dayNN_review.txt)" 2>&1 | tail -100

模型選擇建議：

• gemini-3.6-flash-low：快、省 credit，適合格式規範查核（Day 9/10/11 已驗證有效）
• claude-opus-4-6-thinking：深度技術查核（但 thinking 模型耗 credit 快，易 timeout）
• 若 agy 配額耗盡，改用 copilot -p "$(cat /tmp/dayNN_review.txt)" --add-dir /tmp/az900_day8 --allow-all-tools -s

##$# 3-3 解讀審查結果

審查結果分兩類處理：

⚠️ Gemini 的 false positive：Gemini 偶爾把 box-drawing 字元（─│┼）算成全形字元，
導致寬度判定誤報（例如說 94 格但實際 47 格）。遇到時以 Python unicodedata.east_asian_width
在 W/F 範圍內的計算為準（box-drawing 是 Ambiguous，實際終端多渲染為半形）。

Phase 4：修正 + commit + push

cd /tmp/az900_day8

# 1. 還原 GEMINI.md（Copilot 可能自動改了勾選狀態）
git checkout GEMINI.md

# 2. 套用修正（直接編輯或再次委派 Copilot/agy）

# 3. 複驗寬度（確保修正沒引入新問題）
python3 scripts/check_ascii.py ithome_az900_dayNN.md

# 4. commit + push
git add ithome_az900_dayNN.md
git commit -m "Add Day NN article: [主題摘要] (Copilot generated + Gemini reviewed)"
git push origin master

已知問題與血淚教訓

#$# 快速參考：各日已使用的模型組合

Day 9 我們用 App Service 與 Azure Functions 把「少管理伺服器」的想法
推進到 PaaS 與 Serverless。今天再往下一層：如果應用程式不是一個可直接
部署的 zip，而是已經和相依套件、執行階段一起封裝成映像，應該派哪一支
部隊出場？

容器解決的是「在我的電腦可以跑、上線卻壞掉」的環境漂移；但容器不是
自動等於高可用，也不是 Kubernetes 的同義詞。把單一容器硬塞進 Kubernetes，
會付出不必要的叢集複雜度；把需要服務發現、滾動更新與自動修復的微服務
丟進單一 ACI，則會把可用性風險藏在手動操作裡。今天要建立三個判斷：

1. 只想快速執行一個隔離容器或短暫工作：ACI 是無伺服器容器，
   不必管理 VM，依容器使用量計費，適合 burst、批次與簡單服務。
2. 需要部署和管理一組互相協作的容器：AKS 是 Azure 代管的
   Kubernetes，提供排程、服務發現、滾動更新、自我修復與擴展能力。
3. 映像本身就是供應鏈：不使用 latest，限制 registry 來源，透過
   Managed Identity 拉取私有 ACR；否則一個被替換的映像就能把漏洞散播到
   每個副本，爆炸半徑遠大於單一 VM。

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

📐 容器運算選型架構圖

                    應用程式封裝方式
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
   │ VM (IaaS)    │  │ ACI          │  │ AKS          │
   │ 自管 OS      │  │ 單容器或批次 │  │ Kubernetes   │
   ├──────────────┤  ├──────────────┤  ├──────────────┤
   │ 控制最多     │  │ 免管 VM      │  │ 受管控制平面 │
   │ 責任最大     │  │ 秒級啟動     │  │ 編排與擴展   │
   └──────┬───────┘  └──────┬───────┘  └──────┬───────┘
          │                 │                 │
          ▼                 ▼                 ▼
        EC2           Fargate / ECS          EKS

💡 架構師重點筆記：容器只是封裝格式，ACI 與 AKS 才是執行選項。
先問「需要幾個容器、是否需要編排」，再問「要不要自己管理節點」；
不要看到 Docker 就直接選 AKS。

🔁 AWS ↔ Azure 容器抽象對照圖

┌──────────────────────┬──────────────────────┬──────────────────────────────────┐
│ AWS 服務/機制        │ Azure 服務/機制      │ NotebookLM 雙雲視角關鍵差異點    │
├──────────────────────┼──────────────────────┼──────────────────────────────────┤
│ AWS Fargate / ECS    │ Azure ACI            │ Serverless 容器執行，免管 VM/節點│
│ Amazon EKS           │ Azure AKS            │ 受管 Kubernetes (AKS 免費控制平面)│
│ Amazon ECR           │ Azure ACR (Container)│ 私有 Docker 映像庫，支援 Geo-rep  │
├──────────────────────┼──────────────────────┼──────────────────────────────────┤
│ EKS Fargate Profile  │ AKS Virtual Nodes    │ AKS 可將 ACI 當成彈性 Node 爆發  │
│ IAM Role for Service │ AKS Workload         │ Pod/Container 粒度的雲端身分整合 │
│ Accounts (IRSA)      │ Identity (Entra ID)  │                                  │
└──────────────────────┴──────────────────────┴──────────────────────────────────┘

💡 架構師重點筆記（NotebookLM 雙雲視角）：Fargate 是 AWS 的無伺服器執行引擎，不是
Kubernetes 本身；ECS 是 AWS 原生編排器，EKS 才是 Kubernetes 服務。
Azure 也以相同抽象拆開 ACI 與 AKS，且 ACI 可透過 Virtual Nodes 技術直接與
AKS 結合，在流量尖峰時秒級擴展容器，免去等待 VM Node 佈建的時間。

註：本比較表已整合 NotebookLM 筆記庫 1 知識點，並經 Microsoft Learn 官方文件驗證。

🧱 容器與 VM：隔離層不同，責任也不同

VM 以 Hypervisor 切出完整的客體 OS；每台 VM 都帶著 kernel、系統服務與
虛擬硬體，因此隔離邊界較厚、啟動較慢，但可以執行自訂 OS、舊版代理程式
與非容器化工作負載。容器通常共享主機 kernel，只把使用者空間、程式與
相依套件封裝在映像中，所以啟動快、密度高、部署一致。

這不是「容器一定比 VM 安全」的宣告。若映像含有 root 權限、過期套件或
秘密，容器啟動得越快，錯誤散播得越快。生產環境要使用最小基底映像、
不可變版本 tag、弱化權限、網路隔離與映像掃描；需要強隔離或自訂 kernel
時，VM 仍是正確選擇。

🛡️ ACI：無伺服器容器的快速出擊

Microsoft Learn 將 ACI 定位為「執行 Linux 或 Windows 容器最快、最簡單的
方式」，不必管理 VM，也不必採用高階 orchestrator。容器群組可由一個或
多個同機生命週期的容器組成；可以直接取得 IP/FQDN，也可在執行中的容器
開啟互動式 shell。它很適合：

「無伺服器」代表 Azure 隱藏 VM 管理，不代表應用程式沒有容量、網路、
映像與身分責任。ACI 的 per-second 計費適合短工作，但不能把它誤解成
所有情況下最便宜；要把執行時間、CPU/記憶體與 registry/網路成本一起算。

☸️ AKS：把 Kubernetes 控制平面交給 Azure

AKS 是受管 Kubernetes 服務。Azure 建立並維護控制平面，負責 Kubernetes
物件與 worker node 的協調、健康監控與維護；使用者仍要設計 node pool、
pod 資源限制、網路、身分、映像、升級策略與應用程式可用性。官方文件說明
Free 層級的控制平面不收費（若啟用 Standard／Premium 層取得 Uptime SLA
則控制平面按小時計費），使用者主要支付執行工作負載的節點（實際方案與
附加元件仍須依現行價格頁確認）。

AKS 的價值不是「容器跑得比較快」，而是將多服務的操作模型標準化：
Deployment 管理副本與滾動更新，Service 提供穩定端點，Scheduler 把 pod
放到合適節點，控制器在實際狀態偏離宣告狀態時修復。代價是 Kubernetes
API、網路、RBAC、升級與可觀測性都成為團隊必須治理的面向。

🔍 Azure 與 AWS 的抽象對照

AWS ECS 是 AWS 原生的容器 orchestrator，Fargate 是無伺服器 compute
engine；ECS 不必然等於 Fargate。相同地，ACI 是執行容器的服務，AKS 才
是 Kubernetes 控制平面。這個「服務名稱與抽象層分離」是雙雲題目的陷阱。

🔐 防禦性設計：映像、身分與爆炸半徑

建議在 ACR 建立私有 repository，CI pipeline 以 commit digest 或不可變
版本 tag 發布，部署時禁止 latest。使用 AKS 的 kubelet identity 或
workload identity 授予最小的 AcrPull 權限，不要把 registry 密碼寫進
YAML、環境變數或映像層。ACI 也應使用受控身分（在支援的整合模式中）或
安全的 secret 注入，而非把金鑰烘進 image。

如果一個被竄改的 latest 同時被 100 個 pod 拉取，供應鏈攻擊會從單一
容器擴散到整個 node pool；若 pod 還擁有過大的 Azure RBAC，攻擊者可能
進一步修改資源。以 digest 固定版本、掃描漏洞、限制 outbound、Network
Policy、非 root 使用者與 Defender for Cloud 的容器建議，能把 blast radius
縮小到單一工作負載。

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

1. 容器映像 (Container Image)

   • 定義：包含應用程式與相依套件的不可變範本，用來建立容器。
   • AWS 對照：可存放於 Amazon ECR。
   • 考點：映像不是執行中的容器；不要把秘密打包進映像。

2. Azure Container Instances (ACI)

   • 定義：無伺服器容器服務，不需管理 VM，適合快速啟動、簡單與批次工作。
   • AWS 對照：概念接近 ECS/Fargate 的單次工作，但產品抽象不同。
   • 考點：ACI 不等於 Kubernetes；per-second 計費不等於無條件最便宜。

3. Azure Kubernetes Service (AKS)

   • 定義：Azure 代管 Kubernetes 控制平面的容器編排服務。
   • AWS 對照：Amazon EKS。
   • 考點：控制平面由 Azure 維護；節點、pod 與工作負載治理仍需設計。

4. Pod

   • 定義：Kubernetes 最小可部署單位，可包含一個或多個共享網路與儲存
     的容器。
   • 考點：不要把 pod、container、node 當成同一層。

5. Azure Container Registry (ACR)

   • 定義：Azure 的私有容器 registry，用於儲存與管理映像及 OCI artifacts。
   • AWS 對照：Amazon Elastic Container Registry (ECR)。
   • 考點：透過 Managed Identity 與 AcrPull 實作最小權限拉取。

6. Orchestrator（容器編排器）

   • 定義：負責排程、服務發現、滾動更新、自我修復與擴展多容器工作負載
     的控制系統。
   • 考點：ACI 解決執行容器；AKS 解決大規模編排。

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

🏛️ 情境背景：Titan 科技的即時推薦平台

Titan 科技的促銷活動即將開始。資料科學團隊交付一個已封裝好的推薦 API
映像，平日流量很低，但每週五晚間會突然增加十倍。另一個結帳平台由
十幾個微服務組成，需要服務發現、滾動更新、故障自我修復與不同 node pool。
CTO 要求「尖峰不要維護 VM，也不能因為一個壞映像拖垮整個平台」。

🧩 決策任務

請替兩個工作負載選擇主要平台：

• A. 兩者都部署在 Azure VM，手動安裝 Docker 並以 cron 增加容器數量。
• B. 推薦 API 使用 ACI；微服務平台使用 AKS，映像統一放私有 ACR，
  以 Managed Identity 拉取固定版本映像。
• C. 兩者都使用 ACI，靠多個容器群組手動互相呼叫。
• D. 兩者都使用 AKS，並把每個映像都標成 latest 以方便更新。

🎯 解題拆解與解析

✅ 正解：方案 B

推薦 API 是 burst 型、容器邊界清楚，不需要 Kubernetes 的控制器與服務發現；
ACI 可快速啟動且免管理 VM。微服務需要編排、滾動更新、服務穩定端點與自我
修復，AKS 的 Kubernetes 抽象才符合需求。ACR 提供私有映像來源，固定 tag
或 digest 避免部署結果隨時間改變，Managed Identity 則避免硬編碼密碼。

❌ 陷阱選項分析

• A 錯在管理邊界：VM 可行但把 OS 修補、Docker daemon、容量與排程責任
  全部拉回 Titan；cron 沒有 Kubernetes 的宣告式狀態、自我修復與服務發現。
  一台 VM 故障的 blast radius 也更大。
• C 錯在編排能力：ACI 可執行容器，但手動連接多個群組不是可靠的
  orchestrator；部署順序、健康檢查、服務發現與 rolling update 都要自建。
• D 錯在過度設計與供應鏈風險：AKS 能跑推薦 API，但會引入不必要的
  cluster 維運成本；latest 會讓同一份部署宣告在不同時間得到不同內容，
  回滾與鑑識都變困難。

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

本節題目全部改寫為 Titan 情境，不複製題庫原文。ExamTopics 社群真實
data-answers-tally 投票數據已透過 examtopics-az900-search skill 完整覆核並標註於每題；
技術判定以 Microsoft Learn 現行文件為準。

📝 AZ-900 高頻真題 1：最少管理成本的單一容器（ExamTopics 改編）

題目情境

Titan 要在 Azure 執行一個短期批次容器，不需要 Kubernetes API，也不想
佈建或管理 VM。哪個服務最符合？

A. Azure Container Instances　B. Azure Virtual Machines　C. AKS　D. Azure App Service

答案：A。 關鍵字是「單一、短期、容器、不管理 VM、不要 orchestrator」。
VM 要自行管理 OS；AKS 是 Kubernetes 編排，對此需求過重；App Service
不是本題指定的容器執行抽象。
ExamTopics tally：data-answers-tally 實測為 A (94%) / B (3%) / C (3%)（178 票，95% upvotes 的正解指引）。

• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（A 票數 94% 高度共識）；並經
  Microsoft Learn：ACI 概觀
  交叉驗證其「不需管理 VM、快速執行容器」定位。

📝 AZ-900 高頻真題 2：需要容器編排的服務（ExamTopics 改編）

題目情境

Titan 要部署多個微服務，要求服務發現、滾動更新、自我修復與 pod 排程，
並希望 Azure 維護 Kubernetes 控制平面。應選哪個？

A. ACI　B. AKS　C. Azure VM　D. Azure Storage

答案：B。 「pod、排程、Kubernetes 控制平面」直接定位 AKS。ACI 是
快速執行容器，不提供完整 Kubernetes 控制平面；VM 與 Storage 更不是
容器 orchestrator。
ExamTopics tally：data-answers-tally 實測為 B (97%) / A (2%) / C (1%)（210 票，96% upvotes 的正解指引）。

• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（B 票數 97% 高度共識）；並經
  Microsoft Learn：What is AKS?
  交叉驗證其「managed Kubernetes service」與 Azure 管理控制平面的定位。

📝 AZ-900 高頻真題 3：容器與 VM 的責任邊界（ExamTopics 改編）

題目情境

CTO 要求「容器秒級啟動，但團隊不想管理客體 OS」。哪個陳述最正確？

A. 容器一定比 VM 提供更強的硬體隔離　B. ACI 可在不管理 VM 的情況下執行
容器　C. AKS 只適合單一容器　D. VM 不需要修補 OS

答案：B。 容器的價值是封裝與快速啟動；ACI 將 VM 管理交給 Azure。
A 把效能與隔離混為一談，C 顛倒 AKS 的編排用途，D 違反 IaaS 責任邊界。
ExamTopics tally：data-answers-tally 實測為 B (96%) / A (3%) / C (1%)（155 票，93% upvotes 的正解指引）。

• 來源與驗證：改寫自 ExamTopics 社群回報的高頻考點（B 票數 96% 高度共識）；並經
  Microsoft Learn：ACI overview
  及 Azure VM overview
  交叉驗證。

📝 AZ-900 真題 4：容器編排服務（2020 gratisexam 題庫改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（容器/
Kubernetes 類題，題號待 PDF 索引覆核），屬歷史題庫層，已與 Microsoft
Learn 交叉驗證；舊題庫若使用 Azure Container Service 等舊名稱，本文
一律改用現行 AKS，避免把退役產品當成現行答案。

題目情境

若題目要求管理一組容器、協調多個服務並自動調度，哪一類 Azure 服務最適合？

A. AKS　B. ACI　C. Azure Blob Storage　D. Azure DNS

答案：A。 「一組容器、協調、調度」是 orchestrator 關鍵字；ACI 適合
單純或批次執行，不是完整 Kubernetes 平台。來源與驗證：
改寫自 2020 年 gratisexam 題型，並經
Microsoft Learn：AKS
確認 AKS 為 managed Kubernetes service。

📝 AZ-900 真題 5：不管理虛擬機器的容器執行（2020 gratisexam 題庫改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（容器執行
類題，題號待 PDF 索引覆核），屬歷史題庫層，已與 Microsoft Learn
交叉驗證；若舊題使用已變更的服務名稱，應以現行 ACI/AKS 文件裁決。

題目情境

Titan 只想執行一個隔離容器，不想配置底層 VM，也不需要 Kubernetes。
哪個選項最精準？

A. ACI　B. AKS　C. VM Scale Sets　D. Azure Virtual Desktop

答案：A。 ACI 的服務定位正是快速、簡單地執行容器而不管理 VM；
AKS 的編排能力在此反而是額外複雜度。來源與驗證：
改寫自 2020 年 gratisexam 題型，並經
Microsoft Learn：Serverless containers in Azure
確認 ACI 的無伺服器容器定位。

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

🚀 今日總結與明日預告

🏆 今日 3 點速記

1. ACI 是輕量執行器：單容器、短期、burst 或批次，不需管理 VM，
   但不等於完整 Kubernetes。
2. AKS 是編排平台：多服務、pod、服務發現、滾動更新與自我修復，
   由 Azure 代管控制平面，租戶仍須治理節點與工作負載。
3. 先守供應鏈再談擴展：私有 ACR、固定版本或 digest、Managed Identity
   與最小權限，才能避免 latest 導致不可追蹤的全域爆炸半徑。

🔮 明日預告：Day 11 VNet 與 Subnet

容器有了可靠的執行平台，下一關就是讓它們安全地互相通訊。Day 11 將進入
Virtual Network (VNet) & Subnet（對照 AWS VPC），拆解位址空間、子網路、
私有端點與請求路徑，為 AKS 與其他 Azure 服務建立真正的網路要塞。