GCP 面試題指南：2026 年 20 道核心題與回答框架

Google Cloud 面試最難的地方，通常不是忘記某個服務的規格，而是面試官在你回答之後接著問：「為什麼？」

如果第一題問 Cloud Run 和 GKE 怎麼選，只背「Cloud Run 是 Serverless、GKE 是 Kubernetes」很快就會卡住。下一題可能是：服務需要 sidecar 怎麼辦？有長連線呢？團隊是否有 Kubernetes 維運能力？成本要怎麼估？出了事故怎麼回滾？

所以這份指南不再堆五十個看似完整、其實容易過期的標準答案。下面選出二十個能展開追問的核心題，示範如何把答案說成一個有條件、有取捨、也有營運考量的技術判斷。

回答技術題的四段式框架

回答服務選型或架構題時，可以依序說：

需求：流量、延遲、一致性、資料量、合規與團隊條件是什麼？
選擇：在這些假設下，我會先選哪個服務？
取捨：它換來了什麼，又犧牲了什麼？
營運：怎麼監控、擴充、備份、控成本與復原？

例如被問「Cloud Run 還是 GKE」時，可以先回答：「如果是一個無狀態 HTTP 服務，沒有 Kubernetes API、特權容器或自訂 node 的需求，我會先用 Cloud Run，因為營運面較簡單。若團隊需要 StatefulSet、複雜的 sidecar、叢集層網路策略或統一的 Kubernetes 平台，再評估 GKE。最後會用壓測、SLO 與成本估算確認。」

這比「小專案用 Cloud Run、大專案用 GKE」更可靠，因為專案大小不是產品邊界。

不同職位，準備深度不同

職位	應優先準備	面試官可能繼續追問
Cloud Engineer	IAM、VPC、Compute、CLI、監控	權限、部署、故障排除與日常操作
SRE / DevOps	GKE、Cloud Run、CI/CD、SLO、事件處理	回滾、容量、可觀測性與事故應變
Data Engineer	Cloud Storage、BigQuery、Pub/Sub、Dataflow	schema、延遲、重送、分區與成本
Cloud Architect	資源階層、網路、資料庫、安全、DR	取捨、治理、RTO/RPO 與遷移策略

沒有任何一份題庫能代表所有公司。職缺描述若反覆出現 GKE、Terraform 或 BigQuery，就應把時間放在那個技術棧，不必平均背完所有 Google Cloud 產品。

一、平台與治理

Q1：請說明 Google Cloud 的資源階層

基本結構是 Organization → Folder → Project → service resource。Folder 可以再包含 Folder，Project 則承載 VM、bucket、database 等服務資源。

更完整的回答要提到兩件事：

IAM allow policy 會往下繼承；某個資源的有效 allow policy，是本身與祖先 allow policy 的聯集。
Project 不只是帳單容器，也常被當成 trust boundary。共享同一組生命週期、權限與責任歸屬的資源，才適合放在同一個 Project。

如果面試官問「子 Project 能不能撤銷 Organization 授予的角色」，不要只回答不能。Allow policy 本身不能用子層的 allow binding 抵銷，但 IAM deny policy、Principal Access Boundary 與 Organization Policy 可能進一步限制實際行為，應先確認用的是哪一種政策模型。

延伸閱讀：IAM 基礎入門

Q2：Region 和 Zone 怎麼選？

Region 是地理區域，Zone 是 Region 內的部署區域。選擇時至少看：

使用者與相依資料的延遲
服務是否支援該 Region
資料落地與法規要求
區域間傳輸成本
可用性目標與故障範圍

同 Region 多 Zone 能降低單一 Zone 故障風險，但不等於跨 Region 災難復原。若業務要求區域級事故後仍可服務，還要定義跨 Region 的資料複寫、流量切換、RTO 與 RPO。

一句「主站放台灣、備援放東京」仍不夠，因為資料庫能否跨區一致、切換由誰觸發，以及使用者可接受多少資料損失，才是設計核心。

Q3：Project 應該依團隊、環境還是應用拆分？

沒有通用答案。Google 的 landing zone 指南也強調，資源階層要配合組織的治理方式。

常見考量包括：

prod 與 non-prod 是否需要不同權限和政策
團隊能否獨立管理生命週期
Billing 與 quota 是否要隔離
網路是否由中央團隊控管
日誌與稽核資料要集中還是分開

實務上可以用 Folder 表示環境或事業單位，用 Project 當應用或 trust boundary，再透過 Shared VPC 集中網路。重點不是畫出唯一正確的樹，而是解釋這棵樹如何降低權限外溢與營運耦合。

Q4：Labels、Network Tags 與 Resource Manager Tags 有什麼不同？

Labels 是資源上的 key-value metadata，常用於篩選、盤點與成本分析。
Network Tags 主要用來指定 VPC firewall rule 套用到哪些 VM。
Resource Manager Tags 是受 IAM 管理、可沿資源階層使用的 tag key/value，可搭配條件式政策與 Organization Policy。

不要只用「Labels 管錢、Tags 管網路」作答，因為 Resource Manager Tags 已經超出網路用途。最好先說清楚是哪一種 tag，再討論它的政策能力。

Q5：Budget 能不能限制支出？

不能。Cloud Billing Budget 會依實際或預測成本發出 email 或 Pub/Sub 通知，但不會自動停止用量，而且成本資料有延遲。

比較好的回答是分層控制：

Budget 和 anomaly detection 用來發現趨勢。
Quota、Cloud Run maximum instances、BigQuery maximum bytes billed 等機制縮小用量上限。
IAM 限制誰能建立高成本資源。
Label、Billing Export 與定期 review 找出責任歸屬。
若要自動停用資源，必須處理通知延遲、重送、例外清單與資料風險。

延伸閱讀：Google Cloud Free Tier 與帳單管理

二、Compute、Container 與 Serverless

Q6：Compute Engine、GKE、Cloud Run 怎麼選？

先問應用要控制到哪一層：

需求	優先評估	原因
需要特定 OS、driver、legacy agent 或完整 VM 權限	Compute Engine	控制作業系統與 VM 生命週期
需要 Kubernetes API、生態系或叢集層控制	GKE	支援 Kubernetes 工作負載與平台能力
無狀態 HTTP、gRPC、WebSocket 或事件服務	Cloud Run	不需管理叢集，依服務自動擴縮
有開始與結束的容器批次	Cloud Run job 或 Batch	不需假裝成長期 HTTP 服務

「已經容器化」不代表一定要 GKE。若應用不依賴 Kubernetes，Cloud Run 通常能減少營運工作。反過來，若需要 DaemonSet、特定 node、複雜的 multi-container pod 或叢集政策，GKE 會更自然。

Q7：Managed Instance Group 解決什麼問題？

Managed Instance Group（MIG）以 instance template 管理一組 VM，可搭配 autoscaling、autohealing、regional deployment 與 rolling update。

面試時要分清楚：

Load balancer health check 決定是否把流量送給 VM。
Autohealing health check 決定是否重建不健康 VM。
Autoscaler 決定執行個體數量，不能取代應用層容量測試。

Unmanaged instance group 比較像把既有 VM 放進同一個 backend 的集合，不會自動維持 template 或重建成員。若回答「MIG 就是 VM 的 Kubernetes」，會忽略兩者的調度與應用模型差異。

Q8：Spot VM 適合什麼工作？

Spot VM 隨時可能被回收，價格也會依機型與區域不同。適合能中斷、能重試、能從 checkpoint 繼續的工作，例如批次轉檔、可分割資料處理、CI worker 或容錯型訓練。

一個完整答案應說明：

工作單位要足夠小，失敗後不必全部重做。
狀態與 checkpoint 要放在 VM 之外。
queue message 的 acknowledgement 時機要避免工作遺失。
MIG、GKE 或 Batch 如何補回容量。
正常隨需 VM 是否保留基礎容量，避免 Spot 全部不可用。

不要背固定折扣或回收時間，把設計建立在「可能隨時消失」才安全。

Q9：Cloud Run service、function 和 job 有什麼差別？

Service 持續接收 HTTPS 請求，適合 Web、API、gRPC、WebSocket 與 push event。
Function 用 Functions Framework 寫一個 HTTP 或 CloudEvents handler，由平台從原始碼建置並部署成 Cloud Run 服務。
Job 執行工作後結束，適合 migration、批次處理與排程任務。

如果是 Kafka consumer 或持續 pull queue 的背景程序，還可評估 Cloud Run worker pool，但要另外處理它的容量與擴縮模式。

回答時順便提到 concurrency、maximum instances、request timeout、idempotency 與 downstream connection limit，會比只說「函式比較簡單」更有實戰感。

延伸閱讀：Cloud Run、functions 與 App Engine 選型

Q10：GKE Autopilot 和 Standard 怎麼選？

Autopilot 由 GKE 管理 node、scaling 與多項安全預設，官方把它列為建議的操作模式；Standard 則讓團隊控制 node pool 與更多叢集設定。

目前的選擇已不是完全二分：Standard cluster 也能透過 compute class 執行 Autopilot workload。回答時可以說：

多數一般 production workload，先評估 Autopilot cluster。
需要特定 node 設定、alpha feature、特殊主機操作或更直接的基礎設施控制，再評估 Standard。
不論哪種模式，都要管理 workload request/limit、release channel、maintenance window、網路與可觀測性。

「Autopilot 不支援 DaemonSet」這類絕對句要避免；支援範圍會更新，應指出真正依賴的權限或 node 能力，再查當前限制。

三、Storage、Database 與 Analytics

Q11：Cloud Storage 的 storage class 怎麼選？

一般物件常見 Standard、Nearline、Coldline、Archive。存取頻率愈低的類別，at-rest storage 通常較便宜，但有 retrieval fee 和 minimum storage duration。

選擇時不要只問「多久讀一次」，還要問：

物件會放多久，會不會頻繁覆寫或提早刪除？
retrieval 與 operation 成本是多少？
資料和 compute 是否在同一位置？
存取模式是否不確定，適不適合 Autoclass？
是否是極低延遲、高 I/O 的 zonal workload，需要 Rapid Bucket？

所有一般 storage class 都能線上存取，不是 Archive 要等人工取帶。Class 主要改變價格與可用性模型，不是把資料搬到離線磁帶。

延伸閱讀：Cloud Storage 完整指南

Q12：Cloud SQL、AlloyDB、Spanner、Firestore、Bigtable 怎麼選？

先用資料模型和存取模式切，不要用「小資料庫、大資料庫」猜：

需求	優先評估
一般 MySQL、PostgreSQL、SQL Server 相容工作負載	Cloud SQL
PostgreSQL 相容、需要較高吞吐與讀取擴展	AlloyDB
關聯式資料、水平擴展、跨區強一致與高可用	Spanner
文件模型、行動或 Web 應用、即時同步	Firestore
大量 key-based 低延遲讀寫、寬欄或時序型資料	Bigtable

再追問 transaction、一致性、query pattern、索引、資料量、區域、備份、團隊 SQL 能力與成本。不要在沒有 workload benchmark 的情況下引用「快幾倍」，也不要用固定月費當產品邊界。

延伸閱讀：Google Cloud 資料庫選型指南

Q13：High availability、read replica 和 backup 有什麼差別？

三者解決不同問題：

High availability 降低單一執行個體或 zone 故障造成的中斷。
Read replica 分擔讀取或提供跨區副本，不等於自動成為完整 DR。
Backup / point-in-time recovery 用於誤刪、資料損壞與回復到過去狀態。

只開 HA 不能防止應用把錯誤資料同步到 standby；只有 backup 也無法滿足低 RTO。回答資料庫可靠性題時，先問 RTO、RPO、故障範圍與復原演練頻率，再決定組合。

Q14：BigQuery partitioning 和 clustering 有何不同？

Partitioning 依日期、攝取時間或整數範圍把資料切成 partition，查詢加上 partition filter 可避免掃描無關分區。Clustering 則依選定欄位組織 storage block，讓 BigQuery 在符合條件時做 block pruning。

常見做法是先以時間 partition，再用常出現在 filter 或 aggregation 的欄位 clustering，但不是每張表都要兩者一起開。小表、更新模式或查詢分布不同時，收益可能有限。

面試若追問成本，可以回答：先看 dry run 或 query plan 的 bytes processed，再比較 on-demand 與 capacity model；不要直接背每 TiB 的單一價格，因為價格和 edition 會更新。

四、Networking 與 Security

Q15：Google Cloud VPC 有什麼特性？

VPC network 是 global resource，subnet 則屬於 Region。這讓同一個 VPC 可以包含多個 Region 的 subnet，但不代表跨區流量沒有成本或延遲。

Firewall policy 是 stateful，應用在 VM 網路介面層；route 決定封包往哪裡走，firewall 決定是否允許。排查連線時可以依序確認：

DNS 是否解析到預期位址
Route 是否存在且 next hop 正確
Hierarchical、global 或 VPC firewall policy 是否允許
Target service account 或 network tag 是否匹配
VM 內 OS firewall 與應用是否監聽正確介面
回程路由、NAT 與對端規則是否成立

Q16：Application Load Balancer 和 Network Load Balancer 怎麼選？

先看流量語意：

HTTP(S) routing、TLS termination、URL map、Cloud CDN 或 Cloud Armor，選 Application Load Balancer。
TCP proxy、TLS proxy、UDP、保留 client source IP 等需求，再從 Network Load Balancer 類型中選。

接著判斷 external 或 internal、global、cross-region 或 regional，以及 backend 類型。Google Cloud 的 load balancer 產品不只「四種」，用 L4/L7 加內外部的舊表格很容易漏掉 proxy、passthrough 與 cross-region deployment mode。

延伸閱讀：Load Balancing 選型

Q17：Shared VPC 和 VPC Network Peering 有何差別？

Shared VPC 讓同一 Organization 內的 service project 使用 host project 的 subnet，由中央網路團隊管理 VPC、route 與 firewall。它解決的是多 Project 共用一套網路與權責分工。

VPC Network Peering 則連接兩個獨立 VPC，即使它們位於不同 Project 或 Organization。Peering 不具 transitive routing，兩側 IP range 也要避免衝突。

所以答案不是「生產環境一律 Shared VPC」。如果兩個組織各自擁有網路，Shared VPC 根本不適用；若同一企業要中央治理多個 application project，它才通常更合理。

Q18：Service account 要怎麼安全使用？

Service account 是 workload 的非人類身分，同時也是可被授權的 principal 與受管理的 resource。

安全順序可以這樣回答：

Google Cloud 上的 workload，將專用 service account attached 到執行資源。
GKE 使用 Workload Identity Federation for GKE。
外部雲或地端使用 Workload Identity Federation。
人員需要代為操作時使用 service account impersonation。
只有前述方式都不適用，才建立 user-managed service account key。

再搭配 least privilege、限制誰能 impersonate、停用未使用帳號、啟用 audit log，以及用 Organization Policy 禁止不必要的 key 建立。不要把「每 90 天輪替 JSON key」當第一選擇；最好的 key 管理通常是不建立 key。

五、系統設計與故障排除

Q19：如何設計一個高可用服務？

先問 SLO、RTO、RPO 和可接受成本，再從故障範圍往下設計：

單一 process：health check、graceful shutdown、retry budget
單一 instance：多 instance 與負載平衡
單一 zone：regional deployment
單一 region：跨 Region 流量與資料策略
人為錯誤：progressive delivery、權限、backup 與復原演練

高可用不等於把每個服務都開 multi-region。若資料層不能安全切換，前端多區只是把錯誤放大；若業務允許數小時復原，昂貴的 active-active 也可能不合理。

Google Cloud Well-Architected Framework 把 reliability、security、operations、cost、performance 與 sustainability 分開檢視。面試時能主動說明這些非功能需求如何互相牽制，比畫滿產品 logo 更重要。

Q20：Cloud Run 出現大量 5xx，你會怎麼查？

先確定是誰回的 5xx，再縮小範圍：

事件時間與影響範圍：單一 revision、region 還是所有流量？
Cloud Monitoring：request count、latency、instance count、container CPU/memory。
Cloud Logging：應用 exception、啟動失敗、記憶體超限與 downstream timeout。
Revision 設定：image、environment variable、secret、service account、ingress、timeout。
Runtime contract：程式是否監聽 $PORT、能否在啟動期限內 ready。
相依服務：Cloud SQL connection、DNS、VPC egress、第三方 API quota。
最近變更：把流量切回上一個健康 revision，先止血再找根因。

不要一看到 502 就直接加 CPU。先用指標建立假設，再用 log、trace 或 rollback 驗證。

一道系統設計題的完整答法

題目：「設計一個讓使用者上傳照片、非同步產生縮圖，再提供全球下載的服務。」

先問問題

檔案大小、格式與每日上傳量？
縮圖需要幾秒完成？失敗可以重試嗎？
原圖是否含個資，能不能公開？
使用者分布、下載流量與快取命中預期？
原圖和縮圖要保存多久？

一個合理起點

API 在 Cloud Run 產生短效 Signed URL，讓前端直接上傳 Cloud Storage，避免檔案穿過應用服務。
Cloud Storage 事件經 Eventarc 觸發 Cloud Run function 或 service。
處理器用 object generation 或 event ID 去重，縮圖寫到另一個 prefix 或 bucket。
下載由 External Application Load Balancer 與 Cloud CDN 提供，private origin 依權限需求設計。
原圖和縮圖設定不同 lifecycle、soft delete 與 retention 策略。
監控處理失敗率、queue age、處理延遲、5xx 與 storage/network cost。

主動說出取捨

若圖片處理依賴特定原生套件，可以用 Cloud Run 自訂映像；若每次處理很久或適合成批，則改用 Cloud Run job。若 CDN cache 是公開內容，要設計不含敏感資料的 cache key 與 invalidation；若資料必須留在特定國家，location 選擇會限制 DR 與服務組合。

這段取捨才是系統設計題真正要看的部分。

準備面試的練習方式

1. 每題只寫關鍵字，不寫逐字稿

逐字背誦很容易在追問時斷線。每題留下「需求、選擇、取捨、營運」四個提示，練習用不同措辭回答。

2. 準備三個真實故事

至少準備：

一次部署或 migration
一次故障排除
一次成本、安全或效能改善

用 STAR（Situation、Task、Action、Result）說明，Result 只放你真的量過的數字。沒有 production 經驗也可以用 lab 或 side project，但要誠實交代規模。

3. 練習承認不確定

可以這樣回答：「我不確定目前的 quota 數字，不會拿記憶值做設計。我會先查該 Region 的 Quotas 頁，再用壓測確認。」

這比硬背已經改版的上限可靠，也顯示你知道如何取得正確資訊。

4. 每個架構都補齊六個面向

Security：身分、最小權限、secret、資料邊界
Reliability：SLO、故障範圍、retry、backup
Operations：部署、監控、告警、runbook
Cost：主要 SKU、流量、閒置資源、用量限制
Performance：延遲、吞吐、容量測試
Sustainability：資源效率、閒置容量與資料生命週期

這六項來自 Google Cloud Well-Architected Framework，也是一份比「多塞幾個產品」更好用的面試檢查表。

面試前一天的自我檢查

能用兩分鐘畫出 resource hierarchy 並解釋 IAM inheritance
能比較 Compute Engine、GKE、Cloud Run 的控制邊界
能說明 storage、database 選型需要哪些需求
能從 DNS、route、firewall、application 分層排查網路
能說明 service account key 的替代方案
能為一個架構定義 SLO、RTO、RPO
能說出三個真實經驗與自己的貢獻
遇到不知道的規格時，知道要去哪份官方文件確認

結論

面試準備不是把 Google Cloud 產品目錄背下來。真正有辨識度的回答，會先建立需求，再提出選擇、限制與營運方式。

這二十題若能用自己的話回答，並接受兩到三層追問，會比記住五十個固定數字更接近實際工作。產品名稱與限制會改版，但「需求、選擇、取捨、營運」這套思路不容易過時。

官方資料

Google Cloud 產品與限制會更新。本文最後查核日期為 2026-07-14；面試前請再依職缺技術棧確認相關產品的 release notes、quotas 與 pricing。