🏗️ 組織と基盤の Bootstrap 徹底深掘り
Google Cloud 組織を正しい姿で立ち上げる Landing Zone 設計から、Shared VPC・WIF・IaC・GKE Fleet・Cloud Workstations まで、実務 BP と事故ケースを深掘り。Cloud Foundation Fabric / Enterprise Foundations Blueprint / Workload Identity Federation の attribute condition / Fleet の Sameness 原則 / Config Sync の RootSync vs RepoSync など、PCDE で「Google が推奨するパターン」を即答するための一枚教材です。
公式 docs 準拠
🎯 上級
⚙️ 内部動作
📊 制限値表
⚠️ 事故ケース 35+
🏛️ Landing Zone
🎯 試験頻出
⚠️ 事故ケース
✅ ベストプラクティス
📋 制限値
💰 コスト
🔑 TL;DR — このページの結論
Landing Zone は Identity / Resource Hierarchy / Network / Security の 4 要素を Terraform で IaC 化して bootstrap、Google 公式は Enterprise Foundations Blueprint（4 ステージ：bootstrap → org → environments → networks/projects）。Resource Hierarchy は Org → Folder（最大 10 階層 / Org あたり 300 フォルダ）→ Project（Project ID は作成後変更不可、削除後 30 日 reservation）。Shared VPC は 1 Host Project に複数 Service Project（Service Project は 1 Host にのみ所属、同一 Org 内のみ）、VPC Peering は 非推移（A↔B↔C で A↔C 不通）/ CIDR 重複禁止、PSC は NAT で IP 重複 OK / マネージドサービス推奨。
Workload Identity Federation は OAuth 2.0 Token Exchange + STS で SA Key を完全廃止、Workload Identity Pool（1 Project 100 個）/ Provider（1 Pool 100 個）/ Attribute Mapping（最大 50 個、google.subject 必須・127 文字）/ Attribute Condition で必ず repo/branch 限定。IaC は Infrastructure Manager（マネージド Terraform、State 自動）/ Config Connector（K8s CRD で GCP リソース）/ CFT / Cloud Foundation Fabric（FAST）を用途別に選択。
GKE Fleet の核心は Sameness（同名 namespace / service は同一エンティティ）/ Exclusivity（1 cluster は 1 fleet のみ）/ High Trust。Config Sync は RootSync（クラスタ全体・Platform 用）vs RepoSync（namespace 単位・アプリ用）。Policy Controller は OPA Gatekeeper 統合の ConstraintTemplate + Constraint。
Cloud Workstations は Cluster（VPC 紐付け）→ Config（テンプレ：machineType / image / IDE）→ Instance（ephemeral GCE VM + Persistent Home）の 3 層、Gemini Code Assist 統合。最大の事故源は SA Key 流出 / WIF Attribute Condition 緩すぎ / Folder 削除でリソース道連れ / Project quota 上限到達 / Config Sync drift で本番上書き / Workstations 中断で作業消失の 6 つです。
Workload Identity Federation は OAuth 2.0 Token Exchange + STS で SA Key を完全廃止、Workload Identity Pool（1 Project 100 個）/ Provider（1 Pool 100 個）/ Attribute Mapping（最大 50 個、google.subject 必須・127 文字）/ Attribute Condition で必ず repo/branch 限定。IaC は Infrastructure Manager（マネージド Terraform、State 自動）/ Config Connector（K8s CRD で GCP リソース）/ CFT / Cloud Foundation Fabric（FAST）を用途別に選択。
GKE Fleet の核心は Sameness（同名 namespace / service は同一エンティティ）/ Exclusivity（1 cluster は 1 fleet のみ）/ High Trust。Config Sync は RootSync（クラスタ全体・Platform 用）vs RepoSync（namespace 単位・アプリ用）。Policy Controller は OPA Gatekeeper 統合の ConstraintTemplate + Constraint。
Cloud Workstations は Cluster（VPC 紐付け）→ Config（テンプレ：machineType / image / IDE）→ Instance（ephemeral GCE VM + Persistent Home）の 3 層、Gemini Code Assist 統合。最大の事故源は SA Key 流出 / WIF Attribute Condition 緩すぎ / Folder 削除でリソース道連れ / Project quota 上限到達 / Config Sync drift で本番上書き / Workstations 中断で作業消失の 6 つです。
📚 参照する公式ドキュメント
本資料は以下の Google Cloud 公式ドキュメント（2026 年時点）から技術詳細・制限・SLA・ベストプラクティスを抽出しています。各章で都度引用と URL を併記します。
1Landing Zone と組織設計
Landing Zone とは「Google Cloud に最初に降り立つ場所」=「組織として安全に・スケーラブルにワークロードを動かせる最低限の土台」のこと。Google は Identity / Resource Hierarchy / Network / Security の 4 要素を IaC で bootstrap し、ワークロードを追加しながら段階的に拡張することを推奨します。試験では「最初に何を Folder で切るか」「Org Policy をどこに当てるか」「IAM / Org Policy の継承」「Cloud Foundation Fabric / CFT の選定」が頻出です。
「A landing zone is the modular, scalable foundation that enables your enterprise to adopt Google Cloud. ... designed around four key elements: identity provisioning, resource hierarchy, network design, and security.」 — Landing zone design in Google Cloud
1.1 リソース階層の全体像（Org / Folder / Project / Resource）
図 1-1：Google Cloud リソース階層と IAM/Org Policy の継承
1.2 各階層の役割と制限値
| 階層 | 役割 | 制御単位 | 主な制限 |
|---|---|---|---|
| Organization | 最上位、Cloud Identity / Workspace に紐付け | Org Policy、Aggregated Sink、Org Admin | 1 ドメインに 1 つ、削除に注意 |
| Folder | 部門 / 環境の論理境界 | IAM / Org Policy 継承境界 | 最大 10 階層 / Org あたり 300 Folder / 1 親 直下 300 Folder |
| Project | リソース所有・課金・API 有効化の単位 | API、Quota、課金、IAM | Project ID 作成後変更不可、削除後 30 日 reservation、Org あたり quota 制（拡張可） |
| Resource | 実リソース (GCE / GCS / GKE 等) | IAM（一部）、Labels | 各サービスのリソース quota |
1.3 Folder 設計パターン（Application-centric vs Environment-centric）
🅰 Application-centric
Org
├─ app-payment
│ ├─ dev / stage / prod
├─ app-search
│ ├─ dev / stage / prod
└─ common- アプリチームが IAM / 予算を自律運用
- 新規アプリ追加が容易（テンプレ Folder 複製）
- 環境横断の統制（Org Policy）は Org / common に集中
- マイクロサービス組織・スタートアップ向け
🅱 Environment-centric
Org
├─ prod
│ ├─ app-payment / app-search
├─ stage
│ └─ ...
└─ dev- 本番 / 開発の 境界が明確（金融・規制対応）
- prod Folder に「外部 IP 禁止」等の 強い Org Policy 集中
- アプリ追加で 3 Folder 触る必要あり
- 強い変更管理 / 監査プロセスのある企業向け
💡 ベストプラクティス
混在禁止。組織内では Application-centric / Environment-centric のどちらか 1 つに統一する（途中で変えると Folder 構造の再設計が必要 = 数百プロジェクト動かすことになる）。新規組織には Application-centric がやや推奨（チーム自律性 / DevOps カルチャー）。
1.4 Enterprise Foundations Blueprint（Google 公式の Landing Zone）
Google は Enterprise Foundations Blueprint（旧 Security Foundations Blueprint）として、Terraform で構築する Landing Zone の参照実装を提供。4 ステージで段階的に bootstrap します。
- Stage 0: bootstrap — Terraform の bootstrap プロジェクト・seed project・CI/CD（Cloud Build）・Terraform 用 SA を作成。これだけは 手作業 or gcloud で一度だけ。
- Stage 1: org — Org Policy / IAM の組織横断ポリシー、共通 Folder（common / production / non-production / development）作成。
- Stage 2: environments — 各環境 Folder 配下の共通プロジェクト（host VPC / DNS / Secret / logging / monitoring）作成。
- Stage 3: networks & projects — 各環境の Shared VPC / Subnet / Firewall / Interconnect、アプリ用 Service Project の量産（Project Factory）。
1.5 Cloud Foundation Toolkit (CFT) vs Cloud Foundation Fabric (FAST)
| 観点 | Cloud Foundation Toolkit (CFT) | Cloud Foundation Fabric (FAST) | Terraform Modules for Google |
|---|---|---|---|
| 提供元 | Google Cloud Professional Services | Google Cloud（OSS、より opinionated） | HashiCorp 公式 Verified |
| 提供形式 | Terraform / Helm の module 集 | End-to-End FAST (Foundation, Application, Security, Team) blueprint | module 集 |
| カスタマイズ性 | 高（module を選んで自分で組む） | 低（Google 推奨を素直に採用） | 高 |
| 学習コスト | 中 | 高（FAST 全体の理解が必要） | 低 |
| 適合 | 既存 Terraform 資産がある組織 | 新規組織・PoC から本番まで一気通貫 | マルチクラウド組織 |
🔑 試験ポイント
「Google が推奨する Landing Zone を Terraform で素早く構築」=「Cloud Foundation Toolkit の
terraform-example-foundation」または「Cloud Foundation Fabric」。組織がエンタープライズ規模なら Fabric / FAST、既存 Terraform module 資産がある中堅組織なら CFT。「全く同じものを 100 プロジェクトで複製したい」→ Project Factory module が答え。
1.6 Organization Policy の Constraint タイプ
| タイプ | 説明 | 例 | 設定方法 |
|---|---|---|---|
| Boolean Constraint | true / false で機能を on/off | compute.disableSerialPortAccess、iam.disableServiceAccountKeyCreation | enforce: true/false |
| List Constraint | allow / deny リストで値制限 | compute.vmExternalIpAccess、gcp.resourceLocations | allowedValues / deniedValues |
| Custom Constraint | CEL で任意条件（2023 GA） | custom.requireProjectLabel | CEL 式、CREATE/UPDATE methodType |
1.7 試験頻出 Org Policy Constraint（20 個）
| Constraint | タイプ | 効果 / 用途 |
|---|---|---|
iam.disableServiceAccountKeyCreation | Boolean | SA Key 作成禁止（WIF 移行の第一歩） |
iam.disableServiceAccountKeyUpload | Boolean | 外部生成 Key のアップロード禁止 |
iam.disableServiceAccountCreation | Boolean | SA 自体の作成禁止（中央管理） |
iam.automaticIamGrantsForDefaultServiceAccounts | Boolean | Default SA への Editor 自動付与を阻止 |
iam.allowedPolicyMemberDomains | List | 許可ドメイン制限（外部メンバー流入防止） |
compute.vmExternalIpAccess | List | 外部 IP 付与可能な VM を限定 |
compute.requireOsLogin | Boolean | OS Login 必須（SSH 鍵集中管理） |
compute.requireShieldedVm | Boolean | Shielded VM 必須 |
compute.skipDefaultNetworkCreation | Boolean | 新規プロジェクトの default VPC 作成抑止 |
compute.restrictVpcPeering | List | VPC Peering 相手の制限 |
compute.restrictSharedVpcHostProjects | List | Shared VPC Host にできる Project 限定 |
compute.restrictSharedVpcSubnetworks | List | 使える Shared VPC subnet 制限 |
storage.uniformBucketLevelAccess | Boolean | GCS の均一アクセス強制（ACL 禁止） |
storage.publicAccessPrevention | Boolean | GCS public 公開禁止 |
sql.restrictPublicIp | Boolean | Cloud SQL Public IP 禁止 |
sql.restrictAuthorizedNetworks | Boolean | Cloud SQL の Authorized Networks 禁止 |
gcp.resourceLocations | List | リソース作成可能リージョン制限（データ常駐） |
gcp.restrictNonCmekServices | List | CMEK 必須サービス指定 |
gcp.restrictCmekCryptoKeyProjects | List | CMEK 鍵に使える Project 限定 |
essentialcontacts.allowedContactDomains | List | essential contact のドメイン制限 |
1.8 Org Policy の Dry-Run モード
Org Policy を本番適用する前に、違反対象を Audit Log に出力するだけのモードで検証できます。「数年運用後に Org Policy を追加 → 大量違反で動かないリソース続出」の事故を防ぐ必須機能。
# Dry-Run モードで適用（実際にはブロックしない）
gcloud org-policies set-policy policy.yaml --update-mask=dryRunSpec
# policy.yaml
name: organizations/123/policies/iam.disableServiceAccountKeyCreation
dryRunSpec:
rules:
- enforce: true
# Audit Log で違反検出
gcloud logging read 'protoPayload.metadata.dryRunPolicy=*' --limit=50
# 検証後、本番適用
gcloud org-policies set-policy policy.yaml # spec で適用
1.9 Resource Manager / Project Factory の API
# Project の作成（Resource Manager API）
gcloud projects create acme-prod-payment-001 \
--folder=123456789 \
--labels=env=prod,team=payment,cost-center=cc-1001
# Project に Billing Account を紐付け
gcloud billing projects link acme-prod-payment-001 \
--billing-account=01ABCD-234567-EFGHIJ
# Folder 作成（10 階層まで）
gcloud resource-manager folders create \
--display-name="production" \
--organization=98765432100
# プロジェクト削除 → 30 日間は restore 可能
gcloud projects delete acme-prod-payment-001
gcloud projects undelete acme-prod-payment-001 # 30 日以内
1.10 事故ケース
⚠️ 事故 1: Org Policy 設定漏れで外部ドメインに Owner 権限
| 状況 | 新人エンジニアが partner@example.org（外部ドメイン）に Org-level で roles/owner を付与してしまった |
|---|---|
| 影響 | 全プロジェクトに対する完全管理権限が外部ユーザーに渡る。本番 DB 削除可能な状態 |
| 根本原因 | iam.allowedPolicyMemberDomains Constraint が未設定。誰でも任意ドメインのメンバー追加可能 |
| 即対処 | 該当 binding を即削除 → 全 Audit Log を確認 → 該当ユーザーのアクションを全 revoke |
| 恒久対策 | Org 直下に iam.allowedPolicyMemberDomains Constraint で自社ドメインのみ allow に固定 |
⚠️ 事故 2: Folder 削除でリソース道連れ削除
| 状況 | 「使わないチームの Folder を整理」と思って削除 → 配下に運用中の Project が残っており、Project ごと削除状態に |
|---|---|
| 影響 | 30 日以内なら undelete 可能だが、BigQuery dataset / Spanner instance / Pub/Sub subscription など Project 削除と同時に消えるリソースは復旧不能 |
| 根本原因 | Folder 削除前のリソース棚卸し未実施、IAM で resourcemanager.folders.delete を Org Admin が即実行 |
| 即対処 | gcloud projects undelete で 30 日以内に復旧 → ただし Spanner 等は喪失 |
| 恒久対策 | Org Policy の Deny Policy で resourcemanager.folders.delete をブロック、PAM（Privileged Access Manager）で都度承認制に |
⚠️ 事故 3: Project quota 上限到達で新規環境作れず
| 状況 | PR ごとに ephemeral 環境を作る運用で、Org あたりの Project 数上限に到達 → 新規 PR の deploy が全停止 |
|---|---|
| 影響 | 1 週間リリース全停止、quota 拡張申請に 3-5 営業日 |
| 根本原因 | 古い ephemeral Project の自動削除 lifecycle 未設定、削除済み Project も 30 日間 quota を消費 |
| 即対処 | 不要 Project を hard delete（gcloud projects delete + undelete 待たない）、quota 増申請 |
| 恒久対策 | ephemeral Project は TTL ラベル付与 + Cloud Scheduler で 24h 後削除、quota dashboard を Cloud Monitoring で監視 |
⚠️ 事故 4: 命名規則なしで Project ID 重複・命名カオス
| 状況 | 各チームが自由に Project を作成し、test1 poc-2 kainuma-demo 等が乱立。3 年後に棚卸し不能 |
|---|---|
| 影響 | 所有者不明 Project が 200 個、月 $50,000 の無駄コスト発生、監査で指摘 |
| 根本原因 | 命名規則の Custom Constraint なし、Label 必須化なし |
| 即対処 | BigQuery で Billing Export 分析、所有者不明 Project にラベル付与依頼を automation |
| 恒久対策 | Custom Constraint で「cost-center ラベル必須」「Project ID は <company>-<env>-<app>-<seq> 形式」を CREATE 時に enforce |
⚠️ 事故 5: Default SA への Editor 自動付与を放置
| 状況 | 新規プロジェクト作成時に GCE / Cloud Build / App Engine の Default SA に Editor が自動付与される（2024 以前のデフォルト動作） |
|---|---|
| 影響 | Default SA を使う Cloud Build job が全プロジェクトリソースを操作可能、権限昇格穴に |
| 根本原因 | iam.automaticIamGrantsForDefaultServiceAccounts Org Policy 未設定 |
| 即対処 | Default SA の Editor binding を全プロジェクトから削除、User-managed SA に切替 |
| 恒久対策 | Org 直下に iam.automaticIamGrantsForDefaultServiceAccounts Constraint で自動付与 disable |
⚠️ 事故 6: Bootstrap Terraform State 喪失で Org 再構築不能
| 状況 | Bootstrap Project の Terraform State を 個人 PC の local backend で管理していたが、退職者の PC 廃棄で消失 |
|---|---|
| 影響 | Org 構造を変更する全ての変更が import からやり直しに、6 か月停滞 |
| 根本原因 | GCS backend 未設定、State 暗号化なし、版管理なし |
| 即対処 | terraform import で 1 リソースずつ取り込み、新規 GCS backend に移行 |
| 恒久対策 | 必ず Infrastructure Manager（State 自動） または GCS backend + 版管理 + CMEK、Bootstrap State だけ別 Project で分離 |
2Shared VPC / VPC Peering / Private Service Connect
「複数プロジェクトのネットワーク方式」は Shared VPC / VPC Network Peering / Private Service Connect (PSC) の 3 択。試験では「どれを選ぶか」の判断軸と、それぞれの非推移性 / IP 重複可否 / Org 跨ぎ可否 / マネージドサービス接続が頻出。
「Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network. ... A project cannot be both a host project and a service project simultaneously, and each service project can only be attached to a single host project.」 — Shared VPC overview
2.1 Shared VPC のアーキテクチャ
図 2-1：Shared VPC の Host / Service Project 構造
2.2 3 方式の詳細比較マトリクス
| 観点 | Shared VPC | VPC Network Peering | Private Service Connect |
|---|---|---|---|
| 用途 | Org 内集中管理 | VPC 1:1 接続 | サービスエンドポイント公開 |
| スコープ | 同一 Org のみ | Org 跨ぎ可 | Org 跨ぎ可 |
| 推移性 | N/A（同一 VPC） | なし（A↔B↔C で A↔C 不通） | エンドポイント単位 |
| ルート交換 | 同一 VPC で共有 | 自動 | 不要（エンドポイント IP） |
| IP 重複 | 不可（同一 VPC） | 不可（CIDR 重複禁止） | 可（NAT 動作） |
| レイテンシ | VPC 内通信（最速） | VPC 内通信 | +1 hop（ほぼ無視可） |
| 追加コスト | 無料 | 無料（egress 課金あり） | エンドポイント時間課金 + データ処理料 |
| マネージド接続 | △（Private Services Access 併用） | × | ◎（推奨） |
| 運用負荷 | 中（Host/Service の IAM 分離） | 低（peering 数増えると爆発） | 低（per-service endpoint） |
| クォータ | Project quota 個別 | VPC あたり peering 25 個 | Project あたり endpoint 数 |
| Firewall | Host で一括管理 | 各 VPC で個別 | Producer / Consumer で個別 |
2.3 Shared VPC の必須 IAM ロール
| ロール | 付与対象 | 権限 |
|---|---|---|
roles/compute.xpnAdmin(Shared VPC Admin) | Network Team（Org or Folder level） | Host を有効化、Service Project の attach / detach、subnet 単位の IAM 委譲 |
roles/compute.networkUser | Service Project の SA / ユーザー | 指定 subnet を使ってリソース作成（特定 subnet のみ可能） |
roles/compute.networkAdmin | Network Team | VPC / route / Cloud NAT / VPN 管理（Firewall / SSL は除く） |
roles/compute.securityAdmin | Security Team | Firewall rule、SSL 証明書管理 |
💡 Shared VPC IAM の最小権限パターン
Network User は Host Project 全体ではなく、特定 subnet にだけ 付与する（subnet-level binding）。これで「app チームは
app subnet のみ使える、db subnet は使えない」を実現。Service Project Admin（=app チーム責任者）は Service Project 内では owner 相当、Host 側には触れない。
2.4 Shared VPC の制限と落とし穴
- Host / Service は排他：1 つの Project は Host にも Service にもなれない
- Service Project は 1 Host のみ：別の Host に attach するには detach が必要
- 同一 Org 必須：Cross-Org Shared VPC は不可（HA VPN / Interconnect で代替）
- サブネット拡張は不可（縮小不可、新規 subnet 追加で対応）
- Folder 跨ぎ attach には Shared VPC Admin が両 Folder で権限必要
- App Engine Standard は Shared VPC に未対応（Serverless VPC Access で接続）
- Cloud SQL Private IP は Host Project に Private Services Access 設定が必要
2.5 VPC Network Peering の制限
25
VPC あたり peering 数（hard limit）
非推移
A↔B↔C で A↔C は不通
CIDR 重複×
subnet CIDR が重なると peering 不可
無料
peering 通信は同一 region なら egress 無料
2.6 Private Service Connect の 3 種類
| タイプ | 用途 | 典型例 |
|---|---|---|
| PSC for Google APIs | googleapis.com にプライベート IP でアクセス | VPC SC 内から GCS / BigQuery に内部 IP で接続 |
| PSC for Published Services | 自社 / SaaS の内部サービスを別 VPC に公開 | Producer (Confluent / Snowflake) → Consumer VPC |
| PSC for Managed Services | Cloud SQL / Memorystore / AlloyDB 等 | Cloud SQL Private Service Connect エンドポイント |
2.7 ハイブリッド接続との組み合わせ
| 接続方式 | 帯域 | SLA | 用途 | Shared VPC との関係 |
|---|---|---|---|---|
| Cloud VPN（Classic） | 3 Gbps | 99.9% | 小規模、PoC | Host VPC に attach、Service Project から透過 |
| HA VPN | 10 Gbps（合計） | 99.99% | 本番、IPsec | Host VPC に attach |
| Dedicated Interconnect | 10 or 100 Gbps | 99.9-99.99% | 大規模、低レイテンシ | Host Project に terminate |
| Partner Interconnect | 50 Mbps - 50 Gbps | 99.9-99.99% | キャリア経由 | Host Project に terminate |
| Cross-Cloud Interconnect | 10 or 100 Gbps | 99.99% | AWS / Azure / OCI 直結 | Host VPC で受ける |
| Network Connectivity Center (NCC) | — | — | 複数 VPN / Interconnect の hub-spoke 統合 | NCC Hub に Spoke として VPC を attach |
2.8 事故ケース
⚠️ 事故 7: VPC Peering の非推移性で 3 拠点が片方向通信不能
| 状況 | VPC A ↔ B、B ↔ C で peering を組み「A から C も通信できる」と勘違いしてアプリ設計 |
|---|---|
| 影響 | 本番リリース当日に A → C への API call が全て timeout、緊急 rollback |
| 根本原因 | VPC Peering は 非推移（non-transitive）。A↔C を直接 peering するか別方式が必要 |
| 即対処 | A↔C の直接 peering を急遽追加（CIDR 重複なければ即可） |
| 恒久対策 | 3 つ以上の VPC を統合するなら最初から Shared VPC または Network Connectivity Center (NCC) で hub-spoke 構成 |
⚠️ 事故 8: Shared VPC で誤って IAM role 上書き → 全 Service Project 停止
| 状況 | Host Project の IAM policy を setIamPolicy で 全置換（add ではなく overwrite） |
|---|---|
| 影響 | 全 Service Project の networkUser binding が消滅、全 VM / GKE node 作成停止 |
| 根本原因 | gcloud projects set-iam-policy は etag を見ずに全置換する破壊的コマンド |
| 即対処 | etag を確認した backup policy.yaml から restore、Terraform state から再 apply |
| 恒久対策 | 本番 IAM 変更は必ず add-iam-policy-binding / remove-iam-policy-binding、または Terraform / Infrastructure Manager で管理。Policy Analyzer で事前影響評価 |
⚠️ 事故 9: PSC エンドポイント quota 上限到達
| 状況 | マイクロサービス 100 個を各 PSC エンドポイント経由で接続、Project あたり endpoint 数上限に到達 |
|---|---|
| 影響 | 新規サービス追加が全停止、quota 増申請に 3 営業日 |
| 根本原因 | サービスごとに endpoint を作る設計（粒度過剰） |
| 即対処 | quota 増申請、優先度の低い endpoint を削除 |
| 恒久対策 | 共通の internal LB を経由させ、PSC endpoint は 環境 × サービスグループ単位に集約 |
⚠️ 事故 10: Cross-Org で Shared VPC が組めず M&A 統合が頓挫
| 状況 | 買収した子会社の Org を統合せずに親会社の Shared VPC に Service Project として attach しようとした |
|---|---|
| 影響 | Shared VPC は同一 Org 必須で attach 不可、ネットワーク統合計画が 3 か月遅延 |
| 根本原因 | Shared VPC のスコープ制約理解不足 |
| 即対処 | 暫定的に HA VPN または Cross-Org HA VPN で接続 |
| 恒久対策 | Org 統合（migrate-from-org）または Cross-Cloud Interconnect / NCC で hub-spoke 接続 |
⚠️ 事故 11: サブネット範囲 /24 で確保 → 1 年で IP 枯渇
| 状況 | GKE クラスタの secondary range を /24 で確保、Pod 数が増えて IP 枯渇 |
|---|---|
| 影響 | 新規 Pod スケジューリング不能、サブネット拡張は range 重複により不可 |
| 根本原因 | 初期設計で Pod range は /17、Service range は /22 等の十分な広さを取らなかった |
| 即対処 | GKE の Discontiguous Multi-Pod CIDR（2023 GA）で追加 range を後付け |
| 恒久対策 | 初期から /16 で Shared VPC subnet を確保、GKE secondary range は十分広く取る |
3IAM と組織ポリシー
IAM は 「誰が（identity） / どのリソースに（resource） / 何ができるか（role）」の 3 要素で構成、Org Policy はその上位レイヤーで 「何が許されるか」を強制。試験では「IAM の継承と Deny」「Conditional IAM」「SA Key 撲滅戦略」「Custom Role vs Predefined」「Policy Analyzer / Recommender」が頻出です。
3.1 IAM 階層と継承（Effective Policy）
図 3-1：IAM の親 → 子継承と Effective Policy（加算）
3.2 ロールの 3 種 + Deny Policy
| 種類 | 例 | 用途 | 注意 |
|---|---|---|---|
| Basic Role（旧 Primitive） | roles/owner、roles/editor、roles/viewer | 初期 PoC のみ | 本番では Org Policy で禁止推奨 |
| Predefined Role | roles/compute.admin（数千種） | 標準 | サービス追加で増える |
| Custom Role | 任意 | 最小権限の厳密定義 | Org / Project スコープ、メンテナンスコスト |
| Deny Policy（2022 GA） | — | 「絶対に禁止」を IAM に優先で強制 | Allow より 強い（IAM allow があっても deny が勝つ） |
3.3 よく出る Predefined Role 一覧
| ロール ID | 用途 |
|---|---|
roles/iam.serviceAccountUser | SA を「使う」（impersonate に必要） |
roles/iam.serviceAccountTokenCreator | SA の短期トークン発行 |
roles/iam.workloadIdentityUser | WIF / GKE Workload Identity で SA impersonation を許可 |
roles/iam.serviceAccountAdmin | SA 作成・削除 |
roles/iam.securityAdmin | IAM 全権限（最も強い、限定的に） |
roles/iam.securityReviewer | IAM 読み取り専用（監査用） |
roles/resourcemanager.organizationAdmin | Org Admin、folder / project 作成 |
roles/resourcemanager.folderAdmin | Folder 管理 |
roles/orgpolicy.policyAdmin | Org Policy 設定 |
roles/compute.xpnAdmin | Shared VPC Admin |
roles/compute.networkUser | Shared VPC subnet 利用 |
roles/container.developer | GKE Pod 操作（cluster 管理不可） |
roles/container.admin | GKE フル管理 |
roles/cloudbuild.builds.editor | Cloud Build job 作成・管理 |
roles/clouddeploy.operator | Cloud Deploy 操作（promotion / rollback） |
roles/artifactregistry.writer | Artifact Registry push |
roles/logging.privateLogViewer | Data Access Audit Log 含む全 Logging 閲覧 |
roles/monitoring.editor | Cloud Monitoring 設定・編集 |
3.4 Conditional IAM（IAM Conditions）
IAM binding に CEL（Common Expression Language）条件を付けて、時間 / リソース属性 / リクエスト属性で動的に許可。「営業時間内のみ」「特定タグの付いたリソースのみ」を表現。
# 平日 9-18 時のみ compute.admin 付与
gcloud projects add-iam-policy-binding PRJ \
--member=group:devops@acme.com \
--role=roles/compute.admin \
--condition='expression=request.time.getHours("Asia/Tokyo") >= 9 &&
request.time.getHours("Asia/Tokyo") < 18 &&
request.time.getDayOfWeek("Asia/Tokyo") >= 1 &&
request.time.getDayOfWeek("Asia/Tokyo") <= 5,
title=weekday_office_hours,description=平日業務時間のみ'
# Resource attribute: 特定 prefix のバケットのみ
expression: resource.name.startsWith("projects/_/buckets/dev-")
# Tag-based: タグ付与されたリソースのみ
expression: resource.matchTag("123456789/env", "dev")
💡 ベストプラクティス
Conditional IAM は Project / Resource level の binding に限定。Org / Folder level の binding に CEL 条件を付けると、影響範囲が広すぎてデバッグ困難。本番は PAM（Privileged Access Manager）で「Just-in-Time 昇格 + 承認制」のほうが運用しやすい。
3.5 Service Account ベストプラクティス
⚠️ アンチパターン
・SA Key（JSON）を生成して GitHub Secrets / Vault / S3 に保存
・Default SA（compute / cloudbuild / app engine）に Editor のまま使う
・「1 つの SA で全部やる」god account
・SA Key を 1 年放置（rotation なし）
・本番 SA を開発者の gcloud auth で impersonate 自由
✅ ベストプラクティス
・SA Key を作らない（Org Policy で disable）
・1 アプリ = 1 SA、責務別に分割
・Workload Identity (GKE) / WIF (外部)でキー不要認証
・人間が SA を使うときは impersonation（短期 token）
・Service Account Recommender で未使用 SA を定期削除
・SA は 専用 admin SA だけが作成可能に
3.6 Service Account Impersonation
# 人 (alice@) が SA (deploy-sa) になりすまして実行
gcloud auth login alice@acme.com
# 1) SA に Token Creator を付与（alice@ → deploy-sa）
gcloud iam service-accounts add-iam-policy-binding \
deploy-sa@PRJ.iam.gserviceaccount.com \
--member=user:alice@acme.com \
--role=roles/iam.serviceAccountTokenCreator
# 2) impersonation で実行
gcloud compute instances list \
--impersonate-service-account=deploy-sa@PRJ.iam.gserviceaccount.com
# Audit Log に alice@ と SA の両方が記録される（accountability 保たれる）
3.7 IAM Recommender / Policy Analyzer
| ツール | 用途 | 典型出力 |
|---|---|---|
| IAM Recommender | 過去 90 日の利用状況から「使われていない権限」を検出 → より狭いロール提案 | 「roles/editor → roles/compute.viewer に縮小可能」 |
| Policy Analyzer | 「誰が」「何に」「どんなアクセス」を持つかを Org 横断で照会 | 「roles/storage.admin を持つ principal を全 Org で列挙」 |
| Policy Troubleshooter | 「なぜこのユーザーがこのリソースに access できない / できる」を逆引き | 「alice@ が gs://bucket に write できる理由は Folder prod の editor binding」 |
| Service Account Insights | 未使用 SA、key 流出疑い、過剰権限 SA を検出 | 「90 日未使用の SA を delete 推奨」 |
| Privileged Access Manager (PAM) | Just-in-Time 権限昇格、承認制 | 「prod-admin role を 4 時間限定、承認者 2 名」 |
3.8 Deny Policy の使い所
# 「絶対に SA Key を作らせない」を IAM allow より優先で強制
gcloud iam policies create deny-sa-key-creation \
--attachment-point="cloudresourcemanager.googleapis.com/organizations/123" \
--kind=denypolicies --policy-file=deny-policy.yaml
# deny-policy.yaml
rules:
- deniedPrincipals:
- principalSet://goog/public:all # 全 principal に対して
deniedPermissions:
- iam.googleapis.com/serviceAccountKeys.create
exceptionPrincipals:
- principalSet://iam.googleapis.com/projects/PRJ_NUM/locations/global/workloadIdentityPools/.../subject/break-glass-bot
3.9 事故ケース
⚠️ 事故 12: Owner ロールを 50 人に付与 → 退職者の元 owner が DB drop
| 状況 | 初期 PoC で「とりあえず Owner を全員に」付与、退職処理時に IAM 削除が漏れた元従業員のアカウントから本番 DB が削除 |
|---|---|
| 影響 | 本番 Cloud SQL の database が drop、PITR から 4 時間ロールバック |
| 根本原因 | Basic Role の濫用、Group 管理なし、IAM 監査なし |
| 即対処 | 該当 binding 即削除、Cloud SQL PITR で復旧、全 Owner binding 棚卸し |
| 恒久対策 | Org Policy で Basic Role 禁止（custom constraint）、Group ベース付与、PAM で JIT 昇格、退職時の Group 自動削除 |
⚠️ 事故 13: SA Key が GitHub に commit → 仮想通貨マイニング
| 状況 | 開発者が key.json を git add してしまい public repo に push |
|---|---|
| 影響 | 3 時間後にスキャナーが検出、GCE で大量の GPU instance が立ち上がり仮想通貨マイニング、3 日間で $80,000 課金 |
| 根本原因 | SA Key の存在、pre-commit hook なし、Org Policy iam.disableServiceAccountKeyCreation なし |
| 即対処 | 該当 SA を即無効化、Key を delete、Cloud Billing Budget Alert で異常検知、GCE instance 全停止、Google Cloud Support に課金交渉 |
| 恒久対策 | SA Key を作らせない（Org Policy + Deny Policy）、WIF 移行、GitHub Secret Scanning、Cloud Budget Alert |
⚠️ 事故 14: Custom Role の権限不足で Cloud Build が deploy 失敗
| 状況 | セキュリティチームが「最小権限」と称して Custom Role を作ったが、Cloud Build SA に必要な iam.serviceAccountUser が欠落 |
|---|---|
| 影響 | 本番デプロイ全停止、Custom Role を編集する人が休暇中で復旧 6 時間 |
| 根本原因 | Custom Role の権限漏れ、Predefined Role を base にせず一から作成 |
| 即対処 | Cloud Build SA に roles/iam.serviceAccountUser を緊急付与 |
| 恒久対策 | Custom Role は Predefined Role を base に Iterate、IAM Recommender で必要権限を学習、CI/CD で「権限テスト」を行う pre-prod 環境を持つ |
⚠️ 事故 15: Conditional IAM の CEL タイポで本番アクセス不能
| 状況 | 「平日 9-18 時のみ」の CEL 条件で >= を > に書き間違え、9:00 ちょうどに access できない |
|---|---|
| 影響 | 朝のオンコール対応で 1 時間 access できず、緊急対応遅延 |
| 根本原因 | Conditional IAM の単体テストなし |
| 即対処 | 条件削除して時間制限なしで一旦回復、後で修正 |
| 恒久対策 | Conditional IAM は Terraform で管理 + Policy Simulator で事前テスト、緊急時は break-glass SA で迂回 |
4Workload Identity Federation 完全攻略
WIF は OAuth 2.0 Token Exchange + Google Security Token Service (STS) を使い、AWS / Azure / GitHub Actions / GitLab / OIDC / SAML / X.509 などの外部 IdP から、SA Key なしで GCP API を呼ぶ仕組み。PCDE で最頻出かつ実務必須。「外部 CI/CD から GCP に認証」と聞いたら即 WIF。
「Workload identity federation follows the OAuth 2.0 token exchange specification. You provide a credential from your IdP to the Security Token Service, which verifies the identity on the credential, and then returns a federated token in exchange.」 — Workload Identity Federation overview
4.1 WIF アーキテクチャ
図 4-1：WIF のトークン交換フロー
4.2 対応 IdP と Issuer URL
| IdP | Issuer URL / Type | 典型 attribute |
|---|---|---|
| GitHub Actions | https://token.actions.githubusercontent.com | assertion.repository, assertion.ref, assertion.environment |
| GitLab CI | https://gitlab.com または self-hosted URL | assertion.project_path, assertion.ref, assertion.ref_type |
| AWS | AWS provider (account ID 指定) | assertion.arn, assertion.account |
| Azure AD | https://sts.windows.net/{tenant-id}/ | assertion.sub, assertion.tid, assertion.appid |
| Okta | https://<org>.okta.com | assertion.sub, assertion.groups |
| Terraform Cloud | https://app.terraform.io | assertion.terraform_workspace_id |
| Kubernetes（自前） | cluster の OIDC issuer | assertion.sub（system:serviceaccount:ns:sa） |
| SAML 2.0 | IdP metadata URL | assertion.attributes.role |
| X.509 | trust anchor 証明書 | assertion.subject |
4.3 Attribute Mapping と Attribute Condition
Attribute Mapping は外部 IdP の token claim を Google STS の attribute に変換するルール、Attribute Condition はその attribute に対する CEL 条件で「許可する／しない」を決定する 最重要セキュリティ層。
# Attribute mapping（外部 token claim → google.subject / attribute.*）
--attribute-mapping="
google.subject=assertion.sub,
attribute.repository=assertion.repository,
attribute.ref=assertion.ref,
attribute.environment=assertion.environment
"
# Attribute condition（CEL で許可条件、false なら拒否）
--attribute-condition="
assertion.repository=='myorg/myapp' &&
assertion.repository_owner_id=='12345' &&
assertion.ref in ['refs/heads/main', 'refs/heads/release/v1']
"
# 注意：repository だけでチェックすると、同名 repo を別 owner が作れば認証できてしまう
# → 必ず repository_owner_id を併用
🔑 試験ポイント：Attribute Condition の最低限
- GitHub Actions：
assertion.repository_owner_id（owner ID）とassertion.repositoryの両方を条件に - 環境分離：本番 SA への WIF は
assertion.environment=='production'で GitHub Environment Protection と連携 - ブランチ制限：
assertion.ref=='refs/heads/main'で main からの workflow のみ許可 - Reusable workflow：
job_workflow_refで「特定の reusable workflow から」を強制
4.4 External Account Credentials JSON 構造
WIF を利用するクライアント（gcloud / SDK / Terraform）には、credential configuration JSON を渡す。これは「key file」ではなく「STS にどう問い合わせるかのレシピ」。
{
"type": "external_account",
"audience": "//iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/gh-pool/providers/gh-provider",
"subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
"token_url": "https://sts.googleapis.com/v1/token",
"service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/deploy-sa@PRJ.iam.gserviceaccount.com:generateAccessToken",
"credential_source": {
"url": "https://api.github.com/repos/myorg/myapp/actions/runners/registration-token",
"headers": {"Authorization": "Bearer ACTIONS_ID_TOKEN_REQUEST_TOKEN"},
"format": {"type": "json", "subject_token_field_name": "value"}
}
}
# このファイルは秘密情報を含まない（公開しても安全）
# 各 SDK が credential_source で外部 token を取得 → STS で交換 → SA token で API call
4.5 GitHub Actions からの WIF 完全例
# ===== 1) GCP 側セットアップ =====
# Pool 作成
gcloud iam workload-identity-pools create gh-pool \
--location=global --display-name="GitHub Actions"
# Provider 作成（GitHub OIDC）
gcloud iam workload-identity-pools providers create-oidc gh-provider \
--workload-identity-pool=gh-pool --location=global \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,
attribute.repository=assertion.repository,
attribute.repository_owner_id=assertion.repository_owner_id,
attribute.ref=assertion.ref" \
--attribute-condition="assertion.repository_owner_id=='12345' &&
assertion.repository=='myorg/myapp'"
# SA に workloadIdentityUser 付与（repo 単位で principal set 制限）
gcloud iam service-accounts add-iam-policy-binding \
deploy-sa@PRJ.iam.gserviceaccount.com \
--role=roles/iam.workloadIdentityUser \
--member="principalSet://iam.googleapis.com/projects/PRJ_NUM/locations/global/workloadIdentityPools/gh-pool/attribute.repository/myorg/myapp"
# ===== 2) GitHub Actions workflow =====
name: Deploy
on: { push: { branches: [main] } }
permissions:
id-token: write # ← OIDC token 発行に必須
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- id: auth
uses: google-github-actions/auth@v2
with:
workload_identity_provider: projects/PRJ_NUM/locations/global/workloadIdentityPools/gh-pool/providers/gh-provider
service_account: deploy-sa@PRJ.iam.gserviceaccount.com
# token_format: access_token（デフォ）/ id_token も可
- uses: google-github-actions/setup-gcloud@v2
- run: gcloud builds submit --tag asia-northeast1-docker.pkg.dev/PRJ/repo/app:$GITHUB_SHA
4.6 GitLab CI からの WIF 設定例
# GitLab provider 作成
gcloud iam workload-identity-pools providers create-oidc gitlab-provider \
--workload-identity-pool=gitlab-pool --location=global \
--issuer-uri="https://gitlab.com" \
--attribute-mapping="google.subject=assertion.sub,
attribute.project_path=assertion.project_path,
attribute.ref=assertion.ref,
attribute.ref_type=assertion.ref_type" \
--attribute-condition="assertion.project_path=='myorg/myapp' &&
assertion.ref_type=='branch' && assertion.ref=='main'"
# .gitlab-ci.yml
deploy:
image: google/cloud-sdk:slim
id_tokens:
GCP_ID_TOKEN:
aud: //iam.googleapis.com/projects/PRJ_NUM/locations/global/workloadIdentityPools/gitlab-pool/providers/gitlab-provider
script:
- echo $GCP_ID_TOKEN > /tmp/oidc_token
- |
gcloud iam workload-identity-pools create-cred-config \
projects/PRJ_NUM/locations/global/workloadIdentityPools/gitlab-pool/providers/gitlab-provider \
--service-account=deploy-sa@PRJ.iam.gserviceaccount.com \
--output-file=/tmp/cred.json \
--credential-source-file=/tmp/oidc_token
- export GOOGLE_APPLICATION_CREDENTIALS=/tmp/cred.json
- gcloud auth login --cred-file=/tmp/cred.json
- gcloud builds submit ...
4.7 Workforce Identity Federation との違い
| 観点 | Workload Identity Federation | Workforce Identity Federation |
|---|---|---|
| 対象 | マシン（CI/CD、外部クラウド） | 人間（社員、契約者） |
| 用途 | SA impersonation で API call | Console / gcloud / BigQuery にログイン |
| Pool 種類 | Workload Identity Pool | Workforce Pool（Org level） |
| IdP | OIDC / SAML / AWS / Azure 等 | Okta / Azure AD / SAML / OIDC |
| 料金 | 無料 | 月額 / user 課金あり |
| BigQuery / Looker 統合 | — | ◎（人間ユーザーとして permission 評価） |
4.8 Direct Resource Access（SA impersonation なし）
2024 以降、SA を経由せずに external identity に直接ロールを付与可能（一部サービスのみ）。BigQuery / Cloud Storage / Pub/Sub 等が対応。
# external identity (GitHub repo) に直接 storage.objectViewer を付与
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
--role=roles/storage.objectViewer \
--member="principalSet://iam.googleapis.com/projects/PRJ_NUM/locations/global/workloadIdentityPools/gh-pool/attribute.repository/myorg/myapp"
# 利点：SA を作らなくて良い、Audit Log にも external identity が直接記録
# 制約：対応していない API が多い（GKE / GCE 等は SA impersonation 必須）
4.9 制限値
100
Pool / Project
100
Provider / Pool
50
attribute / Provider
127
google.subject の最大文字数
その他：Pool / Provider は 削除後 30 日で完全削除（その間 restore 可）、disable は即時。token TTL は 1 時間（federated token）→ impersonated SA token も 1 時間。
4.10 事故ケース
⚠️ 事故 16: Attribute Condition 緩すぎで任意 GitHub repo から認証可能
| 状況 | WIF Provider の attribute condition を assertion.repository_owner=='myorg' のみ指定（owner ID なし） |
|---|---|
| 影響 | 攻撃者が「myorg」という GitHub Org を新規作成 → 同名で WIF 認証成功 → 本番 SA を impersonate |
| 根本原因 | GitHub Org の repository_owner は 文字列で再利用可能。owner_id（数値）でないと不変ではない |
| 即対処 | Provider を disable、attribute condition に assertion.repository_owner_id を追加 |
| 恒久対策 | 必ず repository_owner_id（数値 ID）を条件に。Terraform で WIF Provider を管理し、PR review で条件を強制 |
⚠️ 事故 17: WIF Pool 削除で全 CI/CD が一斉停止
| 状況 | 「使ってない pool を整理」と思って delete、実は 50 リポジトリが利用中 |
|---|---|
| 影響 | 全社 deploy が 30 分間停止、Pool は 30 日 soft delete だが provider URL の audience が無効化 |
| 根本原因 | Pool 利用状況の可視化なし、Org Policy で delete 制限なし |
| 即対処 | gcloud iam workload-identity-pools undelete で 30 日以内に復旧 |
| 恒久対策 | WIF Pool / Provider は IaC 管理、Terraform state lock + 2 名承認、Deny Policy で iam.workloadIdentityPools.delete をブロック |
⚠️ 事故 18: audience mismatch で workflow 全失敗
| 状況 | WIF Provider を rename（pool ID 変更）したが、GitHub Actions の workflow の workload_identity_provider 値を更新し忘れ |
|---|---|
| 影響 | 「audience claim doesn't match」エラーで全 deploy 失敗 |
| 根本原因 | audience（pool/provider full path）と GitHub Actions 側 workflow の不一致 |
| 即対処 | 旧 Pool を再作成（同名で）、または全 workflow を一斉更新 |
| 恒久対策 | Pool / Provider ID は 初期から汎用名で固定（rename 想定外設計）、Terraform で workflow 側も同時更新 |
⚠️ 事故 19: SA に過剰権限 → fork PR が本番 deploy 可能
| 状況 | WIF で deploy-sa（roles/owner 付与）を使い、GitHub Actions の trigger に pull_request も含めていた |
|---|---|
| 影響 | 外部の悪意 contributor が fork から PR 送信 → workflow 起動 → 本番 deploy 可能 |
| 根本原因 | fork からの PR でも secrets / OIDC token は通常発行される（pull_request_target 等の混同） |
| 即対処 | workflow の trigger から pull_request を除外、本番 deploy は main push のみ |
| 恒久対策 | 本番 SA は Environment Protection（GitHub Environments）と attribute condition で environment=='production'、SA は最小権限 |
5Infrastructure as Code の Google 推奨
GCP の IaC は Infrastructure Manager / Terraform 直接 / Config Connector / Cloud Foundation Toolkit / Cloud Foundation Fabric / Helm の 6 つが主要選択肢。試験では「マネージド state 管理が欲しい」「K8s で GCP リソース管理したい」「Google 推奨パターンで素早く構築」の 3 つの判断軸が頻出。
5.1 IaC ツール比較マトリクス
図 5-1：IaC ツール選定マトリクス（マネージド度 × カスタマイズ性）
5.2 6 ツールの詳細比較
| 観点 | Infrastructure Manager | Terraform 直接 | Config Connector | CFT | Cloud Foundation Fabric (FAST) | Helm |
|---|---|---|---|---|---|---|
| 形式 | Terraform HCL | HCL | K8s CRD (YAML) | HCL / Helm | HCL (blueprint) | YAML テンプレ |
| 実行 | GCP マネージド | 自己管理 (CLI / Cloud) | K8s controller | 自己実行 | 自己実行 (Terraform) | helm CLI / Argo |
| State | 自動 (GCP 内) | GCS / TF Cloud 自前 | etcd (reconcile) | 自前 | 自前 (GCS 推奨) | K8s release |
| Lock | 自動 | GCS lockless / TF lock | K8s lease | 自前 | 自前 | K8s |
| 認証 | IAM (API) | SA / WIF / ADC | Workload Identity | SA / WIF | SA / WIF | kubeconfig |
| マルチクラウド | ×（GCP のみ） | ◎ | × | △ | × | K8s なので可 |
| 適合 | GCP ネイティブ、CI/CD 統合 | マルチクラウド | K8s 文化 | 既存 TF 資産 | 新規 enterprise | アプリ deploy |
5.3 Infrastructure Manager 詳細
Infrastructure Manager（2023 GA）は GCP マネージドの Terraform 実行サービス。state 管理 / locking / SA 認証 / Terraform バージョン管理を全て GCP 側で行う。Cloud Build と統合して GitOps に。
# Deployment 作成（Git ソースから）
gcloud infra-manager deployments apply projects/PRJ/locations/asia-northeast1/deployments/my-deploy \
--git-source-repo=https://github.com/myorg/infra \
--git-source-directory=terraform/prod \
--git-source-ref=main \
--service-account=projects/PRJ/serviceAccounts/im-runner@PRJ.iam.gserviceaccount.com \
--input-values=region=asia-northeast1,env=prod
# 内部動作
# 1) GCP が Git から HCL を fetch
# 2) Terraform image を ephemeral VM で起動
# 3) terraform init / plan / apply を実行
# 4) state は GCP 内に保存（GCS 不要、暗号化済み）
# 5) lock も GCP 内で自動
# 制限：Terraform CLI のすべての provider が使えるわけではない（OSS provider OK）
# 料金：実行時間に応じた compute 課金（Terraform 実行 VM のみ）
5.4 Config Connector 詳細
Config Connector は GKE クラスタ内で動く controller で、Kubernetes CRD として GCP リソースを宣言。kubectl apply で GCP リソースが作成され、K8s の reconciliation loop が drift 検出 → 自動修復。
# Config Connector で GCS バケットを作る例
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
name: my-app-bucket-prod
namespace: payment-team
annotations:
cnrm.cloud.google.com/project-id: "prod-payment"
spec:
location: ASIA-NORTHEAST1
uniformBucketLevelAccess: true
versioning: { enabled: true }
lifecycleRule:
- action: { type: Delete }
condition: { age: 90 }
# 同じく Cloud SQL Instance を CRD で
apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLInstance
metadata:
name: payment-db-prod
spec:
databaseVersion: POSTGRES_15
region: asia-northeast1
settings:
tier: db-custom-4-15360
ipConfiguration:
privateNetworkRef:
external: projects/net-host/global/networks/shared-vpc
💡 Config Connector のユースケース
- K8s native な GitOps：Argo CD / Config Sync で K8s manifest と GCP リソースを統合管理
- アプリチームの自律：開発者が PR で
StorageBucketやPubSubTopicを追加可能（Platform チームが Custom Constraint で制御） - drift 自動修復：誰かが Console で手動変更 → 数分で K8s spec に戻る
- 注意：reconciler が API quota を消費、大規模になると
cnrm-systemnamespace の CPU/Memory が逼迫
5.5 Cloud Foundation Toolkit（CFT）の主要 module
| module 名 | 用途 | 使い所 |
|---|---|---|
terraform-example-foundation | Org 全体の Landing Zone（4 ステージ） | 新規 Org の bootstrap |
terraform-google-project-factory | Project 量産（SA / API enable / 予算アラート 同梱） | 「アプリチームが PR で Project 自作成」 |
terraform-google-network | VPC / Shared VPC / Firewall / NAT | Host Project でのネットワーク構築 |
terraform-google-iam | IAM binding（Group ベース付与） | Org / Folder / Project の IAM 一括管理 |
terraform-google-kubernetes-engine | GKE Standard / Autopilot | クラスタ作成 |
terraform-google-cloud-build | Cloud Build Trigger / Private Pool | CI 自動化 |
terraform-google-bigquery | BigQuery dataset / table / scheduled query | データ基盤 |
terraform-google-log-export | Aggregated Sink 設定 | 監査ログ集約 |
5.6 GitOps：Argo CD vs Flux vs Cloud Deploy + Terraform
| 観点 | Argo CD | Flux | Cloud Deploy + Terraform |
|---|---|---|---|
| 提供 | OSS (CNCF Graduated) | OSS (CNCF Graduated) | GCP マネージド |
| 対象 | K8s リソース | K8s リソース + Helm | K8s / Cloud Run / Anthos / Custom |
| UI | ◎ 専用 UI 充実 | △ CLI 中心 | ○ Console + CLI |
| マルチクラスタ | ApplicationSet | multi-tenancy | multiple targets |
| Approval Gate | SyncWindow | — | ◎ approval phase |
| Canary | Argo Rollouts と併用 | Flagger | ◎ built-in canary |
| 適合 | K8s 中心、複雑な app | OSS GitOps 純正 | GCP マネージド志向、進歩的 delivery |
5.7 Terraform State 管理ベストプラクティス
- backend は GCS（Object Versioning ON + CMEK）または Infrastructure Manager（state 不要）
- state を環境 / コンポーネント単位で分割：1 state にすべてを入れると plan 時間爆発、blast radius 拡大
- state locking：GCS backend は object generation で実装、Infrastructure Manager は自動
- state は秘密情報を含む（DB password 等）→ 必ず暗号化、IAM で厳格制御
- workspace：環境分離は workspace より directory 分離（dev/ stage/ prod/）が推奨（IAM 分離可能）
- terraform plan の出力を PR に貼る：Atlantis / Cloud Build 連携で自動化
5.8 事故ケース
⚠️ 事故 20: terraform apply -auto-approve で本番リソース大量削除
| 状況 | 新人が dev 用の Terraform に -target を付けずに apply -auto-approve、リソース定義が消えていた本番リソースが destroy |
|---|---|
| 影響 | 本番 GKE node pool / Cloud SQL 削除、PITR / バックアップから 6 時間復旧 |
| 根本原因 | -auto-approve 利用、本番 / dev で同じ state 共有、code review なし |
| 即対処 | Cloud SQL PITR、GKE は CFT module で再構築、Backup and DR で復旧 |
| 恒久対策 | 本番 apply は 必ず承認制（Infrastructure Manager + Approval Workflow）、prevent_destroy = true lifecycle、CI で plan diff チェック |
⚠️ 事故 21: Terraform state lock 競合で 3 時間停止
| 状況 | 2 つの CI ジョブが同じ state に同時 apply → lock 競合、片方が timeout、lock が stale lock として残留 |
|---|---|
| 影響 | その後の全 apply が「state is locked」エラー、復旧まで 3 時間 |
| 根本原因 | lock の TTL なし、強制 unlock の手順が文書化されてない |
| 即対処 | terraform force-unlock LOCK_ID（lock holder 確認後） |
| 恒久対策 | Infrastructure Manager に移行（lock 自動）、または lock TTL 設定、Cloud Build trigger で同一 state への並行実行を mutex 制御 |
⚠️ 事故 22: Config Connector reconciler 暴走で API quota 枯渇
| 状況 | YAML 定義に誤った field（spec 衝突）、Config Connector が 無限 retry、Compute API へのリクエストが quota 上限到達 |
|---|---|
| 影響 | 同 Project 内の全 GCE / GKE 操作が 503、3 時間停止 |
| 根本原因 | controller の backoff 設定不足、CRD のバリデーション不足 |
| 即対処 | 該当 CRD を kubectl delete --force、controller を pause |
| 恒久対策 | Custom Constraint / kyverno で CRD の事前バリデーション、reconciler の retry budget 設定、Cloud Monitoring で controller error rate を監視 |
⚠️ 事故 23: 1 つの state にすべて入れて plan が 40 分
| 状況 | Org / Network / IAM / 全 Project / GKE / Cloud SQL を 1 つの Terraform state に詰め込み |
|---|---|
| 影響 | terraform plan が 40 分、PR review が機能停止、些細な変更で全社の lock を占有 |
| 根本原因 | State 分割設計なし、layer 分離なし |
| 即対処 | terraform state mv で段階的に分割 |
| 恒久対策 | Foundations Blueprint に倣い bootstrap / org / env / project の 4 layer に state 分割、各 layer 単体で apply 可能に |
⚠️ 事故 24: Helm chart の values 漏れで本番が dev 設定起動
| 状況 | Helm chart で replicas: 1 が default、本番では values-prod.yaml で override する設計だったが -f を渡し忘れ |
|---|---|
| 影響 | 本番 replica が 1、Pod 落ち時にダウンタイム発生 |
| 根本原因 | Helm の引数管理が手作業、CI 検証なし |
| 即対処 | helm upgrade で正しい values を再適用 |
| 恒久対策 | Cloud Deploy + Skaffold で render を envファイル管理、Helm より Kustomize overlay 推奨（本番 / dev の差分が PR で明確） |
6GKE Fleet & マルチクラスタ管理
Fleet（旧 Environs）は 「複数の GKE / Anthos / Attached cluster を 1 つの論理単位として扱う」概念。Sameness / Exclusivity / High Trust / Grouping の 4 原則の上に、Config Sync / Policy Controller / Multi-cluster Services (MCS) / Multi-cluster Ingress (MCI) / Cloud Service Mesh（旧 ASM）/ Workload Identity Pool 等の機能が乗ります。試験では「同名 namespace は同一エンティティ」「1 Project = 1 Fleet」「RootSync vs RepoSync」が頻出。
「A fleet is a Google Cloud concept for logically organizing clusters and other resources, letting you use and manage multi-cluster capabilities and apply consistent policies across your systems. ... Fleet-aware resources can only be members of a single fleet at any given time.」 — Fleet management
6.1 Fleet の概念図
図 6-1：GKE Fleet と一括機能
6.2 Fleet の 4 つの設計原則
| 原則 | 意味 | 実装上の影響 |
|---|---|---|
| Grouping | 「強く関連する cluster」だけを 1 fleet に | 本番 fleet と dev fleet は分離、cross-service 通信が多いものを集約 |
| Sameness | 同名 namespace / service / identity は 同一エンティティとして扱う | cluster A の payment namespace と cluster B の payment namespace は同じチーム所有とみなす（MCS / 認可で重要） |
| Exclusivity | 1 cluster は 1 fleet にのみ所属、1 Project は 1 fleet のみ host | fleet 変更には membership 削除 → 再 registration が必要 |
| High Trust | fleet 内 cluster は互いに高い信頼関係 | blast radius の境界は cluster ではなく fleet、セキュリティ境界には不向き → 環境ごとに fleet 分離 |
🔑 試験ポイント：Sameness の罠
Sameness は便利だが、「同名で別チームの namespace を別 cluster で作る」と意図せず統合される。例：cluster A の
monitoring（Platform 用）と cluster B の monitoring（あるアプリ用）が MCS で結合 → service 名衝突。Team Scopes（2023 GA）で namespace prefix を team-bound にすると安全。
6.3 Config Sync：RootSync vs RepoSync
| 観点 | RootSync | RepoSync |
|---|---|---|
| スコープ | クラスタ全体（cluster-scoped + 全 namespace） | 1 namespace のみ |
| 権限 | cluster-admin（強い） | namespace 内 admin（弱い） |
| 用途 | Platform チームが全 namespace の baseline 配布 | アプリチームが自 namespace の deploy |
| 同居 | クラスタに 1 つ（v1beta1）/ 複数 (v1) | namespace 単位で 1 つ |
| Source Type | git / oci / helm | git / oci / helm |
| 典型構成 | 1 cluster に 1 RootSync + N RepoSync（マルチテナント） | — |
# RootSync 例（Platform チーム配布、cluster 全体）
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
name: root-sync
namespace: config-management-system
spec:
sourceFormat: unstructured
git:
repo: https://github.com/myorg/platform-baseline
branch: main
dir: clusters/asia-tokyo
auth: gcpserviceaccount
gcpServiceAccountEmail: config-sync@PRJ.iam.gserviceaccount.com
---
# RepoSync 例（payment チームの自 namespace 管理）
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
name: repo-sync
namespace: payment # アプリチームの namespace
spec:
sourceFormat: unstructured
git:
repo: https://github.com/payment-team/manifests
branch: main
dir: overlays/prod
auth: gcpserviceaccount
gcpServiceAccountEmail: payment-cs@PRJ.iam.gserviceaccount.com
6.4 Policy Controller（OPA Gatekeeper 統合）
Policy Controller は OPA Gatekeeper を Google が拡張したもの。ConstraintTemplate（ルールの定義 / Rego）と Constraint（適用インスタンス）で K8s リソースに admission policy を強制。Policy Bundles（Google 提供のプリセット）で PCI-DSS / NIST 800-53 / CIS Benchmark に即準拠。
# ConstraintTemplate（再利用可能なルール定義）
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: k8srequiredlabels
spec:
crd:
spec:
names: { kind: K8sRequiredLabels }
validation:
openAPIV3Schema:
type: object
properties:
labels: { type: array, items: { type: string } }
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8srequiredlabels
violation[{"msg": msg}] {
required := input.parameters.labels
provided := input.review.object.metadata.labels
missing := required[_]
not provided[missing]
msg := sprintf("Label %v is required", [missing])
}
---
# Constraint（ConstraintTemplate を使って実際に enforce）
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-team
spec:
enforcementAction: deny # dryrun / warn / deny
match:
kinds: [{apiGroups: [""], kinds: ["Namespace"]}]
parameters:
labels: ["team", "cost-center"]
💡 Policy Bundles で即準拠
Google は policy-essentials / pci-dss-v3.2.1 / nist-sp-800-53-r5 / cis-k8s-v1.5.1 / asm-policy-v0.0.1 等のプリセットを提供。Fleet に enable するだけで「特権 Pod 禁止」「latest tag 禁止」「resource limits 必須」等の数十ルールが即時 enforce。最初は
enforcementAction: dryrun で violation を観測 → 段階的に deny 化。
6.5 Multi-cluster Services (MCS) / Multi-cluster Ingress (MCI)
| 機能 | 仕組み | 用途 |
|---|---|---|
| Multi-cluster Services | cluster 跨ぎの Service discovery、ServiceExport CRD で export → 他 cluster で service.namespace.svc.clusterset.local で resolve | active-active region、リージョン跨ぎ failover |
| Multi-cluster Ingress | Global LB を 1 つ作成し、複数 cluster の backend に weighted で振り分け | blue-green region migration、grobal availability |
| Multi-cluster Gateway | MCI の後継、Gateway API ベース、より高度な traffic 制御 | HTTP/TCP, header-based routing |
6.6 GKE Release Channels と Upgrade 戦略
| Channel | 更新頻度 | 適合 |
|---|---|---|
| Rapid | 数週 | 最新機能の早期検証、開発環境 |
| Regular（デフォ） | 数ヶ月 | 一般的な本番 |
| Stable | 半年 | 金融、規制業界、保守的 |
| Extended | 16 ヶ月 LTS | 長期サポート、ダウンタイム最小化 |
| No channel | 手動 | 非推奨（自動 patch も停止 = CVE 放置） |
6.7 Surge Upgrade vs Blue-Green Node Pool Upgrade
Surge Upgrade（デフォルト）
- 追加ノード作成 → 旧ノード drain → 削除を繰り返し
- パラメータ：
maxSurge=1（追加 node 数）/maxUnavailable=0 - コスト：一時的に 1-25% 増
- PDB（PodDisruptionBudget）必須、漏らすと瞬断
- 適合：一般用途
Blue-Green Node Pool Upgrade
- 新 Node Pool を 全量並列で作成 → traffic 切替 → 旧 Pool 削除
- コスト：upgrade 中 2x
- 切戻し即座（旧 Pool を残せば）
- 適合：ステートフル、リスク高、auto-rollback 必須
- 「soak time」で本番 traffic を一定期間流して確認後切戻し可
6.8 Maintenance Window / Exclusion
# Maintenance Window：upgrade を許可する時間帯
gcloud container clusters update prod-tokyo \
--maintenance-window-start="2026-06-01T18:00:00Z" \
--maintenance-window-end="2026-06-02T02:00:00Z" \
--maintenance-window-recurrence="FREQ=WEEKLY;BYDAY=SA,SU"
# → 毎週土日 UTC 18-02 のみ自動 upgrade
# Maintenance Exclusion：絶対に upgrade させない期間（セール / 決算）
gcloud container clusters update prod-tokyo \
--add-maintenance-exclusion-name=blackfriday-2026 \
--add-maintenance-exclusion-start=2026-11-25T00:00:00Z \
--add-maintenance-exclusion-end=2026-12-02T00:00:00Z \
--add-maintenance-exclusion-scope=NO_MINOR_OR_NODE_UPGRADES
# scope: NO_UPGRADES / NO_MINOR_UPGRADES / NO_MINOR_OR_NODE_UPGRADES
# 最長：NO_UPGRADES = 7 日、NO_MINOR_UPGRADES = 90 日、NO_MINOR_OR_NODE_UPGRADES = 180 日
6.9 事故ケース
⚠️ 事故 25: Config Sync の drift 検出漏れで本番設定が手動上書きされた
| 状況 | 運用者が緊急対応で kubectl edit deployment したまま Git に反映せず放置、Config Sync が drift を warning のみで継続 |
|---|---|
| 影響 | 1 か月後に別の修正で Config Sync が override、緊急対応が消えて本番障害 |
| 根本原因 | Config Sync の spec.override.reconcileTimeout 設定不足、drift policy が respect ではなく force |
| 即対処 | 緊急対応内容を Git に commit、Config Sync の drift status を確認 |
| 恒久対策 | 「手動 kubectl edit 禁止」を Policy Controller で enforce（admission webhook で last-applied-configuration を強制）、drift 検知時に PagerDuty alert |
⚠️ 事故 26: Multi-cluster Ingress の weight split が想定外動作
| 状況 | MCI で asia-tokyo 80% / us-central 20% に振り分けたが、tokyo cluster の NEG (Network Endpoint Group) が unhealthy 扱いで全 traffic が us に集中 |
|---|---|
| 影響 | us-central の cluster が capacity 不足で 5xx 多発 |
| 根本原因 | health check の path が間違っていて NEG が常に unhealthy、weight より health 判定が優先 |
| 即対処 | health check の path / port を修正、cluster の readiness probe と一致させる |
| 恒久対策 | NEG status を Cloud Monitoring で監視、MCI 設定変更後は必ず synthetic check で各 region への到達確認 |
⚠️ 事故 27: GKE auto-upgrade で本番停止（ABI 非互換）
| 状況 | Regular channel で自動 upgrade、新版 Kubernetes で 非推奨 API (policy/v1beta1 PodDisruptionBudget) 削除、アプリ起動不能 |
|---|---|
| 影響 | 本番 Pod が ImagePullBackOff の山、4 時間ダウン |
| 根本原因 | Release notes 未確認、API deprecation 検知なし |
| 即対処 | マニフェスト修正（policy/v1 に移行）、緊急 deploy |
| 恒久対策 | Stable channel に切替、API Deprecation Insights（GKE）で事前検知、staging cluster で先に upgrade テスト、pluto ツールで deprecated API 検出を CI に |
⚠️ 事故 28: PDB なしで Surge Upgrade で全 Pod 同時 drain
| 状況 | Deployment に PodDisruptionBudget を設定せず Surge Upgrade、複数 node から同時 drain で 全 replica が同時に terminate |
|---|---|
| 影響 | 瞬断 30 秒、SLO 違反、エラーバジェット消費 |
| 根本原因 | PDB minAvailable 未設定 |
| 即対処 | 緊急で kubectl create pdb |
| 恒久対策 | Policy Controller で「Deployment には PDB 必須」を enforce、CI で同 namespace の PDB 存在チェック |
⚠️ 事故 29: Sameness で別チームの monitoring namespace が結合
| 状況 | cluster A の monitoring（Platform チーム所有）と cluster B の monitoring（payment チームが個別作成）が、MCS で同一視され ServiceExport が衝突 |
|---|---|
| 影響 | Platform の Prometheus に payment 用 ServiceMonitor が見えてしまい、metrics 衝突 |
| 根本原因 | Sameness 原則の理解不足、namespace 命名規則なし |
| 即対処 | payment 側を payment-monitoring に rename |
| 恒久対策 | Team Scopes で team-prefix を強制、Policy Controller で「namespace 名に team prefix 必須」を enforce |
7Cloud Workstations & Gemini
Cloud Workstations は 「VPC 内で動く、IDE プリセット済みの ephemeral 開発 VM」。BYOD / 退職者の data 残留 / オンプレ DB アクセス等のセキュリティ要件に強い。Gemini 3 兄弟（Code Assist / Cloud Assist / CLI）と組み合わせて、開発生産性も底上げ。
「Workstations run on ephemeral Compute Engine VMs, and can be started or stopped on demand to improve cost savings. ... Updates to a workstation configuration automatically apply to workstations when each workstation restarts.」 — Cloud Workstations overview
7.1 Cloud Workstations アーキテクチャ（3 階層）
図 7-1：Cloud Workstations の Cluster / Config / Instance 3 階層
7.2 各階層の役割と制限
| 階層 | 役割 | 主な設定 | 制限 |
|---|---|---|---|
| Cluster | VPC / region 単位の境界 | VPC、subnet、private/public、CMEK | 1 region 内、Project あたり複数可 |
| Config | テンプレート（machineType / image / idle timeout） | e2 / n2 / GPU、persistent home サイズ | 1 cluster 内に複数（チーム別） |
| Instance | 個人の VM、ephemeral | config から起動、停止可 | idle timeout（default 20m）/ running timeout（default 12h） |
7.3 カスタムイメージのビルド・配布
# 公式 base 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 make \
&& curl -sL https://cli.github.com/install.sh | bash
# VS Code 拡張機能をプリインストール（OpenVSX 経由）
ENV VSCODE_EXTENSIONS="GoogleCloudTools.cloudcode,golang.go,ms-python.python,hashicorp.terraform"
# 自社 root CA 同梱（内部 API への HTTPS）
COPY company-ca.crt /usr/local/share/ca-certificates/
RUN update-ca-certificates
# Cloud SDK / kubectl / gcloud は同梱済み（base image）
# Build & Push
docker build -t asia-northeast1-docker.pkg.dev/PRJ/workstations/dev:v1.2.3 .
docker push asia-northeast1-docker.pkg.dev/PRJ/workstations/dev:v1.2.3
# Config に image を指定
gcloud workstations configs update my-config \
--container-custom-image=asia-northeast1-docker.pkg.dev/PRJ/workstations/dev:v1.2.3 \
--cluster=my-cluster --region=asia-northeast1
7.4 Private Cluster + CMEK + VPC SC
- Private Cluster：public IP なし、IAP TCP forwarding で SSH / HTTPS、社内 VPN からのみ access
- CMEK：Persistent Home の暗号化、Cloud KMS の鍵を Workstations service agent に grant
- VPC Service Controls：workstations.googleapis.com を境界に含める、外部からの API access 不可
- Disable Public IP：Org Policy
compute.vmExternalIpAccessで workstation VM の外部 IP を禁止 - Audit Logs：admin / data access logs、誰がいつ workstation を作成 / 削除 / start したか
7.5 Gemini Code Assist（IDE 内 AI）
| 機能 | Standard | Enterprise |
|---|---|---|
| コード補完（inline） | ◎ | ◎ |
| チャット（自然言語 → コード） | ◎ | ◎ |
| 30+ 言語サポート | ◎ | ◎ |
| プライベートコード参照（自社 repo を context に） | — | ◎ |
| Code Transformation（API 移行等の一括リファクタ） | — | ◎ |
| GitHub / GitLab PR review | — | ◎ |
| Customization（社内コーディング規約） | — | ◎ |
| データプライバシー：プロンプト学習 | opt-out 可 | 学習に使われない（zero data retention 設定可） |
| 対応 IDE | VS Code / JetBrains / Cloud Shell Editor / Cloud Workstations | 同左 |
| ライセンス | 無料枠あり | per user / 月課金 |
7.6 Gemini Cloud Assist（Console / 運用 AI）
| 機能 | 用途 |
|---|---|
| アーキ設計 | 「100 RPS の API インフラを設計」→ 構成図 + Terraform スニペット出力 |
| Investigations | Logs Explorer / Metrics から障害ストーリーを自動構築、Root Cause 仮説提示 |
| コスト分析 | 「先月のコスト急増の理由は？」→ Billing Export を分析 |
| gcloud / Terraform 生成 | 自然言語 → コマンド / HCL |
| SQL 生成 | BigQuery 内で自然言語 → SQL |
| セキュリティ | Security Command Center の findings を Gemini が要約・優先度付け |
7.7 Gemini CLI（ターミナル AI エージェント）
Gemini CLI（2024 OSS 公開、2025 拡張）は、ターミナルで動く AI エージェント。ファイル読み書き / シェル実行 / Web 検索 / MCP server 連携が可能で、リポジトリ理解・自動修正・IaC 生成等のタスクを自律実行。
# ローカル / Cloud Shell / Cloud Workstations で実行
brew install gemini-cli # または npm install -g @google/gemini-cli
gemini auth login # 個人 Google アカウント / Vertex AI / WIF
gemini # 対話モード起動
> @./src このリポジトリの構成を要約して
> @./terraform 既存 IaC を読み取って、Cloud SQL を追加する PR を作成して
> @./.github/workflows GitHub Actions の deploy job を Cloud Build に変換して
# 非対話（CI で使う）
gemini "Update package.json dependencies" --yolo # 自動承認モード（dangerous）
gemini -p "Find security issues in src/" --output-format=json
7.8 3 ツールの使い分け
| ツール | 場所 | 主用途 | 典型 prompt |
|---|---|---|---|
| Gemini Code Assist | IDE 内（VS Code / JetBrains / Cloud Workstations） | コーディング中の補完・チャット | 「この関数の単体テストを書いて」 |
| Gemini Cloud Assist | GCP Console 内 | クラウド運用・設計・障害調査 | 「prod-payment の 5xx 増加の原因は？」 |
| Gemini CLI | ターミナル（ローカル / Cloud Shell / Workstations） | エージェント的タスク（リポ理解、IaC 生成、自動修正） | 「全 Dockerfile に health check を追加する PR を作成」 |
7.9 事故ケース
⚠️ 事故 30: Cloud Workstations の idle timeout で作業データ消失
| 状況 | 開発者が 30 分席を外し、idle timeout（default 20m）で workstation 停止。/tmp や /workspace の作業データが消失（PD 以外） |
|---|---|
| 影響 | 2 時間分の試行錯誤データが消失、開発者の士気低下 |
| 根本原因 | persistent home（/home）以外の場所に作業ファイルを置いていた、idle timeout が短すぎ |
| 即対処 | workstation を再 start（PD の /home は残る）、消えた作業は git にあるもののみ復旧 |
| 恒久対策 | 「作業ファイルは必ず /home 配下に」を周知、persistent_directories に /workspace を追加、idle timeout を 1-2h に延長、頻繁な git push を文化に |
⚠️ 事故 31: カスタムイメージ更新後に拡張機能が壊れた
| 状況 | Workstations 用カスタムイメージを VS Code 最新版に更新したら、社内独自の VSIX 拡張が API 非互換で起動不能 |
|---|---|
| 影響 | 全開発者の IDE が壊れ、半日間生産性低下 |
| 根本原因 | カスタムイメージのテスト環境なし、即本番に推送 |
| 即対処 | config を旧 image tag に rollback、各 workstation を再起動 |
| 恒久対策 | カスタムイメージは dev → stage → prod の段階リリース、Cloud Build で smoke test（image を ephemeral workstation で起動して IDE 起動確認） |
⚠️ 事故 32: Workstations から Gemini Code Assist が動かない（VPC SC）
| 状況 | VPC Service Controls で workstations を境界に入れたが、aiplatform.googleapis.com を ingress rule に追加し忘れ |
|---|---|
| 影響 | Gemini Code Assist が「permission denied」、開発者の AI 補助が全停止 |
| 根本原因 | VPC SC の境界設定で AI Platform API 未許可 |
| 即対処 | VPC SC perimeter に aiplatform / generativelanguage を追加 |
| 恒久対策 | VPC SC 設定変更前に Dry Run mode で違反を確認、Gemini 利用 API を一覧化して必ず allow rule に |
⚠️ 事故 33: Gemini CLI の
--yolo で本番リソース削除
| 状況 | Gemini CLI を --yolo（自動承認）で実行、prompt の解釈ミスで terraform destroy 相当のコマンドを実行 |
|---|---|
| 影響 | 本番 staging 環境のリソース全削除、復旧 3 時間 |
| 根本原因 | 自動承認モードを本番アクセス可能な環境で実行、SA 権限過剰 |
| 即対処 | Terraform から再 apply、Backup and DR で復旧 |
| 恒久対策 | --yolo は dev sandbox のみで使用、Gemini CLI 実行 SA は読み取り中心の権限のみ、本番への apply は人間承認必須 |
8事故ケース総集編 / 試験で問われる即答パターン
8.1 全章の事故ケース一覧
| # | 領域 | 事故 | 根本原因 | 即対処 |
|---|---|---|---|---|
| 1 | Org Policy | 外部ドメインに Owner 付与 | allowedPolicyMemberDomains 未設定 | Constraint で自社ドメインのみ allow |
| 2 | Resource Mgr | Folder 削除でリソース道連れ | 削除前棚卸し漏れ | Deny Policy で folders.delete ブロック + PAM |
| 3 | Project | Project quota 上限到達 | ephemeral lifecycle なし | TTL ラベル + Scheduler で自動削除 |
| 4 | 命名 | 所有者不明 Project 200 個 | Custom Constraint なし | cost-center ラベル必須化 |
| 5 | IAM | Default SA の Editor 自動付与 | Org Policy 未設定 | automaticIamGrantsForDefaultServiceAccounts disable |
| 6 | Terraform | State 喪失で Org 再構築不能 | local backend | Infrastructure Manager / GCS + CMEK |
| 7 | VPC Peering | 非推移で 3 拠点不通 | 仕様理解不足 | NCC で hub-spoke 構成 |
| 8 | Shared VPC | IAM 全置換で Service Project 停止 | setIamPolicy 破壊的 | add-iam-policy-binding 強制 + IaC 管理 |
| 9 | PSC | endpoint quota 上限 | 粒度過剰 | internal LB 経由で集約 |
| 10 | Shared VPC | Cross-Org で attach 不可 | 同一 Org 必須 | HA VPN / NCC で接続 |
| 11 | Network | /24 で IP 枯渇 | subnet 設計 | /16 + Discontiguous Multi-Pod CIDR |
| 12 | IAM | Owner 50 人付与で DB drop | Basic Role 濫用 | Group ベース + PAM JIT |
| 13 | SA Key | GitHub 流出で仮想通貨マイニング | SA Key 存在 | WIF 移行 + Org Policy で SA Key 禁止 |
| 14 | Custom Role | 権限不足で Cloud Build 失敗 | Predefined を base にせず | Predefined を base + Iterate |
| 15 | Conditional IAM | CEL タイポで access 不能 | テストなし | Policy Simulator + break-glass |
| 16 | WIF | condition 緩く任意 repo 認証 | owner_id 未指定 | repository_owner_id 必須化 |
| 17 | WIF | Pool 削除で全 CI 停止 | IaC 管理なし | undelete + Deny Policy + IaC |
| 18 | WIF | audience mismatch | rename ミス | 初期から汎用名固定 |
| 19 | WIF | fork PR で本番 deploy | trigger 制御不足 | Environment Protection + condition |
| 20 | Terraform | -auto-approve で本番削除 | 承認なし | 承認 workflow + prevent_destroy |
| 21 | Terraform | state lock 競合 3h 停止 | stale lock | Infrastructure Manager 移行 |
| 22 | Config Connector | reconciler 暴走で API quota 枯渇 | CRD バリデーション不足 | kyverno + retry budget |
| 23 | Terraform | 1 state で plan 40 分 | 分割設計なし | 4 layer 分割（Foundations） |
| 24 | Helm | values 漏れで本番起動失敗 | 引数手作業 | Kustomize overlay + Cloud Deploy |
| 25 | Config Sync | drift 検出漏れで本番上書き | drift policy 設定 | kubectl edit 禁止 + alert |
| 26 | MCI | weight が NEG unhealthy で偏った | health check 誤設定 | synthetic check + Monitoring |
| 27 | GKE | auto-upgrade で deprecated API | Release notes 未確認 | Stable channel + pluto in CI |
| 28 | GKE | PDB なし Surge で瞬断 | PDB 未設定 | Policy Controller で PDB 必須 |
| 29 | Fleet | Sameness で別チーム ns 衝突 | 命名規則なし | Team Scopes + 強制 prefix |
| 30 | Workstations | idle timeout で作業消失 | /home 外に保存 | persistent_directories 拡張 + timeout 延長 |
| 31 | Workstations | image 更新で拡張壊れ | テスト環境なし | dev→stage→prod の段階リリース |
| 32 | VPC SC | Gemini Code Assist 不通 | aiplatform 未許可 | Dry Run mode で事前確認 |
| 33 | Gemini CLI | --yolo で本番削除 | 権限過剰 | read-only SA + 本番は人間承認 |
8.2 試験本番で迷ったらこれ：即答マトリクス
🔑 即答マトリクス（PCDE 試験で頻出）
| 問題のキーワード | 正解（即答） |
|---|---|
| Google 推奨の Landing Zone を Terraform で構築 | Cloud Foundation Toolkit (terraform-example-foundation) / Cloud Foundation Fabric |
| 複数プロジェクトで 1 つのネットワーク基盤を中央管理 | Shared VPC（同一 Org 内） |
| 異なる Organization の VPC を接続 | VPC Peering or HA VPN（Cross-Org Shared VPC は不可） |
| Cloud SQL / Memorystore 等のマネージドにプライベート接続 | Private Service Connect |
| 複数 VPN / Interconnect を hub-spoke で統合 | Network Connectivity Center (NCC) |
| GitHub Actions / GitLab CI から GCP に SA Key 無しで認証 | Workload Identity Federation |
| GKE Pod から GCP API に認証 | Workload Identity for GKE |
| 人間ユーザーが外部 IdP（Okta 等）で GCP Console にログイン | Workforce Identity Federation |
| SA Key を作らせない | Org Policy iam.disableServiceAccountKeyCreation + Deny Policy |
| Default SA に Editor 自動付与を止める | Org Policy iam.automaticIamGrantsForDefaultServiceAccounts |
| 外部ドメイン user 流入を防ぐ | Org Policy iam.allowedPolicyMemberDomains |
| リソース作成可能リージョン制限（データ常駐） | Org Policy gcp.resourceLocations |
| 規制対応のフォルダ単位プロファイル | Assured Workloads |
| Org Policy を本番適用前にテスト | Dry Run mode（dryRunSpec） |
| 「絶対に禁止」を IAM allow より優先 | Deny Policy |
| 過去 90 日の利用から最小権限を提案 | IAM Recommender |
| 誰が何にアクセスできるかを Org 横断で照会 | Policy Analyzer |
| 「なぜ access できる/できない」逆引き | Policy Troubleshooter |
| 時限・承認制の権限昇格 | Privileged Access Manager (PAM) |
| IaC の state 管理を GCP に任せる | Infrastructure Manager |
| K8s で GCP リソースを宣言管理 | Config Connector |
| Google 推奨 module 集 | Cloud Foundation Toolkit (CFT) |
| opinionated な end-to-end blueprint | Cloud Foundation Fabric (FAST) |
| 複数の GKE / Anthos cluster を論理単位として扱う | GKE Fleet |
| Git → 複数 cluster へ K8s マニフェスト同期 | Config Sync |
| Platform チームが cluster 全体に baseline 配布 | RootSync |
| アプリチームが自 namespace を管理 | RepoSync |
| OPA Gatekeeper で K8s admission 制御 | Policy Controller |
| PCI-DSS / NIST のルール集を即適用 | Policy Controller の Policy Bundles |
| cluster 跨ぎ Service Discovery | Multi-cluster Services (MCS) |
| 複数 region cluster に global LB | Multi-cluster Ingress (MCI) / Multi-cluster Gateway |
| cluster に kubectl したい（VPN 不要） | Connect Gateway |
| 金融・規制業界の保守的 GKE channel | Stable channel（または Extended で LTS） |
| blue-green node pool upgrade を選ぶ理由 | ステートフル、即時 rollback 要求 |
| セール期間中の upgrade 抑止 | Maintenance Exclusion（最長 180 日） |
| ブラウザベース開発環境（VPC 内） | Cloud Workstations |
| 無料の軽量シェル | Cloud Shell（5GB 永続） |
| IDE 内 AI 補完 | Gemini Code Assist |
| Console 内クラウド運用 AI | Gemini Cloud Assist |
| ターミナルエージェント | Gemini CLI |
| Software Delivery Shield の傘下 | Cloud Workstations + Cloud Build (SLSA L3) + AR + Binary Auth + Cloud Deploy |
| Cloud Service Mesh の正体 | 旧 Anthos Service Mesh（Istio ベース） |
8.3 ベストプラクティス チェックリスト
✅ 組織 / IAM
・Folder 構造を Application-centric or Environment-centric で統一
・命名規則を Custom Constraint で enforce（cost-center label 必須）
・Basic Role 禁止、Group ベース付与
・SA Key を作らない（Org Policy + Deny Policy）
・automaticIamGrantsForDefaultServiceAccounts を disable
・allowedPolicyMemberDomains で外部 user 流入防止
・PAM で JIT 権限昇格
✅ ネットワーク
・同一 Org 内集中管理 → Shared VPC
・マネージドサービス接続 → PSC
・複数 VPN / Interconnect → NCC で hub-spoke
・subnet は /16 で広く確保、後で広げられない
・Cross-Org は HA VPN / Cross-Cloud Interconnect
✅ IaC
・State は Infrastructure Manager または GCS + CMEK + Object Versioning
・State を 4 layer 分割（bootstrap / org / env / project）
・本番 apply は 必ず承認 workflow
・prevent_destroy = true lifecycle
・Policy Simulator で事前テスト
・Cloud Foundation Toolkit / Fabric から始める
✅ WIF / CI-CD
・SA Key を完全廃止 → WIF
・attribute condition で repository_owner_id 必須
・GitHub Environment Protection と連携（attribute.environment）
・WIF Pool / Provider は IaC + Deny Policy で delete 禁止
・SA は最小権限、責務別に分割
✅ GKE / Fleet
・Fleet は 環境ごとに分離（blast radius）
・Team Scopes + namespace prefix 強制（Sameness の事故防止）
・Config Sync の drift policy を force に
・Policy Controller の Policy Bundles を dryrun → deny
・PDB 必須化（Policy Controller）
・Stable channel + Maintenance Exclusion（セール期間）
✅ Workstations / Gemini
・Private Cluster + CMEK + VPC SC で配布
・persistent_directories に /workspace を追加、idle timeout を 1-2h
・カスタムイメージは dev→stage→prod の段階リリース＋ smoke test
・Gemini Code Assist Enterprise で zero data retention
・Gemini CLI の --yolo は dev sandbox のみ、本番は read-only SA
8.4 トラブルシュート意思決定フロー
💡 「Bootstrap 領域で何かおかしい」時の切り分け順序
- Cloud Audit Logs を見る：誰がいつ何を呼んだか。Resource Manager / IAM / Org Policy / WIF / Config Connector は全て Audit Logs に記録
- エラーメッセージで層を特定：
permission denied→IAM、policy violation→Org Policy、audience mismatch→WIF、quota exceeded→quota - Policy Troubleshooter：「なぜ access できない」を逆引き
- Org Policy の effective policy を
gcloud org-policies describeで確認 - WIF なら token を decode（jwt.io）して claim を確認、attribute condition と照合
- Shared VPC なら Host で IAM
networkUserが付いているか、subnet が許可されているか - Config Sync / Connector なら controller pod のログを確認、reconcile error を見る
- 最近の変更：直近 24h の Org Policy / IAM / Terraform / Config Connector CRD の diff