変更要約: Associate Cloud Engineer 第3章を新規作成（ドメイン3「デプロイと実装」: Compute Engine と GKE＝インスタンス/MIG・オートスケール/インスタンステンプレート/OS Login/GKE(Autopilot/Standard/リージョナル/プライベート)/kubectl、サーバーレスとデータ＝Cloud Run/Cloud Functions/Eventarc/データプロダクト/AlloyDB/ロード、ネットワークと IaC＝VPC/サブネット/ファイアウォール/Cloud VPN/VPC ピアリング/Terraform/Config Connector）。
3.1Compute Engine と GKE のデプロイ
Compute Engine インスタンスの起動、インスタンステンプレートを用いた自動スケールするマネージドインスタンスグループ（MIG）、OS Login によるアクセス管理、そして GKE クラスタの構成（Autopilot・Standard・リージョナル・プライベート）とコンテナアプリのデプロイ、kubectl の利用を理解します。
デプロイは Associate Cloud Engineer の中心（公式 ~25%）です。まず VM とコンテナの2大デプロイ先＝Compute Engine と GKE を押さえます。
3.1.1Compute Engine と MIG
Compute Engine では、ディスク・可用性ポリシー・SSH 鍵などを指定して インスタンス を起動します。同じ構成の VM を多数・自動で増減させるには、インスタンステンプレート（VM の設計図）を作り、それを基に マネージドインスタンスグループ（MIG） を構成して オートスケール させます（負荷に応じて台数を増減）。VM への SSH アクセスは OS Login で IAM と連携して一元管理でき、鍵を個別に配るより安全です。
3.1.2GKE のデプロイ
コンテナは GKE にデプロイします。クラスタの運用モードには、ノード管理まで Google に任せる Autopilot と、ノードを自分で構成する Standard があります。可用性を高めるには複数ゾーンにまたがる リージョナルクラスタ、外部公開を絞るには プライベートクラスタ を選びます。クラスタを操作するには kubectl を構成し、コンテナイメージから Pod/Service などの Kubernetes リソースをデプロイします。「ノード管理が不要＝Autopilot」「細かく制御＝Standard」と結びます。
「要件 → 構成」が頻出。例：「同じ VM を自動で増減」＝インスタンステンプレート＋MIG＋オートスケール、「VM の SSH を IAM で一元管理」＝OS Login、「コンテナを動かす」＝GKE、「ノード管理を任せる」＝Autopilot、「ゾーンをまたいで高可用」＝リージョナルクラスタ、「外部公開を絞る」＝プライベートクラスタ、「クラスタを操作」＝kubectl。
混同に注意：
①インスタンステンプレート（設計図）とMIG（実体のグループ）を区別。
②オートスケールはMIGの機能。
③Autopilot（ノードお任せ）とStandard（ノード自管理）。
④可用性はリージョナル/複数ゾーンで高める。
3.1.3この節のまとめ
- インスタンステンプレート→MIG→オートスケールで同一 VM を自動増減。SSH は OS Login で IAM 一元管理
- GKE のモード＝Autopilot（ノードお任せ）/Standard（自管理）。可用性はリージョナル、公開制限はプライベート
- クラスタ操作は kubectl
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 同じ構成の VM を負荷に応じて自動的に増減させたい。必要な組み合わせはどれですか？
Q2. VM への SSH アクセスを IAM と連携して一元管理し、鍵を個別配布せずに安全にしたい。何を使いますか？
Q3. GKE で、ノードの管理まで Google に任せて運用負荷を最小化したい。最適なモードはどれですか？
Q4. 複数のゾーンにまたがって高可用な GKE クラスタを構成したい。適切な選択はどれですか？
Q5. GKE クラスタを操作してコンテナをデプロイするために構成・利用するツールはどれですか？
Q6. マネージドインスタンスグループ（MIG）の主な利点として最も適切なものはどれですか？