~12–14問
2.1-Aコンピューティングサービスの選択とマシンファミリー▼
サービス選択フローチャート
▶ ワークロード種別によるサービス選択
コンピューティングサービス比較表
| サービス | 管理レベル | 課金単位 | 最適なユースケース | 特記事項 |
|---|---|---|---|---|
| Compute Engine | IaaS(完全制御) | vCPU/時 + メモリ/時 | レガシー移行、特定 OS・ライセンス | OS カーネル変更が可能 |
| Spot VM | IaaS(完全制御) | 最大 91% 割引 | バッチ、ML トレーニング、レンダリング | プリエンプト(強制停止)あり |
| GKE Autopilot | フルマネージド | Pod リソース(vCPU/メモリ) | マイクロサービス、API サービス | デフォルト推奨、セキュリティ自動強化 |
| GKE Standard | 半マネージド | ノード(VM)単位 | 特権コンテナ、DaemonSet、GPU/TPU | ノードプールを直接管理 |
| Cloud Run | サーバーレス | リクエスト / CPU 秒 | HTTP API、イベント処理、ゼロスケール | 第2世代推奨、Direct VPC Egress |
| Cloud Run Functions | サーバーレス | 呼び出し回数 + 時間 | 軽量グルーロジック、Webhook | イベント駆動の最小単位 |
| Agent Runtime | フルマネージド | vCPU 時 + GiB 時 | AI エージェントの実行基盤 | Python フレームワーク対応 |
試験の重要ポイント: GPU/TPU 搭載 VM は
--maintenance-policy=TERMINATE が強制されます(ライブマイグレーション不可)。試験の罠: OS Login が有効な場合、プロジェクトレベルのメタデータ SSH キーは無視されます。
2.1-Bストレージ選択 — Hyperdisk / Persistent Disk / Local SSDNEW 2026▼
Hyperdisk の最大優位点: 性能(IOPS/スループット)と容量を独立してプロビジョニング可能。Persistent Disk は容量を増やさないと性能が上がらないが、Hyperdisk はサイズを変えずに IOPS だけ増減できる。
ストレージ選択フローチャート
▶ データ永続性・性能要件によるストレージ選択
ストレージ種別詳細比較
| ストレージタイプ | 最大 IOPS | 最大スループット | 永続性 | 特徴・用途 |
|---|---|---|---|---|
| Hyperdisk Balanced | 160,000 | 2,400 MiB/s | ✅ 永続 | ★推奨。ベースライン 3,000 IOPS / 140 MiB/s が無料 |
| Hyperdisk Extreme | 350,000 | 5,000 MiB/s | ✅ 永続 | OLTP、ミッションクリティカル DB |
| Hyperdisk Throughput | 低い | 2,400 MiB/s | ✅ 永続 | 大規模分析、低コスト |
| Hyperdisk ML | 高(読み取り) | 高(読み取り) | ✅ 永続 | AI/ML モデルの高速配信、読み取り専用共有 |
| Balanced Persistent Disk | 80,000 | 1,200 MiB/s | ✅ 永続 | 従来型。容量に依存した性能 |
| SSD Persistent Disk | 100,000 | 1,200 MiB/s | ✅ 永続 | 高 IOPS 従来型 |
| Standard Persistent Disk | 7,500 | 400 MiB/s | ✅ 永続 | 最安。バッチ、コールドデータ |
| Local SSD | 2,400,000+ | 超高速 | ❌ 一時 | VM停止でデータ消失。キャッシュ、一時処理のみ |
bash
# Hyperdisk Balanced の作成例(IOPS とスループットを独立指定)
gcloud compute disks create my-hyperdisk \
--type=hyperdisk-balanced \
--size=500GB \
--provisioned-iops=10000 \
--provisioned-throughput=500 \
--zone=asia-northeast1-a2.1-CManaged Instance Group (MIG) — 自動スケールと高可用性▼
▶ MIG のアーキテクチャと自動機能
| 項目 | ゾーン MIG | リージョン MIG |
|---|---|---|
| 展開範囲 | 1ゾーン | 最大3ゾーンに均等分散 |
| 耐障害性 | 低い(ゾーン障害で全停止) | 高い(1ゾーン障害でも継続) |
| 推奨環境 | 開発・テスト | 本番環境(必須) |
bash
# インスタンステンプレート作成 → リージョン MIG → オートスケール
gcloud compute instance-templates create web-template \
--machine-type=n2-standard-4 --boot-disk-type=hyperdisk-balanced
gcloud compute instance-groups managed create web-mig \
--template=web-template --size=3 --region=asia-northeast1
gcloud compute instance-groups managed set-autoscaling web-mig \
--region=asia-northeast1 --max-num-replicas=10 \
--min-num-replicas=3 --target-cpu-utilization=0.61
リージョン MIG を選択 — ゾーン障害への耐性を確保(本番環境必須)
2
max-num-replicas に上限 — コスト暴走を防止
3
ローリングアップデートは max-unavailable=0 — ゼロダウンタイムを実現
4
Spot VM との組み合わせ — バッチ処理コストを最大 91% 削減
2.1-DOS Login と VM Manager(OS パッチ・インベントリ・設定管理)▼
▶ OS Login による IAM 統合アクセス管理フロー
| OS Login ロール | sudo 権限 | ユースケース |
|---|---|---|
roles/compute.osLogin | なし | 一般オペレーター |
roles/compute.osAdminLogin | あり | システム管理者 |
bash
# OS Login + 2FA 有効化(プロジェクト全体)
gcloud compute project-info add-metadata \
--metadata enable-oslogin=TRUE,enable-oslogin-2fa=TRUE
# VM Manager を有効化
gcloud compute project-info add-metadata \
--metadata=enable-osconfig=TRUE| VM Manager 機能 | 説明 |
|---|---|
| OS パッチ管理 | パッチの定期スケジュール、ゾーン単位のローリング適用 |
| OS インベントリ管理 | インストール済みパッケージ・OS 情報の自動収集 |
| OS 設定管理 | エージェントの大規模展開、設定の強制適用 |
2.1-ESpot VM とカスタムマシンタイプ▼
▶ Spot VM の仕組みとフォールトトレラント設計
bash
# Spot VM の作成
gcloud compute instances create my-spot-vm \
--machine-type=n2-standard-4 \
--provisioning-model=SPOT \
--instance-termination-action=STOP \
--zone=asia-northeast1-a
# カスタムマシンタイプ(6 vCPU、20GB メモリ)
gcloud compute instances create custom-vm \
--custom-cpu=6 --custom-memory=20GB \
--zone=asia-northeast1-a2.1-FGKE の展開設定 — Autopilot / Standard / プライベートクラスタ▼
▶ GKE Autopilot vs Standard の選択フロー
| 項目 | Autopilot | Standard | 説明 |
|---|---|---|---|
| ノード管理 | Google が自動管理 | ユーザーが管理 | Autopilot は OS パッチも自動 |
| 課金単位 | Pod リソース | ノード(VM) | Autopilot はアイドルコストなし |
| 特権コンテナ | ❌ 不可 | ✅ 可能 | Standard のみ |
| Workload Identity | 自動有効 | 手動設定 | JSON キーなしで GCP API アクセス |
| GPU/TPU | 制限あり | ✅ 完全対応 | カスタム GPU ノードは Standard |
bash
# Autopilot クラスタの作成(推奨)
gcloud container clusters create-auto my-autopilot-cluster \
--region=asia-northeast1 --enable-private-nodes
# kubectl インストールとクラスタ認証
gcloud components install kubectl
gcloud container clusters get-credentials my-cluster --region=asia-northeast12.1-Gサーバーレス — Cloud Run / Cloud Run Functions / Eventarc▼
▶ Cloud Run ネットワーキングアーキテクチャ(第2世代)
| トリガー種別 | ユースケース | 設定方法 |
|---|---|---|
| Pub/Sub メッセージ | 非同期処理、キューイング | Eventarc / 直接 Pub/Sub push |
| Cloud Storage 変更通知 | ファイルアップロード処理 | Eventarc |
| HTTP リクエスト | REST API、Webhook | 直接 HTTPS エンドポイント |
| Cloud Scheduler | 定期バッチ処理 | Scheduler → Pub/Sub → Cloud Run |
bash
# Cloud Run のデプロイ(第2世代 + Direct VPC Egress)
gcloud run deploy my-service \
--image=gcr.io/PROJECT_ID/my-app:latest \
--region=asia-northeast1 \
--execution-environment=gen2 \
--vpc-egress=all-traffic --network=my-vpc \
--min-instances=1 --max-instances=1002.1-HGPU と TPU の選択基準NEW 2026▼
▶ GPU vs TPU の選択フローチャート
| アクセラレータ | マシンファミリー | ユースケース | 特記事項 |
|---|---|---|---|
| NVIDIA L4 | G2 | コスト効率の良い推論、動画処理 | 汎用 GPU の中でコスパ最高 |
| NVIDIA A100 | A2 | 大規模 ML トレーニング、科学計算 | HBM メモリ搭載 |
| NVIDIA H100 | A3 | 最先端 LLM トレーニング | 最高性能 GPU |
| Cloud TPU v4/v5 | 専用 Pod | 大規模 TF/JAX モデル | Google 独自設計、超大規模 LLM |
必須: GPU/TPU 搭載 VM は
--maintenance-policy=TERMINATE が強制されます(ライブマイグレーション不可)。2.1-IAgent Runtime on Gemini Enterprise Agent PlatformNEW 2026▼
2026年6月版の試験ガイドで新規追加。旧名: Vertex AI Agent Engine。Python フレームワーク(LangChain、ADK 等)で構築した AI エージェントをフルマネージドで実行するプラットフォームです。
▶ Agent Runtime のアーキテクチャ
| 機能 | 説明 |
|---|---|
| マネージドランタイム | コンテナ化・デプロイを自動処理、スケーリングも管理不要 |
| Sessions | 会話履歴を管理、マルチターン会話をサポート |
| Memory Bank | 会話から長期記憶を抽出、パーソナライズを実現 |
| 課金モデル | vCPU 時 + GiB 時(使用リソースに応じた課金) |
~8–10問
2.2-Aデータベースサービスの選択と展開▼
▶ データベース選択フローチャート
データベースサービス完全比較表
| サービス | 種別 | スケール | 整合性 | ユースケース | 2026 新機能 |
|---|---|---|---|---|---|
| Cloud SQL | リレーショナル | 中規模 | 強整合性 | Web アプリ、ERP | — |
| Cloud Spanner | リレーショナル | グローバル水平 | 外部整合性 | 金融、グローバル在庫 | — |
| AlloyDB | リレーショナル(PG互換) | 大規模 | 強整合性 | HTAP、高性能 OLTP | pgvector ベクトル検索 |
| Firestore | ドキュメント型 | 自動 | 強整合性 | モバイル、IoT | — |
| Cloud Bigtable | ワイドカラム型 | ペタバイト | 結果整合性 | 時系列、IoT、広告 | — |
| Memorystore | インメモリ | 中規模 | — | キャッシュ、セッション | — |
| BigQuery | DWH | ペタバイト | — | 分析、BI、ML | BigQuery ML、Omni |
| Managed Kafka | ストリーミング | 大規模 | — | Kafka 互換ストリーミング | ★2026年新サービス |
2.2-Bストレージサービス — Cloud Storage / Filestore / Managed Lustre / NetApp VolumesNEW 2026▼
Cloud Storage ストレージクラスの選択
▶ アクセス頻度によるストレージクラス選択
ファイルストレージサービスの比較(2026年版)
2026年版では Google Cloud Managed Lustre と Google Cloud NetApp Volumes が試験範囲に追加されました。
| サービス | プロトコル | パフォーマンス | ユースケース | 特徴 |
|---|---|---|---|---|
| Filestore | NFS | 高い | GKE 共有ストレージ、CMS | スケール: GiB〜100TiB |
| Managed Lustre | Lustre(並列FS) | 超高速(ペタバイト) | HPC、AI/ML トレーニング、大規模科学計算 | 複数 VM からの並列 I/O アクセス |
| NetApp Volumes | NFS / SMB / iSCSI | 高い(複数ティア) | エンタープライズ、Windows/Linux 混在 | ONTAP 互換、スナップショット/レプリケーション内蔵 |
▶ ファイルストレージ選択フローチャート
2.2-Cデータのロード方法とマルチリージョン冗長性▼
データロード手法の比較
| 方法 | ユースケース | 特徴 |
|---|---|---|
| gcloud storage cp | 小〜中規模のファイル転送 | シンプル、スクリプト化が容易 |
| Cloud Storage からのロード | BigQuery、Bigtable への一括ロード | 最も効率的なバルクロード手法 |
| Storage Transfer Service | 他クラウド/オンプレミスからの移行 | スケジュール設定、大規模データ移行 |
| Dataflow | ストリーミング/バッチ ETL | リアルタイム変換、複雑なパイプライン |
| BigQuery Data Transfer Service | SaaS からの定期取り込み | Google Analytics、Ads 等と統合 |
マルチリージョン冗長性の設計パターン
▶ SLA / RPO 要件によるリージョン冗長性の選択
| サービス | Single Region | Dual Region | Multi Region |
|---|---|---|---|
| Cloud Storage | ✅ | ✅(2リージョン) | ✅(US/EU/ASIA) |
| Cloud SQL | HA(同一リージョン2ゾーン) | クロスリージョンレプリカ(読み取り専用) | ❌ |
| Cloud Spanner | ✅ | ✅ | ✅(真のグローバル分散) |
| Firestore | ✅ | ❌ | ✅ |
~8–10問
2.3-AVPC とサブネットの設計 — Shared VPC / VPC Peering▼
| VPC モード | 説明 | 推奨用途 |
|---|---|---|
| Auto Mode | 各リージョンにサブネットを自動作成(10.128.0.0/9) | 学習・PoC |
| Custom Mode | サブネット of IP レンジを手動設計 | 本番環境(必須) |
▶ Shared VPC vs VPC Network Peering の比較
| 比較項目 | Shared VPC | VPC Network Peering |
|---|---|---|
| 管理の一元化 | ✅ ホストプロジェクトで集中管理 | ❌ 各 VPC で個別管理 |
| 推移性 | ✅ サービスプロジェクト全体でアクセス | ❌ 推移的でない(A-B-C は A-C 通信不可) |
| 異組織間 | ❌ 同一組織内のみ | ✅ 異組織間も可能 |
| IP 重複 | 管理可能 | ❌ 重複した IP レンジは Peering 不可 |
試験の最頻出トラップ: VPC Peering は推移的ではありません。VPC A↔B、B↔C でも A と C は直接通信できません。A-C 間も通信させるには追加の Peering が必要です。
2.3-BVPC ファイアウォールと Cloud NGFW — Secure TagsNEW 2026▼
▶ Cloud NGFW のティア構成
ネットワークタグ vs セキュアタグ(Cloud NGFW)
| 比較項目 | ネットワークタグ(従来) | セキュアタグ(Cloud NGFW) |
|---|---|---|
| 管理 | VM のメタデータに直接設定 | 組織/プロジェクトレベルで IAM 管理 |
| セキュリティ | ユーザーが自由に変更可能 | タグの付与・変更に IAM 権限が必要 |
| スコープ | ネットワーク内のみ | 組織全体に適用可能 |
| 適用ポリシー | VPC ファイアウォールルール | Cloud NGFW ネットワークポリシー |
bash
# SSH は IAP からのみ許可(ネットワークタグベース)
gcloud compute firewall-rules create allow-ssh-iap \
--network=my-vpc --direction=INGRESS \
--action=ALLOW --rules=tcp:22 \
--target-tags=ssh-allowed \
--source-ranges=35.235.240.0/20
# セキュアタグキーの作成(Cloud NGFW)
gcloud resource-manager tags keys create webserver \
--parent=organizations/ORG_ID \
--purpose=GCE_FIREWALL \
--purpose-data=network=//compute.googleapis.com/projects/PROJECT/global/networks/my-vpc2.3-Cネットワーク接続の確立 — Cloud VPN / Cloud Interconnect▼
▶ オンプレミス / 他クラウドとの接続オプション
| 接続方法 | 帯域 | SLA | コスト | ユースケース |
|---|---|---|---|---|
| HA VPN | 最大 3Gbps/トンネル | 99.99%(HA 構成) | 低い | オンプレミス接続の標準 |
| Interconnect (Dedicated) | 10G or 100Gbps | 99.99% | 高い | 大規模・ミッションクリティカル |
| Interconnect (Partner) | 50Mbps〜10Gbps | 99.99% | 中程度 | 専用線が直接引けない場合 |
| VPC Network Peering | ネットワーク上限まで | — | なし | 同一 GCP 内の VPC 間 |
2.3-Dロードバランサの選定▼
▶ ロードバランサ選択フローチャート
| ロードバランサ | レイヤ | スコープ | 送信元 IP 保持 | SSL 終端 | Cloud Armor |
|---|---|---|---|---|---|
| Global External ALB | L7 | グローバル | ❌ | ✅ エッジ | ✅ |
| Regional External ALB | L7 | リージョン | ❌ | ✅ リージョン | ✅ |
| Internal ALB | L7 | VPC 内部 | ❌ | ✅ | ❌ |
| Proxy Network LB | L4 | リージョン | ❌ | ✅ | ❌ |
| Passthrough Network LB | L4 | リージョン | ✅ | ❌ | ❌ |
| Internal Passthrough NLB | L4 | VPC 内部 | ✅ | ❌ | ❌ |
試験頻出の罠(3つ):
① コンプライアンス要件(データを特定リージョンに留める)がある場合は必ず Regional LB を選択
② Proxy 型 NLB は送信元 IP が失われる(
③ UDP が必要な場合は Passthrough Network LB のみ対応
① コンプライアンス要件(データを特定リージョンに留める)がある場合は必ず Regional LB を選択
② Proxy 型 NLB は送信元 IP が失われる(
X-Forwarded-For ヘッダーで補完)③ UDP が必要な場合は Passthrough Network LB のみ対応
2.3-Eネットワークサービスティア — Premium vs StandardNEW 2026▼
| ティア | コスト | パフォーマンス | 特徴 |
|---|---|---|---|
| Premium Tier | 高い | 最高 | Google のグローバルバックボーンを使用。Global ALB、低レイテンシ、Anycast IP |
| Standard Tier | 低い | 通常 | インターネット経由でルーティング。リージョン単位の処理。Global ALB は使用不可 |
▶ Premium vs Standard ルーティング経路
重要:
Global External ALB は Premium Tier でのみ真のグローバル配信が可能です。Standard Tier を選択すると Regional LB として動作し、Anycast IP のメリットが失われます。~4–6問
2.4-AInfrastructure as Code — Terraform / Fabric FAST / Config Connector / HelmNEW 2026▼
| ツール | 特性 | 主な用途 |
|---|---|---|
| Terraform | 宣言的 IaC、プロバイダーエコシステム | GCP リソースの全般的な管理 |
| Fabric FAST | Terraform ベースのエンタープライズ Landing Zone | 組織全体の基盤構築、Google PSO 推奨 |
| Config Connector | Kubernetes CRD で GCP リソースを管理 | GKE 環境での GCP リソース管理 |
| Helm | Kubernetes パッケージマネージャー | GKE アプリケーションのデプロイ管理 |
Terraform の安全なデプロイフロー
▶ GitOps による Terraform 運用フロー
hcl
# backend.tf — State をリモートバックエンドで管理(必須)
terraform {
backend "gcs" {
bucket = "my-terraform-state-bucket"
prefix = "terraform/state"
}
}bash
# State バケットの作成(バージョニング必須)
gcloud storage buckets create gs://my-terraform-state-bucket \
--location=asia-northeast1 --uniform-bucket-level-access
gcloud storage buckets update gs://my-terraform-state-bucket --versioningFabric FAST — Google PSO 推奨の Landing Zone ツールキット
▶ Fabric FAST の段階的デプロイフロー
Fabric FAST の特徴: YAML ファクトリでサブネット・ファイアウォール・プロジェクトを宣言的管理。Google Cloud Professional Services Organization が実績から構築したエンタープライズ向けベストプラクティスが組み込み済み。
2.4-BAI 支援による計画と実装 — Gemini Cloud Assist / Gemini CLINEW 2026▼
| ツール | 主な機能 | ユースケース |
|---|---|---|
| Gemini Cloud Assist | Cloud Console 内の AI アシスタント | アーキテクチャ設計、トラブルシューティング、根本原因分析(RCA) |
| Gemini CLI | コマンドライン AI インターフェース | ターミナルから自然言語で GCP を操作 |
| Application Design Center | アプリケーション設計の可視化・管理 | マイクロサービスアーキテクチャの設計 |
▶ Gemini Cloud Assist の主要機能
Summary-Aキーワード → 正解サービス 即答マップ▼
💻 Pattern A: コンピューティングサービス
「VM 完全制御・特定 OS・ライセンス」Compute Engine
「コスト最小化・バッチ・停止許容」Spot VM + MIG
「コンテナ・K8s・運用負荷を減らしたい」GKE Autopilot ★
「特権コンテナ・DaemonSet・GPU」GKE Standard
「HTTP API・ゼロスケール・サーバーレス」Cloud Run
「イベント駆動・軽量処理・Webhook」Cloud Run Functions
「AI エージェント・Python フレームワーク」Agent Runtime 🆕
🗄️ Pattern B: データベースサービス
「グローバル分散・99.999%・水平スケール」Cloud Spanner
「PG 互換・高性能 OLTP・HTAP」AlloyDB
「MySQL/PG・標準的な Web アプリ」Cloud SQL
「ペタバイト・時系列・IoT・ミリ秒以下」Cloud Bigtable
「リアルタイム同期・モバイルアプリ」Firestore
「マイクロ秒・キャッシュ・セッション」Memorystore
「DWH・SQL 分析・ペタバイト分析」BigQuery
「Kafka 互換・ストリーミング」Managed Kafka 🆕
🌐 Pattern C: ネットワーク / FW
「SSH を IAM で管理したい」OS Login
「SSH を安全に・外部 IP なしで接続」IAP + OS Login
「組織全体に FW ポリシーを適用」Cloud NGFW 🆕
「ID ベースのマイクロセグメンテーション」Secure Tags 🆕
「データを特定リージョンに限定」Regional LB + 組織ポリシー
「複数プロジェクトでネットワーク共有」Shared VPC
「A→B→C でも A から C に通信したい」追加 Peering が必要
「UDP・送信元 IP 保持が必要」Passthrough Network LB
💾 Pattern D: ストレージ選択
「IOPS/スループットを独立制御したい」Hyperdisk Balanced 🆕
「最高 IOPS・ミッションクリティカル DB」Hyperdisk Extreme 🆕
「HPC・並列 FS・多数 VM から同時アクセス」Managed Lustre 🆕
「NFS/SMB 両方・ONTAP・エンタープライズ」NetApp Volumes 🆕
「VM の一時データ・最高速・消失 OK」Local SSD
「頻繁アクセス・コスト最安/GB」GCS Standard
「年 1 回以下・法規制保管・365日+」GCS Archive
「グローバル ALB + 最低レイテンシ」Premium Tier 🆕
Summary-B試験直前チェックリスト — Section 2 完全版▼
2.1 コンピューティング
- GKE Autopilot vs Standard の使い分け基準(特権コンテナ・DaemonSet・カーネル変更)を即答できる
- Spot VM のプリエンプト対応設計(チェックポイント・シャットダウンスクリプト・MIG との組み合わせ)を知っている
- Hyperdisk Balanced が Persistent Disk より優れている点(性能と容量の独立制御)を説明できる
- OS Login が有効な場合、プロジェクトレベルの SSH キーが無視されることを知っている
- VM Manager の OS Patch Management の主要機能(パッチ管理・インベントリ・設定管理)を知っている
- Cloud Run のトリガー種別(HTTP・Pub/Sub・Eventarc・Cloud Storage)を知っている
- GPU/TPU 搭載 VM は Maintenance Policy が TERMINATE 強制であることを知っている
- Agent Runtime が Python エージェントのマネージド実行基盤であることを知っている
2.2 ストレージとデータ
- Cloud Storage の 4 クラスと最小保存期間(なし・30日・90日・365日)を暗記している
- Cloud SQL / Spanner / AlloyDB / Bigtable / Firestore の使い分けを即答できる
- Managed Lustre(並列 FS・HPC)と NetApp Volumes(ONTAP・NFS/SMB/iSCSI)の違いを説明できる
- BigQuery へのデータロードは Cloud Storage 経由が最も効率的であることを知っている
- マルチリージョン vs デュアルリージョン vs シングルリージョンの使い分けを知っている
2.3 ネットワーク
- Shared VPC vs VPC Network Peering の使い分けを説明できる
- VPC Peering が推移的でないことを知っている(A-B-C でも A-C は直接通信不可)
- ネットワークタグ vs セキュアタグ(Cloud NGFW)の違いを説明できる
- コンプライアンス要件(データ主権)がある場合は Regional LB を選ぶことを知っている
- Passthrough Network LB が送信元 IP を保持できる唯一の LB であることを知っている
- Premium Tier vs Standard Tier の違いと Global ALB が Premium Tier 必須であることを知っている
2.4 IaC とツール
- Terraform の State ファイルをリモートバックエンド(GCS)で管理する理由を説明できる
- State ファイルを手動編集することの危険性を知っている
- Fabric FAST が Google PSO 推奨のエンタープライズ Landing Zone ツールであることを知っている
- Config Connector が Kubernetes CRD で GCP リソースを管理することを知っている
- Gemini Cloud Assist の主要機能(RCA・IaC 生成・コスト最適化)を知っている
ACE 試験公式ページ認定資格の概要・登録
試験ガイド PDF(2026年6月版)出題範囲の詳細
Google Cloud Hyperdisk新世代ブロックストレージ
ストレージ種別選択ガイドHyperdisk vs PD vs Local SSD
GKE Autopilot セキュリティセキュリティ標準の自動適用
GKE Autopilot vs Standard機能比較
Cloud Run ネットワーキングDirect VPC Egress
VM Manager OS パッチ自動パッチ管理
OS Login 設定IAM 統合 SSH アクセス
Spot VM作成と使用方法
Spot VM ベストプラクティスフォールトトレラント設計
MIG 作成ガイドオートスケール・ヒーリング
GPU ドキュメントアクセラレータ選択基準
Agent RuntimeGemini Enterprise Agent Platform
Cloud NGFW 概要次世代ファイアウォール
Secure TagsIAM 管理 ID ベースタグ
Cloud NGFW TiersEssentials/Standard/Enterprise
Shared VPC組織内ネットワーク共有
VPC 設計ベストプラクティスネットワーク設計指針
ロードバランサ選定ガイドL4/L7/Regional/Global
ネットワークサービスティアPremium vs Standard
Terraform ベストプラクティスState 管理・CI/CD 統合
Fabric FAST(GitHub)エンタープライズ Landing Zone
Config ConnectorKubernetes CRD で GCP 管理
Gemini Cloud AssistAI 支援の運用管理
Cloud Storage ベストプラクティスセキュリティ・コスト最適化
Google Cloud Managed Lustre並列ファイルシステム
Google Cloud NetApp Volumesエンタープライズファイルストレージ
Managed Kafkaフルマネージド Kafka サービス
DB 選定ガイド(ブログ)Google Cloud データベース比較