変更要約: Professional Cloud Architect 第3章を新規作成（ドメイン2「管理とプロビジョニング」前半: IaC＝Terraform/Infrastructure Manager・状態/モジュール・CI/CD/PR・クリックオプス回避・Config Connector、ネットワーク構成＝VPC/サブネット/ファイアウォール・共有 VPC・ロードバランサー種別・Cloud NAT・Private Google Access・VPC Service Controls）。
3.1Infrastructure as Code によるプロビジョニング
Infrastructure as Code（Terraform・Infrastructure Manager）による再現可能なプロビジョニング、状態管理とモジュール化、CI/CD への組み込み、そして手作業（クリックオプス）を避けて一貫性とレビュー可能性を得る考え方を理解します。
設計が決まったら、インフラを再現可能・レビュー可能な形で構築します。手作業（クリックオプス）はミスとドリフトの温床です。アーキテクトは Infrastructure as Code（IaC） を前提に運用を設計します。
3.1.1IaC ツールと状態管理
Google Cloud では、業界標準の Terraform や、そのマネージド版である Infrastructure Manager でインフラをコードとして定義します。コードは 状態（state） で現実のリソースと対応づけられ、モジュールで再利用可能に構造化します。これにより、同じ構成を環境（本番/開発）へ再現でき、変更は Pull Request でレビューできます。「再現可能なインフラ＝IaC（Terraform/Infrastructure Manager）」と結びます。
3.1.2CI/CD への組み込みと一貫性
IaC は CI/CD パイプライン（Cloud Build など）に組み込み、コードの変更を自動で検証・適用します。これにより、誰がいつ何を変えたかが追跡でき（監査）、本番への変更が統制されます。手作業の変更は ドリフト（コードと現実のずれ）を生むため避け、IaC を唯一の真実の源にします。「一貫性・監査・統制＝IaC を CI/CD に乗せる」「手作業はドリフトの原因」を押さえます。
「要件 → 手段」が頻出。例：「同じ構成を複数環境へ再現」＝IaC＋モジュール、「変更をレビュー・追跡」＝IaC を CI/CD＋PR、「マネージドな Terraform」＝Infrastructure Manager、「クリックオプスのドリフトを防ぐ」＝IaC を唯一の真実の源に、「Kubernetes 流に GCP リソース管理」＝Config Connector。
混同に注意：
①手作業の変更は IaC とのドリフトを生む＝原則 IaC 経由で変更。
②状態（state）の保護と共有（リモートバックエンド）を設計する。
③Infrastructure Manager は Terraform のマネージド実行で、Terraform を置き換える別言語ではない。
3.1.3この節のまとめ
- IaC＝Terraform/Infrastructure Manager でインフラをコード化し再現可能にする
- 状態とモジュールで構造化、CI/CD＋PR で検証・レビュー・監査
- 手作業（クリックオプス）はドリフトの原因。IaC を唯一の真実の源にする
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 同じインフラ構成を本番と開発で再現可能に構築し、変更をレビューできるようにしたい。最も適した方法はどれですか？
Q2. Google Cloud がマネージドで提供する Terraform 実行サービスはどれですか？
Q3. 手作業でコンソールから直接変更を加えることの主な問題はどれですか？
Q4. IaC の変更を自動で検証・適用し、誰が何を変えたか追跡したい。最も適した方法はどれですか？
Q5. Terraform の「状態（state）」の役割として正しいものはどれですか？
Q6. Kubernetes の宣言的な方法で Google Cloud リソースを管理したい。使うのはどれですか？