先別急著背產品名稱
第一次打開 Google Cloud，最容易被一長串服務名稱嚇到：Compute Engine、Cloud Run、GKE、BigQuery……看起來每個都要學，其實不用。
這一課先抓住三件事就好：
- 你為什麼會需要雲端
- Google Cloud 把資源放在哪裡
- 面對一個需求時，該從哪一類服務開始找
把這三件事弄懂，後面看到新產品，才知道它要解決什麼問題。
讀 Google Cloud 先用三層心智模型：責任從自建機房逐步移到受管服務；資源依 Global、Region、Zone 劃分故障與資料邊界；產品則從業務需求回推服務類別。ACE 的工作不是背清單，而是持續設定、部署、保護、監控並排除雲端環境問題。
Google Cloud 到底是什麼？
Google Cloud 是 Google 提供的一整套雲端服務。你可以按需求租用運算、儲存、資料庫、網路與 AI 資源，不必先買伺服器、等硬體到貨，再派人進機房安裝。
大家口中的 GCP 原本是 Google Cloud Platform 的縮寫。現在官方品牌主要使用 Google Cloud，不過工程師之間仍常說 GCP，兩者通常指的是同一套雲端平台。
雲端最值得記的不是「別人的電腦」，而是這三個特性：
- 隨用隨開：需要一台 VM 或一個資料庫，可以透過 Console、CLI 或 API 建立
- 用量計費：多數服務依實際使用量收費，不必一次買斷硬體
- 能自動化：同一套環境可以用指令或程式碼重複建立，不靠人工逐頁點選
雲端也不是把責任全部交給 Google。Google 負責資料中心、硬體和受管平台；你仍要管好帳號權限、資料、應用程式設定與成本。這條責任分界，之後談 IAM 和安全時會一直遇到。
流程圖暫時無法顯示。可先查看下方的流程與節點文字，或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向；方括號與引號內是節點名稱，可搭配下方圖解閱讀。
flowchart TB A["自建機房<br/>團隊管理設施、硬體、OS、應用與資料"] --> B["使用 Google Cloud"] B --> G["Google 負責<br/>資料中心、硬體與受管平台"] B --> C["客戶仍負責<br/>IAM、資料、<br/>應用設定與成本"] G --> S["共同責任<br/>邊界依服務型態改變"] C --> S
Region、Zone，差一個層級差很多
Google Cloud 把全球基礎架構切成 Region（區域） 和 Zone（可用區）。截至 2026 年 10 月，官方列出 43 個 Region、130 個 Zone。
- Region 是一個地理區域，例如台灣的
asia-east1 - Zone 是 Region 裡相互隔離的部署區，例如
asia-east1-a、asia-east1-b - Global resource 不綁單一 Region，例如 VPC network，也就是你在雲端上的私有網路
假設你把 VM 只放在一個 Zone，該 Zone 出問題，服務也會跟著停。把多台 VM 分散到同一 Region 的不同 Zone，才能扛住單一 Zone 故障。若連整個 Region 中斷都要撐住，就得再做跨 Region 設計。
選位置時，先問三件事：使用者在哪裡、資料能不能離開特定國家、該服務在當地 Region 有沒有提供。不要只挑離自己最近的地點。
流程圖暫時無法顯示。可先查看下方的流程與節點文字，或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向；方括號與引號內是節點名稱，可搭配下方圖解閱讀。
flowchart TB G["Global resource<br/>例如 VPC network"] --> R1["Region：asia-east1"] G --> R2["另一個 Region"] R1 --> Z1["Zone a<br/>VM instance"] R1 --> Z2["Zone b<br/>VM instance"] R1 --> Z3["Zone c"] Z1 -. "單一 Zone 故障" .-> Z2 R1 -. "整個 Region 故障時<br/>需要跨 Region 設計" .-> R2
用需求找服務，不要反過來
Google Cloud 產品很多，但日常工作大致繞著下面幾個問題：
| 你正在處理的問題 | 先認識這些服務 | 一句話理解 |
|---|---|---|
| 程式要跑在哪裡？ | Compute Engine、GKE、Cloud Run | VM、Kubernetes、全代管容器 |
| 檔案和磁碟放哪裡？ | Cloud Storage、Persistent Disk | 物件儲存、VM 區塊儲存 |
| 應用資料放哪裡？ | Cloud SQL、Firestore、Spanner | 關聯式、文件型、全球分散式資料庫 |
| 資源怎麼互通？ | VPC、Cloud Load Balancing、Cloud DNS | 私有網路、流量分配、網域解析 |
| 誰可以做什麼？ | IAM、Secret Manager、Cloud KMS | 權限、機密、加密金鑰 |
| 怎麼知道系統壞了？ | Cloud Monitoring、Cloud Logging | 指標、告警、日誌 |
表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。
例如「我要部署一個 HTTP API」還不是完整需求。若你想自己管理作業系統，可以從 Compute Engine 開始；只想交付容器、不想顧 VM，Cloud Run 往往更省事；已經有 Kubernetes 團隊與需求，再看 GKE。服務沒有絕對的最好，只有是否符合限制。
流程圖暫時無法顯示。可先查看下方的流程與節點文字，或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向；方括號與引號內是節點名稱，可搭配下方圖解閱讀。
flowchart TB
A["要部署應用程式"] --> B{"需要控制 OS<br/>或特殊驅動？"}
B -->|"是"| C["Compute Engine"]
B -->|"否"| D{"已有 Kubernetes<br/>需求與維運能力？"}
D -->|"是"| E["GKE"]
D -->|"否"| F{"能封裝成無狀態容器？"}
F -->|"是"| G["Cloud Run"]
F -->|"否"| H["重新確認執行模型<br/>與服務限制"] Google Cloud 為什麼值得學？
Google Cloud 的特色不是每一項都贏過別家，而是幾個領域特別有辨識度：
- 資料分析：BigQuery 把基礎設施管理藏在後面，適合大量分析查詢
- 容器平台：Kubernetes 源自 Google，GKE 提供代管的 Kubernetes 環境
- AI 平台：Gemini Enterprise Agent Platform（原 Vertex AI）把模型開發、部署與生成式 AI 工具放在同一個平台
- 全球網路：許多服務能利用 Google 的全球網路做跨區連線與流量分配
但實務選雲還要看團隊經驗、既有系統、法規、地區服務供應和總成本。把「某家雲一定最好」當答案，通常太早。
ACE 在考什麼？
Associate Cloud Engineer 現行考綱（PDF） 分成四個 Section；這一版從 2026-06-30 起用在英文考試。括號裡是官方標示的約略比重：
- 設定雲端環境（約 20%）
- 規劃與實作雲端方案（約 30%）
- 確保雲端方案順利運作（約 30%）
- 設定存取權與安全性（約 20%）
你不只要認得產品名稱，還要真的會建立專案、切換 gcloud 設定、部署資源、看日誌，再把權限收好。官方也建議考前累積至少六個月的實作經驗；課程可以幫你少走彎路，操作次數仍得自己補。
這門入門課只有三堂，不會把整份考綱走完：這一課先建立觀念，第 2 課設定環境（專案、帳單、gcloud），第 3 課部署第一台 VM。其餘範圍沿著 零基礎 → ACE 認證 學習路徑往下接。
流程圖暫時無法顯示。可先查看下方的流程與節點文字，或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向；方括號與引號內是節點名稱，可搭配下方圖解閱讀。
flowchart TB A["設定環境<br/>Project、Billing、gcloud"] --> B["規劃與配置<br/>服務、位置、容量"] B --> C["部署實作<br/>建立與更新資源"] C --> D["維持運作<br/>監控、日誌、排錯"] D --> E["存取與安全<br/>IAM、Secret、Policy"] E --> F["觀察結果與新需求"] F --> A
💡 考試小提示
題目問「該選哪個服務」時，先找需求裡的限制：要不要管理伺服器、能不能中斷、資料量多大、需要哪個可用性等級。先排除不符合的選項，比硬背產品表有效。
離開這一課前，確認你答得出來
先不看前面的教材，用自己的話回答下面三個情境，再展開參考判斷。每題都要說出「需求裡的哪個限制，讓我做這個選擇」，只背出產品名稱還不算完成。
情境 1：兩台 VM 就能避免停機嗎？
同事把兩台 VM 都放在 asia-east1-a，說「有兩台就不怕 Zone 故障」。這個判斷哪裡有問題？如果要承受單一 Zone 故障，部署還缺什麼？
看參考判斷與檢核標準
兩台 VM 仍在同一個 Zone，會一起受到該 Zone 故障影響。應把可服務流量的實例分散到不同 Zone，並安排流量切換；資料與其他相依服務也要避免只留在單一 Zone。同 Region 多 Zone 的設計，仍不等於能承受整個 Region 中斷。
檢核標準：你能說出「數量增加」和「故障邊界分開」的差別，也能指出應用、資料、流量都要一起設計。若漏掉其中一點，回讀 Region 與 Zone，再查 官方故障邊界說明。
情境 2：同樣是 HTTP API，為什麼選擇不同？
A 團隊的 API 已容器化，符合 Cloud Run 執行要求，也希望減少 OS 維護。B 團隊的程式必須安裝特定 OS 套件並掌控 VM 設定。各自先評估哪個服務？你還會確認什麼？
看參考判斷與檢核標準
A 先評估 Cloud Run，把容器執行平台交給 Google 管理；B 先評估 Compute Engine，保留 OS 與 VM 設定的控制權。部署前仍要確認應用的執行限制、資料存放方式、位置、權限與成本，而不是只看「有沒有 HTTP」。
檢核標準：你用「需要的控制權」與「願意承擔的維護工作」解釋選擇，而不是說某個產品永遠比較好。答不清楚就回讀 用需求找服務，對照 Cloud Run 官方介紹。
情境 3：上雲後，誰負責收好資料權限？
團隊把資料放上雲後，讓所有成員都能讀取，理由是「安全已經由 Google 負責」。你會怎麼解釋問題，並提出第一個改善動作？
看參考判斷與檢核標準
Google 管理平台與基礎設施，不會替團隊決定誰應該讀取業務資料。先盤點哪些人或服務真的需要存取，再調整 IAM 授權，移除不必要的權限；應用設定、資料保護與成本也仍需要團隊管理。
檢核標準：你能指出資料存取是團隊要管理的責任，並提出具體的權限檢查動作。若只回答「雲端比較安全」，回讀 共同責任的分界。
能獨立說出三題的選擇理由，再將這一課標記為完成；仍需要看答案的題目，隔天再試一次。
名詞還不熟就查 GCP 術語表，服務分類可以對照 GCP 核心服務速查表；想讀更完整的版本，看 GCP-101 新手入門。
下一課會打開 Google Cloud Console，建立專案，順便把新手最常混淆的專案名稱、Project ID、帳單帳戶一次講清楚。