examlab .net 用最有效率的方法，考取最有價值的證照
支持
本篇導覽 約 18 分鐘

GCP 資源階層：治理的基礎

3,550 字 · 約 18 分鐘閱讀 ·

為 Associate Cloud Engineer (ACE) 考試掌握 Google Cloud 資源階層。了解組織 (Organizations)、資料夾 (Folders)、專案 (Projects) 和資源 (Resources) 如何與 IAM 繼承互動。

立即做 20 題練習 → 免費 · 不用註冊 · ACE

理解 Google Cloud 資源階層

Google Cloud 資源階層是在 GCP 中管理存取權限、計費和組織結構的基石。對於 Associate Cloud Engineer (ACE) 考試來說，理解這個階層不僅僅是知道有哪些層級，更重要的是理解政策和權限是如何向下流動的。

可以將資源階層想像成雲端環境的「骨架」。你創建的每一個資源——無論是 Compute Engine 虛擬機器 (VM)、Cloud Storage 儲存桶，還是 GKE 叢集——都必須駐留在專案中，而該專案則位於更廣泛的結構之內。

白話文解釋

為了真正掌握資源階層，讓我們透過三個不同的視角來觀察：

1. 企業大樓類比 (實體結構)

想像一個巨大的企業總部：

  • 組織 (Organization) 是整棟大樓。它擁有土地和建築結構。
  • 資料夾 (Folders) 是樓層。你可能有「財務樓層」、「工程樓層」和「行銷樓層」。
  • 專案 (Projects) 是每個樓層上的獨立辦公室。這是實際工作發生的地方。
  • 資源 (Resources) 是辦公室內的辦公桌和設備。

如果你有大樓（組織）的鑰匙，你可能擁有對所有內容的基本存取權限。如果你是樓層管理員（資料夾），你控制該樓層的所有辦公室。

2. 檔案系統類比 (數位結構)

想想你電腦的作業系統：

  • 組織 (Organization) 是根目錄 (/)。
  • 資料夾 (Folders) 是子目錄 (例如 /projects/frontend/)。
  • 專案 (Projects) 是程式碼所在的特定應用程式資料夾。
  • 資源 (Resources) 是這些資料夾中的單個檔案。

就像在檔案系統中一樣，如果你在根目錄設定了「唯讀」，那麼底下的每個檔案都會繼承該屬性，除非被明確覆蓋。

3. 家譜類比 (生物結構)

想想家族中的繼承：

  • 組織 (Organization) 是曾祖父母。
  • 資料夾 (Folders) 是父母。
  • 專案 (Projects) 是孩子。
  • 資源 (Resources) 是特徵。

如果曾祖父母有一條特定的規則 (例如「出門一定要戴帽子」)，該規則會傳給父母，然後傳給孩子，最後體現在資源上。一旦在頂層設定，就很難輕易地「取消繼承」某個特徵。

階層的四個層級

1. 組織節點 (The Organization Node)

組織資源代表一家公司，是 Google Cloud 資源階層中的根節點。它與 Google Workspace 或 Cloud Identity 網域相關聯。

組織節點是階層的根部，提供對所有資源的集中檢視與控制。 Source ↗

2. 資料夾 (Folders)

資料夾提供了一種額外的分組機制，以及專案之間的隔離層。它們可用於模擬組織內的不同法律實體、部門或團隊。

資料夾最多可以巢狀嵌套 10 層深，允許建立複雜的組織結構。 Source ↗

3. 專案 (Projects)

專案是啟用和使用 Google Cloud 服務的主要基礎。所有資源都必須屬於一個專案。專案是管理計費和啟用 API 的層級。

每個專案都有唯一的專案 ID (Project ID)、專案名稱 (Project Name) 和專案編號 (Project Number)。只有專案 ID 和名稱可以由使用者選擇，且專案 ID 是全球唯一且不可更改的。 Source ↗

4. 資源 (Resources)

資源是服務層級的組件，例如虛擬機器、資料庫和儲存桶。這些是樹狀結構的「葉子」。

政策繼承：黃金法則

ACE 考試中最關鍵的概念是政策繼承 (Policy Inheritance)。權限 (IAM) 和組織政策 (Organization Policies) 總是從父級繼承到子級。

  • 如果你在資料夾層級授予 roles/viewer，該使用者就是該資料夾內每個專案的檢視者。
  • 你可以在較低層級添加更多權限，但你不能在較低層級移除繼承自上層的權限。

考試陷阱：常見問題描述了一個情境，使用者在資料夾層級擁有「編輯者 (Editor)」權限，但你希望他們在該資料夾內的一個特定專案中僅擔任「檢視者 (Viewer)」。這無法透過 IAM 繼承來實現。你需要移動該專案或更改資料夾層級的角色。 Source ↗

透過 gcloud CLI 管理專案

作為一名 Associate Cloud Engineer，你必須知道管理階層的指令。

建立專案：'gcloud projects create PROJECT_ID'。列出專案：'gcloud projects list'。 Source ↗

  • 建立專案： gcloud projects create my-ace-project-123
  • 連結計費： gcloud billing projects link PROJECT_ID --billing-account BILLING_ACCOUNT_ID
  • 設定預設專案： gcloud config set project PROJECT_ID

組織政策 (Organization Policies) 與 IAM 是分開的機制，可掛載在 GCP 資源階層的組織、資料夾或專案節點上。布林限制條件 (Boolean constraints，例如「Disable Serial Port Access」) 與清單限制條件 (List constraints，例如「Allowed Locations」) 在上層設定後，若限制條件類型允許，可在較具體的子節點覆寫；正式套用前務必先以 Dry Run 模式驗證影響範圍。 Source ↗

資源管理員角色 (Resource Manager Roles)

為了管理階層本身，Google 提供了特定角色：

  • roles/resourcemanager.organizationAdmin: 對組織的完整控制權。
  • roles/resourcemanager.folderAdmin: 可以建立和管理資料夾。
  • roles/resourcemanager.projectCreator: 可以在資料夾或組織內建立新專案。

階層設計的最佳實務

  1. 鏡像你的組織結構： 使用資料夾來代表部門 (人力資源、工程、財務)。
  2. 環境隔離： 使用「生產 (Prod)」、「測試 (Staging)」和「開發 (Dev)」資料夾來套用不同的安全政策。
  3. 最小權限原則： 在最高層級套用最嚴格的角色，並隨著向下移動而添加特定權限。

常見考試情境

  • 情境： 開發人員需要建立專案，但不應能夠刪除專案。
    • 解決方案： 在資料夾層級分配 roles/resourcemanager.projectCreator。
  • 情境： 你需要確保「財務 (Finance)」資料夾中的所有專案都啟用了計費匯出。
    • 解決方案： 在「財務」資料夾層級套用組織政策或必要的 IAM 角色。

常見問題 (FAQ)

問：專案可以在沒有組織的情況下存在嗎？ 答：可以，存在「無組織 (No Organization)」專案，但它們缺乏集中管理功能，通常用於個人用途。

問：專案 ID 是否與專案名稱相同？ 答：不同。專案名稱供你參考 (可以更改)。專案 ID 是全球唯一的，用於 API 和 CLI (不可更改)。

問：我可以建立多少個專案？ 答：有一個「專案配額 (Project Quota)」。如果達到上限，你可以透過控制台申請增加。

問：我可以將專案在資料夾之間移動嗎？ 答：可以，需要在該專案和目標資料夾上擁有 resourcemanager.projects.update 權限。

問：資料夾可以包含其他資料夾嗎？ 答：可以，資料夾最多可以嵌套 10 層深。

ACE 總結清單

  • 理解 4 個層級 (組織、資料夾、專案、資源)。
  • 記住權限只能向下流動。
  • 了解專案 ID、名稱和編號之間的區別。
  • 熟悉 gcloud projects create 和 gcloud projects list。
  • 認識到組織節點需要 Google Workspace 或 Cloud Identity。

官方資料來源

更多 ACE 主題