雲端工程師面試問題 — 30+ 道問題與專家答案
美國勞工統計局（BLS）預計到 2034 年每年將新增約 317,700 個電腦和 IT 職缺，而雲端工程位於這波成長的核心 — AWS、Azure 和 GCP 雲端工程師的中位數薪資為 $140,000–$143,000，取決於平台專業化方向 [1]。雲端工程師面試極具挑戰性，因為它融合了基礎架構知識、程式設計能力、資安意識和架構思維。本指南涵蓋了決定你是否能大規模設計、建置和營運可靠雲端基礎架構的關鍵問題。
核心要點
- 雲端工程師面試測試網路、運算、儲存和資安方面的廣泛知識 — 以及至少一個主要平台（AWS、Azure 或 GCP）的深度專業能力 [2]。
- 行為問題探究你如何處理正式環境事故、管理成本最佳化以及與開發團隊協作進行部署自動化。
- 技術問題從 VPC 網路基礎到多區域災難復原和容器編排等進階主題不等。
- 基礎架構即程式碼（Infrastructure-as-Code）— Terraform、CloudFormation — 的熟練掌握現在是基本期望，而非差異化因素。
行為問題
1. 請描述一次你在雲端環境中解決關鍵正式環境故障的經歷。
專家答案： 「我們在 us-east-1 的主要正式環境叢集發生了連鎖故障，原因是 Auto Scaling Group 將執行個體啟動到了一個 EBS 效能降低的可用區。我們的監控（Datadog）在 3 分鐘內對 p99 延遲升高發出了警告。我透過檢查 AWS Health Dashboard（確認 AZ 降級）進行分類，然後立即修改 ASG 以排除受影響的 AZ。同時，我在其餘 AZ 中擴展了健康執行個體以吸收負載。整個事故持續 22 分鐘，其中 8 分鐘對客戶可見。事後，我實施了 AZ 感知健康檢查和基於 AWS Health API 事件的自動 AZ 排除。事後分析揭示我們從未測試過單一 AZ 故障 — 我們現在每季進行一次故障演練。」
2. 描述你如何大幅降低雲端基礎架構成本。
專家答案： 「我接手了一個每月支出 $180K 且無成本治理的 AWS 環境。我首先使用 AWS Cost Explorer 識別主要成本驅動因素 — 40% 是 EC2，25% 是 RDS。我發現 30% 的 EC2 執行個體規格過大（t3.xlarge 以平均 8% CPU 運行），15 個開發/預發佈 RDS 執行個體全天候運行無自動關閉，Reserved Instance 覆蓋率僅為 20%。我使用 CloudWatch 指標調整執行個體規格，為非正式環境資源實施基於 Lambda 的排程，購買了覆蓋 70% 穩態運算的 Savings Plans，並將兩個 RDS 執行個體遷移到 Aurora Serverless。月度支出降至 $112K — 降低 38% — 且無任何效能下降。我建置了一個每週成本報告儀表板，由工程主管審查。」
3. 你如何確保雲端基礎架構變更不會影響正式環境？
專家答案： 「所有基礎架構變更都透過流水線：Terraform 撰寫程式碼，同儕評審 PR，CI（GitHub Actions）中透過 terraform plan 驗證，先套用到預發佈環境，驗證後再推廣到正式環境。我實施分支保護規則 — 不允許直接套用到正式環境。對於高風險變更（網路、IAM、資料庫），我要求兩人核准，並在低流量時段安排變更，在 PR 描述中記錄回滾計畫。我還使用 Terraform Sentinel 政策來防止已知危險模式 — 如將安全群組開放到 0.0.0.0/0 或建立未加密的 EBS 磁碟區。兩年內，我們實現了零次基礎架構變更相關故障 [3]。」
4. 請描述一次你將工作負載從本地遷移到雲端的經歷。
專家答案： 「我們將一個舊版 .NET 單體應用程式從託管資料中心遷移到 AWS。我主導了評估階段 — 記錄所有依賴關係、資料流和效能基準線。我們首先選擇了直接遷移（lift-and-shift）方式（EC2 + RDS）以降低風險，並制定了第二階段（容器化）的現代化路線圖。關鍵挑戰是資料庫遷移 — 一個 2TB 的 SQL Server 資料庫，要求幾乎零停機。我使用 AWS DMS（資料庫遷移服務）進行持續複寫，在凌晨 2 點的 30 分鐘維護視窗內完成切換，並透過列數和校驗和比較驗證資料完整性。遷移後，由於運算和資料庫位於同一區域，延遲降低了 15%。」
5. 描述你如何與開發團隊協作處理基礎架構需求。
專家答案： 「我作為內部平台工程師運作 — 建置自助服務能力，而不是充當工單處理者。我為常見模式（ECS 服務、RDS 資料庫、帶加密的 S3 儲存貯體）建立了 Terraform 模組，開發者可以在自己的儲存庫中使用。我每兩週舉辦一次辦公時間，開發者可以討論架構，並參加產品團隊的衝刺計畫以了解即將到來的基礎架構需求。當一個團隊想要部署新的微服務時，我提供了一個包含 Terraform、CI/CD 流水線、監控儀表板和運維手冊的範本儲存庫 — 他們在 4 小時內就擁有了正式環境就緒的環境，而不是之前的 2 週工單流程。」
6. 你在日常工作中如何處理雲端資安？
專家答案： 「資安不是一項獨立活動 — 它融入到每一個基礎架構決策中。我對所有 IAM 政策遵循最小權限原則，使用 IAM Access Analyzer 識別過度授權的角色。所有靜態資料使用 KMS 金鑰加密（敏感工作負載使用客戶管理金鑰），傳輸中的資料使用 TLS 1.2+。我持續執行 AWS Config 規則和 Security Hub 檢查，對常見發現（公開的 S3 儲存貯體、不受限的安全群組）實施自動修復。我還進行季度存取權限審查，並按 90 天週期輪換憑證。我們最近一次 SOC 2 稽核中零雲端相關發現 [4]。」
技術問題
7. 解釋 AWS、Azure 或 GCP 的共享責任模型。
專家答案： 「雲端供應商負責雲端『自身』的安全 — 實體基礎架構、虛擬機器管理程式、託管服務內部。客戶負責雲端『內部』的安全 — IAM 政策、網路組態、資料加密、應用層安全以及 EC2/VM 的作業系統修補。邊界根據服務類型而變化：使用 IaaS（EC2）時，你管理虛擬機器管理程式以上的所有內容；使用 PaaS（Lambda、RDS）時，供應商管理作業系統和執行階段；使用 SaaS 時，你主要管理存取權限和資料。最常見的安全失敗源於客戶對這個邊界的誤解 — 假設供應商保護的實際上是自己的責任，如 S3 儲存貯體政策或安全群組規則 [2]。」
8. 為使用關聯式資料庫的 Web 應用程式設計一個高可用多區域架構。
專家答案： 「該架構跨越兩個區域，採用主動-被動資料庫組態。在主要區域：Application Load Balancer 將流量分發到三個可用區的 Auto Scaling Group EC2 執行個體（或 ECS/EKS 容器）。資料庫是 Amazon Aurora，每個 AZ 都有唯讀複本。在次要區域：規模縮減（溫備）的相同基礎架構。Aurora Global Database 提供跨區域複寫，延遲通常不到 1 秒。Route 53 健康檢查監控主要區域 — 故障時 DNS 故障轉移將次要區域提升。靜態資源透過 CloudFront 提供，S3 來源透過 S3 跨區域複寫進行複製。RTO 目標：5 分鐘以內。RPO 目標：Aurora Global Database 下不到 1 秒。我還會實施 Route 53 Application Recovery Controller 以處理更複雜的故障轉移情境 [5]。」
9. 什麼是基礎架構即程式碼（IaC），你如何實施？
專家答案： 「IaC 將基礎架構組態視為原始碼 — 版本控制、審查、測試和自動套用。我在多雲環境中主要使用 Terraform（HCL），因為它與供應商無關，並且擁有最強大的模組和供應者生態系統。我的 Terraform 工作流程：按領域組織模組（網路、運算、資料），使用 DynamoDB 鎖定的 S3 遠端狀態，用工作區進行環境隔離，以及在建立 PR 時執行 terraform plan、在合併到 main 時執行 terraform apply 的 CI/CD 流水線。我使用 tflint 進行程式碼品質檢查、Checkov 進行安全掃描、Infracost 進行成本估算。對於純 AWS 環境，CloudFormation 或 CDK 是可行的替代方案，但 Terraform 的可攜性和狀態管理使其成為我的預設選擇 [3]。」
10. 解釋 Kubernetes 架構，以及何時選擇它而非 Serverless。
專家答案： 「Kubernetes 由控制平面（API 伺服器、etcd、排程器、控制器管理器）和執行 kubelet、kube-proxy 和容器執行階段的工作節點組成。Pod 是最小可部署單元。Deployment 管理無狀態工作負載；StatefulSet 管理具有穩定網路識別和持久磁碟區的有狀態工作負載。Service 提供網路（ClusterIP、NodePort、LoadBalancer）。選擇 Kubernetes 的情況：工作負載需要細緻的資源控制、團隊需要跨雲可攜性、工作負載具有一致的流量模式從而受益於預留運算，或應用程式有複雜的網路需求。選擇 Serverless（Lambda、Cloud Functions）的情況：工作負載是事件驅動的、流量不穩定且不可預測、團隊規模小無法管理叢集營運，或冷啟動延遲可接受。決策關乎營運複雜性與控制權的權衡 — Kubernetes 給你更多控制權但需要更多營運投入 [6]。」
11. 你如何為基礎架構部署實施 CI/CD 流水線？
專家答案： 「我的標準流水線：(1) 開發者將 Terraform 變更推送到功能分支。(2) GitHub Actions 執行 terraform init、terraform validate、tflint 和 checkov 進行靜態分析。(3) 對目標環境執行 terraform plan，plan 輸出作為 PR 評論發佈以便審查者查看。(4) 核准和合併後，terraform apply 自動在預發佈環境執行。(5) 預發佈驗證（手動或自動冒煙測試）後，透過手動核准閘道的獨立工作流套用到正式環境。我使用 OIDC 進行 AWS 認證（CI 中無靜態憑證），流水線有用於臨時環境的 terraform destroy 選項。狀態鎖定防止並行修改 [3]。」
12. 你在雲端環境中使用哪些監控和可觀測性策略？
專家答案： 「我實施三大支柱：指標（CloudWatch/Datadog 用於基礎架構和應用程式指標）、日誌（CloudWatch Logs 或 ELK/Loki 集中收集，使用結構化 JSON 日誌）和追蹤（AWS X-Ray 或 Jaeger 用於分散式追蹤）。告警方面，我採用基於嚴重等級的方法：P1（自動呼叫，影響客戶）、P2（Slack 告警，降級但可用）、P3（工單，下個工作日調查）。我使用黃金訊號 — 延遲（p50、p95、p99）、流量（請求/秒）、錯誤（錯誤率）和飽和度（CPU、記憶體、磁碟）。SLO（服務等級目標）定義目標可靠性 — 例如 99.9% 可用性、p99 延遲低於 500ms。從 SLO 衍生的錯誤預算決定何時優先考慮可靠性而非功能 [5]。」
13. 解釋 VPC 網路基礎知識以及你如何設計網路架構。
專家答案： 「VPC 是雲端區域內的隔離虛擬網路。我使用標準化 CIDR 方案設計 VPC：VPC 使用 /16，子網路使用 /20（每個 4,094 個 IP），跨可用區分佈。公有子網路（帶網際網路閘道路由）託管負載平衡器和堡壘機；私有子網路（NAT 閘道路由）託管應用程式執行個體；隔離子網路（無網際網路路由）託管資料庫。網路 ACL 提供無狀態邊界過濾；安全群組提供有狀態執行個體層級過濾。對於多 VPC 架構，我使用 AWS Transit Gateway 作為樞紐，而不是 VPC 對等連線，因為後者在超過 10-15 個 VPC 後擴展性不佳。我還實施 VPC Flow Logs 進行網路監控和故障排除，以及透過 Route 53 Resolver 進行混合環境的 DNS 解析 [4]。」
情境問題
14. 你公司的 AWS 帳單在沒有對應流量成長的情況下每月增長 15%。你如何調查？
專家答案： 「我會採取系統化方法：(1) 開啟 AWS Cost Explorer，按服務、區域和帳戶過濾，識別哪個服務在驅動增長。(2) 尋找新建立的資源 — CloudTrail 日誌顯示誰在何時建立了什麼。(3) 檢查常見浪費模式：孤立的 EBS 磁碟區、閒置的負載平衡器、被遺忘的測試環境，以及跨區域或跨 AZ 流量的資料傳輸成本。(4) 審查近期架構變更 — 是否有人啟用了將 TB 級資料傳送到 S3 的日誌功能？(5) 檢查 Marketplace 訂閱或自動續約的第三方服務。我會提交帶有優先級排序的修復計畫，顯示每個操作項的預估節省金額。應實施自動成本異常偵測（AWS Cost Anomaly Detection 或客製化 Lambda），以便更早發現未來的峰值。」
15. 開發團隊想從自己的筆記型電腦直接部署到正式環境。你如何引導他們採用更好的方法？
專家答案： 「我不會以『不行』開頭 — 我會先理解他們為什麼想這樣做。通常是因為部署流程太慢或太官僚。我會提出折衷方案：一個快速、自動化的流水線，從合併到 main 到正式環境部署不超過 10 分鐘。我會與他們一起（而不是替他們）建置流水線，使其擁有歸屬感，包含自動化測試和安全掃描閘道，並演示它比手動部署既快又安全。我會解釋筆記型電腦部署的風險 — 不可重現的建置、無稽核追蹤、無回滾能力和憑證暴露。一旦體驗過流水線，他們很少想回到原來的方式。你透過開發者體驗贏得採用，而非政策強制。」
16. 你被指派為新應用程式設計基礎架構，但需求模糊。你如何推進？
專家答案： 「我會提出五個澄清問題：(1) 預期的流量模式是什麼（穩定、突發、事件驅動）？(2) 資料駐留要求是什麼（單一區域、多區域、特定國家）？(3) 可用性目標是什麼（99.9%、99.99%）？(4) 資料儲存和保留要求是什麼（量、存取模式、合規性）？(5) 預算限制是什麼？有了這些答案，我就能設計合適的架構。我會從處理核心需求的最小可行架構開始，使用託管服務減少營運負擔（Aurora 替代自建 PostgreSQL，ECS Fargate 替代自建 EC2 叢集）。我記錄每個元件的擴展策略，以便無需重新設計架構即可成長。」
17. 尖峰時段發生資料庫故障轉移，但應用程式沒有自動重新連線。你調查什麼？
專家答案： 「常見原因：(1) DNS 快取 — 應用程式正在解析舊的資料庫端點。我檢查連線池是否遵守 DNS TTL（Aurora DNS TTL 為 5 秒，但許多連線池在作業系統或 JVM 層級快取 DNS）。(2) 連線池耗盡 — 池保持著過期連線且使用前不進行驗證。我檢查連線驗證查詢（SELECT 1）和閒置逾時設定。(3) 應用程式層級重試邏輯 — 如果應用程式在連線失敗時不重試，單次故障轉移會導致永久斷線。我會實施帶抖動的指數退避重試。(4) 故障轉移期間的安全群組或路由變更。立即解決方案是重啟應用程式 Pod/執行個體。長期方案是實施連線池健康檢查、DNS TTL 感知和適當的重試邏輯。」
18. 合規稽核要求你證明所有靜態資料都已加密。你如何證明？
專家答案： 「我會從三個來源收集證據：(1) AWS Config 規則 — 展示 encrypted-volumes、rds-storage-encrypted、s3-bucket-server-side-encryption-enabled 的活動規則及其合規狀態。(2) Terraform 程式碼 — 展示預設強制加密的 IaC 模組（EBS、RDS 和 S3 資源定義中的 KMS 金鑰參考）。(3) AWS Config 合規時間軸 — 顯示這些規則在稽核期間持續合規。我還會展示我們防止建立未加密資源的 Terraform Sentinel 或 Checkov 政策。對於稽核人員，我會準備一份摘要文件，將每個資料儲存映射到其加密方法、金鑰管理政策和合規證據。」
向面試官提的問題
- 公司使用哪些雲端平台，是否有多雲策略？（確定哪些平台技能最相關。）
- 基礎架構即程式碼的實務成熟度如何 — 有多少百分比的基礎架構透過程式碼管理？（揭示營運成熟度。）
- 雲端基礎架構的值班輪替是怎樣的？（關於工作生活平衡和事故頻率的實際問題。）
- 雲端團隊如何與應用程式開發團隊協作？（確定你是平台工程師還是工單處理者。）
- 每月雲端支出是多少，是否有 FinOps 實務？（表明你關注成本效率 — 每個招募經理都重視的特質。）
- 你們如何處理雲端中的資安和合規要求？（揭示資安成熟度和監管負擔。）
- 團隊當前面臨的最大基礎架構挑戰是什麼？（表明你想為解決實際問題做出貢獻。）
面試形式
雲端工程師面試通常跨越 1-2 週，包含 4-5 輪 [2]。第一輪是招募人員篩選（30 分鐘），涵蓋背景和雲端認證。第二輪是技術電話篩選（45-60 分鐘），包含雲端架構和網路問題。第三輪是系統設計練習，你需要在白板或共用文件上設計雲端架構。第四輪是實作練習 — 一些公司提供即時 AWS/Azure 環境，要求你排除故障或建置基礎架構。行為面試穿插在整個過程中。一些公司會增加程式設計輪（用於自動化指令碼的 Python 或 Go）。FAANG 公司會增加額外的系統設計和程式設計輪。
如何準備
- 取得認證。 AWS Solutions Architect Associate、Azure Administrator 或 GCP Associate Cloud Engineer 認證證明基礎能力並通過 HR 篩選 [2]。
- 練習系統設計。 為常見模式繪製架構圖：多層 Web 應用程式、事件驅動流水線、多區域災備。練習解釋權衡取捨。
- 精通網路。 VPC、子網路、路由表、安全群組、NACL、DNS、負載平衡器 — 網路問題出現在每次雲端面試中。
- 撰寫 Terraform。 準備一個包含你建置的 Terraform 模組的公開 GitHub 儲存庫。能夠結合程式碼範例討論你的 IaC 方法非常有說服力 [3]。
- 了解成本最佳化。 熟悉 Savings Plans 與 Reserved Instances 的區別、合理調整規格策略和常見浪費模式。
- 學習 Kubernetes 基礎。 即使職位不以 Kubernetes 為中心，也期望你理解 Pod、Service、Deployment 和 Ingress。
- 使用 ResumeGeni 建置 ATS 最佳化的履歷，突顯雲端認證、特定平台經驗（AWS/Azure/GCP）、IaC 工具和量化的基礎架構改善。
常見面試錯誤
- 記住服務名稱卻不理解架構。 知道 S3 是物件儲存還不夠 — 解釋何時使用 S3、EFS 與 EBS 及其權衡 [2]。
- 在設計中忽視成本。 每個架構都應考慮成本效率。為只有 100 個使用者的新創公司設計多區域、多 AZ、全冗餘架構說明判斷力不足。
- 不討論資安。 如果你的架構設計沒有提到 IAM、加密或網路分段，面試官會感到擔憂。
- 只熟悉一個平台而不了解替代方案。 如果你只了解 AWS，你至少應在較高層面了解 Azure 和 GCP 的對等服務。
- 忽略營運方面。 設計基礎架構而不討論監控、告警、日誌和事故回應是不完整的。
- 不提及 IaC。 如果你描述的是手動在主控台點擊操作，對於資深職位來說面試基本上就結束了 [3]。
- 不量化影響。 「我管理 AWS 基礎架構」太弱。「我管理每月 $150K 的 AWS 環境，服務 200 萬月活躍使用者，可用性達 99.95%」展示了規模和影響力。
核心要點
- 雲端工程師面試測試平台知識、架構思維、資安意識和營運成熟度 — 在所有維度做好準備。
- 系統設計練習是訊號最強的環節 — 練習繪製多層、多區域架構並清晰解釋權衡取捨。
- 基礎架構即程式碼和基礎架構 CI/CD 是中級和資深職位的基本期望。
- 使用 ResumeGeni 確保你的履歷突顯雲端認證、平台專業知識和量化的基礎架構指標。
常見問題
我應該首先取得哪個雲端認證？
AWS Solutions Architect Associate 是最廣泛認可且適用性最廣的。如果目標公司使用 Azure 或 GCP，優先選擇該平台的助理級認證。認證本身不如準備過程中獲得的知識重要 [2]。
雲端工程師的薪資範圍是多少？
根據平台專業化方向，中位數薪資在 $130,000 到 $143,000 之間。AWS 工程師平均 $140,000，Azure 工程師 $141,619，GCP 工程師 $143,000。頂級公司的資深和首席雲端工程師總薪酬達 $180,000–$250,000+ [1]。
我需要了解所有三個主要雲端平台嗎？
深入了解一個，其餘兩個在概念層面了解即可。大多數公司使用一個主要平台。理解跨平台的對等服務（EC2/Compute Engine/VMs、S3/Cloud Storage/Blob Storage）展示了廣度。
程式設計對雲端工程師有多重要？
重要且越來越重要。預期掌握 Python、Go 或 Bash 指令碼用於自動化。除非職位標註為科技公司的「Cloud Platform Engineer」或「SRE」，否則通常不要求完整的軟體開發技能（資料結構、演算法）。
我應該學 Terraform 還是 CloudFormation？
Terraform。它與雲端無關，有更大的社群，是跨產業的事實 IaC 標準。CloudFormation 知識對於重度 AWS 環境是加分項，但可攜性較差 [3]。
雲端工程師和 DevOps 工程師的區別是什麼？
有大量重疊。雲端工程師更注重基礎架構設計、佈建和最佳化。DevOps 工程師更注重 CI/CD 流水線、開發者工具以及連接開發與營運。許多職位混合了兩種職責。使用 ResumeGeni 為你目標的具體職位名稱定位履歷。
如何從系統管理員轉型為雲端工程師？
從雲端認證開始，將一個個人或小型工作專案遷移到雲端。儘早專注於 IaC（Terraform）— 這是從 GUI 點擊到思維方式的最大轉變。你的網路和作業系統知識可以直接遷移；在此基礎上添加雲端原生服務和自動化。
引用： [1] DataCamp, "Cloud Engineer Salaries in 2026: AWS, Azure, Google Cloud," https://www.datacamp.com/blog/cloud-engineer-salary [2] DataCamp, "Top 34 Cloud Engineer Interview Questions and Answers in 2026," https://www.datacamp.com/blog/cloud-engineer-interview-questions [3] HashiCorp, "Terraform Documentation," https://developer.hashicorp.com/terraform/docs [4] AWS, "AWS Well-Architected Framework," https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html [5] DigitalDefynd, "Top 50 Advanced Cloud Engineer Interview Questions," https://digitaldefynd.com/IQ/cloud-engineer-interview-questions/ [6] Kubernetes, "Kubernetes Documentation," https://kubernetes.io/docs/home/ [7] Bureau of Labor Statistics, "Computer and Information Technology Occupations," https://www.bls.gov/ooh/computer-and-information-technology/ [8] Coursera, "AWS Cloud Practitioner Salary: Your 2026 Guide," https://www.coursera.org/articles/aws-cloud-practitioner-salary
