Domain 1: 環境設定
包括的解説

Domain 1 は試験全体の約 23%（Standard Exam 50〜60問中 約12〜14問）を占める最重要基盤領域。 ここで設計する階層・ポリシー・請求構成が後続のすべての運用・セキュリティ・コスト管理の土台となる。

現代のエンタープライズITにおいて、パブリッククラウドの導入は単なるインフラストラクチャの移行ではなく、組織のガバナンス、セキュリティ、財務管理、そして開発アジリティを根本から再定義する戦略的プロセスである。初期設定の段階で適切なリソース階層、アクセス制御、請求構成を設計することは、将来的なセキュリティインシデントや予算超過（クラウド破産）を防ぎ、スケーラブルな運用を実現するための絶対条件である。

レベル1: Organization（組織）

Organization: example.com
├── 全プロジェクトの親
├── 組織ポリシーを全体に適用できる
└── 組織レベルのIAMロール付与が可能

レベル2: Folder（フォルダ）— ネスト構造

Organization: example.com
├── Folder: 開発環境
│   ├── Project: dev-frontend
│   ├── Project: dev-backend
│   └── Project: dev-database
│
├── Folder: ステージング環境
│   └── Project: staging-webapp
│
└── Folder: 本番環境
    ├── Project: prod-frontend
    └── Project: prod-backend

フォルダは最大 10レベル まで入れ子にできます

レベル3: Project（プロジェクト）— 3つの識別子

Project: my-webapp-prod
├── 一意の Project ID（変更不可）
├── Project Number（自動採番、変更不可）
├── Project Name（変更可能）
├── 紐付けられた Billing Account
├── 有効化された API のリスト
└── リソース（VM、DB、ストレージ...）

✅ 同一プロジェクトに置くべきリソース:
   → 同じチームが管理するリソース
   → 同じセキュリティ要件を持つリソース
   → 同じ予算で管理するリソース

❌ 別プロジェクトに分けるべきケース:
   → 開発環境と本番環境（セキュリティレベルが異なる）
   → 異なる部門のシステム（責任範囲が異なる）
   → コストを独立して管理したいシステム

IAM Policy の基本構造:

Policy = {
  "bindings": [
    {
      "role": "roles/editor",        ← 何ができるか（役割）
      "members": [                   ← 誰が
        "user:alice@example.com"
      ]
    }
  ]
}

継承の仕組み（上位 → 下位に自動適用）

Organization レベル: alice に roles/viewer を付与
    ↓ 自動的に継承される
Folder レベル: alice はここでも viewer
    ↓ 自動的に継承される
Project レベル: alice はここでも viewer
    ↓ 自動的に継承される
Resource レベル: alice はここでも viewer

【ルール1】上位の許可は下位でも有効
  Organization で roles/editor を付与
  → その配下のすべてのプロジェクトでも editor 権限が有効

【ルール2】下位での制限で上位の許可は取り消せない
  Organization で roles/editor を付与
  Project レベルで拒否しようとしても無効
  → 上位の許可は下位で上書きできない（原則）

【ルール3】権限は「和集合（Union）」
  Organization: roles/viewer
  Project: roles/editor
  → 実際の権限 = viewer + editor の両方

実践的な設計パターン

【パターン1: 環境ごとの分離】
Organization: example.com
├── Folder: 開発環境
│   └── Project: dev-app
│       ← ここで dev-team@example.com に roles/editor を付与
│         （開発環境だけ編集できる）
│
└── Folder: 本番環境
    └── Project: prod-app
        ← ここで ops-team@example.com に roles/editor を付与
          （本番は ops チームのみ編集可能）

【パターン2: 横断的な閲覧権限】
Organization レベルで
  monitoring-team@example.com に roles/viewer を付与
→ すべてのプロジェクトのリソースを閲覧できる
→ 個別プロジェクトに設定不要でメンテコスト削減！

Google Cloudのリソース階層は、最上位の「組織（Organization）」、中間層の「フォルダ（Folders）」、そして最下層の「プロジェクト（Projects）」という厳密なツリー構造で構成される。この構造の最大の利点は、ポリシーの「継承（Inheritance）」とリソースの「所有権（Ownership）」の明確化にある。上位階層で設定されたIAMの許可ポリシーや組織のポリシーは、下位のすべてのリソースに自動的に適用され、管理のオーバーヘッドを劇的に削減する。また、従業員が退職した場合でも、リソースは個人のアカウントではなく組織に属しているため、システムが停止することなく安全に保持される。

Google Workspace            Cloud Identity
（旧 G Suite）              （無料版）
  ├── Gmail                   ├── 組織 ID 管理のみ
  ├── Drive                   ├── Google Cloud 利用
  ├── Meet など               └── コスト: 無料（Free）
  └── Google Cloud 利用
  コスト: 有料

💡 試験ポイント: 企業がGoogle Workspaceを既に使っている場合、追加コストなしでGoogle CloudのOrganization機能が利用できます。

【管理対象ユーザー（Managed Users）】
  会社ドメイン: alice@example.com
  → Google Workspace / Cloud Identity で管理される
  → Organization 配下にプロジェクトを作成
  → 組織ポリシーが適用される

【非管理対象ユーザー（Unmanaged Users）】
  個人Gmail: alice@gmail.com
  → Organization なし（個人プロジェクトのみ）
  → 組織ポリシーは適用されない
  → 企業での利用は非推奨

エンタープライズ環境において、数百、数千のユーザーを手動で管理することは非現実的である。Google Cloudのユーザー基盤は、Google WorkspaceまたはCloud Identityのディレクトリサービスによって提供される。既存のITインフラストラクチャとしてActive Directory (AD) やLDAPを運用している企業は、Google Cloud Directory Sync (GCDS) やSAMLベースのフェデレーション（シングルサインオン）を構成することで、オンプレミスのID情報をクラウドとシームレスに同期できる。これにより、人事システム上で従業員が退職扱いとなった瞬間にクラウドへのアクセス権も自動的に剥奪され、孤立したアカウントによる不正アクセスのリスクを根絶することが可能となる。

方法①: Google Cloud Console（GUI）

1. https://console.cloud.google.com にアクセス
2. 上部のプロジェクト選択メニューをクリック
3. 「新しいプロジェクト」をクリック
4. 以下を入力:
   - プロジェクト名: My Webapp Prod
   - プロジェクトID: my-webapp-prod-xxxx（自動生成 or 手動指定）
   - 場所（親組織/フォルダ）: 選択
5. 「作成」をクリック

方法②: gcloud CLI

# プロジェクトの作成
gcloud projects create PROJECT_ID \
  --name="My Webapp Prod" \
  --folder=FOLDER_ID

# 作成後、そのプロジェクトをデフォルトに設定
gcloud config set project my-webapp-prod-20240101

方法③: Terraform（IaC）

resource "google_project" "my_project" {
  name            = "My Webapp Production"
  project_id      = "my-webapp-prod-20240101"
  folder_id       = "987654321"
  billing_account = "ABCDEF-123456-GHIJKL"
}

ACTIVE（アクティブ）
    ↓ 削除操作
DELETE_REQUESTED（削除予約）
    │
    ├── 30日間の猶予期間
    │   └── この間に「削除取り消し」が可能
    │
    └── 30日後
        ↓
    完全削除（復元不可）

# プロジェクトを削除（30日の猶予あり）
gcloud projects delete PROJECT_ID

# 削除をキャンセル（30日以内）
gcloud projects undelete PROJECT_ID

# プロジェクトのステータス確認
gcloud projects describe PROJECT_ID

💡 試験ポイント: プロジェクト作成数のクォータを超えた場合は、Google Cloud サポートに増加申請が必要です。

【IAM の役割】
「alice は VM を作成できる（権限の制御）」

【組織ポリシー の役割】
「誰であっても外部IPを持つVMは作成できない（設定の強制）」
     ↑
  alice が admin でも制約を受ける！

セキュリティ関連

ネットワーク関連

リージョン制限関連

# 例: 日本リージョンのみにリソースを限定
constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
    - in:asia-northeast1-locations  # 東京
    - in:asia-northeast2-locations  # 大阪

Organization レベル: ポリシー A を設定
    ↓ 継承
Folder レベル: ポリシー A が有効（+ ポリシー B を追加も可能）
    ↓ 継承
Project レベル: ポリシー A, B が有効

【上書きの例外】
  特定フォルダ/プロジェクトで「継承をリセット」することで
  上位のポリシーを無効化し、独自のポリシーを設定可能
  （ただし Organization Admin 権限が必要）

# 特定の制約を有効化（外部IPを持つVMの作成を禁止）
gcloud resource-manager org-policies enable-enforce \
  constraints/compute.disableExternalIpAddresses \
  --organization=ORG_ID

# 特定のプロジェクトに制約を設定
gcloud resource-manager org-policies set-policy policy.yaml \
  --project=PROJECT_ID

# 現在のポリシーを確認
gcloud resource-manager org-policies describe \
  constraints/compute.disableExternalIpAddresses \
  --organization=ORG_ID

IAMが「誰がリソースにアクセスできるか（認証と認可）」を制御するのに対し、組織のポリシーは「リソースがどのように構成されるか（構成の制限）」を定義する強力なガバナンスツールである。これにより、強力な管理者権限を持つユーザーであっても、企業のコンプライアンス要件に反する操作をシステムレベルでブロックすることが可能となる。ベストプラクティスとして、組織のベースラインとなるセキュリティ要件は組織またはフォルダレベルで適用し、特定の検証が必要なプロジェクトに対してのみ、タグや条件付きルールを用いて例外処理（免除）を設定するアプローチが推奨される。

# Google Cloud SDK のインストール
# macOS (Homebrew)
brew install --cask google-cloud-sdk

# Ubuntu/Debian
sudo apt-get install google-cloud-cli

# インストール確認
gcloud version

# 初期設定（インタラクティブ）
gcloud init

# インタラクティブに以下を設定:
# 1. Google アカウントでログイン（ブラウザが開く）
# 2. デフォルトプロジェクトの選択
# 3. デフォルトリージョン/ゾーンの設定

設定（Configuration）= プロファイルのようなもの
  ├── config: default（デフォルト設定）
  ├── config: dev-project（開発環境用）
  └── config: prod-project（本番環境用）

# 現在の設定を確認
gcloud config list

# デフォルトプロジェクトを変更
gcloud config set project PROJECT_ID

# デフォルトリージョンを変更
gcloud config set compute/region asia-northeast1

# 新しい設定（プロファイル）を作成
gcloud config configurations create dev-profile

# 設定を切り替え
gcloud config configurations activate dev-profile

# 設定一覧を表示
gcloud config configurations list

# ----- ユーザー認証 -----
gcloud auth login
gcloud auth list
gcloud auth revoke USER_EMAIL

# ----- Application Default Credentials (ADC) -----
gcloud auth application-default login
gcloud auth application-default print-access-token

ADC（Application Default Credentials）の検索順序:
1. GOOGLE_APPLICATION_CREDENTIALS 環境変数
2. gcloud auth application-default login で設定した認証情報
3. GCE/GKE などのコンピューティング環境の場合はメタデータサーバー

💡 試験ポイント: ローカル開発環境では gcloud auth application-default login を使用します。サービスアカウントの JSON キーをローカルに保存することはセキュリティリスクです。

# ----- プロジェクト操作 -----
gcloud projects list
gcloud projects describe PROJECT_ID
gcloud config set project PROJECT_ID

# ----- IAM 操作 -----
gcloud projects get-iam-policy PROJECT_ID
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/editor"
gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/editor"

# ----- API 管理 -----
gcloud services enable compute.googleapis.com
gcloud services list --enabled

# ----- リージョン/ゾーン -----
gcloud compute regions list
gcloud compute zones list

特筆すべきは、Google Cloud Consoleに統合されている「Cloud Shell」の存在である。Cloud Shellを起動すると、最新のCloud CLIツール群（gcloud、bq、gsutil、kubectlなど）がプリインストールされた一時的な（エフェメラルな）Linuxコンテナが即座に立ち上がり、現在コンソールにログインしているユーザーの認証情報とプロジェクトコンテキストが自動的に引き継がれる。ただし、Cloud Shell内のデータ（ホームディレクトリ以外）はセッション終了後に消去される一時的なものである点に留意が必要である。

実務において、エンジニアは「開発環境（dev）」、「ステージング環境（stg）」、「本番環境（prod）」といった複数のプロジェクトを行き来しながら作業することが日常的である。初期化時に作成された単一の「デフォルト構成（default configuration）」のみに依存して運用を行うことは、致命的なオペレーションミスの温床となる。たとえば、開発環境だと思い込んでデータベースの削除コマンドを実行したところ、実際にはCLIのコンテキストが本番環境のプロジェクトに向いており、本番データを消失させてしまうといった事故である。

さらに高度な自動化手法として、ディレクトリごとに構成を自動的に切り替えるアプローチが存在する。direnv のような環境変数管理ツールを使用し、プロジェクトのディレクトリ配下に配置した .envrc ファイルに export CLOUDSDK_ACTIVE_CONFIG_NAME=prod-env のように記述する。これにより、ターミナルでディレクトリを移動した瞬間に環境変数が自動的に読み込まれ、gcloudコマンドのコンテキストがディレクトリと完全に同期する。

【請求の全体構造】

支払いプロファイル（Payment Profile）
  │  ← クレジットカードや銀行口座の情報
  │
  ├── 請求先アカウント A（Billing Account）
  │   ├── Project 1 ← このプロジェクトの料金が請求先 A に請求
  │   ├── Project 2
  │   └── Project 3
  │
  └── 請求先アカウント B（Billing Account）
      ├── Project 4
      └── Project 5

重要な仕様:
・1つのプロジェクトは 正確に1つの請求先アカウント にリンク
・1つの請求先アカウントには 複数のプロジェクト をリンク可能
・請求先アカウントがリンクされていないプロジェクトは
  有料APIを使用できない

  Project A ──→ Billing Account X
  Project B ──→ Billing Account X  ✅ 複数プロジェクト → 1つのBA
  Project C ──→ Billing Account Y
  Project D ──→ Billing Account X または Y（どちらか一方のみ）

【職務分掌の例】

財務部門 Admin: billing.admin
  └── 支払い方法の変更、アカウントの作成

プロジェクトマネージャー: billing.projectManager
  └── プロジェクトを請求先アカウントにリンク
      （支払い方法の変更はできない）

一般エンジニア: billing.viewer
  └── コストを確認するだけ

一般的なエンタープライズアーキテクチャでは、企業全体で1つのマスター請求先アカウントを作成し、すべての部門のプロジェクトをそこにリンクさせることで、組織全体の利用状況を統合的に可視化し、ボリュームディスカウントの恩恵を最大化するアプローチが取られる。

# 利用可能な請求先アカウント一覧を取得
gcloud billing accounts list

# プロジェクトを請求先アカウントにリンク
gcloud billing projects link PROJECT_ID \
  --billing-account=BILLING_ACCOUNT_ID

このような自動化を導入することで、開発者が手動でプロジェクトを作成した際に請求設定を忘れるというオペレーションミスを排除できる。

予算設定の構成要素:

┌─────────────────────────────────────────┐
│  予算名: Monthly API Budget              │
│                                          │
│  スコープ: Project: my-webapp-prod       │
│  期間: 月次（毎月リセット）               │
│  予算金額: $1,000                        │
│                                          │
│  アラート閾値:                            │
│    ├── 50%  → $500  → メール通知         │
│    ├── 90%  → $900  → メール通知         │
│    └── 100% → $1,000 → メール + Pub/Sub  │
└─────────────────────────────────────────┘

スコープの粒度（大→小）:
  組織全体
    ↓
  特定のフォルダ
    ↓
  特定のプロジェクト（複数も可）
    ↓
  特定のサービス（例: Compute Engine のみ）
    ↓
  特定のラベル（例: env=production のリソースのみ）

# gcloud で予算を作成する例
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Monthly Prod Budget" \
  --budget-amount=1000USD \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0 \
  --filter-projects=projects/my-webapp-prod

【よくある誤解】
  予算の上限に達したら → Google が自動でリソースを停止してくれる

【正しい動作】
  予算の上限に達したら → 通知が来るだけ
                        → リソースは停止しない！
                        → 課金は継続される！

自動停止を実現するには、自分でアーキテクチャを組む必要があります

┌──────────────────────────────────────────────────────────┐
│                                                          │
│  ① 予算の100%閾値に到達                                   │
│           ↓                                              │
│  ② Cloud Billing が Pub/Sub トピックにメッセージを発行   │
│           ↓                                              │
│  ③ Cloud Functions が Pub/Sub をトリガーとして起動       │
│           ↓                                              │
│  ④ Cloud Functions が GCP API を呼び出してリソース操作   │
│     例: VM を停止、プロジェクトをシャットダウン           │
│                                                          │
└──────────────────────────────────────────────────────────┘

実装例: Cloud Functions で VM を自動停止（Python）

# Cloud Functions のコード例（Python）
import base64
import json
import googleapiclient.discovery

def stop_billing(data, context):
    """予算アラートを受け取ってVMを停止する"""
    # Pub/Sub メッセージをデコード
    pubsub_data = base64.b64decode(data['data']).decode('utf-8')
    budget_notification = json.loads(pubsub_data)

    # 予算超過を確認
    cost_amount = budget_notification['costAmount']
    budget_amount = budget_notification['budgetAmount']

    if cost_amount >= budget_amount:
        # Compute Engine API を使って VM を停止
        compute = googleapiclient.discovery.build('compute', 'v1')
        compute.instances().stop(
            project='my-project',
            zone='asia-northeast1-a',
            instance='my-vm-instance'
        ).execute()
        print(f"VM stopped due to budget exceeded: {cost_amount}")

より高度なパターン: プロジェクト全体を無効化

def disable_billing(project_id):
    """プロジェクトから請求先アカウントを切り離す（全リソース停止）"""
    billing = googleapiclient.discovery.build('cloudbilling', 'v1')

    # 請求先アカウントのリンクを解除
    billing.projects().updateBillingInfo(
        name=f'projects/{project_id}',
        body={'billingAccountName': ''}  # 空文字でリンク解除
    ).execute()

【リスク①: 認証情報の漏洩 → 暗号資産マイニング】
開発者が誤って GitHub に
サービスアカウントの JSON キーを公開
    ↓
攻撃者がキーを発見して即座に悪用
    ↓
大量の高性能 VM や GPU インスタンスを起動
    ↓
数時間で数百万円の請求が発生！

対策:

• constraints/iam.disableServiceAccountKeyCreation を有効化してキー生成を禁止
• Secret Scanner（GitHub の機能）でキーの誤コミットを検出
• VM インスタンスの作成に上限クォータを設定

【リスク②: DDoS 攻撃 → オートスケールによるコスト急増】
悪意のある大量トラフィック（DDoS 攻撃）
    ↓
Cloud Load Balancing が大量のリクエストを受信
    ↓
バックエンドのオートスケーリングが発動
    ↓
VM が大量に起動 → 攻撃が終わっても請求は発生！

# Cloud Armor のセキュリティポリシーを作成
gcloud compute security-policies create my-ddos-policy \
  --description="DDoS protection policy"

# レート制限ルールを追加（1IPあたり1000リクエスト/分）
gcloud compute security-policies rules create 1000 \
  --security-policy=my-ddos-policy \
  --expression="true" \
  --action=rate-based-ban \
  --rate-limit-threshold-count=1000 \
  --rate-limit-threshold-interval-sec=60 \
  --ban-duration-sec=600

初学者が最も誤解しやすいポイントは、「予算を設定すれば、その金額に達した時点で自動的にリソースが停止し、課金が止まる」という思い込みである。Google Cloudのデフォルトの予算アラートは、あくまで「メール等による情報提供」に過ぎず、APIの利用を自動的にブロックする機能は持っていない。

真の意味で予算を上限（キャップ）として機能させ、過剰な請求を強制的に防ぐためには、「Programmatic Notifications（プログラムによる予算通知）」のアーキテクチャを構築する必要がある。

Cloud Billing Console だけでは:
  ✗ 過去データは限られた期間しか見られない
  ✗ 複雑なカスタムクエリは実行できない
  ✗ 複数の請求先アカウントの横断分析が難しい

BigQuery エクスポートにより:
  ✓ 全期間のコストデータを保持
  ✓ SQL で自由に分析可能
  ✓ Looker Studio などで可視化
  ✓ 監査証跡として活用

BigQuery エクスポートの設定手順:

1. Cloud Billing → 請求先アカウントを選択
2. 「課金データのエクスポート」をクリック
3. BigQuery エクスポートを選択
4. 以下を設定:
   - プロジェクト: billing-data-project
   - データセット: billing_export
5. 保存

→ 以降、課金データが BigQuery に自動で書き込まれる

-- プロジェクト別の月次コストを集計
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_XXXXXX`
WHERE
  DATE(usage_start_time) >= DATE_SUB(CURRENT_DATE(), INTERVAL 6 MONTH)
GROUP BY
  project_id, month, currency
ORDER BY
  month DESC, total_cost DESC;

-- サービス別コストのトップ10
SELECT
  service.description AS service_name,
  ROUND(SUM(cost), 2) AS total_cost
FROM
  `my_project.billing_export.gcp_billing_export_v1_XXXXXX`
WHERE
  DATE(usage_start_time) >= DATE_TRUNC(CURRENT_DATE(), MONTH)
GROUP BY
  service_name
ORDER BY
  total_cost DESC
LIMIT 10;

【推奨ラベル一覧】

env: production / staging / development
team: backend / frontend / data
cost-center: engineering / marketing / finance
app: webapp / api / batch
owner: alice / bob

# VM インスタンスにラベルを付ける
gcloud compute instances add-labels INSTANCE_NAME \
  --labels=env=production,team=backend,cost-center=engineering

# Cloud Storage バケットにラベルを付ける
gcloud storage buckets update gs://BUCKET_NAME \
  --update-labels=env=production,team=data

-- チーム別のコスト分析（ラベル付き）
SELECT
  labels.value AS team,
  SUM(cost) AS total_cost
FROM
  `billing_export.gcp_billing_export_v1_XXXXXX`,
  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;

エクスポート設定を有効にすると、その時点以降の請求データが定期的に指定したBigQueryデータセットに自動的にストリーミングされる（過去のデータは遡ってエクスポートされないため、プロジェクト設立直後の設定が不可欠である）。

新規プロジェクト作成直後:
  ├── Compute Engine API: ❌ 無効
  ├── Cloud Storage API: ❌ 無効
  ├── Cloud SQL Admin API: ❌ 無効
  └── ...（ほぼすべて無効）

↓ 使いたいAPIを有効化する必要がある

有効化後:
  ├── Compute Engine API: ✅ 有効 → VM を作成できる
  ├── Cloud Storage API: ✅ 有効 → バケットを作成できる
  └── ...

💡 なぜデフォルトで無効？: セキュリティ上の理由から、使わないAPIは無効にしておくことで攻撃面（アタックサーフェス）を最小化します。

# 単一の API を有効化
gcloud services enable compute.googleapis.com

# 複数の API を一度に有効化
gcloud services enable \
  compute.googleapis.com \
  storage.googleapis.com \
  sqladmin.googleapis.com \
  container.googleapis.com \
  cloudrun.googleapis.com

# 有効化されている API の一覧
gcloud services list --enabled

# API を無効化
gcloud services disable compute.googleapis.com

Terraform による API 有効化（IaC）

# 複数の API をまとめて有効化
locals {
  services = [
    "compute.googleapis.com",
    "storage.googleapis.com",
    "sqladmin.googleapis.com",
    "container.googleapis.com",
  ]
}

resource "google_project_service" "apis" {
  for_each = toset(local.services)

  project            = var.project_id
  service            = each.value
  disable_on_destroy = false  # Terraform 削除時にサービス中断を防ぐ
}

【推奨度: 高】
  Workload Identity Federation
    ├── AWS、Azure、GitHub Actions などから GCP API にアクセス
    └── JSON キー不要、動的なクレデンシャルを使用

  Application Default Credentials (ADC)
    ├── ローカル開発環境での利用
    └── gcloud auth application-default login で設定

  インスタンスに紐付けられたサービスアカウント
    ├── GCE / GKE 上のアプリが GCP API にアクセス
    └── JSON キー不要、メタデータサーバーから自動取得

【推奨度: 低（非推奨）】
  サービスアカウント JSON キー
    ├── ローカルファイルに秘密鍵を保存
    ├── 漏洩リスクが高い
    └── 緊急時を除き使用しない

API キーの使い分け:
  ✅ Google Maps JavaScript API（フロントエンドから利用）
  ✅ YouTube Data API など公開データの取得
  ❌ Cloud Storage や Compute Engine などの管理 API

API管理における高度な洞察として、API間の「依存関係」の理解が挙げられる。特定のAPI（例：GKE API）を有効化すると、それが依存する基盤となるAPI（例：Compute Engine API）も非同期に有効化される。TerraformなどのIaCツールを使用してAPIを一括で有効化する際、この非同期的な有効化プロセスと依存関係が原因で競合状態（レースコンディション）が発生することがある。そのため、ベストプラクティスとしては、アプリケーションの実行に真に必要なAPIのみを厳格に特定して有効化し、攻撃者が利用可能なアタックサーフェス（攻撃面）を最小限に抑えることが推奨される。

クラウド環境にデプロイされたリソースの正常性を確保し、障害に迅速に対応するためには、包括的なオブザーバビリティ（可観測性）基盤が必要である。Cloud Monitoringを使用するためには、プロジェクトを「指標スコープ（Metrics Scope）」に追加してワークスペースを構築する。指標スコープの強力な点は、単一のプロジェクト内のリソースだけでなく、複数のGoogle CloudプロジェクトやAWS環境のメトリクスを単一のガラス板（Single Pane of Glass）で一元的に監視できることである。

【パターン①: リソース階層の設計問題】
典型的な問題文:
「A 社は 3 つの部門（開発・営業・財務）を持ち、
 各部門が複数の環境（開発・本番）を持つ。
 最適なリソース階層はどれか？」

解答の考え方:
Organization: a-company.com
├── Folder: 開発部門
│   ├── Project: dev-dept-dev
│   └── Project: dev-dept-prod
├── Folder: 営業部門
│   ├── Project: sales-dept-dev
│   └── Project: sales-dept-prod
└── Folder: 財務部門
    ├── Project: finance-dept-dev
    └── Project: finance-dept-prod

→ 各部門でフォルダを作り、環境ごとにプロジェクトを分ける
→ 共通のポリシーは上位フォルダで一括設定

【パターン②: コスト管理の自動化問題】
典型的な問題文:
「開発チームが予算を超えた場合、自動的に VM を停止させたい。
 どのアーキテクチャが正しいか？」

正解パターン:
予算アラート（Pub/Sub 通知設定）
    ↓
Pub/Sub トピック
    ↓
Cloud Functions
    ↓
Compute Engine API で VM 停止

よくある不正解:
「予算に上限金額を設定すれば自動停止される」
→ 誤り！予算上限ではリソースは止まりません！

【パターン③: 組織ポリシーの適用問題】
典型的な問題文:
「本番環境のプロジェクトで外部IPを持つVMを作成できないよう
 強制したい。どうするか？」

正解:
組織ポリシー: constraints/compute.disableExternalIpAddresses
を本番環境フォルダに適用する

IAM との違いを理解する:
IAM: 「誰が」VM を作成できるか → ユーザーへの権限付与
組織ポリシー: 「どんな VM を」作れるか → リソース設定の強制

リソース階層とガバナンス

• ☐ Organization → Folder → Project → Resource の順序を説明できる
• ☐ IAM ポリシーが上位から下位へ 継承 されることを知っている
• ☐ 下位レベルで上位の IAM ポリシーを 取り消せない ことを知っている
• ☐ Project ID は グローバルに一意で変更不可 だと知っている
• ☐ 削除したプロジェクトは 30日以内 なら復元できることを知っている
• ☐ Google Workspace または Cloud Identity がないと Organization は作れないことを知っている

組織ポリシー

• ☐ 組織ポリシーと IAM の違い（設定の強制 vs アクセス制御）を説明できる
• ☐ constraints/iam.disableServiceAccountKeyCreation の効果を説明できる
• ☐ constraints/gcp.resourceLocations の効果を説明できる

請求とコスト管理

• ☐ 1つのプロジェクトは 正確に1つ の請求先アカウントにリンクされることを知っている
• ☐ 予算アラートが上限に達してもリソースは 自動停止しない ことを知っている
• ☐ 自動停止には Pub/Sub + Cloud Functions が必要なことを知っている
• ☐ BigQuery への Billing データエクスポートの目的と設定方法を知っている
• ☐ ラベルを使ったコストセンター別分析の方法を知っている
• ☐ DDoS → オートスケール → コスト急増のリスクと対策（Cloud Armor）を知っている

gcloud CLI と API 管理

• ☐ gcloud config set project でプロジェクトを切り替えられる
• ☐ gcloud config configurations で複数プロファイルを管理できる
• ☐ gcloud auth application-default login の目的を説明できる
• ☐ 新規プロジェクトでは API を個別に有効化する必要があることを知っている
• ☐ gcloud services enable で API を有効化できる

Google Cloud Associate Cloud Engineer認定試験の「Domain 1: クラウドソリューション環境の設定」は、単なる初期設定の操作手順を暗記する領域ではない。それは、堅牢でセキュア、かつコスト効率の高いエンタープライズ・クラウドインフラストラクチャを支える哲学と設計思想を深く理解し、実装する能力を測る領域である。

リソース階層の設計は組織のガバナンスと信頼境界をクラウド上に物理的に反映させる作業であり、フォルダと組織ポリシーの継承メカニズムを前提とした精緻なアーキテクチャ設計が求められる。アクセス制御においては、従来の基本ロールに依存した大雑把な権限付与から脱却し、Workload Identity連携やカスタムサービスアカウントを通じた「最小権限の原則」を徹底する、高度なアイデンティティ管理へと昇華させなければならない。

また、コスト管理は単なる事後的な経費報告であってはならない。BigQueryへの詳細な課金データエクスポートによるリソースレベルのFinOps分析と、Pub/SubおよびCloud Functionsを用いたプログラム駆動型のアラート・強制遮断メカニズムを組み込むことで、クラウドの持つ俊敏性を損なうことなく、財務的な安全性を担保するプロアクティブな防衛線が構築される。そして、これらのすべての設計をコードとして具現化し、反復可能でスケーラブルなオペレーションを実現する入り口となるのが、Google Cloud CLIの的確な操作である。