【Day 5】ARM Templates & Bicep：基礎架構即程式碼 (IaC) 的精髓 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★☆☆☆
核心考點：Infrastructure as Code (IaC), Declarative (宣告式) vs Imperative (命令式), ARM Templates (JSON 結構與五大區塊), Azure Bicep (專屬 DSL), AWS CloudFormation ↔ ARM Template 對照, AWS CDK ➔ Bicep 抽象演化, 冪等性 (Idempotency), 部署模式 (Incremental vs Complete) 與爆炸半徑, 範本機密防護 (Key Vault / SecureString), What-If 變更預覽 (對照 AWS Change Sets)

🎯 前言與今日目標

今天更新了撰文規則，使用的是 ANTIGRAVITY 2.0 也就是以agent mode 為主的生成文章，對標 kiro-ide 就是agent focus 。 並擷取了一段 aws saa domain1 的影片解說文字，增加詳細程度，

Hi, and welcome back. Let's begin with the first task statement from Domain one Design Secure Access to AWS Resources. We just mentioned that security is one of the biggest and earliest considerations you will make when designing an architecture. This includes defining how people, tools, and applications you build will access the necessary AWS services and your data. This could involve determining not only who or what can launch or terminate your resources but also managing how and when access is given along with operational permissions and almost anything else that would involve calls to the services. In the course introduction we mentioned the importance of understanding fundamentals specifically the Shared Responsibility Model, the AWS global infrastructure, and different AWS service resilience. This task statement covers securing access to your AWS resources and securing access to services in different types of cloud environments. Ensure you know the differences between public, private, hybrid, and multi-cloud environments and how to design secure access to all of them. One area that is often overlooked when studying for this certification exam is AWS accounts. AWS accounts may seem too basic to take the time to understand, but I consider it part of the required, need-to-know fundamentals for AWS. You must understand what accounts are and how they work to ensure you have secure access to your AWS resources. Back to our fundamentals. What level of service is AWS IAM? Zonal, regional or global? IAM is a global AWS service that secures any data in the AWS IAM database across all AWS Regions. Ensure you understand IAM. Review the best practices for account root user security, applying the principle of least privilege, and multifactor authentication. AWS accounts begin with a single account root user with full permissions. So why is this a risk to use the account root user? Well, these account permissions cannot be changed or modified and if this account root user is compromised then so is the whole AWS environment. One way to secure the account root user is to add multifactor authentication. But what else could we implement to secure our AWS account? How about adding another user with more limited permissions instead of using the account root user? When we add new users to our AWS account, those new users will be different people and need different levels of access. What level of permissions do new IAM users have in your AWS account? IAM identities start with no permissions but permissions can be granted. Dive deeper into IAM users, groups, and roles and what goes into deciding between which to use and how they might be combined. Understand how using the principle of least privilege limits your blast radius. Here are a few questions to consider. How do you create IAM users, groups, and roles? What are their strengths and limitations? And what scenarios would dictate possibly switching between the various user group and role-based permissions? Along with those identities, make sure you know how IAM and other AWS services give you the ability to secure the necessary credentials and best practices for handling those credentials. Look at various methods of assuming roles including assigning roles to AWS services. Understand how to use AWS Security Token Service within and across accounts, and how roles are used with federations. Your users might already have identities outside of AWS such as in your corporate directory. If those users need to work with AWS resources or work with applications that access those resources then those users will need security credentials. You can use an IAM role to specify permission for users whose identity is federated from your organization or third party identity provider. Do you know how to design and configure active directory to federation access to AWS IAM roles or users? Also dive into the best practices for controlling your application's access to AWS APIs. When should you hard code credentials into your application? The answer to this is never, but know the other ways to enable API access and dive deeper into IAM policies. For this certification, you do not need to know how to write advanced policies, but you should be able to read and interpret policy documents. Learn the major parts of a policy statement what's required, and what are the ways in which the policies provide granularity with permissions. For this exam, learn the major parts of a policy statement, what is required, and the ways in which the policies provide granularity with permissions. Make sure you also understand IAM decision logic when evaluating policies including how that will affect an identity with multiple policies attached. Also ensure you know the appropriate use of resource policies for AWS services. What is a policy? Well, it's an object in AWS that when associated with an identity or resource defines their permissions. The two types of policies are identity based policies which are attached to an IAM user group or role. These policies give you the ability to specify what that identity can do. Its permissions. With identity policies, we control what resources that identity can access. With resource policies, we control who can access the resource. So resource based policies are attached to a resource such as an Amazon S3 bucket, Amazon SQS queues, VPC endpoints, AWS Key Management Service encryption keys to specify who has access to the resource and what actions they can perform on it. And bucket policies are structured differently compared to the structure of identity policies. The difference is the principle part of the policy. The principle part of a resource policy defines which principles are affected by this resource policy. And lastly, understand the methods, services and tools available that help you create traceability for access to AWS resources. Traceability helps to monitor, alert and audit actions and changes to your environment in real time. It also helps to integrate log and metric collection with systems to automatically investigate and take action. Just as you need to be aware of the performance and behaviors of your application components. You also need to have insight into who and what has access to your account resources and data. You will be tested on designing security strategies for multiple AWS accounts, know how to gain that visibility, how to enforce security standards, and how to alert and automate based on that data. Ensure you understand AWS Control Tower, AWS Organizations and service control policies. Learning to design secure access to the resources is an important step in learning how to prioritize security at every step. Take your time when learning these topics and get practice with both the designing and implementation whenever possible. Let's get started with our first walkthrough question. I'll see you in the next video.

在 Day 4 中，我們介紹了 Azure 的五大管理工具（Portal、CLI、PowerShell、Cloud Shell、Mobile App），並理解了它們背後全部匯流至 Azure Resource Manager (ARM) 控制平面的核心原理。

但當你從基礎操作邁向架構設計時，必須思考一個根本性的問題：「當系統規模擴大到數十個微服務、數百個雲端資源時，我們該如何保證每次部署都安全、精確、可被審計且絕對一致？」

想像一個真實的雲端維運場景：
Titan 科技即將為跨國電商核心業務，在全球三個不同的 Azure 區域（East US、East Asia、North Europe）分別建立「開發 (Dev)」、「測試 (Test)」與「生產 (Prod)」環境。每個環境都包含 1 組虛擬網路 (VNet)、3 個子網路 (Subnet)、多組安全性規則 (NSG)、數台負載平衡虛擬機器 (VM) 以及加密儲存體帳戶。

如果這套架構由工程師在 Azure Portal 上手動點擊（Manual ClickOps）建立：

• 每套環境至少需要點擊 100 次以上，三個環境就超過 300 次點擊。
• 只要工程師在生產環境手滑漏勾了一個 NSG 連接埠，或者在子網段打錯了一個 CIDR 數字，就會引發致命的跨環境 Bug，甚至是嚴重的資安破口！
• 更嚴重的是：手動點擊無法版控、無法審查，出了事無法一鍵回滾，也無法向資安稽核員出具架構變更軌跡！

這正是雲端架構設計中最核心的基石——Infrastructure as Code (IaC，基礎架構即程式碼)！

在 AWS 生態系中，架構師會使用 AWS CloudFormation 或以 TypeScript/Python 編寫的 AWS CDK；而在 Azure 世界裡，微軟的原生 IaC 王牌是基於 JSON 的 ARM Templates，以及專為雲端打造的新一代領域專用語法 Azure Bicep！

今天 Day 5，我們將以媲美原廠架構培訓的深度，帶你徹底打通雙雲 IaC 的底層機制、語法解構、安全性最佳實踐，以及 AZ-900 考卷上所有關於自動化治理的必考題！

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

🔄 1. 雙雲 IaC 抽象層演進：從「JSON 地獄」到「現代化抽象」

在早期，AWS 與 Azure 都是以宣告式範本起家：

• AWS 推出了 CloudFormation Templates（支援 JSON 與 YAML）。
• Azure 推出了 ARM Templates（以 JSON 為核心標準）。

但純手寫宣告式 JSON 存在巨大的工程痛點（被工程界稱為 JSON Hell）：

1. 語法極度冗長 (Boilerplate)：宣告一台簡單的 VM 往往需要上百行 JSON。
2. 無原生註解支援：標準 JSON 不允許寫註解，維運人員難以記錄架構設計決策。
3. 字串函式難以除錯：在 JSON 中做字串拼接或動態傳參時，語法極其晦澀（AWS 的 {"Fn::Sub": "..."} vs Azure 的 "[concat('app-', parameters('env'), '-', uniqueString(resourceGroup().id))]"）。

為了解決這個問題，雙雲龍頭各自演化出了截然不同、卻殊途同歸的高階抽象武器：

┌───────────────────────────────────┬───────────────────────────────────┐
│     🟠 AWS IaC 抽象演化架構       │      🔵 Azure IaC 抽象演化架構    │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【高階語言抽象層】                │ 【專屬 DSL 抽象層】               │
│  AWS CDK (TypeScript/Python/C#)   │  Azure Bicep (.bicep 領域語法)    │
│  • 物件導向 L1/L2/L3 Constructs   │  • 簡潔宣告式語法、模組化重用     │
│  • 具備迴圈、條件式與邏輯判斷     │  • VS Code 智慧感知與型別檢查     │
├───────────────────────────────────┼───────────────────────────────────┤
│               │                   │                 │                 │
│               ▼ cdk synth 合成    │                 ▼ bicep build 轉譯│
│               │ (Synthesize)      │                 │ (Transpile)     │
│               ▼                   │                 ▼                 │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【底層宣告式範本 Payload】        │ 【底層宣告式範本 Payload】        │
│  CloudFormation JSON / YAML       │  ARM Template JSON                │
├───────────────────────────────────┼───────────────────────────────────┤
│               │                   │                 │                 │
│               ▼ HTTPS API 請求    │                 ▼ HTTPS API 請求  │
├───────────────────────────────────┼───────────────────────────────────┤
│ 【雲端部署與管理引擎】            │ 【雲端部署與管理引擎】            │
│  AWS CloudFormation (Stacks)      │  Azure Resource Manager (ARM)     │
│  • 依賴分析與 Change Sets 變更集  │  • 依賴分析與冪等性 (Idempotency) │
│  • 建立與管理 AWS 實體資源        │  • 建立與管理 Azure 實體資源      │
└───────────────────────────────────┴───────────────────────────────────┘

💡 架構哲學深度對比：AWS CDK vs Azure Bicep

• AWS CDK 的哲學（通用語言 ＋ 多層物件封裝）：
  • AWS 認為開發者應該用熟悉的通用語言（TypeScript, Python, Java, C#, Go）來寫架構。
  • 引入了 Constructs 體系：
    • L1 (CFn Primitives)：1 對 1 對應 CloudFormation 資源（如 CfnBucket）。
    • L2 (Curated)：帶有安全最佳實踐預設值的封裝（如 s3.Bucket 自動啟用安全阻擋與方便的 .grantRead() 授權方法）。
    • L3 (Solutions/Patterns)：多資源組合的高階架構模式（如 ApplicationLoadBalancedFargateService 一行指令自動建置 VPC、ALB、ECS Fargate 與 DNS）。
  • 代價：需要安裝 Node.js 執行環境、管理語言套件依賴，且除錯時需理解合成後的 CloudFormation 結構。
• Azure Bicep 的哲學（透明 DSL ＋ 零依賴 ＋ 0-Day 支援）：
  • 微軟認為維運人員不需要承擔通用程式語言的複雜度，因此打造了專門針對 Azure 的領域特定語言 (DSL)。
  • 透明抽象 (Transparent Abstraction)：Bicep 不是黑盒子，所有語法與型別 100% 精準對齊 ARM 資源規範。
  • 零環境依賴：不需要裝 Node.js 或 npm，Azure CLI 原生內建編譯器，VS Code 安裝外掛即可享受頂級的 Auto-complete 智慧補全。
  • 0-Day 支援：只要 Azure 發布新服務或新 API 版本，Bicep 當天就能直接宣告，完全無需等待官方維護團隊編寫 L2 封裝！

📊 2. 雙雲 IaC 核心技術全維度對照表

💻 3. 程式碼結構解構：ARM JSON vs Azure Bicep

為了讓你具體感受兩者的差異，以下是部署一個標準 Azure 儲存體帳戶 (Storage Account) 的代碼對比：

傳統 ARM Template (JSON) —— 冗長、巢狀括號、無註解

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storagePrefix": {
      "type": "string",
      "defaultValue": "titanstore"
    }
  },
  "variables": {
    "uniqueStorageName": "[concat(parameters('storagePrefix'), uniqueString(resourceGroup().id))]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-01-01",
      "name": "[variables('uniqueStorageName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "properties": {
        "supportsHttpsTrafficOnly": true
      }
    }
  ],
  "outputs": {
    "storageEndpoint": {
      "type": "string",
      "value": "[reference(variables('uniqueStorageName')).primaryEndpoints.blob]"
    }
  }
}

現代 Azure Bicep (.bicep) —— 簡潔、具備註解、支援直覺字串插值

// 定義輸入參數，支援預設值與型別檢查
param storagePrefix string = 'titanstore'
param location string = resourceGroup().location

// 使用直覺的字串插值 (String Interpolation) 產生全域唯一名稱
var storageAccountName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

// 宣告儲存體帳戶資源
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

// 輸出建立後的 Blob 端點 URL
output blobEndpoint string = storageAccount.properties.primaryEndpoints.blob

💡 代碼精華解析（ARM/Bicep 的五大核心結構）：

1. $schema / API Version：指定範本遵循的 JSON Schema 規則與 Azure 資源提供者版本。
2. parameters (參數區塊)：範本的外部輸入口（如環境名稱 dev/prod、虛擬機大小），實踐「一份範本、多環境部署」的關鍵。
3. variables (內部變數區塊)：在範本內部運算的輔助數值（如使用 uniqueString 自動計算全域唯一的 S3/Blob 名稱）。
4. resources (資源區塊)：欲在 Azure 建立的實體資源陣列（VM、VNet、Database）。
5. outputs (輸出區塊)：部署完成後回傳的動態資訊（如新 VM 的 Public IP 或 Storage Connection String），供後續自動化 Pipeline 使用。

🛡️ 4. 架構師必備：IaC 安全性與部署控制最佳實踐

在大型企業架構中，只會寫範本是不夠的，必須懂得如何控制爆炸半徑 (Blast Radius) 與保護敏感資料：

1. 機密資料保護 (Never Hardcode Credentials!)：
   • 絕對禁止將資料庫密碼、私密金鑰直接寫死在範本中。
   • 最佳實踐：在參數中將密碼型態宣告為 @secure() (Bicep) 或 "type": "securestring" (ARM)，Azure 不會將其寫入部署日誌。更進階的做法是直接在範本中動態引用 Azure Key Vault（對應 AWS Secrets Manager / Parameter Store）的金鑰參照。
2. 部署模式 (Deployment Mode) 的風險控制：
   • Incremental 增量模式（預設）：如果 Resource Group 裡原本有 10 台 VM，你的範本只寫了 1 台，部署後原本的 10 台完全不會被更動。
   • Complete 完整模式：ARM 引擎會將整個 Resource Group 強制重置為與範本完全一致，不在範本中的那 10 台 VM 會被直接永久刪除！架構師必須在 CI/CD 中嚴格限制 Complete 模式的使用權限。
3. What-If 變更預覽（對照 AWS Change Sets）：
   • 在執行正式部署前，先透過 az deployment group what-if 進行變更預測。系統會以顏色標示即將建立 (Create)、修改 (Modify)、忽略 (Ignore) 或刪除 (Delete) 的資源，避免災難性誤操作。

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

1. Infrastructure as Code (IaC，基礎架構即程式碼)
   • 定義：以程式碼與設定檔來定義、配置與管理雲端基礎架構的方法論。
   • AWS 對照：AWS CloudFormation / AWS CDK。
   • 考點：核心價值在於提升部署重複性 (Repeatability)、保障跨環境一致性 (Consistency)、消除手動配置失誤 (Reduce Human Errors)、實現版本控制與審計 (Version Control)。
2. ARM Template (Azure Resource Manager 範本)
   • 定義：微軟原生基於 JSON 格式的宣告式基礎架構部署檔案。
   • AWS 對照：AWS CloudFormation JSON Template。
   • 考點：必考其檔案格式為 JSON；單一範本可同時定義跨多種不同服務的資源（VM + VNet + Storage）。
3. Bicep
   • 定義：微軟推出的領域專用語言 (DSL)，旨在簡化 ARM Template 的語法，部署時自動轉譯為 ARM JSON。
   • AWS 對照：AWS CDK / CloudFormation YAML。
   • 考點：具備宣告式語法、易讀性高、與 ARM 範本 100% 互通。
4. Idempotency (冪等性)
   • 定義：同一份範本不論執行 1 次還是執行 100 次，只要定義未變，系統最終狀態始終保持完全相同，不會重複建立多餘資源。
   • 考點：IaC 與自動化部署的核心保證。
5. Declarative (宣告式) vs Imperative (命令式)
   • 定義：宣告式描述「期望的最終狀態」（ARM/Bicep/CloudFormation/Terraform）；命令式逐步執行「具體操作腳本」（CLI/PowerShell/Bash）。
   • 考點：ARM Templates 與 Bicep 屬於宣告式語法。

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

🏛️ 情境背景：Titan 科技的 Dev/Test/Prod 多環境複製難題

Titan 科技即將推出核心支付閘道微服務。為了確保產品質量與交易安全，團隊規劃了三個標準環境：開發環境 (Dev)、整合測試環境 (Test) 與 線上正式環境 (Prod)。

每個環境都包含複雜的拓撲結構：1 組隔離的 Virtual Network、3 個子網段（Web / App / DB）、多組 Network Security Groups 防火牆規則、跨可用性區域 (AZ) 的 Virtual Machines 以及加密的 Storage Accounts。

在架構審查會議上，團隊成員提出了不同的部署提案：

維運主管：「上次產品上線，因為測試環境是用 Portal 手動點擊建立的，工程師漏開了一個安全性群組通訊埠，導致測試通過的程式碼一推到生產環境立刻全面崩潰！這次我們有三個環境，我要求一定要有防呆機制！」
資深工程師：「不如我寫一份 50 頁的 Word 操作手冊（Checklist），附上每一頁的截圖，讓三位工程師對著螢幕一步一步點？」
Linux 腳本專家：「我可以用 Bash 寫一個 500 行的命令式腳本，呼叫 az vm create 逐台建立，只是如果中間網路斷線，重跑會報錯，需要人工進 Portal 刪除半成品！」
CTO 轉頭看向你：「架構師，我們在 AWS 習慣用 AWS CDK 與 CloudFormation 確保環境一致性。在 Azure 這種跨環境部署到底該如何做到 100% 規格一致、消除人為失誤、具備冪等性，並且將所有基礎設施納入 GitHub 進行版本控制與審查？」

🧩 決策任務

身為 Titan 科技的 Chief Cloud Architect，你該如何制定標準基礎架構部署策略？

• A：撰寫詳細的 50 頁 Word 截圖手冊，嚴格要求維運團隊每個人在 Azure Portal 上對照操作三次，並在完成後以人工肉眼比對各環境設定。
• B：使用 Azure Resource Manager (ARM) Templates 或 Bicep 撰寫宣告式基礎架構即程式碼 (IaC)，將範本儲存於 Git 程式庫進行版本控管，並透過參數檔（Parameter Files）為 Dev、Test 與 Prod 部署出拓撲完全相同但配置（如 SKU 與實例數量）適配的環境。
• C：只在生產環境 (Prod) 建立一次實體資源，開發與測試團隊不需要真實雲端環境，直接在各自的本機電腦用 Docker 容器模擬即可。
• D：撰寫長達數百行的命令式 Bash 腳本，逐行呼叫 az vm create 與 az network vnet create，並要求工程師在腳本執行失敗時手動清理所有已建立的半成品資源。

🎯 解題拆解與解析

✅ 正解：B

❌ 陷阱分析與架構決策拆解：

• 選項 A 陷阱（手動 ClickOps 與人為失誤）：
  手動操作（Manual ClickOps）既耗時又無法避免人為疏忽。當環境包含數十種資源時，人工肉眼審查必定會遺漏配置細節，完全違背現代雲端架構的自動化與可重複性原則。
• 選項 B 正解（IaC 最佳實務：一致性、版本化、自動化、冪等性）：
  • 環境一致性 (Consistency)：如同 AWS CloudFormation/CDK，同一份 Bicep / ARM 範本定義了標準架構拓撲，消除 Dev/Test/Prod 之間的配置漂移（Configuration Drift）。
  • 參數化重用 (Parameterization)：透過分離的參數檔（如 dev.parameters.json 與 prod.parameters.json），可在開發環境使用平價的 VM 規格（如 Standard_B2s），在生產環境自動切換至高規格實例（如 Standard_D4s_v5），範本主體完全無需修改。
  • 版本控制與審計 (Version Control & Audit)：範本作為純文字檔直接託管於 Git，任何架構變更都必須經過 Pull Request (PR) 程式碼審查與稽核。
  • 冪等性保證 (Idempotency)：Pipeline 重複觸發不會產生意外副本或中斷服務。
• 選項 C 陷阱（環境不對等帶來上線風險）：
  單純依靠本機容器無法驗證 Azure 原生網路拓撲、安全性群組 (NSG)、受控身分 (Managed Identity) 與儲存體權限等雲端特有架構，無法取代真實的雲端測試環境。
• 選項 D 陷阱（命令式腳本缺乏冪等性與容錯力）：
  命令式腳本必須自行處理依賴關係、錯誤攔截與狀態復原；一旦中間步驟中斷，腳本無法自動計算差集，容易造成殘留垃圾資源或重複建立衝突。

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

以下精選 3 題 關於 ARM Templates、Bicep 與 IaC 的高頻核心真題進行深度拆解：

📝 考題 1：ARM Templates 的技術格式與多資源定義（多選題 / 下拉題）

【Question】 (改寫自 AZ-900 官方題庫高頻真題)
Titan 科技計劃利用 Azure 原生自動化工具來部署微服務基礎架構。關於 Azure Resource Manager (ARM) Templates，下列哪兩項敘述是正確的？（選兩項）

• A. ARM 範本是以 XML 格式編寫的結構化文件
• B. ARM 範本是以 JSON (JavaScript Object Notation) 格式編寫的文件
• C. 一個 ARM 範本在單一檔案內只能定義一種特定類型的 Azure 資源（例如只能放 VM）
• D. 可以在單一 ARM 範本中同時定義多個不同類型的 Azure 資源（例如同時定義 Virtual Network、Storage Account 與 Virtual Machines）
• E. ARM 範本僅能在 Windows 作業系統的伺服器上執行部署

• 正確答案：B、D
• 考點深度解析：
  • B 正解（JSON 格式）：微軟官方的 ARM Template 格式嚴格採用 JSON（非 XML 或 YAML）。(註：若使用 Bicep，最終也會轉譯為 JSON 送至 ARM)。
  • D 正解（多資源宣告能力）：在 ARM Template 的 resources 陣列中，你可以任意組合宣告各種服務（VNet、Subnet、NSG、VM、Database、Storage 等），並透過 dependsOn 指定資源建立的相依順序。
  • 選項 A 錯誤：不是 XML。
  • 選項 C 錯誤：ARM 範本天生就是為了整體架構部署設計，完全不限制單一資源類型。
  • 選項 E 錯誤：ARM 範本部署是透過 HTTPS REST API 送到 Azure 雲端核心，可以在任何作業系統（Windows/macOS/Linux）或 CI/CD pipeline 中透過 CLI、PowerShell、Portal 或 SDK 觸發。

📝 考題 2：跨環境自動化部署的最佳工具選型（情境單選題）

【Question】 (改寫自 AZ-900 官方題庫真題 Question 22 / Question 17)
Titan 科技每週需要為不同的開發專案快速部署 20 台具有相同規格、相同安全性設定與網路拓撲的虛擬機器。
身為架構師，你應該建議團隊使用下列哪一項解決方案，以達到最高效率、消除人為錯誤並確保每週部署的重複一致性？

• A. 每次手動在 Azure Portal 中依序建立 20 台虛擬機器
• B. 建立 Azure Management Group (管理群組) 來自動產生虛擬機器
• C. 使用 Azure Resource Manager (ARM) Template 定義基礎架構並重複執行自動化部署
• D. 使用 Azure Advisor 執行資源建立排程

• 正確答案：C
• 考點深度解析：
  • 自動化與重複一致性的唯一首選：當題目出現「重複部署 (Repeatable deployment)」、「相同配置 (Identical configurations)」、「消除手動人為錯誤 (Reduce manual errors)」、「自動化建立 (Automate creation)」時，標準答案一律鎖定 ARM Templates (或 Bicep / Infrastructure as Code)。
  • 選項 A 錯誤：手動在 Portal 重複操作 20 次非常耗時且極易發生配置錯誤。
  • 選項 B 錯誤：Management Group 是 Day 1 學過的「邏輯組織與權限/合規容器」，它本身不具備自動建立資源的功能。
  • 選項 D 錯誤：Azure Advisor 是提供架構優化建議（成本、安全性等）的分析顧問服務，不是部署工具。

📝 考題 3：IaC 核心特性與宣告式語法判斷（判斷題 / Hotspot）

【Question】 (改寫自 AZ-900 官方題庫精選)
針對以下關於 Infrastructure as Code (IaC) 與 Azure 範本技術 的陳述，請判斷敘述為 Yes (正確) 還是 No (錯誤)：

• 正確答案：
  • 1 ➔ Yes
  • 2 ➔ No
  • 3 ➔ Yes
• 考點深度解析：
  • 陳述 1 (Yes)：這正是 Declarative（宣告式）的標準定義——定義「What you want」而非「How to do it」。
  • 陳述 2 (No)：這是對「冪等性 (Idempotency)」的經典陷阱！冪等性的核心就是「執行一次與執行一百次的效果完全相同」。如果範本中的資源已經存在且配置一致，ARM 引擎會確認狀態後直接跳過或更新，絕對不會重複建立出同名資源或無故產生雙倍費用。
  • 陳述 3 (Yes)：Bicep 是微軟打造的透明抽象層（DSL），執行 bicep build 或透過 CLI 部署時，底層機制就是將 .bicep 轉譯為 ARM JSON 傳送至 ARM API。

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

🚀 今日總結與明日預告

🏆 今日 3 點速記精華

1. IaC 的四大核心價值：可重複性 (Repeatability)、環境一致性 (Consistency)、版本控制 (Git)、自動化消弭人為失誤。
2. 雙雲高階抽象演進：AWS CDK (cdk synth) ➔ CloudFormation，對應 Azure Bicep (bicep build) ➔ ARM Template (JSON)；兩者皆將高階語法轉譯/合成至底層宣告式範本供雲端引擎執行。
3. 架構安全與冪等性：宣告式語法確保冪等性 (Idempotency)；務必使用 securestring 或 Key Vault 保護機密，並謹慎評估 Incremental 與 Complete 部署模式的爆炸半徑。

🔮 明日預告

有了自動化部署的利器，雲端環境已經順利運轉。但身為首席雲端架構師，我們該如何隨時掌握雲端平台的健康狀態？又該如何主動獲得微軟官方針對成本、安全性、可靠性與效能的最佳化改善建議？

明天 Day 6，我們將深入剖析 Azure 兩大維運監控與架構優化神器——【Azure Advisor & Service Health】！