概
試験配点と出題範囲マップ
Section 1 の位置づけ
クラウド環境の「初期設定・基盤構築」に関する全設問。組織の構造設計からコスト管理まで、すべての運用の前提となる知識を問う。
試験での重要度
全体の約23%を占め、Section 2(計画・実装 ~26%)・Section 3(オペレーション ~22%)・Section 4(アクセス・セキュリティ ~18%)と並ぶ主要ドメイン。
頻出トラップパターン
「予算上限でリソースが自動停止する」「IAMと組織ポリシーは同じ」「Project IDは変更できる」— これらは試験の典型的な引っかけ問題。
1.1.1
リソース階層の構築
Google Cloud のすべてのリソースは Organization → Folder → Project → Resource という4層の厳密な階層で管理される。この構造を正確に理解することが、IAMポリシー設計・コスト管理・セキュリティ境界の設計すべての基礎となる。
階層の4レベル
| レベル | 特徴 | 主な役割 | 最大深度 |
|---|---|---|---|
| Organization | Google Workspace / Cloud Identity ドメインに自動紐付け。階層のルートノード。 | 組織全体のポリシー・IAM 管理の起点 | 1(固定) |
| Folder | オプション。部門・事業部・環境ごとのグループ化 | 環境(prod/dev)・部門・チームの分離 | 最大10階層 |
| Project | リソースの基本単位。課金・API・IAMの境界 | リソースの作成・管理コンテナ | 制限なし |
| Resource | 実際のクラウドサービス(VM、DB、GCS等) | ビジネスロジックを実行する実体 | 制限なし |
Project の3つの識別子
| 識別子 | 特性 | 例 | 試験での重要度 |
|---|---|---|---|
Project ID | グローバルに一意。作成後変更不可 | my-webapp-prod-20250101 | ⭐⭐⭐ |
Project Number | Google が自動採番する数値 ID。変更不可 | 123456789012 | ⭐⭐ |
Project Name | 表示名のみ。変更可能・一意性不要 | My Webapp Production | ⭐ |
IAMポリシーの継承メカニズム
試験トラップ: 下位レベルで上位から継承された権限を「削除」しても無効。有効な権限は全レベルの和集合(Union)で決まる。上位の許可を取り消す唯一の手段は IAM Deny Policy を使用すること。
gcloud コマンド
bash
# プロジェクトの作成(フォルダ配下)
gcloud projects create PROJECT_ID --name="My Project" --folder=FOLDER_ID
# 組織配下のプロジェクト一覧
gcloud projects list --filter="parent.id=ORG_ID"
# プロジェクトの詳細確認
gcloud projects describe PROJECT_ID
# 削除(30日間の猶予あり・元に戻せる)
gcloud projects delete PROJECT_ID
# 削除のキャンセル(30日以内)
gcloud projects undelete PROJECT_ID✅ ベストプラクティス
1
企業の組織構造をフォルダ階層に反映する
部門・事業部・チームの構造をそのままフォルダ設計に落とし込むことで、権限管理が直感的になりポリシーの継承が自然に機能する。
2
開発・ステージング・本番を別プロジェクトに分離する
セキュリティ境界・課金・アクセス制御を独立管理でき、本番環境への意図しない変更を防止できる。
3
複数プロジェクト共通の権限は親フォルダレベルで付与
個別設定の手間を省き、設定漏れを防止する。フォルダに付与したロールはすべての子プロジェクトに継承される。
4
同じ信頼境界のリソースを同一プロジェクトに配置
セキュリティポリシーの一貫性を保ち、異なるセキュリティレベルのリソースが混在するリスクを排除する。
1.1.2
組織ポリシーの適用
IAMとの根本的な違い
| 観点 | IAM | Organization Policy |
|---|---|---|
| 制御対象 | 誰が何をできるか(アクセス制御) | 何をどう設定できるか(リソース設定の強制) |
| 設定対象 | Principal(ユーザー・SA・グループ) | リソースの設定値・構成 |
| 例 | alice が VM を作成できる | 外部 IP を持つ VM は誰も作成できない |
| 強制力 | IAM Deny Policy で上書き可能 | IAM より強制力が高い(adminも制限される) |
主要な制約(Constraints)一覧
🔐 セキュリティ強化系
| 制約名 | 効果 | 推奨設定 |
|---|---|---|
iam.disableServiceAccountKeyCreation | SA の静的 JSON キー生成を禁止 | 組織全体で有効化 |
iam.disableServiceAccountKeyUpload | 外部キーのアップロードを禁止 | 有効化推奨 |
compute.requireOsLogin | 全 VM で OS Login を強制 | 有効化推奨 |
iam.allowedPolicyMemberDomains | IAM に追加できるドメインを限定 | 自社ドメインのみ許可 |
🌐 ネットワーク制限系
| 制約名 | 効果 |
|---|---|
compute.disableExternalIpAddresses | 外部 IP を持つ VM の作成を禁止 |
compute.vmExternalIpAccess | 外部 IP を許可する VM のリストを制限 |
compute.restrictCloudNATUsage | Cloud NAT の使用を特定サブネットに制限 |
🏛 データ主権・コンプライアンス系
| 制約名 | 効果 |
|---|---|
gcp.resourceLocations | リソースを特定リージョン/ゾーンに限定 |
storage.uniformBucketLevelAccess | Cloud Storage でバケットレベルアクセスを強制 |
storage.publicAccessPrevention | Cloud Storage のパブリックアクセスを禁止 |
継承と上書きのフロー
gcloud コマンド
bash
# 制約の一覧確認
gcloud org-policies list-constraints --organization=ORG_ID
# 外部IP禁止ポリシーを組織に適用
gcloud resource-manager org-policies enable-enforce constraints/compute.disableExternalIpAddresses --organization=ORG_ID
# YAMLでリージョン制限ポリシーを適用
gcloud org-policies set-policy policy.yaml --project=PROJECT_ID
# Dry-Runモード(本番適用前のテスト: 違反はログに記録されるが拒否されない)
gcloud org-policies set-policy policy.yaml --dry-run
# 有効なポリシーを確認
gcloud org-policies describe constraints/gcp.resourceLocations --effective --project=PROJECT_IDyaml — policy.yaml(リージョン制限の例)
name: projects/PROJECT_ID/policies/gcp.resourceLocations
spec:
rules:
- values:
allowedValues:
- in:asia-northeast1-locations # 東京
- in:asia-northeast2-locations # 大阪✅ ベストプラクティス
1
SA キー生成禁止を組織全体に適用
constraints/iam.disableServiceAccountKeyCreation を組織レベルで有効化し、静的 JSON キーの漏洩リスクを根本から排除する。2
Dry-Run モードで事前テスト
本番環境への適用前に必ず Dry-Run モードでテストし、意図しないサービス停止を防止する。
3
データ主権要件は resourceLocations で強制
GDPR・個人情報保護法などの規制対応として、リソースを特定リージョンに限定する。
4
開発環境は制約を緩和し本番は厳格に
フォルダ単位で制約を上書きし、開発効率と本番セキュリティのバランスを実現する。
1.1.3
IAMロールの付与
IAMの3要素
ロールの3種類
基本ロール(Basic Roles)
roles/viewer / roles/editor / roles/owner — 粒度が粗く過剰権限。本番環境では原則使用禁止。事前定義ロール(Predefined Roles)
Google がキュレーションした細かい権限セット。
roles/compute.instanceAdmin.v1 など。通常はこれを使用。カスタムロール(Custom Roles)
特殊なワークフローのみ自前で定義。管理コストが増大するため最小限にとどめる。
主要な事前定義ロール(試験頻出)
Compute Engine
| ロール | 権限の概要 |
|---|---|
roles/compute.admin | Compute Engine の完全管理 |
roles/compute.instanceAdmin.v1 | VM の作成・管理(ネットワーク変更は不可) |
roles/compute.osLogin | OS Login での SSH(sudo なし) |
roles/compute.osAdminLogin | OS Login での SSH(sudo あり) |
IAM / Service Accounts
| ロール | 権限の概要 |
|---|---|
roles/iam.serviceAccountAdmin | SA の作成・管理 |
roles/iam.serviceAccountUser | SA を VM にアタッチする権限(actAs) |
roles/iam.serviceAccountTokenCreator | SA の短期トークン生成(権限借用) |
roles/iam.workloadIdentityUser | Workload Identity 経由での SA アクセス |
gcloud コマンド
bash
# ユーザーにロールを付与
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:alice@example.com" --role="roles/compute.instanceAdmin.v1"
# グループにロールを付与(推奨)
gcloud projects add-iam-policy-binding PROJECT_ID --member="group:dev-team@example.com" --role="roles/run.developer"
# IAM Conditions(有効期限付き権限)
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:contractor@partner.com" --role="roles/viewer" --condition='title=Temp,expression=request.time < timestamp("2025-12-31T23:59:59Z")'
# カスタムロールの作成
gcloud iam roles create customDeployer --project=PROJECT_ID --file=custom-role.yaml
# IAMポリシーの確認
gcloud projects get-iam-policy PROJECT_ID✅ ベストプラクティス
1
最小特権の原則を徹底する
必要な権限だけを、必要な期間だけ、必要なリソースのみに付与する。侵害時の被害範囲を最小化できる。
2
個人ではなくグループにロールを付与
Google グループにロールを付与することで、メンバーの追加・削除だけで権限を管理でき、IAM ポリシーの変更が不要になる。
3
Policy Recommender で定期的に棚卸し
90日間の実際の使用状況を分析して不要な権限を検出・削除することで、権限のクリープ(肥大化)を防止する。
4
一時的な作業には IAM Conditions を活用
有効期限・時間帯・リソースパスの条件を付与することで、永続権限によるリスクを排除する。
1.1.4
Cloud Identity のユーザー・グループ管理
Cloud Identity vs Google Workspace
| 項目 | Google Workspace | Cloud Identity Free | Cloud Identity Premium |
|---|---|---|---|
| Gmail / Drive | ✅ あり | ❌ なし | ❌ なし |
| Google Cloud 利用 | ✅ | ✅ | ✅ |
| Organization ノード | ✅ 自動作成 | ✅ 自動作成 | ✅ 自動作成 |
| MDM(モバイル管理) | 一部 | ❌ | ✅ |
| コスト | 有料 | 無料 | 有料 |
自動プロビジョニング(GCDS / SCIM)
✅ ベストプラクティス
1
退職者管理は Cloud Identity での無効化を基点にする
Cloud Identity でアカウントを無効化するだけで、Google Cloud の IAM アクセスも即時失効する。
2
GCDS または SCIM で自動プロビジョニングを設定
人的ミスと管理コストを削減。Okta・Azure AD などの IdP との連携が標準的。
3
allUsers / allAuthenticatedUsers への権限付与を禁止
組織ポリシー
iam.allowedPolicyMemberDomains で自社ドメイン外への権限付与を制限する。📎 公式ドキュメント
▸ Cloud Identity Overview1.1.5
APIの有効化
新規プロジェクトではほとんどの API がデフォルトで無効化されている。これは攻撃面(Attack Surface)を最小化するためのセキュリティ設計であり、意図的な仕様である。
主要 API と対応サービス
| API 名 | 対応サービス |
|---|---|
compute.googleapis.com | Compute Engine |
container.googleapis.com | Google Kubernetes Engine |
run.googleapis.com | Cloud Run |
sqladmin.googleapis.com | Cloud SQL |
bigquery.googleapis.com | BigQuery |
secretmanager.googleapis.com | Secret Manager |
cloudasset.googleapis.com | Cloud Asset Inventory |
geminicloudassist.googleapis.com | Gemini Cloud Assist |
monitoring.googleapis.com | Cloud Monitoring |
logging.googleapis.com | Cloud Logging |
gcloud コマンド & Terraform
bash
# 複数APIを一括有効化
gcloud services enable compute.googleapis.com container.googleapis.com run.googleapis.com secretmanager.googleapis.com cloudasset.googleapis.com --project=PROJECT_ID
# 有効化されているAPIの確認
gcloud services list --enabled --project=PROJECT_IDhcl — Terraform
resource "google_project_service" "apis" {
for_each = toset([
"compute.googleapis.com",
"container.googleapis.com",
"run.googleapis.com",
"secretmanager.googleapis.com",
])
project = var.project_id
service = each.value
disable_on_destroy = false # Terraform削除時にAPIを無効化しない
}✅ ベストプラクティス
1
必要なAPIのみを有効化する
最小権限の原則をAPIレベルでも適用し、不要なAPIは無効のままにすることで攻撃面を最小化する。
2
Terraform で API 有効化を IaC 管理する
環境の再現性・一貫性を確保し、手動操作による設定漏れを防止する。
3
disable_on_destroy = false を設定Terraform destroy 時に意図しないサービス中断を防止する。
1.1.6
Google Cloud Observabilityの設定
Cloud Monitoring
メトリクス・アラート・SLO・ダッシュボード管理
Cloud Logging
ログ収集・検索・ルーティング・エクスポート
Cloud Trace
マイクロサービス間の分散トレーシング
Ops Agent
VM 内部のメモリ・ディスク使用率収集に必須
試験頻出: Compute Engine VM のメモリ使用量はデフォルトでは収集されない。Ops Agent のインストールが必須。CPU・ネットワーク I/O はエージェントなしで収集可能。
bash
# Monitoring/Logging API の有効化
gcloud services enable monitoring.googleapis.com logging.googleapis.com --project=PROJECT_ID
# Ops Agent のインストール(VM にSSH後)
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
# GKE Managed Service for Prometheus を有効化
gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --region=REGION1.1.7
クォータの評価と申請
| クォータの種類 | 例 |
|---|---|
| レート制限 | 1 秒あたりの API リクエスト数 |
| リソース制限 | プロジェクトあたりの VM 数・vCPU 数 |
| ストレージ制限 | GCS バケット数(デフォルト 100/プロジェクト) |
重要: クォータ増加申請は承認まで数日かかる場合がある。大規模デプロイ前は事前申請が必須。
📎 公式ドキュメント
▸ Quota Management — cloud.google.com1.1.8
スタンドアロン組織の設定
Google Cloud で Organization ノードを持つには Google Workspace または Cloud Identity のドメインが必要。これにより組織レベルの IAM・組織ポリシー・フォルダ管理が初めて利用可能になる。
Organization ノード取得フロー
個人 Gmail vs Cloud Identity vs Google Workspace
| 項目 | 個人 Gmail (@gmail.com) | Cloud Identity Free | Google Workspace |
|---|---|---|---|
| Organization ノード | ❌ 取得不可 | ✅ 自動作成 | ✅ 自動作成 |
| フォルダ管理 | ❌ 使用不可 | ✅ 使用可能 | ✅ 使用可能 |
| 組織ポリシー | ❌ 使用不可 | ✅ 使用可能 | ✅ 使用可能 |
| Shared VPC | ❌ 制限あり | ✅ 利用可能 | ✅ 利用可能 |
| Gmail / Drive | ✅ あり | ❌ なし | ✅ あり |
| コスト | 無料 | 無料 | 有料 |
| 本番推奨 | 非推奨 | 推奨 | 推奨 |
Organization 設定後の初期タスク
bash
# 組織 ID の確認
gcloud organizations list
# 組織レベルの IAM ポリシー確認
gcloud organizations get-iam-policy ORG_ID
# Organization Admin ロールを付与
gcloud organizations add-iam-policy-binding ORG_ID \
--member="user:admin@example.com" \
--role="roles/resourcemanager.organizationAdmin"
# フォルダの作成(組織直下)
gcloud resource-manager folders create \
--display-name="Production" \
--organization=ORG_IDCloud Identity Free で十分: Google Workspace のメール・ドライブ機能が不要な場合でも、Cloud Identity Free を取得するだけで Organization ノード・組織ポリシー・フォルダ管理のすべてが利用できる。追加コストゼロで企業レベルのガバナンスを実現できる。
✅ ベストプラクティス
1
個人用 Gmail (@gmail.com) での本番環境構築は避ける
Organization ノードが取得できず、組織ポリシー・フォルダ管理・Shared VPC が利用できない。
2
Cloud Identity Free でコストゼロで Organization を取得
メール機能不要でも Cloud Identity Free を使えば Organization ノードが取得できる。
3
Organization Admin は最小人数に限定し Break-Glass アカウントを設定
組織全体に影響を与える強力なロールのため、緊急用アカウントを含む最小構成にする。
1.1.9
クラウドネットワーキングの設定
Section 1 のネットワーキングでは VPC の初期セットアップとセキュアなアクセス設計が問われる。Google Cloud VPC は 1 つの VPC がグローバルに広がり、すべてのリージョンにまたがるサブネットを配置できる点が他社クラウドとの大きな違い。
デフォルト VPC vs カスタム VPC
| 項目 | デフォルト VPC | カスタム VPC(推奨) |
|---|---|---|
| 自動作成 | ✅ 各リージョンに自動 | ❌ 手動で設計・作成 |
| サブネット IP 範囲 | 固定(10.128.0.0/9) | 自由に設計 |
| VPC Peering | ❌ IP 重複で制限 | ✅ 計画的な IP 設計で対応 |
| Shared VPC | ❌ 非推奨 | ✅ 対応 |
| 本番環境での推奨 | 非推奨 | 推奨 |
セキュアなネットワーク初期設計フロー
gcloud コマンド
bash
# デフォルト VPC の削除(本番環境では推奨)
gcloud compute networks delete default --project=PROJECT_ID
# カスタムモード VPC の作成
gcloud compute networks create my-vpc \
--subnet-mode=custom \
--project=PROJECT_ID
# サブネットの作成
gcloud compute networks subnets create web-subnet \
--network=my-vpc \
--region=asia-northeast1 \
--range=10.1.1.0/24 \
--project=PROJECT_ID
# IAP からの SSH のみ許可するファイアウォールルール
gcloud compute firewall-rules create allow-ssh-iap \
--network=my-vpc \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20 \
--target-tags=iap-ssh \
--project=PROJECT_ID
# Cloud Router の作成(Cloud NAT の前提条件)
gcloud compute routers create my-router \
--network=my-vpc \
--region=asia-northeast1
# Cloud NAT の作成(外部 IP なし VM のアウトバウンドを確保)
gcloud compute routers nats create my-nat \
--router=my-router \
--region=asia-northeast1 \
--nat-all-subnet-ip-ranges \
--auto-allocate-nat-external-ips
# IAP トンネル経由で VM に SSH(外部 IP 不要)
gcloud compute ssh VM_NAME \
--zone=asia-northeast1-a \
--tunnel-through-iap✅ ベストプラクティス
1
デフォルト VPC を削除しカスタムモード VPC を使用
IP 範囲の計画的な管理と VPC Peering / Shared VPC 対応のために必須。将来の拡張を見越した IP 設計が重要。
2
VM に外部 IP を付与せず Cloud NAT でアウトバウンドを確保
外部 IP を持たない VM はインターネットから直接アクセスできないため、攻撃面を大幅に削減できる。
3
SSH アクセスは IAP トンネルのみに制限
IAP の IP レンジ(35.235.240.0/20)からのみ SSH を許可し、ブルートフォース攻撃を完全に遮断する。
4
ファイアウォールルールはネットワークタグベースで設定
IP ではなくタグで対象を指定することで、VM スケールアウト時も自動適用され管理コストを削減できる。
1.1.10
製品の地理的可用性の確認
| 考慮事項 | 詳細 |
|---|---|
| データ主権 | 特定国のデータを国外に出せない規制への対応(組織ポリシー gcp.resourceLocations と組み合わせる) |
| レイテンシ | エンドユーザーに近いリージョンを選択することで応答速度を最適化 |
| 可用性 | 複数ゾーンへの分散でゾーン障害に備える(リージョナル MIG・リージョナル PD) |
| サービス対応 | 一部サービスはリージョンによって提供されない場合がある。事前に確認が必要。 |
bash
# 利用可能なリージョン一覧
gcloud compute regions list
# 特定リージョンのゾーン一覧
gcloud compute zones list --filter="region:asia-northeast1"📎 公式ドキュメント
▸ Google Cloud Locations — 製品の地理的可用性1.1.11
Cloud Asset Inventory & Gemini Cloud Assist
Cloud Asset Inventory
組織全体の Google Cloud リソースと IAM ポリシーを一元管理・分析・エクスポートするサービス。
bash
# Cloud Asset Inventory API を有効化
gcloud services enable cloudasset.googleapis.com
# 組織全体の GKE クラスタを検索
gcloud asset search-all-resources --asset-types='container.googleapis.com/Cluster' --scope='organizations/ORG_ID'
# 外部 IP を持つ VM を特定(セキュリティ監査)
gcloud asset search-all-resources --asset-types='compute.googleapis.com/Instance' --scope='organizations/ORG_ID' --query='networkInterfaces.accessConfigs.natIP:*'
# 特定リソースへのアクセス権を持つ全 Identity を分析
gcloud asset analyze-iam-policy --organization=ORG_ID --full-resource-name='//storage.googleapis.com/projects/_/buckets/my-bucket'Gemini Cloud Assist の設定と活用
| 機能 | 説明 |
|---|---|
| リソース分析 | 自然言語でクラウドリソースを質問・分析 |
| アーキテクチャ提案 | ベストプラクティスに基づく構成提案と Terraform 生成 |
| 根本原因分析(RCA) | ログ・メトリクス・設定変更を横断的に分析して障害原因を特定 |
| コスト最適化提案 | 無駄なリソースの特定と削減提案(FinOps Hub 連携) |
bash
# Gemini Cloud Assist API を有効化
gcloud services enable geminicloudassist.googleapis.com --project=PROJECT_ID
# Gemini Cloud Assist ユーザーロールを付与
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:alice@example.com" --role="roles/geminicloudassist.user"
# Cloud Asset Viewer も必要(リソース分析機能のため)
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:alice@example.com" --role="roles/cloudasset.viewer"✅ ベストプラクティス
1
Cloud Asset Inventory のリアルタイムフィードを設定
リソース設定変更を即時検知でき、不正なリソース作成や IAM 変更を早期に発見できる。
2
analyze-iam-policy で定期的な権限棚卸しを実施
過剰な権限を持つ Principal を特定し、最小特権の原則を継続的に維持する。
3
Gemini Cloud Assist に cloudasset.viewer を付与
リソース分析機能が正常に動作するために必要。roles/geminicloudassist.user だけでは不十分。
1.1.12
Workforce Identity Federationの設定
Workload Identity Federation との違い
| 項目 | Workforce Identity Federation | Workload Identity Federation |
|---|---|---|
| 対象 | 人間ユーザー(従業員・パートナー) | アプリケーション・CI/CD・外部クラウド |
| 設定レベル | 組織(Organization)レベル | プロジェクト(Project)レベル |
| 用途 | コンソールアクセス・gcloud CLI | API アクセス(SA キー不要) |
設定フロー
gcloud コマンド
bash
# 1. Workforce Identity Pool の作成(組織レベル)
gcloud iam workforce-pools create my-workforce-pool --organization=ORG_ID --location=global --display-name="Corporate IdP Pool"
# 2. OIDC プロバイダーの登録(Okta の例)
gcloud iam workforce-pools providers create-oidc okta-provider --workforce-pool=my-workforce-pool --location=global --display-name="Okta OIDC" --issuer-uri="https://myorg.okta.com/oauth2/default" --client-id="MY_CLIENT_ID" --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups,attribute.department=assertion.department"
# 3. 外部ユーザーグループに IAM ロールを付与
gcloud projects add-iam-policy-binding PROJECT_ID --member="principalSet://iam.googleapis.com/locations/global/workforcePools/my-workforce-pool/attribute.department/engineering" --role="roles/viewer"✅ ベストプラクティス
1
属性マッピングでグループ情報を取得しグループ単位で IAM 管理
個人ごとの IAM 設定を排除し、IdP 側のグループ管理と Google Cloud の権限管理を連携させる。
2
SAML より OIDC を優先する
標準準拠・JWT 活用でセキュリティと互換性が高い。ほとんどのモダン IdP が OIDC をサポートしている。
3
attribute-condition で信頼する IdP の範囲を限定
不正なトークンでのアクセスを防止し、フィッシング攻撃への耐性を高める。
📎 公式ドキュメント
▸ Workforce Identity Federation Overview1.2.1
請求アカウントの作成
重要: 1 つのプロジェクトは正確に 1 つの請求先アカウントにリンクされる。1 つの請求先アカウントには複数のプロジェクトをリンクできる。
| ロール | 権限 | 付与対象例 |
|---|---|---|
roles/billing.admin | 請求アカウントの完全管理 | 財務部門の管理者 |
roles/billing.viewer | 請求情報の閲覧のみ | 一般担当者 |
roles/billing.projectManager | プロジェクトのリンク・アンリンク | プロジェクト管理者 |
roles/billing.costsManager | 予算とアラートの管理 | FinOps 担当者 |
📎 公式ドキュメント
▸ Cloud Billing Overview1.2.2
プロジェクトと請求アカウントのリンク
bash
# プロジェクトを請求先アカウントにリンク
gcloud billing projects link PROJECT_ID --billing-account=BILLING_ACCOUNT_ID
# プロジェクトの請求先アカウントを確認
gcloud billing projects describe PROJECT_ID
# 請求先アカウントにリンクされているプロジェクト一覧
gcloud billing projects list --billing-account=BILLING_ACCOUNT_ID警告: 請求先アカウントのリンクを解除すると、プロジェクト内のすべてのリソースが停止する。本番環境では絶対に注意すること。
1.2.3
予算とアラートの設定
⛔ 試験最頻出トラップ
Google Cloud は予算の上限に達してもリソースを自動停止しません。通知が来るだけです。自動停止を実現するには Pub/Sub + Cloud Functions のアーキテクチャが必要です。
自動コスト制御アーキテクチャ
gcloud コマンド
bash
# 予算の作成(3段階のアラート閾値)
gcloud billing budgets create --billing-account=BILLING_ACCOUNT_ID --display-name="Monthly Prod Budget" --budget-amount=100000JPY --threshold-rule=percent=50 --threshold-rule=percent=90 --threshold-rule=percent=100 --filter-projects=projects/my-prod-project
# 予算一覧の確認
gcloud billing budgets list --billing-account=BILLING_ACCOUNT_ID✅ ベストプラクティス
1
すべてのプロジェクトに予算アラートを設定
予期せぬ課金の早期発見のために必須。プロジェクト作成直後に設定する習慣をつける。
2
50% / 90% / 100% の3段階でアラートを設定
段階的な把握と対応が可能。100% 閾値には Pub/Sub 通知も設定して自動制御を実現する。
3
予算金額は前月支出の 120% などで設定
異常なコスト増(認証情報漏洩・DDoS など)を早期検知できる。
4
Cloud Armor と MIG スケーリング上限を設定
DDoS 攻撃によるオートスケール過多でコストが急増するリスクを防止する。
1.2.4
請求エクスポートの設定
| エクスポート種別 | 内容 | 用途 |
|---|---|---|
| 標準使用コストデータ | 日次の基本的なコスト・使用量 | 日常のコスト分析 |
| 詳細使用コストデータ | VM・SSD などリソース単位の詳細コスト | 細粒度のコスト分配・FinOps |
| 料金データ | SKU ごとの公開料金表 | コスト見積もり・予測 |
BigQuery コスト分析クエリ例
sql
-- プロジェクト別の月次コストを集計
SELECT
project.id AS project_id,
FORMAT_DATE('%Y-%m', DATE(usage_start_time)) AS month,
SUM(cost) AS total_cost,
currency
FROM
`my_project.billing_export.gcp_billing_export_v1_XXXXXXXX`
WHERE
DATE(usage_start_time) >= DATE_SUB(CURRENT_DATE(), INTERVAL 3 MONTH)
GROUP BY
project_id, month, currency
ORDER BY
month DESC, total_cost DESC;
-- チーム別ラベルによるコスト分析
SELECT
labels.value AS team,
SUM(cost) AS total_cost
FROM
`billing_export.gcp_billing_export_v1_XXXXXXXX`,
UNNEST(labels) AS labels
WHERE
labels.key = 'team'
AND DATE(usage_start_time) >= DATE_TRUNC(CURRENT_DATE(), MONTH)
GROUP BY team
ORDER BY total_cost DESC;✅ ベストプラクティス
1
プロジェクト作成直後に BigQuery エクスポートを有効化
過去データは遡って取得できないため、作成直後の設定が必須。
2
標準と詳細の両エクスポートを有効化
リソースレベルの精緻な分析が可能になり、コスト分配が正確になる。
3
すべてのリソースにラベルを付けるポリシーを策定
チーム・環境・コストセンター別の分析が可能になる。組織ポリシーでラベル付けを強制することも検討。
4
Looker Studio でコストダッシュボードを構築
ステークホルダーへの費用対効果の可視性を提供し、FinOps 文化を醸成する。
📝
試験頻出パターンと対策
パターン① リソース階層の設計問題
「A 社は開発部・営業部・財務部の3部門を持ち、各部門が dev・prod 環境を持つ。最適な階層は?」
Organization → 部門フォルダ(3つ)→ 環境別プロジェクト(各部門に dev/prod の2つ)→ リソース。共通ポリシーは部門フォルダに付与して継承させる。
パターン② 予算・自動コスト制御問題
「予算超過時に VM を自動停止したい。どのアーキテクチャが正しいか?」
不正解:「予算に上限金額を設定すれば自動停止される」→ 予算上限ではリソースは止まらない!
正解: 予算アラート(100% 閾値)→ Pub/Sub トピック → Cloud Functions → Compute Engine API で VM 停止
パターン③ 組織ポリシーと IAM の使い分け問題
「本番環境のVMで外部IPを持つものを作成できないよう強制したい。どうするか?」
正解: 組織ポリシー
constraints/compute.disableExternalIpAddresses を本番環境フォルダに適用。IAM では「誰が作れるか」、組織ポリシーでは「どんな VM を作れるか」を制御する。管理者でも制約を受ける点が IAM との本質的な違い。パターン④ 最小権限のロール選択問題
「すべてのプロジェクトの Cloud Storage を管理する Jane に必要な最小権限は?」
不正解: Jane に
roles/editor を付与 → 過剰権限(GCEやGKEも操作できてしまう)正解: Jane をグループに追加し、そのグループに
roles/storage.objectAdminを組織/フォルダレベルで付与。個人への直接付与ではなくグループを使うことで管理効率も向上。✓
Section 1 試験直前チェックリスト
1.1 クラウドプロジェクトとアカウントの設定
Organization → Folder → Project → Resource の順序と役割を説明できる
IAM ポリシーが上位から下位へ自動継承され、下位で上位の許可を取り消せないことを知っている
Project ID はグローバルに一意で変更不可だと知っている
削除したプロジェクトは 30日以内なら復元できることを知っている
組織ポリシーと IAM の違い(設定の強制 vs アクセス制御)を説明できる
constraints/iam.disableServiceAccountKeyCreation の効果を説明できる
基本ロール(Editor/Owner)を本番で使うべきでない理由を説明できる
個人ではなくグループにロールを付与する理由を説明できる
Cloud Identity (Free) と Google Workspace の違いを説明できる
新規プロジェクトでは API を個別に有効化する必要があることを知っている
VM のメモリ使用量には Ops Agent が必要(デフォルトでは取得不可)だと知っている
Cloud Asset Inventory で組織全体のリソースを一元検索できることを知っている
Workforce Identity Federation と Workload Identity Federation の違いを説明できる
Workforce Identity Pool は組織レベルで作成することを知っている
1.2 請求設定の管理
1 プロジェクトは正確に 1 つの請求先アカウントにリンクされることを知っている
予算アラートが上限に達してもリソースは自動停止しないことを知っている(最重要)
自動停止には Pub/Sub + Cloud Functions が必要なことを知っている
BigQuery への Billing データエクスポートの目的と設定方法を知っている
ラベルを使ったコストセンター別分析の方法を知っている
DDoS → オートスケール → コスト急増のリスクと対策(Cloud Armor)を知っている