GCP 面試題完全攻略：2026 年 50 道必考題與詳解

面試前你需要知道的事

Google Cloud 到 2026 年還是三大公有雲之一。根據各大人力銀行的數據，會 GCP 的工程師薪資中位數比一般後端工程師高出 15-25%。不管你應徵的是 雲端工程師、DevOps 工程師、資料工程師 還是 雲端架構師，面試幾乎都會碰到 GCP 的技術題。

這篇整理了 50 道最常見的 GCP 面試題，依七大領域分類，每題都附完整答案跟延伸學習資源。建議別只「背答案」，要搞懂背後的原理，因為面試官常常會追問「為什麼？」、「還有沒有別的方案？」

GCP 面試的常見形式

在台灣，GCP 相關面試通常分為以下幾種形式：

技術知識面試（30-60 分鐘）：直接提問 GCP 服務知識、概念解釋、服務比較
系統設計面試（45-90 分鐘）：給一個商業場景，要求用 GCP 服務設計架構
實作測驗（60-120 分鐘）：在 GCP Console 或 CLI 中實際操作，完成指定任務
白板/架構圖面試（30-60 分鐘）：畫出系統架構圖並解釋設計決策
情境問題（15-30 分鐘）：模擬故障排除或生產事件處理

這篇主要寫第一類「技術知識面試」的題目，不過答案的深度也夠你應付系統設計和情境問題。

面試考察的核心能力

面試官想看的不只是你會多少 GCP 服務，而是這四個面向：

基礎扎不扎實——能不能清楚講出核心概念（IAM、VPC、Storage Class）
會不會做技術選型——遇到需求能合理選服務，還講得出理由
有沒有實戰經驗——能舉具體例子、踩過什麼坑、怎麼解掉
有沒有全局觀——懂得在成本、安全、可靠性之間做取捨

如何使用這份攻略：

先快速瀏覽所有題目，標記你不確定的題目
針對弱點領域，點擊延伸學習連結深入閱讀
嘗試用自己的話回答每一題，模擬面試情境
最後用「常見追問題型」做最終練習

準備好了嗎？開始吧。

題目總覽

領域	題數	難度分布	重要程度
基礎概念	Q1–Q8	基礎	必考
Compute	Q9–Q16	基礎～中等	必考
Storage & Database	Q17–Q24	中等	必考
Networking	Q25–Q30	中等	常考
IAM & Security	Q31–Q36	中等～進階	必考
Kubernetes & Serverless	Q37–Q43	中等～進階	常考
Data & AI	Q44–Q50	進階	視職位而定

一、基礎概念（Q1–Q8）

Q1: 請說明 GCP 的資源階層架構（Resource Hierarchy）

答案： GCP 的資源階層由上到下為：Organization → Folder → Project → Resource。Organization 是最頂層，通常對應一個公司的 Google Workspace 或 Cloud Identity 網域。Folder 用來分組管理（例如按部門或環境），可以巢狀嵌套（最多 10 層）。Project 是資源的基本管理單位，所有 GCP 資源（VM、Bucket、Database 等）都必須屬於某個 Project。IAM 政策會沿著階層往下繼承，也就是說，你在 Organization 層級設的權限，會自動套用到底下所有 Folder、Project 和 Resource。

面試加分說法：Organization 層級可以設 Organization Policies（組織政策），例如限制資源只能建在特定 Region（constraints/gcp.resourceLocations），這在金融業、醫療業這類有合規要求的場景特別重要。

📖 延伸學習：GCP 入門 — 為什麼選擇 Google Cloud？

Q2: Region 和 Zone 有什麼差別？如何選擇？

答案： Region 是一個獨立的地理區域（例如 asia-east1 代表台灣彰化），每個 Region 內含多個 Zone（例如 asia-east1-a、asia-east1-b、asia-east1-c）。Zone 是最小的部署單位，每個 Zone 有獨立的電力與網路設施。怎麼選？延遲優先就選離使用者最近的 Region；要高可用性就把資源擺在同 Region 不同 Zone（跨 Zone 會自動故障轉移）；要災難復原就得跨 Region 部署。台灣這邊常用 asia-east1（彰化）當主要、asia-northeast1（東京）當備援。

📖 延伸學習：建立你的第一台 VM

Q3: GCP 專案（Project）的作用是什麼？一個專案能做到哪些事？

答案： Project 是 GCP 中最核心的組織單位，具有三個重要功能：資源管理（所有資源都歸屬於特定 Project）、帳單管理（每個 Project 綁定一個 Billing Account，方便成本歸屬）、以及 API 管理（必須在 Project 中啟用 API 才能使用對應服務）。每個 Project 有三個識別資訊：Project Name（可重複、可修改）、Project ID（全域唯一、不可修改）、Project Number（系統自動產生）。實務上建議用 環境分離策略：dev、staging、prod 各一個 Project，搭配 Folder 做組織管理。

📖 延伸學習：環境設定完全指南

Q4: 請解釋 GCP 的帳單架構，Billing Account 和 Project 的關係是什麼？

答案： GCP 的帳單架構為：Billing Account → Project（一對多）。一個 Billing Account 可以關聯多個 Project，但每個 Project 只能綁定一個 Billing Account。帳單相關的重要功能包括：Budget Alerts（預算警示，可設定多個閾值如 50%、90%、100%）、Billing Export（匯出到 BigQuery 做成本分析）、Committed Use Discounts (CUD)（承諾用量折扣，1 年或 3 年期）。在大型組織中，通常會用多個 Billing Account 來區分不同 BU（事業單位）的成本。

📖 延伸學習：GCP 成本優化完全指南

Q5: 什麼是 Google Cloud 的 Free Tier？包含哪些服務？

答案： GCP Free Tier 分為兩類：90 天 $300 美元試用額度（新帳號專屬，可使用任何服務）和 Always Free（永久免費額度，即使試用期結束後仍可使用）。Always Free 的重點項目包括：1 台 e2-micro VM（限 us-west1、us-central1、us-east1）、每月 5GB Cloud Storage（Standard 類別）、每月 1TB BigQuery 查詢處理量（外加 10GB 免費儲存）、每月 200 萬次 Cloud Functions 調用、每月 2M Cloud Run 請求。面試時聊到 Free Tier，代表你懂得怎麼控成本，這是企業很在意的能力。

📖 延伸學習：環境設定完全指南

Q6: gcloud CLI 是什麼？常用指令有哪些？

答案： gcloud 是 Google Cloud 的命令列工具，是 Cloud SDK 的核心元件。常用指令分類：設定類（gcloud init、gcloud config set project PROJECT_ID、gcloud auth login）；查詢類（gcloud compute instances list、gcloud projects list）；操作類（gcloud compute instances create、gcloud run deploy）。其他重要工具還包括 gsutil（Cloud Storage 操作）、bq（BigQuery 操作）、kubectl（GKE 叢集管理）。實務上建議善用 gcloud config configurations 管理多組設定檔，方便在不同 Project 之間切換。

📖 延伸學習：gcloud CLI 速查表

Q7: Cloud Shell 和本地安裝 Cloud SDK 有什麼差別？

答案： Cloud Shell 是 GCP Console 內建的免費線上終端機，提供一個臨時的 Debian VM（e2-small 等級），預裝了 gcloud、kubectl、terraform、docker 等工具，並提供 5GB 的免費持久性磁碟（$HOME 目錄）。好處是零設定、隨開即用，拿來快速操作或教學很方便。缺點是會閒置超時（20 分鐘沒動作就自動關閉）、每週有使用上限（50 小時），而且非持久性目錄的資料在 session 結束後就不見了。本地安裝 Cloud SDK 則適合日常開發、CI/CD 整合、需要穩定環境的場景。

📖 延伸學習：環境設定完全指南

Q8: 請解釋 Labels 和 Tags 在 GCP 中的差別

答案： Labels 是鍵值對（key-value pair），用於資源的組織、篩選和帳單分類。例如 env:prod、team:data、cost-center:marketing。大多數 GCP 資源都支援 Labels，且可在 Billing Export 中用來做成本分析。Network Tags（網路標籤）則是用於防火牆規則的目標識別——你可以為 VM 加上 web-server 標籤，然後建立防火牆規則只對具有 web-server 標籤的 VM 開放 port 80/443。簡單記：Labels 管錢和組織，Tags 管網路和安全。

另外要注意，GCP 現在還有 Resource Manager Tags（跟 Network Tags 不一樣），這是比較新的功能，可以用在 IAM Conditions 和 Organization Policy，支援繼承、存取控制也更嚴格。面試時如果能把這三種「標籤」（Labels、Network Tags、Resource Manager Tags）分清楚，很加分。

📖 延伸學習：GCP 網路基礎

二、Compute（Q9–Q16）

Q9: GCP 有哪些主要的 Compute 服務？各適合什麼場景？

答案： GCP 的 Compute 服務由「最大控制權」到「最少管理負擔」排列：Compute Engine（IaaS，完全控制 VM，適合需要特定 OS 或 legacy 應用遷移）→ GKE（容器編排，適合微服務架構）→ Cloud Run（全託管容器平台，適合無狀態 HTTP 服務與事件驅動）→ Cloud Functions（FaaS，適合單一用途函式如 webhook 處理）→ App Engine（PaaS，適合快速原型開發）。怎麼選？已經容器化就選 Cloud Run 或 GKE；只是要跑一段程式就用 Cloud Functions；需要完全掌控就用 Compute Engine。

📖 延伸學習：Serverless 選項完全比較

Q10: Compute Engine 的機器類型（Machine Type）有哪幾個系列？

答案： Compute Engine 的機器類型分為四大系列：**通用型（General-purpose）**包括 E2（成本優化）、N2/N2D（平衡型）、N4（最新一代）、Tau T2D/T2A（擴展型）；**運算優化型（Compute-optimized）**為 C2/C2D/C3/C3D，適合 HPC、遊戲伺服器；**記憶體優化型（Memory-optimized）**為 M1/M2/M3，適合 SAP HANA、大型資料庫；**加速器優化型（Accelerator-optimized）**為 A2/A3/G2，配備 NVIDIA GPU，適合 ML 訓練與推論。此外還有 Custom Machine Type，讓你自訂 vCPU 和記憶體比例，適合需求不符合預設規格的場景。

📖 延伸學習：建立你的第一台 VM

Q11: Spot VM（原 Preemptible VM）是什麼？適合什麼情境？

答案： Spot VM 是利用 GCP 閒置運算資源的虛擬機，價格約為一般 VM 的 60-91% 折扣，但 GCP 可以在任何時候以 30 秒通知回收這些資源。適合的場景包括：批次處理（影片轉檔、圖片處理）、大規模資料分析（Dataproc/Spark 叢集的 worker 節點）、CI/CD 建構、以及 容錯型 ML 訓練（搭配 checkpoint 機制）。不適合的場景：任何需要持續穩定運行的服務（如 Web Server、Database）。使用技巧：搭配 Managed Instance Group (MIG) 自動重建被回收的 Spot VM，或在 GKE 中使用 Spot Pod。

📖 延伸學習：建立你的第一台 VM

Q12: 什麼是 Managed Instance Group (MIG)？它和 Unmanaged Instance Group 有什麼差別？

答案： **MIG（代管執行個體群組）**是基於 Instance Template 自動管理一組相同 VM 的服務，提供四大功能：自動修復（Health Check 偵測不健康的 VM 並自動替換）、自動擴縮（根據 CPU、Memory、自訂指標動態調整 VM 數量）、自動更新（Rolling Update 或 Canary Update 無停機時間升級）、跨區域部署（Regional MIG 分散到多個 Zone 提高可用性）。相比之下，Unmanaged Instance Group 只是一組 VM 的邏輯分組，沒有自動化能力，僅用於將既有不同規格的 VM 放到同一個 Load Balancer 後端。

📖 延伸學習：高可用架構設計

Q13: 請解釋 Live Migration 的運作原理

答案： Live Migration 是 GCP 一個很重要的功能。當底層的實體主機要維護（硬體更新、安全性修補）時，VM 會自動搬到另一台實體主機，過程不用停機。運作原理分三個階段：(1) Pre-copy——將 VM 的記憶體內容複製到目標主機，同時 VM 繼續運行；(2) Blackout——極短暫的暫停（通常 < 1 秒）來複製最後的髒頁（dirty pages）；(3) Resume（切換至目標主機）——在目標主機恢復 VM 運行。注意：Spot VM 和具有 GPU 的部分 VM 不支援 Live Migration，只能設定 TERMINATE 行為。

📖 延伸學習：建立你的第一台 VM

Q14: Compute Engine 的 Autoscaling 支援哪些指標？如何設定？

答案： Autoscaling 是 MIG 的核心功能，支援以下指標來決定擴縮：CPU 使用率（最常見，如目標 60%）、HTTP Load Balancing 請求量（如每台 VM 處理 1000 RPS）、Cloud Monitoring 指標（自訂指標，如佇列深度）、Pub/Sub 未處理訊息數。設定關鍵參數包括：min-replicas（最小 VM 數，建議至少 2 以確保 HA）、max-replicas（最大 VM 數，預防成本暴增）、cool-down-period（冷卻期，預設 60 秒，避免頻繁擴縮）、scale-in-control（限制縮減速度，避免流量抖動時過度縮減）。

📖 延伸學習：高可用架構設計

Q15: Sole-tenant Node 是什麼？什麼時候需要用？

答案： Sole-tenant Node 是一台專屬的實體主機，確保你的 VM 不會與其他客戶的 VM 共享硬體。適用場景包括：合規要求（某些金融或醫療法規要求實體隔離）、自帶授權（BYOL）（如 Windows Server、SQL Server 的 per-core 或 per-socket 授權模式）、效能敏感型工作負載（避免 noisy neighbor 問題）。Sole-tenant Node 的定價較高，但可以搭配 CUD 取得折扣。你可以在 Node Group 上使用 Node Affinity Labels 來控制哪些 VM 部署到特定的 Sole-tenant Node。

📖 延伸學習：建立你的第一台 VM

Q16: 如何選擇磁碟類型？Persistent Disk 和 Local SSD 的差異？

答案： GCP 的儲存選項：Persistent Disk（PD）是網路附加儲存，分為 pd-standard（HDD，低成本大容量）、pd-balanced（SSD，均衡型，最常用）、pd-ssd（SSD，高 IOPS/吞吐量）和 pd-extreme（最高效能，適合 SAP 等關鍵負載）。PD 的優點是獨立於 VM 生命週期、支援快照（Snapshot）和大小動態調整。Local SSD 是直接附加在實體主機的 NVMe 磁碟，提供極高的 IOPS（最高 2.4M 讀取 IOPS），但資料在 VM 停止/刪除/遷移時會遺失，適合暫存快取或 scratch space。Hyperdisk 是最新一代，支援動態調整 IOPS 和吞吐量，無需調整磁碟大小。

📖 延伸學習：Storage 策略完全指南

三、Storage & Database（Q17–Q24）

Q17: Cloud Storage 的四種儲存類別（Storage Class）有何差異？

答案： Cloud Storage 提供四種 Storage Class，差別在於存取頻率和成本結構：Standard（存取頻繁的熱資料，儲存成本最高但無取回費用）→ Nearline（每月存取少於一次的資料，最低儲存 30 天）→ Coldline（每季存取少於一次，最低 90 天）→ Archive（每年少於一次，最低 365 天，適合法規保存）。隨著存取頻率降低，儲存費用遞減，但取回費用遞增。重要功能：Object Lifecycle Management 可以自動將物件在類別間轉換或刪除，例如「建立 30 天後從 Standard 轉為 Nearline」。所有類別的延遲和吞吐量都相同，差別只在成本。

📖 延伸學習：Cloud Storage 完全指南

Q18: Cloud Storage 的一致性模型是什麼？

答案： Cloud Storage 提供 strong global consistency（強全域一致性）。這表示：當你成功上傳一個物件後，全世界任何地方的讀取請求都會立即看到最新版本（read-after-write consistency）。同樣地，物件的刪除和元資料更新也是立即生效的（read-after-delete / read-after-metadata-update consistency）。這點跟 AWS S3 早期的 eventual consistency 模型不一樣。但要注意，Bucket/Object ACL 的列表操作（list）可能會有短暫的 eventual consistency。面試時主動強調 GCP 的 strong consistency 是個亮點，代表你懂分散式儲存的一致性問題。

📖 延伸學習：Cloud Storage 完全指南

Q19: 請比較 Cloud SQL、Cloud Spanner、Firestore 和 Bigtable

答案： 這四個資料庫服務各有定位：

特性	Cloud SQL	Cloud Spanner	Firestore	Bigtable
類型	關聯式 (MySQL/PostgreSQL/SQL Server)	全球分散式關聯式	文件型 NoSQL	寬欄型 NoSQL
擴展性	垂直擴展，Read Replica	水平擴展，全球分散	自動擴展	水平擴展
一致性	強一致	強全域一致（TrueTime）	強一致	單列強一致
適用場景	傳統 RDBMS 工作負載	全球金融交易、遊戲排行榜	行動/Web 應用、即時同步	IoT 時序資料、AdTech
月費起點	~$7	~$650/node	免費額度	~$450/node

選擇口訣：需要 SQL → Cloud SQL（小）或 Spanner（大）；NoSQL 文件 → Firestore；NoSQL 大量寫入 → Bigtable。

補充：面試常被追問「那 AlloyDB 呢？」AlloyDB 是 PostgreSQL 相容的全代管關聯式資料庫，效能比標準 Cloud SQL PostgreSQL 最多快 4 倍，適合需要高效能 OLTP 又要內建分析能力的場景，定位剛好卡在 Cloud SQL 和 Spanner 中間。

📖 延伸學習：資料庫選型指南 | Cloud SQL 入門 | Cloud Spanner 深入解析 | Firestore 實戰 | Bigtable 完全指南

Q20: Cloud SQL 的高可用性如何實作？

答案： Cloud SQL HA 採用 Regional 架構：在同 Region 的不同 Zone 建立一台 Primary 和一台 Standby 實例，使用同步複寫確保資料一致。當 Primary 故障時，系統自動故障轉移到 Standby（約 60 秒內完成），對應用程式使用同一個連線 IP。除了 HA 之外，還可以建立 Read Replica（跨 Zone 或跨 Region）來分散讀取負載。備份策略建議：啟用自動備份（每日一次）+ Binary Log（啟用 point-in-time recovery，可還原到特定時間點）。面試加分：提到 Cloud SQL Proxy 可安全連線，不需暴露公有 IP。

📖 延伸學習：Cloud SQL 入門 | 高可用架構設計

Q21: Memorystore 是什麼？何時該使用？

答案： Memorystore 是 GCP 的全代管 In-memory 資料儲存服務，支援 Redis 和 Memcached 兩種引擎。Redis 適合需要資料持久性、豐富資料結構（Sorted Set、Hash 等）和 Pub/Sub 的場景；Memcached 適合單純的快取需求，支援多執行緒。常見使用情境：Session 快取（Web 應用的使用者 session）、資料庫查詢快取（減少 Cloud SQL 讀取壓力）、排行榜/計數器（利用 Redis Sorted Set）、Rate Limiting。Memorystore 完全代管，自動處理高可用性、故障轉移、修補程式更新。

面試加分：講一下快取策略怎麼選，Cache-Aside（應用程式先查快取，miss 才去查 DB 再寫回快取）是最常見的模式。順帶提到快取失效策略（設 TTL、主動 invalidation），更能展現實戰經驗。

📖 延伸學習：Memorystore 使用指南

Q22: 什麼是 Transfer Service？如何將大量資料遷移到 GCP？

答案： GCP 提供多種資料遷移工具：Storage Transfer Service 適合從其他雲端（AWS S3、Azure Blob）或 HTTP 來源排程傳輸到 Cloud Storage；Transfer Appliance 是實體硬體裝置（100TB/480TB），適合網路頻寬不足時的超大規模離線遷移；gsutil / gcloud storage 適合小量資料的直接上傳（gsutil -m cp -r 啟用多執行緒加速）；Database Migration Service (DMS) 專門用於資料庫遷移到 Cloud SQL 或 AlloyDB，支援最低停機時間的持續複寫。選擇原則：< 1TB 用 gsutil、1-10TB 用 Transfer Service、> 10TB 且網路受限用 Transfer Appliance。

📖 延伸學習：GCP 遷移策略

Q23: Cloud Storage 的安全性功能有哪些？

答案： Cloud Storage 的安全性涵蓋多個層面：存取控制方面有 Uniform Bucket-Level Access（推薦，純用 IAM 管理）和 Fine-grained ACL（物件層級控制）；加密方面預設使用 Google-managed Key（GMEK），可升級為 Customer-managed Key（CMEK，透過 Cloud KMS）或 Customer-supplied Key（CSEK，客戶自行管理金鑰）；網路安全可搭配 VPC Service Controls 限制資料存取範圍；稽核功能透過 Cloud Audit Logs 記錄所有存取行為；防刪除可啟用 Object Versioning（版本控制）和 Retention Policy（保留政策，防止提前刪除）、Object Lock（鎖定物件）。面試時強調 Uniform Bucket-Level Access 是最佳實務。

📖 延伸學習：Cloud Storage 完全指南 | Security 最佳實務

Q24: Filestore 是什麼？什麼時候用 Filestore 而不是 Cloud Storage？

答案： Filestore 是 GCP 的全代管 NFS 檔案系統服務，提供 POSIX 相容的共享檔案儲存。如果你需要多台 VM 同時掛載同一個檔案系統、應用程式需要檔案系統語意（像 file locking、directory traversal），或是要搬一個依賴 NFS 的 legacy 應用，就選 Filestore。典型場景包括：CMS（WordPress 等）的共享媒體目錄、EDA（電子設計自動化）工作負載、ML 訓練資料的共享存取。相比之下，Cloud Storage 是物件儲存（Object Storage），用 REST API 存取，適合非結構化資料儲存和 CDN 整合。Filestore 提供 Basic（HDD/SSD）和 Enterprise（跨 Zone HA）兩種層級。

📖 延伸學習：Storage 策略完全指南

四、Networking（Q25–Q30）

Q25: 什麼是 VPC？GCP 的 VPC 有什麼特色？

答案： VPC（Virtual Private Cloud）是你在 GCP 上的私有虛擬網路。GCP VPC 的最大特色是它是 Global 資源——一個 VPC 可以跨越所有 Region，不需要像 AWS 那樣每個 Region 建一個 VPC。Subnet 才是 Regional 資源，屬於特定 Region。GCP VPC 有兩種模式：Auto mode（自動在每個 Region 建立子網路，使用預定義 IP 範圍，適合簡單環境）和 Custom mode（手動建立子網路和 IP 範圍，適合生產環境，推薦使用）。其他特色包括：VPC 網路之間的流量透過 VPC Peering 通訊、支援 Shared VPC 讓多個 Project 共用網路。

面試常見追問：「為什麼生產環境推薦 Custom mode？」因為 Auto mode 的 IP 範圍是固定的，之後要做 VPC Peering 時可能會 IP 衝突。Custom mode 讓你完全掌控 CIDR 規劃，要跟地端網路整合也比較容易。

📖 延伸學習：GCP 網路基礎 | VPC 進階設計

Q26: GCP 防火牆規則（Firewall Rules）如何運作？

答案： GCP 防火牆是分散式、有狀態的（stateful）虛擬防火牆，直接作用在 VM 層級而非 Subnet 邊界。規則要素包括：方向（Ingress / Egress）、動作（Allow / Deny）、優先序（0-65535，數字越小優先度越高）、目標（所有 VM / 指定 Network Tag / 指定 Service Account）、來源/目的地（IP 範圍、Network Tag、Service Account）、協定和埠號（如 tcp:80,443）。預設規則：隱含拒絕所有 Ingress和隱含允許所有 Egress。最佳實務：使用 Service Account 而非 Network Tag 作為目標，因為 SA 的管理權限更易控制；善用 Hierarchical Firewall Policies 在 Organization/Folder 層級統一管理。

📖 延伸學習：GCP 網路基礎

Q27: 請比較 GCP 的四種 Load Balancer

答案： GCP Load Balancer 分為外部和內部，再依據 L4/L7 細分：

類型	層級	範圍	協定	適用場景
External Application LB	L7	Global	HTTP(S)	Web 應用、API Gateway
External Network LB	L4	Regional	TCP/UDP	遊戲伺服器、非 HTTP
Internal Application LB	L7	Regional	HTTP(S)	內部微服務、Service Mesh
Internal Passthrough Network LB	L4	Regional	TCP/UDP	內部 TCP 服務

External Application LB 最常用，支援 URL Map（路徑路由）、CDN 整合、SSL Offloading、Google Cloud Armor（WAF/DDoS 防護）。跨區域的 External Application LB 使用 Google 全球骨幹網路的 Anycast IP，用戶自動連到最近的 POP。

📖 延伸學習：Load Balancing 完全指南

Q28: VPC Peering 和 Shared VPC 有什麼差別？

答案： 兩者都是跨 VPC 通訊的方案，但設計目標不同。VPC Peering 是在兩個 VPC 之間建立對等連線，流量走 Google 內部網路（不經公網），適合不同 Organization 或獨立 Project 之間的通訊。注意 Peering 是非遞移的（A Peer B、B Peer C，不代表 A 能連 C）。Shared VPC 是在同一個 Organization 內，讓一個 Host Project 的 VPC 共享給多個 Service Project 使用，適合集中管理網路架構——網路管理員在 Host Project 管理 VPC/Subnet/Firewall，開發團隊在各自的 Service Project 中建立資源並使用共享的網路。生產環境推薦 Shared VPC。

📖 延伸學習：VPC 進階設計

Q29: Cloud CDN 是什麼？如何啟用？

答案： Cloud CDN（Content Delivery Network）用 Google 全球超過 180 個 Edge POP（Point of Presence）快取你的內容，讓各地用戶都能從最近的節點拿到資料，降低延遲。啟用很簡單，在 External Application Load Balancer 的 Backend Service 上勾選 Enable Cloud CDN 就好。CDN 支援三種快取模式：Cache All（全部快取）、Cache Static（只快取靜態資源如圖片/CSS/JS）、Custom 設定。重要功能包括：Signed URLs/Cookies（保護付費內容）、Cache Invalidation（快取失效）、Cache Key 自訂（控制快取粒度）。計費基於快取命中的流量和 HTTP 請求數。

📖 延伸學習：Load Balancing 完全指南

Q30: 如何實現混合雲連線？Cloud VPN vs Cloud Interconnect

答案： Cloud VPN 透過 IPSec 加密隧道在公網上連接地端網路與 GCP VPC。分為 Classic VPN（單一隧道、靜態路由）和 HA VPN（推薦，雙隧道、BGP 動態路由、99.99% SLA）。適合**頻寬需求中等（< 3 Gbps per tunnel）**且對成本敏感的場景。Cloud Interconnect 則是專用的實體連線：Dedicated Interconnect 是你的網路直接連到 Google Edge（10/100 Gbps，需要共置設施），適合大頻寬需求；Partner Interconnect 透過 Google 合作夥伴連線（50 Mbps - 50 Gbps），適合無法直接連到 Google Edge 的企業。選擇原則：低成本/快速設定 → HA VPN；高頻寬/低延遲 → Dedicated Interconnect；介於之間 → Partner Interconnect。

台灣企業的常見做法：因為 Google 在台灣有 asia-east1 Region，不少企業會透過台灣的合作夥伴（像中華電信、遠傳的 IDC）用 Partner Interconnect 接回地端機房。設好之後再搭配 Cloud Router（BGP 動態路由）自動學習、交換路由，網路管理就省事很多。

📖 延伸學習：混合雲與互連方案

五、IAM & Security（Q31–Q36）

Q31: 請解釋 GCP IAM 的核心概念：Member、Role、Policy

答案： GCP IAM 的授權模型由三個核心組成：**Member（誰）**是被授權的身分，包括 Google Account（個人）、Service Account（服務）、Google Group、Google Workspace Domain、Cloud Identity Domain；**Role（什麼權限）**是一組 Permissions 的集合，分為 Basic Roles（Owner/Editor/Viewer，權限太廣，不建議生產環境使用）、Predefined Roles（Google 預先定義的細粒度角色如 roles/storage.objectViewer）、Custom Roles（自訂權限集合）；Policy（綁定）將 Member 與 Role 綁定在特定資源上。IAM Policy 沿資源階層向下繼承，子層級無法撤銷父層級授予的權限。

📖 延伸學習：IAM 基礎入門

Q32: Service Account 是什麼？有哪些最佳實務？

答案： Service Account 是一種特殊的 Google 帳戶，代表應用程式或服務（而非人）的身分。每個 GCP Project 預設會有 Default Service Account，但最佳實務是為每個服務建立專用的 Service Account。重要原則：(1) 最小權限原則——只授予服務需要的最小角色；(2) 避免使用 Service Account Key——優先使用 Workload Identity（GKE）、metadata server（Compute Engine）或 Workload Identity Federation（外部服務），而非下載 JSON 金鑰；(3) 定期輪換——如必須使用 Key，設定 90 天自動輪換；(4) 停用沒在用的 SA——用 IAM Recommender 找出閒置的 Service Account。面試重點：能講出「不要用 Default SA」跟「不要用 SA Key」就過關了。

📖 延伸學習：IAM 基礎入門 | Security 最佳實務

Q33: 什麼是最小權限原則（Principle of Least Privilege）？如何在 GCP 實踐？

答案： 最小權限原則是指只授予使用者或服務完成工作所需的最少權限，不多給任何額外權限。在 GCP 中的實踐方式：(1) 使用 Predefined Roles 而非 Basic Roles——例如用 roles/storage.objectViewer 而非 roles/viewer；(2) 善用 Conditions——IAM Conditions 可加上時間、資源名稱等條件限制（如只在上班時間有權限）；(3) 利用 IAM Recommender——GCP 會分析過去 90 天的實際使用紀錄，自動建議移除未使用的權限；(4) 使用 Custom Roles——如果 Predefined Role 仍然太廣，建立只包含需要權限的 Custom Role；(5) 定期稽核——透過 Policy Analyzer 檢視誰有什麼權限。

📖 延伸學習：Security 最佳實務

Q34: VPC Service Controls 是什麼？解決什麼問題？

答案： VPC Service Controls 是 GCP 的資料外洩防護機制，在 GCP 服務周圍建立一個安全邊界（Service Perimeter），防止資料從邊界內被未經授權地存取或複製到邊界外。它要解決的核心問題是：就算 IAM 設定都對，有權限的使用者還是可能把敏感資料複製到自己的個人 Project，而 VPC Service Controls 就能擋住這種行為。運作方式：(1) 定義 Service Perimeter（指定哪些 Project 和服務受保護）；(2) 設定 Access Levels（基於 IP、裝置、身分等條件允許存取）；(3) 可選設定 Ingress/Egress Rules（精細控制跨邊界的資料流向）。常見搭配：Cloud Storage、BigQuery、Cloud KMS。建議先用 Dry Run Mode 測試不會阻斷正常流量。

📖 延伸學習：Security 最佳實務

Q35: Cloud KMS（Key Management Service）的金鑰層級是什麼？

答案： Cloud KMS 的階層架構為：Key Ring → Crypto Key → Crypto Key Version。Key Ring 是金鑰的邏輯容器，屬於特定 Location（Region 或 multi-region），建立後無法刪除（但可停用內部的金鑰）。Crypto Key 代表一個金鑰，有四種用途：ENCRYPT_DECRYPT（對稱加密）、ASYMMETRIC_SIGN（非對稱簽章）、ASYMMETRIC_DECRYPT（非對稱解密）、MAC（訊息認證碼）。Crypto Key Version 是實際的金鑰材料，支援自動輪換（建議 90 天）。KMS 搭配 CMEK 使用時，你管理金鑰、Google 管理加密操作——若需要你完全控制金鑰硬體，則用 Cloud HSM（FIPS 140-2 Level 3 認證）或 Cloud External Key Manager (EKM)。

📖 延伸學習：Security 最佳實務

Q36: 如何在 GCP 中實作零信任安全模型？

答案： 零信任（Zero Trust）的核心理念是「永不信任、持續驗證」。在 GCP 中的實作方式：(1) BeyondCorp Enterprise——Google 自家實踐多年的零信任方案，透過 Identity-Aware Proxy (IAP) 在應用程式前驗證身分和裝置狀態，不需要 VPN；(2) VPC Service Controls——建立資料安全邊界，防止資料外洩；(3) Binary Authorization——確保只有經過簽章驗證的容器映像可以部署到 GKE；(4) Workload Identity——讓 GKE Pod 使用 Service Account 身分存取 GCP 服務，取代傳統的 Secret/Key 方式；(5) Access Context Manager——根據使用者身分、裝置安全狀態、IP 位址等動態決定存取權限。零信任不是一個產品，而是一組實踐的組合。

面試時的關鍵論點：傳統的城堡式安全（Castle-and-moat）假設內網是安全的，但雲端時代這個假設早就不成立了。員工可能從任何地方連進系統，服務之間也是走 API 在溝通，不是固定的網路路徑。零信任模型要求每一次存取都要驗證身分和權限，不管請求是從內網還是外網來。Google 自己從 2014 年就開始做 BeyondCorp，是業界最早大規模部署零信任的公司之一。

📖 延伸學習：Security 最佳實務

六、Kubernetes & Serverless（Q37–Q43）

Q37: GKE Autopilot 和 Standard 模式有什麼差別？該如何選擇？

答案： GKE Standard 模式下，你完全管理 Node（包括機器類型、數量、升級、安全修補），計費按 Node 的 VM 費用。GKE Autopilot 模式下，Google 完全管理 Node 層級——你只需定義 Pod，Google 自動配置所需的節點，計費按 Pod 請求的 CPU/Memory/GPU 計算，無需為閒置的 Node 容量付費。

面向	Standard	Autopilot
Node 管理	你管理	Google 管理
計費	按 Node VM	按 Pod 資源
自訂性	高（可安裝 DaemonSet、特權容器）	受限
安全性	需自行加固	預設安全加固
適合	需要高度自訂的團隊	多數工作負載、新專案

推薦：新專案優先選 Autopilot，除非有特殊需求才用 Standard。

面試追問準備：「什麼情況下 Autopilot 不適合？」幾種狀況——要裝 DaemonSet 做自訂日誌收集、要調特定的 Linux Kernel 參數（sysctl）、要用特定的 GPU 類型（不過 Autopilot 已經開始支援部分 GPU）、要跑 Windows 容器。

📖 延伸學習：GKE 入門指南

Q38: 什麼是 GKE Enterprise（前身為 Anthos）？

答案： GKE Enterprise 是 Google 的多叢集、多雲、混合雲 Kubernetes 管理平台。它的核心能力包括：(1) Fleet Management——統一管理分散在 GCP、AWS、Azure 和地端的多個 Kubernetes 叢集；(2) Config Sync——基於 GitOps 的配置管理，確保所有叢集的設定一致；(3) Service Mesh（基於 Istio 的 Cloud Service Mesh）——提供服務間的 mTLS、流量管理、可觀測性；(4) Policy Controller——基於 Open Policy Agent (OPA) 的策略引擎，強制執行合規要求。適合的企業場景：已有地端 Kubernetes 需要統一管理、多雲策略、嚴格的合規需求。

📖 延伸學習：GKE 入門指南

Q39: Cloud Run 和 Cloud Functions 怎麼選？

答案： 兩者都是 Serverless，但定位不同：

Cloud Run 接受任何容器映像，支援任何語言/框架、任何 port、WebSocket、gRPC、串流回應，最長執行時間 60 分鐘（HTTP）或 24 小時（Job），支援最小執行個體數（min-instances）保持 warm，適合API 服務、Web 後端、微服務。

Cloud Functions 是輕量級的事件驅動函式，支援特定語言（Node.js、Python、Go、Java、.NET、Ruby、PHP），與 GCP 事件來源原生整合（如 Cloud Storage 上傳觸發、Pub/Sub 訊息觸發），最長執行時間 60 分鐘（2nd gen），適合事件處理、自動化、Webhook、輕量 API。

簡單判斷：如果你已有容器或需要完整 HTTP 伺服器 → Cloud Run；如果只需寫一個函式回應事件 → Cloud Functions。Cloud Functions 2nd gen 底層其實是 Cloud Run。

進階觀點：照 2026 年的趨勢，Google 一直在加強 Cloud Run 的功能（GPU 支援、Volume Mount、多容器 Sidecar 都有了），讓它變成大多數 Serverless 場景的首選。Cloud Functions 還是有它的價值，像是開發體驗更快（不用寫 Dockerfile）、事件綁定更直覺，但如果你的服務之後會愈長愈複雜，建議一開始就直接用 Cloud Run。

📖 延伸學習：Cloud Run 實戰 | Cloud Functions 入門 | Serverless 完全比較

Q40: App Engine Standard 和 Flexible 有什麼差別？

答案： App Engine Standard 在 Google 管理的沙箱環境中運行，支援特定語言執行環境（Python、Java、Go、Node.js、PHP、Ruby），可縮到零個執行個體（省錢），啟動速度毫秒級，適合流量波動大的 Web 應用。App Engine Flexible 則是在 Compute Engine VM 上運行 Docker 容器，支援任何語言/框架，最少一個執行個體始終運行，啟動速度分鐘級，適合需要自訂 runtime 或存取底層 OS 的應用。實務上，如果是新的 Serverless 專案，建議先評估 Cloud Run，它的彈性和生態系整合都比 App Engine Flexible 好，Google 官方也在引導大家往 Cloud Run 搬。

📖 延伸學習：App Engine 完全指南

Q41: Kubernetes 中 Deployment、Service、Ingress 各自的角色是什麼？

答案： 這三個資源是 K8s 中最核心的元件：Deployment 管理 Pod 的生命週期——定義要跑什麼容器、幾個副本（replica）、更新策略（Rolling Update / Recreate），確保實際狀態與期望狀態一致。Service 提供穩定的網路端點——Pod 是動態的（IP 會變），Service 透過 Label Selector 追蹤一組 Pod，提供固定的 Cluster IP 或 Node Port，實現內部服務發現和負載均衡。Ingress 是 L7 的流量入口——管理外部 HTTP(S) 流量如何路由到內部 Service，支援路徑路由（/api → Service A、/web → Service B）、TLS 終止、域名路由。在 GKE 中，Ingress 會自動建立 Google Cloud Load Balancer。

📖 延伸學習：GKE 入門指南

Q42: 什麼是 Knative？它和 Cloud Run 的關係是什麼？

答案： Knative 是一個開源的 Kubernetes 平台擴展，提供兩個核心元件：Serving（自動擴縮容器，含 scale-to-zero）和 Eventing（事件驅動架構，連接各種事件來源）。Cloud Run 建立在 Knative Serving 之上，是 Google 將 Knative 的能力包裝成全代管服務。也就是說，Cloud Run 用的是 Knative 的 API 規格（像 serving.knative.dev），你也可以自己在 GKE 上裝 Knative，得到類似 Cloud Run 的體驗（也就是 Cloud Run for Anthos，現在已經併進 GKE Enterprise）。面試時提到這層關係，能展現你懂 Serverless 的底層架構。

📖 延伸學習：Cloud Run 實戰

Q43: 如何在 GKE 中實作 CI/CD？

答案： 一個完整的 GKE CI/CD 流程包含：(1) 原始碼管理——Cloud Source Repositories 或 GitHub/GitLab；(2) 持續整合（CI）——Cloud Build 根據 cloudbuild.yaml 自動建構容器映像、跑測試，並推送到 Artifact Registry；(3) 安全掃描——Artifact Registry 的漏洞掃描自動檢查映像安全性，搭配 Binary Authorization 確保只有通過審核的映像可部署；(4) 持續部署（CD）——Cloud Deploy 管理多環境的部署管線（dev → staging → prod），支援 Canary 和 Blue/Green 部署策略；(5) GitOps——用 Config Sync 將叢集配置同步自 Git 倉庫。這套流程的關鍵字：Cloud Build + Artifact Registry + Cloud Deploy + Binary Authorization。

面試時如果被問到「你們的 CI/CD 流程是怎麼設計的？」，建議用以下結構回答：

觸發條件（Git push / PR merge）
建構步驟（Lint → Test → Build Image → Push to Registry）
安全檢查（漏洞掃描 → Binary Authorization 簽章）
部署策略（Canary / Blue-Green / Rolling）
驗證機制（Smoke Test → Monitoring Alert）
回滾機制（自動 / 手動回滾到上一版本）

📖 延伸學習：Cloud Build CI/CD 實戰

七、Data & AI（Q44–Q50）

Q44: BigQuery 的架構有什麼特別之處？為什麼它這麼快？

答案： BigQuery 採用 Storage 與 Compute 完全分離的架構。儲存層使用 Google 的 Colossus 分散式檔案系統，以列式格式（Capacitor）儲存資料，自動壓縮和加密。運算層使用 Dremel 引擎，將查詢拆解為樹狀的執行計畫，分派到數千個 Slot（運算單元）平行處理。這個架構的優勢：(1) 瞬間調度上萬個 CPU——不需要預先配置叢集；(2) 列式儲存——只讀取查詢需要的欄位，大幅減少 I/O；(3) 自動最佳化——查詢計畫自動分散、快取中間結果。計費模式分為 On-demand（每 TB 查詢 $6.25）和 Capacity（購買固定 Slot，適合穩定查詢量）。面試加分：提到 BigQuery 支援 Materialized View（自動維護、增量更新）和 BI Engine（記憶體內加速 BI 查詢）。

跟其他資料倉儲比一比：BigQuery 最大的優勢是零管理，不用配置叢集、不用調參數、不用 vacuum/reindex。相比之下，Redshift 要管叢集大小，Snowflake 的 warehouse 要手動啟停（雖然也算方便）。BigQuery 的 serverless 架構讓你真的只要專心寫 SQL 就好。

📖 延伸學習：BigQuery 完全指南

Q45: BigQuery 的分區（Partitioning）和叢集（Clustering）有什麼差別？

答案： 兩者都是為了減少查詢掃描的資料量，從而提升效能和降低成本。Partitioning 將表格依某個欄位的值切分為多個區塊：支援時間分區（依日期/時戳，最常用）、整數範圍分區、和攝取時間分區（_PARTITIONTIME）。查詢時加上分區欄位的篩選條件，BigQuery 就只掃描相關的分區。Clustering 在分區內進一步依最多 4 個欄位排序資料，讓相同值的資料物理上相鄰儲存。查詢時 BigQuery 能跳過不相關的資料區塊。最佳實務：先按日期分區，再按高基數欄位叢集——例如 PARTITION BY DATE(event_time) CLUSTER BY user_id, event_type。

📖 延伸學習：BigQuery 完全指南

Q46: Pub/Sub 是什麼？請解釋它的核心概念

答案： Pub/Sub 是 GCP 的全代管非同步訊息服務，實現發佈者（Publisher）和訂閱者（Subscriber）的解耦。核心概念：Topic 是訊息的頻道，Publisher 將訊息發佈到 Topic；Subscription 是 Topic 的訂閱，有兩種模式——Pull（Subscriber 主動拉取，適合批次處理）和 Push（Pub/Sub 主動推送到 HTTP 端點，適合 Cloud Run/Functions）；Message 包含 data（最大 10MB）和 attributes（鍵值對 metadata）。重要特性：至少一次傳遞（at-least-once delivery）、訊息保留最長 31 天、Exactly-once delivery（搭配 Dataflow）、Dead Letter Topic（處理失敗的訊息）、Message Ordering（在同一 ordering key 內保證順序）。

面試常見追問：「Pub/Sub 和 Kafka 差在哪？」Pub/Sub 是全代管服務，不用管 broker；Kafka 要自己管叢集（或用 Confluent Cloud）。Pub/Sub 的 throughput 理論上沒上限（會自動擴縮），但 Kafka 在同一個 partition 內能保證嚴格順序，也支援 consumer group 的再平衡。如果真要在 GCP 上跑 Kafka，可以考慮 Dataproc 上的 Kafka，或第三方的 Confluent Cloud。

📖 延伸學習：Pub/Sub 事件驅動架構

Q47: Dataflow 和 Dataproc 有什麼差別？

答案： 兩者都是資料處理服務，但定位不同：

Dataflow 是基於 Apache Beam 的全代管串流和批次處理服務。你寫 Beam Pipeline（Java/Python/Go），Dataflow 負責自動擴縮、資源管理、故障處理。適合：即時串流處理（如 IoT 事件分析、即時 ETL）、新的資料管線專案。

Dataproc 是全代管的 Apache Spark/Hadoop 叢集服務。你提交 Spark/Hadoop/Hive/Pig/Presto 任務到叢集上執行，叢集可在 90 秒內啟動、處理完後立即刪除。適合：已有 Spark/Hadoop 程式碼的遷移、互動式資料分析（Jupyter on Dataproc）。

選擇口訣：新專案用 Dataflow，既有 Spark 用 Dataproc。Dataproc 也可以作為暫時性叢集——任務完成就刪除（Ephemeral Cluster），搭配 Cloud Storage 做永久儲存。

進階比較：Dataflow 的 autoscaling 更細（可以在 pipeline 跑的過程中動態調 worker 數量），而且完全 serverless，你不用管任何 VM。Dataproc 則給你更多控制權，可以裝自訂套件（像 Delta Lake、Iceberg），也能搭 Jupyter Notebook 做互動式分析。資料工程師面試時，能把這兩者的取捨講清楚，是很關鍵的能力展現。

📖 延伸學習：Dataflow 與 Dataproc 比較

Q48: Vertex AI 是什麼？它整合了哪些 ML 功能？

答案： Vertex AI 是 GCP 的統一機器學習平台，將過去分散的 AI/ML 服務整合到單一平台。核心功能包括：(1) AutoML——無需寫程式碼就能訓練圖像分類、文字分類、表格預測等模型；(2) Custom Training——使用你自己的 TensorFlow/PyTorch/XGBoost 程式碼在分散式 GPU/TPU 上訓練；(3) Model Registry——模型版本管理和譜系追蹤；(4) Prediction——線上預測（低延遲）和批次預測（高吞吐量）端點；(5) Pipelines——基於 Kubeflow 或 TFX 的 ML 工作流自動化；(6) Feature Store——集中管理和共享 ML 特徵；(7) Model Monitoring——監測模型效能下降（data drift、concept drift）。2026 年最大亮點是與 Gemini 模型的深度整合。

📖 延伸學習：AI 與大數據入門

Q49: 請介紹 Gemini 3.1 在 GCP 中的應用場景

答案： Gemini 3.1 是 Google 最新的多模態大型語言模型，在 GCP 中的應用場景涵蓋：(1) Vertex AI Gemini API——直接呼叫 Gemini 3.1 進行文字生成、程式碼生成、圖像理解、影片分析、多輪對話；(2) Grounding with Google Search——讓 Gemini 的回答基於最新的 Google 搜尋結果，提高準確度；(3) RAG（Retrieval-Augmented Generation）——結合 Vertex AI Search 或自建向量資料庫，讓 Gemini 根據企業內部知識回答問題；(4) Gemini in BigQuery——在 SQL 查詢中直接呼叫 Gemini 做文字分析（如情感分析、摘要）；(5) Gemini Code Assist——IDE 內的程式碼輔助、解釋和除錯；(6) Gemini in Security Operations——在 Chronicle SIEM 中輔助安全事件分析。面試重點：能舉出至少 2-3 個具體應用場景，展現你跟上最新技術趨勢。

實務建議：面試前去玩玩 Vertex AI Studio（有免費額度），親手測一下 Gemini 3.1 的多模態能力（例如丟一張架構圖給它分析），這樣面試時你能說「我實際用過⋯」，比只懂理論有說服力多了。

📖 延伸學習：AI 與大數據入門 | 2026 雲端趨勢

Q50: 如何設計一個即時資料分析管線？

答案： 一個典型的 GCP 即時資料分析管線架構：

[資料來源] → Pub/Sub → Dataflow → BigQuery → Looker/Data Studio
                                  ↘ Cloud Storage (raw data backup)

各元件的角色：(1) Pub/Sub 作為訊息佇列，接收來自 IoT 裝置、應用程式日誌、第三方 API 的即時資料流；(2) Dataflow（Apache Beam Streaming Pipeline）進行即時的資料轉換、清理、聚合（如每分鐘計算平均值、過濾異常值），支援 Windowing（Fixed、Sliding、Session Window）和 Watermark 處理遲到的資料；(3) BigQuery 作為分析倉庫，透過 Streaming Insert 或 Storage Write API 即時寫入，搭配 Materialized View 預先聚合常用查詢；(4) Looker 做即時儀表板和 BI 報表。可選增強：加入 Bigtable 做低延遲的即時查詢（如最近 1 小時的明細），Cloud Functions 做即時告警。

這題是面試的高頻題。回答時別只是把服務列出來，更要講為什麼選每個服務、它們之間怎麼銜接。額外加分：提到用 Cloud Monitoring 盯管線的健康狀態（像 Pub/Sub 未處理訊息數、Dataflow 的 system lag），還有 Cloud Logging 記錄錯誤方便除錯。

📖 延伸學習：Pub/Sub 事件驅動架構 | BigQuery 完全指南 | Dataflow 與 Dataproc 比較

面試技巧：5 個讓你脫穎而出的訣竅

Tip 1：答案要有結構

面試官一天要面很多人，回答有結構，他才更好聽懂、也更記得住你。推薦用這個框架：

是什麼（What）→ 用一句話定義
為什麼（Why）→ 解決什麼問題
怎麼做（How）→ 實際操作或架構
注意事項（Watch out）→ 限制和替代方案

舉例來說，如果被問到「什麼是 Cloud Run？」，你可以這樣回答：

「Cloud Run 是 GCP 的全代管 Serverless 容器平台（What），它解決了傳統容器部署需要管理叢集的問題（Why）。你只需提供一個 Docker Image，Cloud Run 就會自動處理負載均衡、自動擴縮（包含縮到零），部署方式可以用 gcloud run deploy 或 Cloud Build CI/CD（How）。要注意的是它主要適合無狀態的 HTTP 工作負載，如果需要長時間背景處理可以用 Cloud Run Jobs，但若需要有狀態服務或 GPU 支援則考慮 GKE（Watch out）。」

Tip 2：舉真實經驗

比起背官方文件，面試官更想聽你的實際經驗，就算是 Side Project 也很有價值。可以用 STAR 方法（Situation, Task, Action, Result）來組織你要講的經驗：

「我在實作一個 IoT 資料管線時（Situation），需要處理每秒上千筆感測器資料並即時分析（Task）。我用 Pub/Sub 做訊息緩衝、Dataflow 做串流處理，最後存到 BigQuery（Action）。過程中遇到 late data 的問題，最後透過設定 Allowed Lateness 和 Accumulation Mode 解決，最終管線的端到端延遲從 5 分鐘降到 30 秒以內（Result）。」

如果你還沒有生產環境的經驗，可以：

利用 GCP Free Tier 做一個完整的 Side Project
參加 Google Cloud Skills Boost 的 Lab
在 GitHub 上公開你的 Terraform/Cloud Build 配置檔，面試時直接展示

Tip 3：了解成本考量

每個技術選擇背後都有成本，展現出你有成本意識，會讓面試官印象深刻：

提到 Committed Use Discounts（CUD） 和 Sustained Use Discounts（SUD） 的差異——CUD 需要承諾 1-3 年，折扣最高 57%；SUD 是自動套用，用量超過 25% 的月份自動給折扣
解釋為什麼選 Cloud Run 而非 GKE（小型服務的成本效益——Cloud Run 可以縮到零，GKE 至少需要一個 Node）
知道 BigQuery 的 On-demand vs Capacity 計費差異（On-demand 按掃描量付費，適合不穩定查詢量；Capacity 買 Slot 固定費用，適合穩定高量查詢）
熟悉 Billing Export to BigQuery 的分析方式——這是企業最常用的成本分析手段
了解 Spot VM 在批次處理中的成本節省效果

面試時如果被問到「你會怎麼做成本優化？」，一個好的回答框架是：

先用 Billing Export 分析目前的花費分布
找出最大的成本項目（通常是 Compute 和 Storage）
針對性優化（Right-sizing VM、用 Spot VM、調整 Storage Class、設定 Lifecycle Policy）
設定 Budget Alerts 持續監控

📖 延伸學習：GCP 成本優化完全指南

Tip 4：展現安全意識

不管你應徵的是不是安全工程師，安全都是每個雲端職位一定會考的：

自動帶出「最小權限原則」——每次提到 IAM 就順帶一提
提到加密（at rest 所有 GCP 服務預設加密 + in transit 使用 TLS）
強調「不要用 Service Account Key」——改用 Workload Identity 或 Workload Identity Federation
提及稽核日誌（Cloud Audit Logs）——分為 Admin Activity（預設啟用、免費）和 Data Access（需手動啟用、可能有費用）
知道 Security Command Center（SCC）——GCP 的統一安全管理平台，提供漏洞掃描、威脅偵測、合規報告
理解 Organization Policy 的常見約束——如停用 Service Account Key 建立、限制資源位置、強制使用均勻儲存桶存取

記住一個原則：回答任何架構設計題時，主動把安全考量帶進來，別等面試官問。這展現的不只是知識，更是專業態度。

Tip 5：準備架構設計題

中高階職位會有系統設計題，準備以下模板：

釐清需求——確認流量規模、延遲要求、一致性需求
選擇服務——根據需求選擇適當的 GCP 服務
畫架構圖——說明資料流向和元件互動
討論取捨——解釋為什麼選 A 而非 B
考慮營運——監控、備份、災難復原、成本

常見的系統設計題範例：

「設計一個能處理每秒 10 萬筆請求的短網址服務」
「設計一個全球性的電商平台後端」
「設計一個即時聊天系統」
「設計一個影片上傳與串流平台」

準備這類題目時，建議事先整理好常用的架構模式，例如：

Web 三層架構：Cloud Run/GKE + Cloud SQL + Cloud CDN
事件驅動架構：Pub/Sub + Cloud Functions/Dataflow + BigQuery
微服務架構：GKE + Cloud Service Mesh + Cloud SQL/Firestore
批次處理架構：Cloud Storage + Dataflow/Dataproc + BigQuery

常見追問題型

面試官聽完你的基本回答後，通常會接著追問，目的是測你的理解深度和臨場反應。以下是常見的追問方向，建議先把思路準備好。不用背出完美答案，但要有清楚的思考框架：

架構決策類

「如果流量突然增加 10 倍，你的架構要怎麼調整？」
- 思路：哪些元件需要水平擴展？有沒有快取層可以加？資料庫是否成為瓶頸？
「如果預算砍半，你會犧牲什麼？」
- 思路：先分析成本佔比最大的項目，再根據業務優先級做取捨
「如果要支援全球部署，架構要怎麼改？」
- 思路：多 Region 部署、Global Load Balancer、Cloud CDN、資料同步策略（Spanner or Cross-region Read Replica）
「這個架構的單點故障在哪裡？」
- 思路：逐一檢查每個元件是否有冗餘，特別關注 Database 和 Load Balancer

故障排除類

「VM 無法連上網路，你會怎麼排查？」
- 排查順序：Firewall Rules（是否有 Allow Ingress/Egress）→ Routes（是否有到目標的路由）→ External IP（是否有分配）→ VPC 設定（是否在正確的 Subnet）→ 用 gcloud compute ssh 測試連線 → 檢查 VM 內部的 OS 層防火牆（如 iptables）
「BigQuery 查詢變慢了，可能的原因有哪些？」
- 可能原因：資料傾斜（skewed join/group by）、未使用分區/叢集導致全表掃描、Slot 不足（On-demand 模式的 slot 是共享的）、跨 Region 查詢、UDF 效能瓶頸、過多的 JOIN 層數
「Cloud Run 服務回應 502，怎麼排查？」
- 排查順序：檢查 Cloud Logging 的錯誤日誌 → Container 是否 crash（OOMKilled 表示記憶體不足）→ 啟動時間是否超過 timeout（預設 240 秒）→ Health Check 是否通過 → Container Port 是否正確配置

比較選擇類

「Cloud SQL vs AlloyDB vs Spanner，各自什麼時候用？」
- Cloud SQL：一般 RDBMS 工作負載（< 64TB）；AlloyDB：需要高效能 PostgreSQL + 分析（HTAP）；Spanner：全球分散、無限擴展、強一致性
「Cloud Run vs GKE Autopilot，怎麼選？」
- Cloud Run：單一容器、無狀態服務、想要最少管理負擔；GKE Autopilot：多容器 Pod、需要 Service Mesh、有狀態工作負載、需要更多 K8s 功能（如 CronJob、StatefulSet）
「Pub/Sub vs Kafka on GKE，各有什麼優缺點？」
- Pub/Sub：全代管、自動擴縮、與 GCP 整合好；Kafka：嚴格的 partition 順序、更豐富的生態系（Kafka Connect、Kafka Streams）、但需要管理叢集

安全合規類

「如何確保只有特定國家的資料留在特定 Region？」（Data Residency → Resource Location Restriction Org Policy）
「客戶要求你的系統符合 SOC 2，你需要做什麼？」
「如何偵測並回應安全事件？」（Security Command Center → Chronicle → Cloud Audit Logs）

成本優化類

「目前每月 GCP 帳單是 $50,000，老闆要求降低 30%，你會怎麼做？」
「開發環境和生產環境的成本策略應該有什麼不同？」
「如何預測下個月的 GCP 費用？」
「什麼情況下該買 CUD？什麼情況下不該買？」

遷移類

「你們公司要從 AWS 遷移到 GCP，你會怎麼規劃？」
「一個跑了 10 年的 on-premises 單體應用（monolith），要怎麼搬上 GCP？」
「遷移過程中如何做到零停機？」

回答追問題的框架

被追問時別慌，照這幾步走：

暫停思考——「這是個好問題，讓我想一下」（5-10 秒思考完全可以接受）
釐清假設——「在回答之前，我想確認一下——這個場景的可用性要求是多少個 9？」
分層回答——「首先…, 其次…, 最後…」
承認不知道——「這個部分我不確定具體的數字，但我知道可以在官方文件的 Quotas 頁面找到」

誠實說不知道，比硬掰好太多了。面試官在意的是你解決問題的思考方式，不是你背了多少數字。

面試前的自我評估清單

進面試之前，用這份清單確認自己準備到哪了。每個領域至少要做到「能用自己的話講出來」：

基礎知識 ✅

能畫出 GCP 資源階層並解釋 IAM 繼承
能說明 Region/Zone 的選擇原則
能解釋至少 3 種計費優化策略
熟悉 gcloud CLI 的基本操作

核心服務 ✅

能比較 Compute Engine、GKE、Cloud Run、Cloud Functions 的定位
能根據場景選擇正確的 Storage/Database 服務
能解釋 VPC、Firewall、Load Balancer 的運作方式
能說明 IAM 的三層授權模型和最佳實務

進階能力 ✅

能設計一個包含高可用和災難復原的架構
能規劃一條 CI/CD 管線
能解釋至少一個資料分析管線的架構
能討論安全性和合規性的實作方式

軟實力 ✅

能用結構化方式回答問題（What/Why/How/Watch out）
能舉出至少 3 個具體的實作經驗
能誠實表達不確定的部分並說明如何找答案
能討論技術選型的 trade-off

下一步

恭喜你讀完這 50 道題！但這只是開始，接下來建議你：

動手實作——看十遍不如自己做一遍，用 GCP Free Tier 實際操作
取得認證——通過 Google Cloud ACE 認證是最有說服力的能力證明
系統性學習——跟著《GCP ACE 考試完全攻略》有系統地補齊知識缺口
追蹤最新動態——閱讀《2026 雲端技術趨勢》掌握最新發展
練習口述——找朋友互相模擬面試，練習用清楚的結構口頭回答
準備職涯故事——回顧《雲端工程師職涯發展》規劃你的下一步
學習 IaC——面試中展示 Terraform 經驗是很大的加分項

面試前最後一天的快速複習清單

如果只剩一天，優先複習這些高頻題：

GCP 資源階層和 IAM 繼承（Q1, Q31）
Compute 服務選擇和 MIG 自動擴縮（Q9, Q12, Q14）
資料庫比較和選型（Q19）
VPC 和防火牆基礎（Q25, Q26）
Service Account 最佳實務（Q32）
GKE Autopilot vs Standard（Q37）
Cloud Run vs Cloud Functions（Q39）
BigQuery 架構和分區/叢集（Q44, Q45）
即時資料管線設計（Q50）
成本優化策略（Q4 + Tip 3）

這 10 個知識點涵蓋了面試最常出現的問題。如果這些你都能用自己的話流暢講出來，那就準備得相當充分了。

祝你面試順利，順利拿到理想的雲端職位！

本文由登雲學院整理，持續更新中。如果這篇文章對你有幫助，歡迎加入書籤收藏，面試前隨時複習。有任何問題或補充，歡迎透過登雲學院的學習社群交流討論。