Google Cloud ACESection 1 / 完全解説

Setting up a Cloud
Solution Environment

Google Cloud Associate Cloud Engineer 試験における Section 1 の全出題項目を、中級者〜上級者向けに詳細解説。 各トピックのベストプラクティスと公式ソースを完備した実践型スタディガイド。

~23%試験配点
16出題トピック
2026最新試験ガイド対応

試験配点と出題範囲マップ

📋
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レベル

レベル特徴主な役割最大深度
OrganizationGoogle 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 NumberGoogle が自動採番する数値 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との根本的な違い

観点IAMOrganization Policy
制御対象誰が何をできるか(アクセス制御)何をどう設定できるか(リソース設定の強制)
設定対象Principal(ユーザー・SA・グループ)リソースの設定値・構成
alice が VM を作成できる外部 IP を持つ VM は誰も作成できない
強制力IAM Deny Policy で上書き可能IAM より強制力が高い(adminも制限される)

主要な制約(Constraints)一覧

🔐 セキュリティ強化系

制約名効果推奨設定
iam.disableServiceAccountKeyCreationSA の静的 JSON キー生成を禁止組織全体で有効化
iam.disableServiceAccountKeyUpload外部キーのアップロードを禁止有効化推奨
compute.requireOsLogin全 VM で OS Login を強制有効化推奨
iam.allowedPolicyMemberDomainsIAM に追加できるドメインを限定自社ドメインのみ許可

🌐 ネットワーク制限系

制約名効果
compute.disableExternalIpAddresses外部 IP を持つ VM の作成を禁止
compute.vmExternalIpAccess外部 IP を許可する VM のリストを制限
compute.restrictCloudNATUsageCloud NAT の使用を特定サブネットに制限

🏛 データ主権・コンプライアンス系

制約名効果
gcp.resourceLocationsリソースを特定リージョン/ゾーンに限定
storage.uniformBucketLevelAccessCloud Storage でバケットレベルアクセスを強制
storage.publicAccessPreventionCloud 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_ID
yaml — 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.adminCompute Engine の完全管理
roles/compute.instanceAdmin.v1VM の作成・管理(ネットワーク変更は不可)
roles/compute.osLoginOS Login での SSH(sudo なし)
roles/compute.osAdminLoginOS Login での SSH(sudo あり)

IAM / Service Accounts

ロール権限の概要
roles/iam.serviceAccountAdminSA の作成・管理
roles/iam.serviceAccountUserSA を VM にアタッチする権限(actAs)
roles/iam.serviceAccountTokenCreatorSA の短期トークン生成(権限借用)
roles/iam.workloadIdentityUserWorkload 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 WorkspaceCloud Identity FreeCloud 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 Overview
1.1.5

APIの有効化

ℹ️
新規プロジェクトではほとんどの API がデフォルトで無効化されている。これは攻撃面(Attack Surface)を最小化するためのセキュリティ設計であり、意図的な仕様である。

主要 API と対応サービス

API 名対応サービス
compute.googleapis.comCompute Engine
container.googleapis.comGoogle Kubernetes Engine
run.googleapis.comCloud Run
sqladmin.googleapis.comCloud SQL
bigquery.googleapis.comBigQuery
secretmanager.googleapis.comSecret Manager
cloudasset.googleapis.comCloud Asset Inventory
geminicloudassist.googleapis.comGemini Cloud Assist
monitoring.googleapis.comCloud Monitoring
logging.googleapis.comCloud 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_ID
hcl — 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=REGION
1.1.7

クォータの評価と申請

クォータの種類
レート制限1 秒あたりの API リクエスト数
リソース制限プロジェクトあたりの VM 数・vCPU 数
ストレージ制限GCS バケット数(デフォルト 100/プロジェクト)
⚠️
重要: クォータ増加申請は承認まで数日かかる場合がある。大規模デプロイ前は事前申請が必須。
📎 公式ドキュメント
▸ Quota Management — cloud.google.com
1.1.8

スタンドアロン組織の設定

Google Cloud で Organization ノードを持つには Google Workspace または Cloud Identity のドメインが必要。これにより組織レベルの IAM・組織ポリシー・フォルダ管理が初めて利用可能になる。

Organization ノード取得フロー

個人 Gmail vs Cloud Identity vs Google Workspace

項目個人 Gmail (@gmail.com)Cloud Identity FreeGoogle 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_ID
💡
Cloud 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"
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 FederationWorkload Identity Federation
対象人間ユーザー(従業員・パートナー)アプリケーション・CI/CD・外部クラウド
設定レベル組織(Organization)レベルプロジェクト(Project)レベル
用途コンソールアクセス・gcloud CLIAPI アクセス(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 Overview
1.2.1

請求アカウントの作成

ℹ️
重要: 1 つのプロジェクトは正確に 1 つの請求先アカウントにリンクされる。1 つの請求先アカウントには複数のプロジェクトをリンクできる。
ロール権限付与対象例
roles/billing.admin請求アカウントの完全管理財務部門の管理者
roles/billing.viewer請求情報の閲覧のみ一般担当者
roles/billing.projectManagerプロジェクトのリンク・アンリンクプロジェクト管理者
roles/billing.costsManager予算とアラートの管理FinOps 担当者
📎 公式ドキュメント
▸ Cloud Billing Overview
1.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)を知っている