ACE 完全学習ガイド
試験対策・アーキテクチャ詳細

Google Cloud Associate Cloud Engineer (ACE) は、Google Cloud を使ったアプリケーションやインフラのデプロイ・保守を担うエンジニア向けの入門〜中級認定資格です。

💡 学習のコツ: Domain 2（計画と実装）が最大配点です。Compute Engine、GKE、Cloud SQL などの実装パターンを重点的に学習しましょう。

ACE試験には、初回の認定または失効した認定の再取得を目的とする「スタンダード試験（Standard Exam）」と、有効期限内の更新を目的とする「更新試験（Renewal Exam）」の2つのパスが用意されている。

試験ガイドに基づく主要な出題ドメインは、クラウドソリューション環境の設定（約23%）、クラウドソリューションの計画と実装（約30%）、正常なオペレーションの確保（約27%）、アクセスとセキュリティの構成（約20%）の4つに大別される。これらのドメインは、インフラストラクチャのライフサイクル全体を網羅しており、理論的な知識だけでなく、実務におけるシナリオベースの問題解決能力が問われる。

Google Cloud のすべてのリソースは、以下の厳密な階層構造で管理されます。

IAMポリシーの継承

請求先アカウントの構造

💡 各プロジェクトは 正確に1つ の請求先アカウントにリンクされます。

予算アラートの設定フロー

1. 予算を設定（月次/四半期/年次）
2. スコープを設定（組織 / フォルダ / プロジェクト / ラベル）
3. 閾値を設定（例: 50% / 90% / 100%）
4. 通知先を設定（メール or Pub/Sub）

自動停止を実現するアーキテクチャ:

flowchart LR
    A[予算アラート] --> B[Pub/Sub トピック]
    B --> C[Cloud Functions]
    C --> D[リソースの停止<br/>VM stop / API disable]

Google Cloudのリソースは厳密な階層構造で管理される。リソース階層の設計においては、実際の企業の組織構造（部門、事業部、チームなど）をクラウド階層にミラーリングすることがベストプラクティスとされる。Identity and Access Management (IAM) のポリシーは、この階層を通じて上位レベルから下位レベルへと継承されるため、組織レベルで適用されたアクセス制御ポリシーは、その配下にあるすべてのリソースに自動的に適用される。

プロジェクトは企業内の信頼境界（Trust Boundary）を表すため、同じ信頼境界を共有するリソースは同一のプロジェクトにグループ化することが推奨される。複数のプロジェクトにまたがる役割をユーザーに付与する必要がある場合は、プロジェクト単位で設定するのではなく、親フォルダレベルで役割を設定することで管理のオーバーヘッドを削減できる。

クラウドの運用において、コストの監視と管理は極めて重要である。Google Cloudの請求システムは、支払いプロファイルに紐づく請求先アカウント（Billing Account）を中心に構成されており、各プロジェクトは正確に一つの請求先アカウントにリンクされる必要がある。効果的なコスト管理のためには、「価格（設定された料金）」と「コスト（使用量に基づく実際の支出）」の根本的な違いを理解することが不可欠である。

予期せぬ請求を防ぐための主要なメカニズムが「予算（Budgets）」と「アラート」である。これらは月次、四半期、年次などの期間で設定でき、組織、フォルダ、プロジェクト、または特定のリソースラベルごとにスコープを限定することが可能である。実際のコストや予測コストが設定した閾値に達した際、指定した受信者にメールで通知が送信される。しかし、ここで注意すべき重要な仕様は、Google Cloudは予算の上限に達してもリソースを自動的にシャットダウンしないという点である。プログラムによる自動的なコスト制御（例えば、特定のリソースの停止）を実現するには、予算アラートの通知先としてPub/Subトピックを設定し、Cloud Functionsなどをトリガーするアーキテクチャを構築する必要がある。

また、セキュリティインシデントがコストに与える影響も考慮しなければならない。誤って漏洩した認証情報が悪用されて暗号資産のマイニングが行われたり、DDoS攻撃によってフロントエンドの負荷が急増し、オートスケーリングが不必要にトリガーされたりすることで、多額の請求が発生するリスクがある。これらの脅威を軽減するためには、スケーリングの上限を適切に設定し、ネットワーク境界でCloud Armorを利用して脅威を検出・緩和することが推奨される。さらに、詳細なコスト分析や監査の基盤として、Cloud BillingデータをBigQueryへ継続的にエクスポートする設定を有効にすることが求められる。

セキュアな SSH アクセス管理

OS Login の設定:

# プロジェクト全体に OS Login を有効化
gcloud compute project-info add-metadata \
  --metadata enable-oslogin=TRUE

# 本番環境では 2FA も必須に
gcloud compute project-info add-metadata \
  --metadata enable-oslogin-2fa=TRUE

flowchart TD
    A[Google にキャパシティの余裕あり] --> B[Spot VM をデプロイ可能]
    B --> C[通常 VM の最大 91% 割引で稼働]
    C --> D{Google がキャパシティを<br/>必要としたか?}
    D -->|Yes| E[プリエンプト<br/>強制停止]
    D -->|No| C

プリエンプトへの備え:

# シャットダウンスクリプトで状態を Cloud Storage に保存
#!/bin/bash
# /etc/google-cloud/metadata/shutdown-scripts
gsutil cp /var/app/checkpoint.dat gs://my-bucket/checkpoints/

flowchart TD
    A[コンテナイメージをデプロイ] --> B[インフラ管理不要<br/>ゼロオペレーション]
    B --> C[ゼロへのスケールダウン<br/>アイドル時コストなし]
    C --> D[HTTP リクエスト or<br/>Eventarc イベントで起動]

ネットワーク接続: Direct VPC Egress

💡 第1世代 vs 第2世代: スループットを最大化するには 第2世代の実行環境 + Direct VPC egress を選択。VPC コネクタより高速です。

コンピューティングサービスの選択は、ワークロードの性質、必要な制御レベル、およびコスト効率の要件に依存する。

Compute Engineの運用において、VMへのセキュアなアクセスを確立することは最優先事項である。従来の静的なSSHキー管理に代わり、OS Loginを使用することで、IAMポリシーを通じた継続的なアクセス評価が可能になる。本番環境のVMに対しては、OS Loginにおける二要素認証（2FA）を必須とし、メタデータ enable-oslogin-2fa を TRUE に設定することが推奨される。また、永続的な脅威を防ぐため、特権サービスアカウントがアタッチされたVMへのSSHアクセスは避け、JIT（Just-In-Time）アクセスを採用して一時的に権限を付与する運用がベストプラクティスとされる。

Spot VMを利用する場合、アプリケーションはプリエンプションに耐えうる設計でなければならない。停止イベントを適切に処理するために、シャットダウンスクリプトを構成し、Cloud Storageへのチェックポイントの保存やクリーンな終了プロセスを実行する時間を確保する。また、終了アクションを STOP に設定することで、キャパシティが再び利用可能になった際にVMを再起動し、ローカルディスクのデータを保持することが可能になる。

Cloud Runなどのサーバーレス環境を設計する際、ネットワークトポロジの制約とトラフィックルーティング戦略が重要となる。サーバーレスVPCアクセス（Serverless VPC Access）を通じて、外部IPを持たない内部リソース（Cloud SQLやMemorystoreなど）への安全な接続が提供される。

パフォーマンスとスループットを最大化するためには、第2世代の実行環境を利用し、従来のVPCコネクタを使用する代わりに「Direct VPC egress」を設定してネットワークの送信スループットを高速化することが推奨される。また、大規模なデプロイメントにおいてIPアドレスの枯渇を防ぐため、RFC 1918以外のIPv4アドレスの使用、Cloud NATやPrivate Service Connectの活用、さらにはIPv4とIPv6のデュアルスタックサブネットの導入といった戦略が有効である。

Autopilot モード は Google がノードのプロビジョニング・スケーリング・アップグレード・セキュリティ制約をすべて管理し、課金は Pod が要求する vCPU/Memory 単位（デフォルト推奨）。Standard モード はユーザーがノードプールを直接管理し、課金はノード単位。特権コンテナの実行・カーネルパラメータのチューニング・DaemonSet（ロギング/監視）など低レベル制御が必要な場合に選択する。

Workload Identity Federation（最重要！）

設定例:

# KSA と GSA を紐付け
gcloud iam service-accounts add-iam-policy-binding \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

Binary Authorization（コンテナ整合性の保証）

flowchart LR
    A[CI/CD パイプラインで署名<br/>イメージにデジタル署名を付与] --> B[Artifact Registry]
    B --> C[GKE デプロイ時に検証]
    C --> D{承認済み署名あり?}
    D -->|Yes| E[Deploy 許可]
    D -->|No| F[ブロック]

Security Posture Dashboard

GKE の「セキュリティポスチャダッシュボード」が自動スキャン:

• Pod 仕様の設定上の懸念事項
• コンテナイメージの CVE（脆弱性）
• 修正アクションの推奨

GKEはコンテナ化されたアプリケーションのデプロイを管理するマネージドKubernetesサービスであり、クラスタの動作モードとして「Autopilot」と「Standard」の2つを提供する。

Autopilotモードは、ノードのプロビジョニング、スケーリング、アップグレード、およびセキュリティ制約の管理をすべてGoogleが代行するフルマネージド環境であり、新規クラスタのデフォルトとして推奨される。課金モデルはPodが要求するリソース（vCPU、メモリ、エフェメラルストレージ）に基づいており、アイドル状態のノードに対するコストが発生しないため、負荷変動の激しいワークロードにおいてコスト効率が高い。一方、Standardモードは、ユーザーがノードプールを直接管理するIaaSに近いモデルであり、特権コンテナの実行、特定のカーネルパラメータの調整、高メモリインスタンスの指定、またはロギングや監視用のDaemonSetの実行が必要な場合に選択される。

セキュリティの観点から見ると、AutopilotクラスタはKubernetes Baselineセキュリティ標準をデフォルトで適用し、特権コンテナやホスト名前空間の利用をブロックする。また、Workload Identity Federationが自動的に有効化されており、Podがノードのメタデータサーバーに直接アクセスして機密情報を取得することを防ぐ。アプリケーションがGoogle CloudのAPI（Secret Managerなど）にアクセスする際は、静的なサービスアカウントキーをクラスタ内に保存するのではなく、このWorkload Identityを利用してKubernetesのサービスアカウントとGoogle CloudのIAMサービスアカウントを紐付けることが最も安全なアプローチである。

さらに、GKEのセキュリティ態勢を高めるための機能として、セキュリティポスチャダッシュボード（Security Posture Dashboard）が存在する。この機能は、Podの仕様における構成上の懸念事項や、コンテナイメージ内のワークロードの脆弱性を自動的にスキャンし、影響度の高いセキュリティ情報（CVEリンクや推奨される修正アクション）をプロアクティブに提示する。コンテナイメージの完全性を保証するためには、Binary Authorizationを利用し、事前に承認されたイメージのみがクラスタにデプロイされるようポリシーを強制する設定が求められる。

Object Lifecycle Management (OLM) で自動コスト最適化

# ライフサイクルポリシーの例
lifecycle:
  rule:
  - action:
      type: SetStorageClass
      storageClass: NEARLINE
    condition:
      age: 30        # 30日経過後 Nearline に移行
  - action:
      type: SetStorageClass
      storageClass: COLDLINE
    condition:
      age: 90        # 90日経過後 Coldline に移行
  - action:
      type: Delete
    condition:
      age: 365       # 365日後に削除

バケット名のベストプラクティス

論理削除（Soft Delete）

• デフォルトで有効（7日間保持）
• 削除後10分以内は同名バケットを再作成できない仕様に注意

署名付きURL（Signed URLs）

# Google アカウントなしでも一時的アクセスを提供
gcloud storage sign-url gs://BUCKET/OBJECT \
  --duration=1h \
  --private-key-file=KEY_FILE

• 有効期間は最大 7日間
• X-Goog-Algorithm、X-Goog-Expires などの情報が URL に含まれる

データは構造化？
├── YES → SQL が必要？
│         ├── YES → グローバル分散が必要？
│         │         ├── YES → Cloud Spanner（99.999% SLA）
│         │         └── NO  → 高性能 PostgreSQL？
│         │                   ├── YES → AlloyDB
│         │                   └── NO  → Cloud SQL
│         └── NO  → NoSQL
│                   ├── 大規模時系列・IoTデータ → Cloud Bigtable
│                   └── モバイル/リアルタイム同期 → Firestore
└── NO → 非構造化 → Cloud Storage（オブジェクト）

試験頻出: Cloud SQL vs Cloud Spanner vs AlloyDB

Cloud SQL:      小〜中規模、シングルリージョン、標準的なRDB
    ↓ スケールが足りなくなったら
Cloud Spanner:  グローバル、水平スケール、99.999% SLA が必要
AlloyDB:        PostgreSQL 互換を維持したまま性能を4倍に上げたい

データの性質とアクセスパターンに応じて、最適なストレージクラスやデータベースソリューションを選択することが、システムの性能とコストに直結する。

Cloud Storageは非構造化データの保存に使用され、アクセス頻度に応じて4つのストレージクラス（Standard、Nearline、Coldline、Archive）を使い分ける。コストを最適化するためには、オブジェクトの年齢や新しいバージョンかどうかに基づいて、自動的により低コストなストレージクラスへ移行させるか、削除を行うObject Lifecycle Management (OLM) を設定することが不可欠である。

セキュリティの観点からは、バケット名やオブジェクト名に関する厳格なベストプラクティスが存在する。バケット名は全ユーザー間でグローバルに一意である必要があり、URLとして公開される性質を持つため、個人情報や機密情報を含めてはならない。第三者による推測を防ぐため、意味を持たないコードネームやランダムなサフィックスを付与することが推奨される。

誤削除からの復元を担保する「論理削除（Soft Delete）」機能は、デフォルトで有効化されており、削除されたオブジェクトを7日間保持する。特定のユーザーに一時的なアクセスを許可する場合は、リソースに直接アクセスするための署名付きURL（Signed URLs）を生成する。このURLには、使用されるアルゴリズム（X-Goog-Algorithm）や有効期限（X-Goog-Expires、最大7日間）が含まれ、Googleアカウントを持たないユーザーとのセキュアなデータ共有を可能にする。

データウェアハウスの用途や、SQLを用いた機械学習モデルの構築にはBigQueryが最適であり、既存のOracleデータベースをリフト＆シフトでクラウドに移行する場合は、低遅延のハードウェアを提供するBare Metal Solutionが選択肢となる。

通常のクラウド（他社）:
  リージョンごとに別々の VPC が必要
                ↓
Google Cloud VPC:
  1つの VPC がグローバルに広がる！
  東京・米国・欧州のサブネットを1つの VPC で管理可能

Shared VPC（共有VPC） — 大規模組織での推奨構成

ホストプロジェクト（ネットワーク管理）
    ├── サブネット A（開発チーム用）
    │       ↑ ネットワーク使用権限付与
    │   サービスプロジェクト 1（開発チーム）
    │       └── VM, Cloud Run など
    │
    └── サブネット B（本番チーム用）
            ↑ ネットワーク使用権限付与
        サービスプロジェクト 2（本番チーム）
            └── VM, GKE など

メリット:

• ネットワーク管理と開発を 職務分掌（最小特権の原則）
• セキュリティポリシーを集中管理
• サービスプロジェクトは独自のコスト管理が可能

VPC Network Peering

VPC A ──── Peering ──── VPC B
                         │
                       Peering
                         │
                        VPC C

⚠️ 注意: A → B, B → C でも A → C は通信できない！
         （Peering は推移的でない）

Cloud NAT（プライベートインスタンスのインターネット接続）

プライベート VM（外部 IP なし）
    ↓
Cloud NAT（送信元 IP を変換）
    ↓
インターネット

ポート枯渇の監視（Cloud Monitoring MQL クエリ）:

fetch nat_gateway
| metric 'compute.googleapis.com/nat/port_usage'
| align mean_aligner()
| every 1m

Cloud DNS ベストプラクティス

対象トラフィックは HTTP/HTTPS？
├── YES → Application Load Balancer (L7)
│         ├── グローバル配信が必要 → Global External ALB（Premium Tier）
│         └── リージョン内のみ → Regional ALB
│
└── NO → Network Load Balancer (L4)
          ├── SSL オフロードが必要 → Proxy Network LB
          └── 送信元 IP を保持したい → Passthrough Network LB

Google CloudのVirtual Private Cloud (VPC) は、単一のVPCがグローバルに広がり、すべてのリージョンにまたがってサブネットを配置できるという独自の特徴を持つ。このアーキテクチャにより、マルチリージョン展開におけるネットワークの複雑さが大幅に軽減される。

大規模組織においては、Shared VPC（共有VPC） の導入がベストプラクティスである。Shared VPCは、1つのホストプロジェクト内でネットワークリソース（サブネット、ルート、ファイアウォール）を集中管理し、複数のサービスプロジェクトに属するリソースが共通のVPCネットワークを使用してセキュアに通信できるようにする機能である。これにより、ネットワーク管理タスクとインスタンス作成タスクの職務分掌（最小特権の原則）を徹底でき、例えば「Network User」ロールをサブネットレベルで特定のグループに付与することで、厳密なアクセス制御が実現する。

VPC間の接続には、VPC Network Peeringが一般的に使用される。これはGoogleのSDNを通じて2つのVPCを内部IPで高速に接続する手法であるが、重要な制約として「推移的（Transitive）ではない」点が挙げられる。VPC AがVPC Bとピアリングし、VPC BがVPC Cとピアリングしていても、AとCは直接通信できない。また、ピアリングするVPC間でIPアドレスの範囲が重複している場合、接続は確立できない。より複雑なトポロジやオンプレミスとの接続が必要な場合は、Cloud VPNやCloud Interconnectを利用し、動的ルーティング（BGP）によってネットワークの到達性をグローバルまたはリージョナルに管理する。

外部へのアウトバウンドトラフィックを制御し、プライベートIPしか持たないインスタンス群からインターネットへの安全なアクセスを提供するためには、Cloud NATを使用する。Cloud NATの運用においては、各VMに割り当てられるポートの枯渇を防ぐことが重要であり、Cloud MonitoringとMQLクエリ（compute.googleapis.com/nat/port_usage）を活用してポートの利用状況を継続的に監視する運用が不可欠である。

オンプレミスネットワークとGoogle Cloud間でのシームレスな名前解決を実現するためには、Cloud DNSのベストプラクティスを適用する。オンプレミス環境からCloud DNSのプライベートゾーンを解決するためには、インバウンドのサーバーポリシーを設定し、逆にGoogle CloudからオンプレミスのDNSを解決するためには、転送ゾーン（Forwarding zones）を使用してトラフィックをルーティングする。

管轄区域のコンプライアンス要件により、トラフィックを特定のリージョン内に留める必要がある場合や、TLSの終端を厳密に特定の地域で行う必要がある場合は、グローバルスコープではなく、必ず「リージョナル」ロードバランサを選択しなければならない。

❌ アンチパターン: State をローカルに保存
問題点:
・チームメンバー全員が別々の State を持つ
・並行作業で State が競合する（State Corruption）
・State の紛失リスク

✅ 推奨: Cloud Storage リモートバックエンド

# backend.tf
terraform {
  backend "gcs" {
    bucket  = "my-terraform-state-bucket"
    prefix  = "terraform/state"
  }
}

Cloud Storage バケットの設定:

• オブジェクトバージョニング を有効化（State の変更履歴を保存）
• State ロック を有効化（並行作業による競合を防止）

標準的なデプロイフロー:

1. コードを変更
   └── git commit & push

2. プランファイルを生成・確認
   └── terraform plan -out=tfplan
   └── プランファイルの内容をレビュー

3. 承認後に適用
   └── terraform apply tfplan

※ プランファイルは実行環境に依存するため、
   環境間を移動する際は注意が必要

既存リソースの Import

従来の方法（Terraform < 1.5）:

terraform import google_compute_instance.vm_instance \
  projects/PROJECT/zones/ZONE/instances/VM_NAME

モダンな方法（Terraform >= 1.5）:

# main.tf に import ブロックを追加
import {
  to = google_compute_instance.vm_instance
  id = "projects/PROJECT/zones/ZONE/instances/VM_NAME"
}

→ terraform plan と terraform apply を一連のパイプラインに統合できる。

リポジトリ構造:
environments/
    ├── dev/         ← dev ブランチへの merge で自動 apply
    │   ├── main.tf
    │   └── variables.tf
    └── prod/        ← main ブランチへの merge で自動 apply
        ├── main.tf
        └── variables.tf

認証のベストプラクティス（キーレス認証）

❌ アンチパターン:
# Cloud Build にサービスアカウント JSON キーを渡す
env:
  - GOOGLE_CREDENTIALS=${{ secrets.SA_KEY }}  # 危険！

✅ 推奨:
Cloud Build のサービスアカウント
    ↓ Workload Identity Federation / ADC を使用
権限借用（Impersonation）で一時クレデンシャルを取得
    ↓
Terraform apply を実行

インフラストラクチャの一貫性と再現性を担保するため、Terraformを利用したIaCのプラクティスがACE試験で問われる。

Terraformの運用において最も重要な概念は、状態（State）ファイルの管理である。terraform.tfstate ファイルは、Terraformの構成コードと実際のGoogle Cloudリソースのマッピングを維持する重要なファイルであり、このファイルを手動で直接変更することは構成の破損を招くため固く禁じられている。チームでの並行作業による競合を防ぐため、状態ファイルはローカルに保存するのではなく、Cloud Storageバケットをリモートバックエンドとして構成し、オブジェクトバージョニングと状態ロックを有効にして管理することがベストプラクティスである。

構成変更のデプロイプロセスにおいては、適用前に必ず terraform plan コマンドを実行し、出力されたプランファイル（例: terraform plan -out=tfplan）をレビューする手順を遵守する。この保存されたプランファイルは、実行環境のアーキテクチャや絶対パスに依存するため、実行環境間での移動には注意が必要である。また、コンソールから手動で作成された既存のリソースをTerraformの管理下に取り込む場合、従来は terraform import コマンドを使用していたが、Terraform バージョン 1.5 以降では構成コード内に import ブロックを記述することで、プランと適用を一連のパイプラインに統合するモダンなアプローチが可能となっている。

CI/CDの統合においては、Cloud Buildなどのマネージドサービスを使用し、GitOpsのメソドロジーを採用することが推奨される。例えば、リポジトリ内の environments/dev や environments/prod ディレクトリを使用して環境を論理的に分離し、ブランチへのマージをトリガーとして自動的に terraform apply が実行されるパイプラインを構築する。この際、パイプラインの実行にはサービスアカウントのJSONキーを使用するのではなく、クラウドプロバイダー固有の権限借用メカニズムやApplication Default Credentials (ADC) を活用してセキュアに認証を行う。

Ops Agent の役割

Compute Engine VM
    └── Ops Agent をインストール
            ├── Fluent Bit（ログ収集）
            │     └── アプリログ、システムログ → Cloud Logging
            └── OpenTelemetry Collector（メトリクス収集）
                  └── メモリ使用量、ディスク I/O → Cloud Monitoring

Kubernetes / GKE のモニタリング

GKE クラスタ
    └── Google Cloud Managed Service for Prometheus
            ↓
        オープンソース Prometheus と互換性あり
        運用オーバーヘッドなし（マネージド）
            ↓
        Cloud Monitoring でクエリ・アラート設定

SLO（サービスレベル目標）の設定

SLI（指標）の定義:
  例: 「99.9% のリクエストが 200ms 以内に応答する」

SLO の設定:
  Cloud Monitoring → SLO 作成
      ↓
  SLO 違反時にアラート発報
      ↓
  PagerDuty / Slack へ通知

💡 単純な「CPU 使用率 > 80%」アラートより、ユーザー体験に直結する SLO 監視を推奨。

監査ログ（Audit Logs）の種類

ログのルーティング戦略

Cloud Logging（Log Router）
    ├── Cloud Logging バケット（デフォルト: 30日保持）
    │
    ├── BigQuery（長期保存 + SQL 分析）
    │     └── 法規制対応、セキュリティ監査
    │
    ├── Cloud Storage（低コスト長期保管）
    │     └── コンプライアンス保管
    │
    └── Pub/Sub（リアルタイム処理）
          └── SIEM へのストリーミング

Linux でのスナップショット高速化:

# スナップショット前に未使用ブロックをフラッシュ
sudo fstrim -v /

# または、マウント時に discard オプションを付与
# /etc/fstab:
# /dev/sdb /data ext4 defaults,discard 0 0

→ スナップショットのサイズが小さくなり、取得が高速化されます。

Compute Engineの永続ディスクのバックアップとして、スナップショットを定期的に取得する運用が推奨される（ベストプラクティスとしては1時間に1回）。スナップショットの取得プロセスにおいて、アプリケーションを停止せずに取得するクラッシュ整合性（Crash Consistent）スナップショットと、未書き込みのデータをフラッシュしてから取得するアプリケーション整合性（Application Consistent）スナップショットの違いを理解することが重要である。Linux環境では、スナップショットのサイズを最小化し作成を高速化するために、作成前に fstrim コマンドを実行するか、discard オプションを付けてマウントする手法が推奨される。

Cloud Storageに保存された重要なデータの保護においては、誤削除からの回復を提供する「論理削除」機能に加え、規制遵守要件を満たすための保持ロック機能が存在する。特定のバケット内のすべてのオブジェクトに対して必須の保持期間を強制するバケットロック（Bucket Lock）や、オブジェクト単位で特定の期限まで削除・上書きを禁止するオブジェクト保持ロック（Object Retention Lock）を活用することで、強力なデータガバナンスが実現する。

システムの健全性を可視化するためには、Cloud MonitoringとCloud Loggingを連携させた統合的なアプローチが必要である。VM内の詳細なシステムメトリクス（メモリ使用量など）やサードパーティアプリケーションのログを収集するためには、Compute EngineインスタンスにOps Agentをデプロイする。Ops Agentは、ログ収集にFluent Bitを、メトリクス収集にOpenTelemetry Collectorを利用する統合エージェントである。Kubernetes環境におけるメトリクス収集においては、オープンソース標準との互換性を保ちながら運用オーバーヘッドを削減するために、Google Cloud Managed Service for Prometheusを利用することがベストプラクティスとされる。

Cloud Loggingは、アプリケーションのログやインフラストラクチャのログを一元的に収集する。特に重要なのが、システムへのアクセス履歴や設定変更の履歴を記録する監査ログ（Audit Logs）である。監査ログには、「管理アクティビティ（リソースの構成変更）」、「データアクセス（データの読み書き）」、「システムイベント（システムの動作）」の3種類が含まれ、セキュリティ要件に不可欠なデータソースとなる。GKE環境においては、これらの監査ログを無効化することはできず、さらにContainer-Optimized OSを使用するノードでは、バイナリの実行履歴などを追跡するために詳細なLinux auditdログを有効化することがセキュリティインシデントの調査において有効である。蓄積された膨大なログデータは、Log Routerの機能を利用してフィルタリングし、長期保存や高度なSQLクエリ分析を行うためにBigQueryへルーティング（エクスポート）することで、コストと運用効率のバランスを取る。

基本ロール（Basic Roles）
  ├── Viewer   (閲覧のみ)
  ├── Editor   (閲覧 + 編集)
  └── Owner    (すべての権限)
    ⚠️ 粒度が粗すぎる → 本番環境での使用は原則禁止

事前定義ロール（Predefined Roles）
  ├── roles/compute.instanceAdmin.v1
  ├── roles/storage.objectViewer
  └── ... (Google が用意した細かいロール)
    ✅ 基本的にこれを使用する

カスタムロール（Custom Roles）
  └── 特殊なワークフローのみ自前で定義
    ⚠️ 管理コストが増えるため最小限に

❌ アンチパターン: 静的 JSON キーの使用
サービスアカウント JSON キーを生成
    ↓
開発者のローカル PC / CI/CD に保存
    ↓
キーが GitHub に誤コミット or 漏洩！
    ↓
悪用されて莫大な請求が発生...

権限借用（Impersonation）

ユーザー A（通常権限）
    ↓ 権限借用（SA_B の impersonation 権限を持つ）
サービスアカウント B（管理者権限）
    ↓ 短期有効な認証情報（Short-lived credentials）を取得
管理タスクを実行
    ↓
「誰がいつ何を実行したか」が監査ログに残る

# 権限借用でリソースを操作
gcloud storage ls \
  --impersonate-service-account=SA_EMAIL@PROJECT.iam.gserviceaccount.com

PAM（Privileged Access Manager）

高度なエンタープライズ要件では PAM API を使用:

• 承認ワークフロー付きで一時的に特権を付与
• 自動的な権限取り消し（期限設定）
• 詳細な監査ログ

Cloud Asset Inventory

組織全体のリソースと IAM ポリシーを一元管理

主な機能:
・全リソースの検索・エクスポート
・IAM ポリシーの変更履歴の確認
・特定のリソースへのアクセス権を持つユーザーの一覧表示

# 組織内のすべての VM を一覧表示
gcloud asset search-all-resources \
  --asset-types='compute.googleapis.com/Instance' \
  --scope='organizations/ORG_ID'

IAMによるアクセス制御の根幹は「最小特権の原則（Principle of Least Privilege）」である。権限の割り当てにおいて、「編集者（Editor）」や「オーナー（Owner）」などの基本ロール（Basic Roles）はプロジェクト全体に対して過剰な権限を付与するため、レガシー環境や初期設定時を除き、本番環境での使用は厳しく制限されるべきである。代わりに、Googleによってキュレーションされた細かな権限の集合である「事前定義ロール（Predefined Roles）」を使用し、それでも要件を満たせない特殊なワークフローに対してのみ、独自の「カスタムロール（Custom Roles）」を定義する。

サービスアカウントの管理においては、認証情報の漏洩リスクを最小化する戦略が問われる。開発者がローカル環境からAPIにアクセスする際や、CI/CDパイプラインからリソースを操作する際に、静的なサービスアカウントキー（JSONファイル）を生成して使用することはセキュリティ上の重大なアンチパターンである。代わりに、ローカル開発環境では gcloud auth application-default login コマンドを使用してApplication Default Credentials (ADC) を生成し、外部のクラウドリソース（AWSやオンプレミス）からのアクセスには「Workload Identity連携」を設定して、動的なクレデンシャルを交換する手法が推奨される。

さらに、特権の永続的な割り当てを防ぐため、特定の管理タスクを実行する必要があるユーザーには、サービスアカウントの「権限借用（Impersonation）」を利用させる。これにより、ユーザー自身の権限を拡大することなく、短期有効な認証情報（Short-lived credentials）を用いて一時的に特権操作を実行させることが可能となり、詳細な監査ログを通じて「誰がいつ、どのサービスアカウントを利用したか」を正確に追跡できる。より高度なエンタープライズ要件に対しては、Privileged Access Manager (PAM) APIを利用して、承認ベースのアクセス権付与ワークフローを実装する。

複雑化するクラウド環境全体の設定や脆弱性を把握するためには、統合的な可視化ツールが不可欠である。Cloud Asset Inventoryは、組織全体にわたるGoogle CloudリソースやIAMポリシーの履歴を検索、分析、およびエクスポートする機能を提供し、リソースの階層構造やアクセス権の状況を一元的に把握することを可能にする。

ACE 試験の最新出題範囲として、Gemini Cloud Assist の活用が含まれています。

活用例

コンソールの Gemini Cloud Assist に入力:
「us-central1 で 2時間前から Cloud Run が 503 を返しています。原因を調査してください」
    ↓
Gemini が以下を自動分析:
・Cloud Logging のエラーログ
・Cloud Monitoring のメトリクス
・Cloud Asset Inventory の設定変更履歴
    ↓
根本原因と修正アクションを提示

最新の運用プラクティスとして、生成AIである「Gemini Cloud Assist」の活用がACE試験の出題範囲に組み込まれている。Gemini Cloud Assistは、自然言語によるプロンプトを通じて、インフラストラクチャのアーキテクチャ図の自動生成や、ベストプラクティスに準拠したデプロイ用テンプレート（Terraformなど）の作成を支援する。また、複雑なトラブルシューティングにおいては、Cloud Loggingのログ、Cloud Asset Inventoryの構成変更履歴、およびメトリクスデータを横断的に分析し、システム障害の根本原因（Root Cause Analysis）を特定する調査機能を提供する。FinOps Hubと連携することで、リソースの稼働率や無駄な支出を分析し、コスト最適化の機会をAIが提示する機能も備えており、クラウド運用における意思決定を強力にサポートする。

• ☐ IAM ポリシーの継承方向（上位 → 下位）を理解している
• ☐ 組織 → フォルダ → プロジェクト → リソースの階層を説明できる
• ☐ 予算アラートが上限達成時にリソースを 停止しない ことを知っている
• ☐ 自動コスト制御には Pub/Sub + Cloud Functions が必要だと知っている
• ☐ Cloud Billing を BigQuery にエクスポートする目的を説明できる

• ☐ Spot VM のユースケースとプリエンプト対応設計を説明できる
• ☐ GKE Autopilot vs Standard の使い分けを説明できる
• ☐ Workload Identity Federation が JSON キーより安全な理由を説明できる
• ☐ Cloud SQL / Spanner / AlloyDB / Bigtable / Firestore を使い分けられる
• ☐ OLM（Object Lifecycle Management）の設定方法を知っている
• ☐ Shared VPC とサービスプロジェクトの構成を説明できる
• ☐ Terraform の State ファイルをリモートバックエンドで管理できる
• ☐ VPC Peering が推移的でないことを知っている

• ☐ Ops Agent が必要なメトリクス（メモリ等）を知っている
• ☐ 監査ログの3種類（管理アクティビティ / データアクセス / システムイベント）を説明できる
• ☐ ログを BigQuery にルーティングする方法を知っている
• ☐ スナップショットスケジュールの推奨頻度（1時間ごと）を知っている
• ☐ SLO ベースの監視の重要性を説明できる

• ☐ 基本ロール（Editor/Owner）を本番で使うべきでない理由を説明できる
• ☐ サービスアカウント JSON キーのリスクと代替手法（ADC/WIF）を説明できる
• ☐ 権限借用（Impersonation）の利点（監査ログ + 最小特権）を説明できる
• ☐ 組織ポリシーで SA キー生成を禁止できることを知っている
• ☐ Binary Authorization の役割を説明できる

Google Cloud Associate Cloud Engineerとしての実践能力は、単一のサービスの設定方法を暗記することにとどまらず、セキュリティ、コスト、パフォーマンス、そして運用の自動化という多角的な観点から最適なアーキテクチャを設計し、実装する能力にかかっている。

本ガイドで詳述した通り、適切なリソース階層の設計とIAMによる最小特権の徹底、予算アラートやBigQueryエクスポートを通じた厳格なコスト管理は、クラウドジャーニーの基礎である。GKE Autopilotの採用による運用オーバーヘッドの削減とセキュリティ態勢の向上、Shared VPCとCloud DNSによるセキュアなネットワークトポロジの構築、そしてTerraformを用いたインフラストラクチャの状態管理とCI/CDパイプラインの統合は、スケーラブルなエンタープライズソリューションを実現するための核心技術である。

さらに、Ops AgentやManaged Service for Prometheusを通じたオブザーバビリティの確立と、Gemini Cloud AssistなどのAI駆動型ツールによるプロアクティブな障害調査およびコスト最適化は、現代のクラウドエンジニアにとって不可欠なスキルセットとなっている。これらのベストプラクティスと技術的洞察を日常のオペレーションに統合することで、エンジニアはGoogle Cloud環境における強固なガバナンスとアジリティを両立させ、ビジネス要件を満たすインフラストラクチャを継続的に提供することが可能となる。