SECTION 1

セクション 1：
組織と基盤の Bootstrap

PCDE の土台。Organization → Folder → Project の階層設計、Shared VPC / Peering / PSC の選定、Infrastructure Manager / Config Connector による IaC、Cloud Build + Artifact Registry + Cloud Deploy の GCP ネイティブ CI/CD、GKE Fleet によるマルチクラスタ、Cloud Workstations / Gemini Code Assist / Cloud Assist / CLI までを体系的に押さえます。

📊 出題 ~20% 🏗️ 土台設計 🔑 後から変えづらい意思決定 📘🔧🎯 全レベル対応

出題 ~20% 📘 基礎 🔧 応用 🎯 要点

🔑 TL;DR — このセクションの要約 DevOps Engineer の Day 1 は 「組織の土台を後から直せない形で固める」こと。リソース階層は Organization → Folder（最大 10 階層）→ Project → Resource、IAM は 親 → 子に継承。複数プロジェクト集中管理は Shared VPC、マネージドサービス接続は Private Service Connect。IaC は Infrastructure Manager（マネージド Terraform） と Cloud Foundation Toolkit。CI/CD は Cloud Build + Artifact Registry + Cloud Deploy が GCP ネイティブ三種の神器。マルチクラスタは GKE Fleet + Config Sync + Policy Controller。開発環境は Cloud Workstations と Gemini Code Assist / Cloud Assist / CLI の使い分け。

🎯 学習目標

このセクションの達成度0 / 0

Organization / Folder / Project / Resource の 4 階層と IAM 継承を即答できる
Shared VPC / VPC Peering / Private Service Connect / NCC を要件で選定できる
Workload Identity Federation のフローを説明できる（SA キー禁止）
Infrastructure Manager / CFT / Config Connector / Terraform を使い分けられる
Cloud Build + Artifact Registry + Cloud Deploy の基本フローを描ける
GKE Fleet と Config Sync / Policy Controller / Cloud Service Mesh を語れる
Cloud Workstations と Cloud Shell の使い分けが即答できる
Gemini Code Assist / Cloud Assist / CLI の違いを説明できる

※ チェック状態はこのブラウザに保存されます。

🏛️ Bootstrap 5 原則 — Day 1 で決めるべきこと

Bootstrap で固める 5 つの土台。これらは 後から変更困難（プロジェクト ID は変更不可、サブネット範囲は重複不可など）です。

原則 1

リソース階層

Org → Folder（最大 10 階層）→ Project → Resource。IAM / Org Policy は親→子に継承。

原則 2

命名規則

プロジェクト ID は作成後変更不可。<company>-<env>-<app>-<seq> 形式で統一。

原則 3

ネットワーク設計

Shared VPC / Peering / PSC の選定。サブネット範囲は後から拡張・重複不可。

原則 4

IAM 設計

Basic Role 禁止、Group ベース付与、Predefined Role を最小権限で。SA キーは Workload Identity に置換。

原則 5

IaC 採用

Infrastructure Manager（マネージド Terraform）+ CFT ブループリント。手動構築から後で IaC 化はコスト大。

+α

Org Policy ガード

SA キー無効化、外部 IP 制限、データ常駐リージョン制限を初期から強制。

📐 リソース階層図

IAM / Org Policy は親 → 子に継承。Org で付与した roles/viewer は全 Folder / Project に伝播。

1.1 リソース階層・IAM・ネットワーク

4 階層の役割

階層	役割	制御単位
Organization	会社全体の最上位ノード（Cloud Identity / Workspace 紐付け）	Org Policy、全体監査ログ集約
Folder	部門・環境・国などの論理境界（最大 10 階層）	IAM / Org Policy の継承境界
Project	リソース所有・課金・API 有効化の単位	API、Quota、課金、IAM
Resource	実際のリソース（VM、GCS、GKE 等）	IAM（一部）、Labels

Folder 設計の 2 パターン

Application-centric

Org → App → dev/stage/prod

アプリチームが自律
IAM 分離が自然
新規組織には推奨気味

Environment-centric

Org → dev/stage/prod → App

環境横断の統制が強い
本番ガードを統一
規制強い組織向け

💡 Google の推奨組織内では 混在せず統一。途中で切り替えるのは大規模リファクタが必要。

3 つのネットワーク共有方式

方式	用途	特徴
Shared VPC	Org 内複数プロジェクト集中管理	ホスト + サービスプロジェクト、中央チームが統制
VPC Network Peering	異なる VPC を 1:1 で接続	推移性なし、CIDR 重複禁止
Private Service Connect	マネージドサービス・自社サービス公開	プライベート IP、CIDR 重複可（NAT 動作）
Network Connectivity Center	複数 VPN/Interconnect/SD-WAN 統合	ハブ&スポーク

SA キー禁止と Workload Identity

⚠️ SA キーは原則禁止JSON キーファイルは漏洩・ハードコード事故の温床。GKE Pod は Workload Identity、外部（GitHub Actions / AWS）は Workload Identity Federation、ローカルは ADC + gcloud auth で代替。

🔧 Shared VPC vs Peering vs PSC 詳細比較

観点	Shared VPC	VPC Peering	Private Service Connect
用途	Org 内集中管理	VPC を 1:1 接続	サービスエンドポイント公開
スコープ	Organization 内	Org 跨ぎ可	Org 跨ぎ可
推移性	同一 VPC	なし（A↔B↔C で A↔C 不可）	エンドポイント単位
CIDR 重複	不可	不可	可（NAT 動作）
マネージドサービス接続	△	×	◎（推奨）

🔧 PSC の 3 形態

PSC for Google APIs

googleapis.com にプライベート IP でアクセス。VPC SC 連携。

PSC for Published Services

自社や SaaS の内部サービスを別 VPC に公開（マルチテナント SaaS）。

PSC for Managed Services

Cloud SQL / Memorystore / AlloyDB へプライベート接続。

🔧 Workload Identity Federation フロー

🔧 頻出 Org Policy Constraints

Constraint	効果
`compute.vmExternalIpAccess`	VM への外部 IP 付与を制限
`compute.requireOsLogin`	OS Login 必須化
`iam.disableServiceAccountKeyCreation`	SA キー作成禁止（WIF 推奨）
`storage.uniformBucketLevelAccess`	GCS 均一アクセス制御強制
`gcp.resourceLocations`	リソース作成リージョン制限（データ常駐）
`sql.restrictPublicIp`	Cloud SQL パブリック IP 禁止

💡 Dry Run モードOrg Policy 変更前に どのリソースが違反するか を事前検出。本番適用前のリスク確認に必須（2024 追加）。

🔧 データ常駐性（Data Residency）

要件	解決策
特定リージョン限定	Org Policy `gcp.resourceLocations`
鍵をユーザー管理	CMEK（Cloud KMS）
HSM レベル	CMEK with Cloud HSM（FIPS 140-2 Level 3）
鍵をクラウド外保管	CMEK with Cloud EKM
規制プロファイル	Assured Workloads（FedRAMP / HIPAA / IL5 / EU 等）
EU 主権	Sovereign Controls for EU

🎯 ネットワーク共有方式即答

用途	答え
Org 内複数プロジェクト集中管理	Shared VPC
VPC を 1:1 接続（推移性なし）	VPC Peering
マネージドサービス接続	Private Service Connect
複数 VPN/Interconnect 統合	Network Connectivity Center
GCP ↔ AWS/Azure 直結	Cross-Cloud Interconnect

🎯 SA キー廃止の置換早見

旧（SA Key）	新（推奨）
GitHub Actions に SA Key	Workload Identity Federation
GKE Pod に Secret SA Key	Workload Identity for GKE
ローカル開発 SA Key	ADC + gcloud auth
GCE で SA Key	メタデータサーバ経由（自動）
AWS Lambda → GCP	Workload Identity Federation（AWS OIDC）

1.2 Infrastructure as Code（IaC）

主要 IaC ツール

ツール	種類	特徴
Infrastructure Manager	GCP マネージド Terraform	GCP が Terraform 実行を肩代わり、State 自動管理
Cloud Foundation Toolkit (CFT)	Terraform / Helm ブループリント集	Google 推奨の Org 構築・ネットワーク・IAM パターン集
Config Connector	K8s で GCP リソース管理	kubectl で GCP リソースを定義・適用
Terraform	OSS IaC（HCL）	業界標準、マルチクラウド対応
Helm	K8s パッケージマネージャ	アプリ単位のテンプレ管理

Infrastructure Manager の位置づけ

利用者 Infrastructure Manager GCP │ │ │ │ .tf ファイル / Git ──→ │ │ │ │ Terraform 実行 ────→ │ │ │ State 自動管理 │ │ デプロイ完了 ←──────── │ │

ユーザーは Terraform ファイルを書くだけ
GCP 側が Terraform CLI 実行・State 管理・Lock 制御 を肩代わり
IAM ベースで権限管理（CI/CD パイプラインから API 呼出可能）

Config Connector の例（K8s で GCS バケット作成）

apiVersion: storage.cnrm.cloud.google.com/v1beta1 kind: StorageBucket metadata: name: my-app-bucket namespace: prod spec: location: ASIA-NORTHEAST1 uniformBucketLevelAccess: true # kubectl apply -f bucket.yaml で GCS バケットが GCP に作成される

💡 GitOps の基本Git = Source of Truth。Argo CD / Flux / Config Sync が Git をポーリングしてクラスタを Git の状態に合わせる。

Python / Go による自動化（一時処理）

from google.cloud import compute_v1 client = compute_v1.InstancesClient() for instance in client.list(project="my-proj", zone="asia-northeast1-a"): if instance.labels.get("env") == "dev": client.stop(...) # Terraform で表現しにくい夜間バッチ・棚卸し処理を Python/Go SDK で記述

🔧 IaC 選定マトリクス

観点	Infrastructure Manager	Terraform 直接	Config Connector	CFT
形式	Terraform (HCL)	Terraform (HCL)	K8s CRD (YAML)	Terraform / Helm
実行	GCP マネージド	自己管理	K8s クラスタ内	自己実行
State 管理	自動（GCP 内）	GCS / Terraform Cloud	etcd（reconcile）	自己管理
適合チーム	GCP ネイティブ志向	マルチクラウド	K8s 文化強い	標準ブループリント採用
強み	Lock 自動、サポート	業界標準	K8s リコンシリエーション	Google 推奨パターン集

🔧 CFT の主要ブループリント

ブループリント	内容
`terraform-example-foundation`	Org 全体の Landing Zone（4 ステージ構築）
`terraform-google-network`	VPC / Shared VPC / Firewall
`terraform-google-project-factory`	プロジェクト量産・標準化
`terraform-google-iam`	IAM ロール / メンバー管理
`terraform-google-kubernetes-engine`	GKE クラスタ
`terraform-google-cloud-build`	Cloud Build トリガー

🔧 Config Sync vs Argo CD vs Flux

観点	Config Sync	Argo CD	Flux
提供	Google マネージド（Fleet 統合）	OSS（CNCF Graduated）	OSS（CNCF Graduated）
マルチクラスタ	Fleet 単位で集約	ApplicationSet	Multi-tenancy
UI	Cloud Console	豊富な専用 UI	CLI / Flux UI
ポリシー	Policy Controller 統合	別途必要	別途必要
推奨	GKE Fleet 利用組織	UI 重視	CLI/GitOps 文化

⚠️ よくあるミスTerraform State をローカル管理・Git commit → State 紛失・共同編集不可。Infrastructure Manager か GCS バックエンド + State Locking を使う。

🎯 IaC 選定即答

要件	答え
GCP マネージド Terraform 実行・State 自動	Infrastructure Manager
Google 推奨ブループリント	Cloud Foundation Toolkit (CFT)
K8s CRD で GCP リソース管理	Config Connector
マルチクラウド	Terraform 直接 + WIF
GitOps Pull 型（K8s）	Config Sync / Argo CD / Flux
GitOps Push 型	GitHub Actions / Cloud Build + kubectl
一時スクリプト処理	Python / Go SDK

1.3 CI/CD アーキテクチャ（基礎）

GCP ネイティブ CI/CD 三種の神器

Cloud Build

サーバーレスのビルド実行。cloudbuild.yaml + トリガー（push / PR / tag / Pub/Sub / schedule）。Private Pool で VPC 内ビルド可能。

保管

Artifact Registry

Docker / Maven / npm / Python / Apt / Yum / Helm / Go の統合保管。Remote / Virtual / Cleanup Policies / Artifact Analysis 統合。

Cloud Deploy

マネージド CD パイプライン。Skaffold ベース、Kustomize / Helm ネイティブサポート。Standard / Canary / Blue-Green 戦略対応。

CI/CD パイプラインの全体像

サードパーティ CI/CD ツール

ツール	用途
Git	バージョン管理の基本
Jenkins	老舗の CI、プラグイン豊富、Cloud Build へ移行する組織が増加
Argo CD	K8s GitOps デプロイ
Packer	OS イメージビルド（GCE カスタムイメージ）
kpt	K8s パッケージ管理（マニフェスト配布・更新）

🔧 Cloud Build vs Jenkins vs GitHub Actions

観点	Cloud Build	Jenkins	GitHub Actions
実行環境	サーバーレス（GCP）	自己管理 VM/K8s	GitHub ホスト or Self-hosted
GCP 統合	◎（IAM、Artifact Registry）	△（プラグイン）	◎（WIF）
並列ビルド	自動	ノード数次第	自動（同時実行制限）
プライベートリソース	Private Pool で VPC 内	Self-hosted	Self-hosted Runner
課金	ビルド分単位	VM コスト	分単位
推奨用途	GCP ネイティブ CI	レガシー Jenkins 資産	GitHub 中心の組織

🔧 Cloud Build Private Pool

🔑 VPC 内アクセスに必須VPC 内の Cloud SQL やプライベート GKE クラスタにビルドからアクセスするには Private Pool が必須。デフォルトプールは外部実行のため接続できない。

gcloud builds worker-pools create my-pool \ --region=asia-northeast1 \ --peered-network=projects/HOST_PROJECT/global/networks/shared-vpc \ --worker-machine-type=e2-medium # cloudbuild.yaml options: pool: name: 'projects/PROJECT/locations/asia-northeast1/workerPools/my-pool'

🔧 Artifact Registry の高度な機能

機能	内容
Remote Repositories	DockerHub / Maven Central のキャッシュプロキシ（レート制限回避）
Virtual Repositories	複数 upstream を 1 つの URL で統合
Cleanup Policies	古いイメージ自動削除（ストレージコスト削減）
Vulnerability Scanning	Artifact Analysis で自動 CVE スキャン
VPC Service Controls	境界内のみアクセス可
immutable tag	`--immutable-tags` でタグ上書き禁止（本番再現性）

🎯 CI/CD 即答

役割	サービス
CI（ビルド）	Cloud Build
アーティファクト保管	Artifact Registry
CD（デプロイ）	Cloud Deploy
K8s マニフェスト Render	Skaffold
マニフェストパッチ	Kustomize（base + overlay）
K8s パッケージマネージャ	Helm
VPC 内ビルド	Cloud Build Private Pool
古いイメージ自動削除	Artifact Registry Cleanup Policies

1.4 マルチ環境管理（GKE Fleet / Config Sync）

Ephemeral Environment（一時環境）

PR ごとに自動で環境を作成し、マージ後に破棄する手法。

1. PR を作成 ↓ 2. Cloud Build トリガー発火 ↓ 3. Cloud Deploy で「pr-123」ephemeral ターゲットにデプロイ ↓ 4. レビュアーが動作確認 ↓ 5. PR マージ後、ephemeral 環境を破棄

GKE Fleet（マルチクラスタ管理）

Fleet Host Project ├─ GKE クラスタ asia-tokyo（本番） ├─ GKE クラスタ us-central（本番） ├─ GKE クラスタ on-prem（GKE Enterprise） └─ Fleet 機能を一括有効化 ├─ Config Sync ├─ Policy Controller ├─ Cloud Service Mesh（旧 Anthos Service Mesh） ├─ Multi-Cluster Ingress └─ Multi-Cluster Services

GKE Release Channels の選定

チャネル	更新頻度	用途
Rapid	数週	最新機能を早期検証
Regular	数ヶ月	一般本番（デフォルト推奨）
Stable	半年	保守的、金融・規制業界

GKE アップグレード戦略

戦略	内容	適合
Surge Upgrade（デフォルト）	追加 Node を建ててから古い Node 削除	一般用途、PDB 必須
Blue-Green Upgrade	新旧 Node Pool 並行運用、切替後に旧削除	ステートフル、リスク高、コスト高
Maintenance Window	週/日単位の更新許可時間	運用時間制約
Maintenance Exclusion	セール期間中の更新停止（マイナー 30 日 / メジャー 180 日）	決算期、年末商戦

🔧 GKE Fleet の応用設計

Fleet Host Project: org-fleet-host ├─ Fleet Membership │ ├─ asia-tokyo-prod（GKE） │ ├─ us-central-prod（GKE） │ ├─ on-prem-cluster（Anthos on bare metal） │ ├─ eks-cluster（Anthos on AWS / 接続） │ └─ aks-cluster（Anthos on Azure / 接続） └─ Fleet 機能（一括 enable） ├─ Config Sync（Git → 全クラスタ同期） ├─ Policy Controller（OPA/Gatekeeper） ├─ Cloud Service Mesh（旧 ASM、Istio ベース） ├─ Multi-Cluster Ingress（グローバル LB） ├─ Multi-Cluster Services（クラスタ跨ぎ Service Discovery） ├─ Identity Service（外部 IdP 連携） └─ Workload Identity Fleet（統合プール）

🔧 Config Sync の RootSync vs RepoSync

種類	スコープ	用途
RootSync	クラスタ全体	Platform チームが全 namespace を管理
RepoSync	namespace 単位	アプリチームが自 namespace のみ管理（マルチテナント）

🔧 Ephemeral 環境の実装パターン

パターン	実装
Namespace per PR	1 クラスタ内に namespace 分離（軽量）
Cluster per PR	GKE Autopilot で都度作成（独立性高）
Cloud Run per PR	軽量、Cold Start 許容できる場合
Preview Environments	Cloud Deploy の自動プロモーション機能

🔧 Maintenance Window 設定

gcloud container clusters update my-cluster \ --maintenance-window-start "2024-01-01T18:00:00Z" \ --maintenance-window-end "2024-01-02T02:00:00Z" \ --maintenance-window-recurrence "FREQ=WEEKLY;BYDAY=SA,SU" # → 土日深夜（UTC）のみアップグレード許可

🚨 PDB 未設定で Surge UpgradePod が瞬断 → サービス影響。PodDisruptionBudget は必ず設定。Cluster Autoscaler の scale-down も尊重する。

🎯 複数環境管理即答

要件	答え
PR ごとに環境作成	Ephemeral Environments（Cloud Deploy / 自前）
マルチクラスタ統合管理	GKE Fleet
Git → クラスタ同期	Config Sync
K8s ポリシー強制	Policy Controller（OPA/Gatekeeper ベース）
Istio ベース Service Mesh	Cloud Service Mesh（旧 Anthos Service Mesh）
クラスタ跨ぎグローバル LB	Multi-Cluster Ingress
クラスタ跨ぎ Service Discovery	Multi-Cluster Services
GCE OS パッチ自動	VM Manager（OS Patch Management）

1.5 セキュアな開発環境（Cloud Workstations / Gemini）

Cloud Workstations vs Cloud Shell

用途	選択
一時的なコマンド実行、学習、軽い実験	Cloud Shell（5GB / 無料 / 60 分非アクティブ停止）
本格的な開発（IDE、長時間、社内 VPN リソース）	Cloud Workstations（VPC 内、CMEK、長時間）

Cloud Workstations の特徴

📦 構成

アクセス: ブラウザ（HTTPS）またはローカル IDE
永続化: Persistent Disk で個人ストレージ
ネットワーク: VPC 内（Shared VPC 対応）
イメージ: VS Code / JetBrains プリセット + カスタム
自動停止: アイドル時停止でコスト節約

🔒 エンタープライズ機能

Private Cluster（パブリック IP なし、IAP 経由）
VPC Service Controls
CMEK（Persistent Disk 暗号化）
IAM 統合
Audit Logs

Gemini 3 兄弟（2024-2025 新機能）

IDE

Gemini Code Assist

VS Code / JetBrains / Cloud Workstations 内で動作。コード補完、PR レビュー、30+ 言語。旧 Duet AI for Developers。

Console

Gemini Cloud Assist

GCP コンソール内 AI アシスタント。アーキ設計、トラブルシュート、コスト分析、Investigations。旧 Duet AI in Google Cloud。

CLI

Gemini CLI

ターミナルで動く Gemini エージェント。リポ理解、IaC 生成、CI/CD 設定生成、MCP サーバ連携。

🔧 Cloud Workstations のエンタープライズ構成例

Cloud Workstations Cluster（Private、VPC 内） ├─ Workstation Config A: Frontend チーム │ ├─ ベースイメージ: code-oss + Node.js + Cloud Code │ ├─ Persistent Disk 100 GB │ ├─ アイドル停止: 30 分 │ └─ machineType: e2-standard-4 ├─ Workstation Config B: Backend チーム │ ├─ ベースイメージ: code-oss + Go + Cloud SDK + kubectl │ └─ machineType: e2-standard-8 └─ Workstation Config C: ML チーム ├─ GPU 付き: n1-standard-8 + T4 └─ ベースイメージ: jupyterlab + PyTorch + Vertex AI SDK

🔧 Custom Image の構築

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest # 開発ツール追加 RUN apt-get update && apt-get install -y \ postgresql-client redis-tools jq \ && curl -sL https://cli.github.com/install.sh | bash # VS Code 拡張機能をプリインストール COPY .openvsx-extensions /tmp/extensions RUN /opt/code-oss/bin/code-oss --install-extension /tmp/extensions/*.vsix # → チーム全員が同じツール・拡張機能・設定でスタート可能

🔧 Gemini Code Assist Enterprise の応用

機能	用途
プライベートコード参照	自社リポジトリのコードを学習せずに、文脈として参照
カスタマイズ	社内コーディング規約をプロンプトに組み込み
コードレビュー	PR の自動レビュー（GitHub / GitLab 連携）
チャット	エディタ内対話
Code Transformations	一括リファクタ（古い API → 新 API 等）

🔧 Gemini Cloud Assist のユースケース

ユースケース	例
アーキ設計	「IoT デバイス 1M 台のテレメトリを集めるアーキを設計」
トラブルシュート	「prod-payment クラスタの 5xx が増えた原因は？」（Logs/Metrics を自動分析）
コスト分析	「先月のクラウドコストが 20% 増えた原因は？」
gcloud / Terraform 生成	「VPC ピアリングを 3 つの VPC で構築する Terraform」
Investigation	Cloud Logging から障害ストーリーを自動構築

🎯 開発環境即答

用途	答え
軽量シェル、無料	Cloud Shell
ブラウザ IDE、エンタープライズ	Cloud Workstations
カスタムイメージ	Workstation Config + Container Image
プライベート開発	Cloud Workstations + Private Cluster + IAP
IDE 内 AI コーディング支援	Gemini Code Assist
Console で AI 運用支援	Gemini Cloud Assist
ターミナルで AI エージェント	Gemini CLI

🎯 暗記必須の数値

項目	値
Folder 階層	最大 10 階層
Cloud Shell 永続ストレージ	5 GB
Cloud Shell 非アクティブ停止	60 分
Cloud Build Default タイムアウト	60 分（最大 24 時間）
Cloud Build Default ディスク	100 GB
GKE Maintenance Exclusion	マイナー 30 日 / メジャー 180 日
Monitoring Scope 紐付け	最大 375 プロジェクト
`_Default` Logging Bucket 保持	30 日
`_Required` Logging Bucket 保持	400 日（変更不可）

🔄 サービスリネーム最新一覧

2024-2025 年の改訂で多数のリネーム。旧名で出題されるひっかけに注意。

旧名	新名
Container Registry	Artifact Registry
Container Analysis	Artifact Analysis
Anthos Service Mesh（ASM）	Cloud Service Mesh
Anthos Config Management	Config Sync + Policy Controller
Anthos（一部）	GKE Enterprise
Duet AI for Developers	Gemini Code Assist
Duet AI in Google Cloud	Gemini Cloud Assist
Cloud DLP	Sensitive Data Protection
BeyondCorp Enterprise	Chrome Enterprise Premium
Cloud Functions Gen2	Cloud Run functions
Anthos Policy Controller	Policy Controller
Stratozone	Migration Center

🎯 要点と暗記 — 一問一答

Q1. Org 内の複数プロジェクトでネットワークを集中管理したい

A. Shared VPC。ホストプロジェクトの VPC を複数のサービスプロジェクトで共有。中央 Network チームが統制。

Q2. Cloud SQL や Memorystore にプライベート IP で接続したい

A. Private Service Connect for Managed Services。CIDR 重複も可能。

Q3. GitHub Actions から SA キーなしで GCP に認証したい

A. Workload Identity Federation（WIF）。id-token: write 権限で OIDC token を発行し、WIF Pool で検証 → SA Impersonation。attribute-condition でリポ・ブランチ制限。

Q4. GCP マネージドな Terraform 実行サービスは？

A. Infrastructure Manager。Terraform CLI 実行・State 管理・Lock 制御を GCP が肩代わり。

Q5. Google 推奨パターンの Landing Zone を素早く構築したい

A. Cloud Foundation Toolkit (CFT) の terraform-example-foundation を Infrastructure Manager で適用。

Q6. K8s の文化で GCP リソースも宣言的に管理したい

A. Config Connector。K8s CRD で GCP リソースを定義、kubectl apply で作成。リコンシリエーション付き。

Q7. Cloud Build から VPC 内の Cloud SQL にアクセスしたい

A. Cloud Build Private Pool（Worker Pool）。VPC ピアリングで内部ネットワークアクセス可能に。

Q8. 複数の GKE クラスタを 1 つの論理単位で管理したい

A. GKE Fleet。Config Sync / Policy Controller / Cloud Service Mesh / Multi-Cluster Ingress を一括 enable。

Q9. ブラウザベースの IDE で社内 VPN リソースを使いたい

A. Cloud Workstations。VPC 内に配置、CMEK 対応、JetBrains / VS Code / Cloud Code プリセット。

Q10. GCP コンソール内でアーキ設計や障害調査を AI に手伝わせたい

A. Gemini Cloud Assist（旧 Duet AI in Google Cloud）。Logs / Metrics を自動分析する Investigations 機能あり。

💡 必殺フレーズ集（試験当日用）

状況	即答
「組織基盤を Google 推奨で構築」	Cloud Foundation Toolkit + Infrastructure Manager
「複数プロジェクトのネットワーク集中管理」	Shared VPC
「Cloud SQL にプライベート接続」	Private Service Connect
「GitHub Actions → GCP 認証（キーなし）」	Workload Identity Federation
「GKE Pod → GCP API（キーなし）」	Workload Identity for GKE
「全社の監査ログ集約」	Aggregated Sink（Organization レベル）
「データを EU に留める」	Org Policy `gcp.resourceLocations` + Assured Workloads (EU)
「鍵を自前管理、無効化で即時アクセス停止」	CMEK
「IaC マネージド実行・State 自動」	Infrastructure Manager
「K8s で GCP リソースを宣言管理」	Config Connector
「マルチクラウド K8s 統合」	GKE Enterprise（旧 Anthos）+ Fleet
「Git からマルチクラスタ同期」	Config Sync
「K8s ポリシー強制（OPA）」	Policy Controller
「Pod 単位課金の K8s」	GKE Autopilot
「Cloud Build からオンプレ DB に接続」	Cloud Build Private Pool
「古いイメージ自動削除」	Artifact Registry Cleanup Policies
「マイクロサービスのトラフィック管理」	Cloud Service Mesh（旧 ASM）
「複数クラスタにグローバル LB」	Multi-Cluster Ingress
「PR ごとに環境作成」	Ephemeral Environments
「ブラウザ IDE で社内 VPN リソース利用」	Cloud Workstations
「軽い試し・無料シェル」	Cloud Shell
「IDE 内 AI コーディング支援」	Gemini Code Assist
「Console で AI 運用支援」	Gemini Cloud Assist
「ターミナルで AI エージェント」	Gemini CLI
「Org Policy を本番適用前に検証」	Dry Run モード
「人事異動に強い IAM」	Google Group ベース付与
「時間限定アクセス」	IAM Conditions
「JIT 昇格・承認制」	Privileged Access Manager (PAM)

🔑 5 分で復習する箇条書きまとめ

リソース階層: Org → Folder（10 階層）→ Project → Resource、IAM は親→子に継承
ネットワーク共有: Shared VPC（Org 内集中）/ Peering（1:1 非推移）/ PSC（マネージド接続）
IAM: Basic 禁止、Group ベース、Predefined、Conditional、PAM 承認制
SA キー廃止: Workload Identity（GKE）/ Workload Identity Federation（外部）
データ常駐: gcp.resourceLocations + CMEK + Assured Workloads
IaC: Infrastructure Manager（マネージド）/ CFT（ブループリント）/ Config Connector（K8s）/ Terraform
CI/CD GCP ネイティブ: Cloud Build（Private Pool）+ Artifact Registry + Cloud Deploy
マルチクラスタ: GKE Fleet + Config Sync + Policy Controller + Cloud Service Mesh
アップグレード: Release Channels（Rapid/Regular/Stable）+ Surge/Blue-Green + Maintenance Window
開発環境: Cloud Shell（5GB / 無料 / 60 分）+ Cloud Workstations（VPC 内・CMEK）
Gemini: Code Assist（IDE）/ Cloud Assist（Console）/ CLI（ターミナル）
リネーム: Container Registry → Artifact Registry、ASM → Cloud Service Mesh、Duet AI → Gemini

🧭 次のステップ

← ホームに戻るセクション 2：CI/CD パイプライン → 📝 問題演習を解く 📖 用語集

セクション 1：組織と基盤の Bootstrap

🎯 学習目標

🏛️ Bootstrap 5 原則 — Day 1 で決めるべきこと

リソース階層

命名規則

ネットワーク設計

IAM 設計

IaC 採用

Org Policy ガード

📐 リソース階層図

1.1 リソース階層・IAM・ネットワーク

4 階層の役割

Folder 設計の 2 パターン

Application-centric

Environment-centric

3 つのネットワーク共有方式

SA キー禁止と Workload Identity

🔧 Shared VPC vs Peering vs PSC 詳細比較

🔧 PSC の 3 形態

PSC for Google APIs

PSC for Published Services

PSC for Managed Services

🔧 Workload Identity Federation フロー

🔧 頻出 Org Policy Constraints

🔧 データ常駐性（Data Residency）

🎯 ネットワーク共有方式 即答

🎯 SA キー廃止の置換早見

1.2 Infrastructure as Code（IaC）

主要 IaC ツール

Infrastructure Manager の位置づけ

Config Connector の例（K8s で GCS バケット作成）

Python / Go による自動化（一時処理）

🔧 IaC 選定マトリクス

🔧 CFT の主要ブループリント

🔧 Config Sync vs Argo CD vs Flux

🎯 IaC 選定 即答

1.3 CI/CD アーキテクチャ（基礎）

GCP ネイティブ CI/CD 三種の神器

Cloud Build

Artifact Registry

Cloud Deploy

CI/CD パイプラインの全体像

サードパーティ CI/CD ツール

🔧 Cloud Build vs Jenkins vs GitHub Actions

🔧 Cloud Build Private Pool

🔧 Artifact Registry の高度な機能

🎯 CI/CD 即答

1.4 マルチ環境管理（GKE Fleet / Config Sync）

Ephemeral Environment（一時環境）

GKE Fleet（マルチクラスタ管理）

GKE Release Channels の選定

GKE アップグレード戦略

🔧 GKE Fleet の応用設計

🔧 Config Sync の RootSync vs RepoSync

🔧 Ephemeral 環境の実装パターン

🔧 Maintenance Window 設定

🎯 複数環境管理 即答

1.5 セキュアな開発環境（Cloud Workstations / Gemini）

Cloud Workstations vs Cloud Shell

Cloud Workstations の特徴

📦 構成

🔒 エンタープライズ機能

Gemini 3 兄弟（2024-2025 新機能）

Gemini Code Assist

Gemini Cloud Assist

Gemini CLI

🔧 Cloud Workstations のエンタープライズ構成例

🔧 Custom Image の構築

🔧 Gemini Code Assist Enterprise の応用

🔧 Gemini Cloud Assist のユースケース

🎯 開発環境 即答

🎯 暗記必須の数値

🔄 サービスリネーム最新一覧

🎯 要点と暗記 — 一問一答

💡 必殺フレーズ集（試験当日用）

🧭 次のステップ

セクション 1：
組織と基盤の Bootstrap

🎯 ネットワーク共有方式即答

🎯 IaC 選定即答

🎯 複数環境管理即答

🎯 開発環境即答