変更要約: Professional Cloud DevOps Engineer 第1章を新規作成（ドメイン1「ブートストラップ」: リソース階層/IAM 最小権限/組織ポリシー/サービスアカウント/Workload Identity/Shared VPC/VPC ピアリング/Private Service Connect/複数プロジェクト監視/データ所在地、IaC＝Infrastructure Manager/Config Connector/Terraform/Helm/GitOps/ブループリント、マルチ環境/エフェメラル/GKE フリート/パッチ、Cloud Workstations/Cloud Shell/Gemini Code Assist）。
1.1リソース階層・IAM・共有ネットワーク
組織のリソース階層（組織/フォルダ/プロジェクト）の設計、IAM ロールと組織レベルポリシー、サービスアカウントの作成と管理、Shared VPC・VPC ネットワークピアリング・Private Service Connect による共有ネットワーク、複数プロジェクトの監視/ログ、データ所在地を理解します。
Professional Cloud DevOps Engineer は、開発速度と信頼性を両立する仕組みを組織全体に行き渡らせます。その土台が、最初に正しく作る組織のブートストラップ＝リソース階層・アクセス制御・共有ネットワークです。
1.1.1リソース階層とアクセス制御
リソースは 組織→フォルダ→プロジェクト→リソースの階層で整理し、アプリケーション中心やチーム/環境別にフォルダを設計します。アクセスは IAM の 最小権限 で（基本ロールを避け事前定義/カスタム）、全社一貫の制約は 組織ポリシー（組織レベルポリシー）で階層継承させて強制します。ワークロードの ID は サービスアカウント で表し、鍵の持ち出しを避けるため可能な限り Workload Identity を使います。「全社のガードレール＝組織ポリシー」「許可＝IAM」と結びます。
1.1.2共有ネットワークと複数プロジェクト運用
複数プロジェクトで一貫したネットワークを使うには Shared VPC（ホストプロジェクトの VPC を複数のサービスプロジェクトで共有）を使い、別 VPC 間の接続は VPC ネットワークピアリング、特定サービスへの非公開接続は Private Service Connect を使います。運用では複数プロジェクトを横断する 監視/ログ（集約シンク/メトリクススコープ）を設計し、規制対応のため データ所在地 で保管地域を制御します。「複数プロジェクトで共通ネットワーク＝Shared VPC」「サービスへの非公開接続＝Private Service Connect」を押さえます。
「要件 → 手段」が頻出。例：「全社一貫の制約を強制」＝組織ポリシー、「最小権限のアクセス」＝IAM 事前定義/カスタム、「ワークロードの ID」＝サービスアカウント（鍵を持たない＝Workload Identity）、「複数プロジェクトで共通の VPC」＝Shared VPC、「別 VPC 同士を接続」＝VPC ピアリング、「特定サービスへ非公開接続」＝Private Service Connect、「保管地域の規制」＝データ所在地。
混同に注意：
①IAM（許可）と組織ポリシー（制約の強制）は別レイヤー。
②Shared VPC（1 VPC を共有）と VPC ピアリング（別 VPC を接続）を取り違えない。
③サービスアカウント鍵のダウンロードは最後の手段（漏えい源）＝Workload Identity を優先。
1.1.3この節のまとめ
- 組織/フォルダ/プロジェクト階層で整理、IAM 最小権限＋組織ポリシーで統制
- ワークロード ID はサービスアカウント、鍵を持たない Workload Identity を優先
- 共有ネットワーク＝Shared VPC/VPC ピアリング/Private Service Connect、保管地域はデータ所在地
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 全社で一貫した制約（特定リージョン以外の作成禁止など）を階層継承で強制したい。使うのはどれですか？
Q2. 複数のサービスプロジェクトで共通の VPC ネットワークを使わせたい。最適なのはどれですか？
Q3. ワークロードがサービスアカウント鍵を持たずに Google Cloud API を呼び出せるようにしたい。最適なのはどれですか？
Q4. 規制対応のためデータを特定の国/地域に保管したい。使う概念はどれですか？
Q5. 特定のマネージドサービスへ、インターネットを経由せず非公開で接続したい。最適なのはどれですか？