Cloud Infrastructure Studies

flowchart LR
A["Week 1-2<br/>基礎固め"] --> B["Week 3-4<br/>コンピューティング<br/>ストレージ"]
B --> C["Week 5-6<br/>ネットワーク<br/>IaC"]
C --> D["Week 7-8<br/>運用・セキュリティ<br/>模擬試験"]
A -.-> A1["IAM・リソース階層<br/>VPC基本<br/>Billing管理"]
B -.-> B1["GCE・GKE・Cloud Run<br/>Cloud Storage<br/>DB選定"]
C -.-> C1["VPC設計<br/>LB選定<br/>Terraform"]
D -.-> D1["Monitoring・Logging<br/>Security強化<br/>過去問演習"]
style A fill:#1a73e8,color:#fff,stroke:#1a73e8
style B fill:#0f9d58,color:#fff,stroke:#0f9d58
style C fill:#fbbc04,color:#000,stroke:#fbbc04
style D fill:#ea4335,color:#fff,stroke:#ea4335

cloud.google.com — ACE 試験公式ページ services.google.com — ACE 試験ガイド PDF

D1-01

リソース階層（Resource Hierarchy）

≈ 23%

Google Cloud のすべてのリソースは Organization → Folder → Project → Resource という厳密な階層構造で管理される。IAM ポリシーはこの階層を通じて上位から下位へ継承される。

階層構造の全体像

Resource Hierarchy

HIERARCHY

flowchart TD
ORG["🏢 Organization<br/>example.com"] --> F1["📁 Folder<br/>開発部門"]
ORG --> F2["📁 Folder<br/>本番部門"]
ORG --> F3["📁 Folder<br/>財務部門"]
F1 --> P1["🗂️ Project<br/>dev-frontend"]
F1 --> P2["🗂️ Project<br/>dev-backend"]
F2 --> P3["🗂️ Project<br/>prod-webapp"]
F2 --> P4["🗂️ Project<br/>prod-api"]
P1 --> R1["⚙️ Resources<br/>VM / DB / GCS"]
P3 --> R2["⚙️ Resources<br/>VM / DB / GCS"]
style ORG fill:#1a73e8,color:#fff,stroke:#1a73e8
style F1 fill:#0f9d58,color:#fff,stroke:#0f9d58
style F2 fill:#0f9d58,color:#fff,stroke:#0f9d58
style F3 fill:#0f9d58,color:#fff,stroke:#0f9d58
style P1 fill:#fbbc04,color:#000,stroke:#fbbc04
style P2 fill:#fbbc04,color:#000,stroke:#fbbc04
style P3 fill:#fbbc04,color:#000,stroke:#fbbc04
style P4 fill:#fbbc04,color:#000,stroke:#fbbc04

各レベルの役割と特性

レベル	役割	主な特性
Organization	企業・組織全体のルートノード	Google Workspace / Cloud Identity に紐付く。1ドメイン = 1 Organization
Folder	部門・環境・プロジェクトグループの区分け	最大 10 レベルのネスト。IAM ポリシーの集約点
Project	ビリングと信頼境界の最小単位	Project ID はグローバルに一意・変更不可
Resource	実際の GCP サービスリソース	必ず 1 つのプロジェクトに属する

IAM ポリシーの継承メカニズム（最重要）

IAM Policy Inheritance

INHERITANCE

flowchart TD
O["Organization<br/>roles/logging.admin 付与"] -->|継承| F["Folder<br/>追加ロールを付与可能"]
F -->|継承| P["Project<br/>すべての上位ロールが有効"]
P -->|継承| R["Resource<br/>最終的な権限 = 上位ロールの和集合"]
style O fill:#1a73e8,color:#fff,stroke:#1a73e8
style F fill:#0f9d58,color:#fff,stroke:#0f9d58
style P fill:#fbbc04,color:#000,stroke:#fbbc04
style R fill:#ea4335,color:#fff,stroke:#ea4335

⚠

重要な法則:上位で付与されたロールは下位で取り消せない。権限は「和集合」として機能する。下位レベルで制限しても、上位で許可されていればアクセスできる。

プロジェクトの識別子

識別子	例	変更	一意性
Project ID	`my-webapp-prod-20240101`	不可	グローバルに一意
Project Number	`123456789012`	不可	自動採番
Project Name	`My Webapp Production`	可能	不要

プロジェクトのライフサイクル

Project Lifecycle

LIFECYCLE

stateDiagram-v2
[*] --> ACTIVE : プロジェクト作成
ACTIVE --> DELETE_REQUESTED : gcloud projects delete
DELETE_REQUESTED --> ACTIVE : gcloud projects undelete<br>(30日以内)
DELETE_REQUESTED --> DELETED : 30日経過後<br>(完全削除・復元不可)

ベストプラクティス

1企業の組織構造をフォルダ階層に反映する — IAM 管理の直感性と継承を最大活用
2共通権限は親フォルダで付与する — 個別設定の手間と設定漏れを防止
3同一信頼境界のリソースを同一 Project にまとめる — セキュリティポリシーの一貫性
4Organization レベルのロール付与は最小限に — 影響範囲が最大のため慎重に

docs.cloud.google.com — リソース階層ドキュメント cloud.google.com — IAM ベストプラクティスガイド docs.cloud.google.com — IAM 継承とアクセス制御

D1-02

組織ポリシー（Organization Policy）

≈ 23%

IAM vs 組織ポリシーの違い

観点	IAM	組織ポリシー
制御対象	誰が（Who）何をできるか	リソースをどう設定できるか
主体	ユーザー・SA・グループ	リソース設定そのもの
例	alice は VM を作成できる	誰であっても外部 IP を持つ VM を作れない

主要な制約（Constraints）一覧

カテゴリ	制約名	効果
セキュリティ	`constraints/iam.disableServiceAccountKeyCreation`	SA の静的 JSON キー生成を禁止
セキュリティ	`constraints/iam.allowedPolicyMemberDomains`	IAM に追加できるユーザーを特定ドメインに限定
ネットワーク	`constraints/compute.disableExternalIpAddresses`	外部 IP を持つ VM の作成を禁止
ネットワーク	`constraints/compute.requireOsLogin`	全 VM で OS Login を強制
リージョン	`constraints/gcp.resourceLocations`	リソースを特定リージョンに限定（データ主権対応）

cloud.google.com — 組織ポリシーの概要

D1-03

請求管理 & コスト制御

頻出

予算アラートの自動制御アーキテクチャ

Budget Auto-Control Architecture

BILLING

flowchart LR
B["予算設定<br/>金額・スコープ・期間"] --> T["閾値設定<br/>50% / 90% / 100%"]
T --> N{通知方法}
N -->|メール| E["📧 最大5アドレスに送信"]
N -->|Pub/Sub| PS["📨 Pub/Sub トピック"]
PS --> CF["⚡ Cloud Functions"]
CF --> A["🔴 リソース自動停止<br/>VM停止 / API無効化"]
style PS fill:#1a73e8,color:#fff,stroke:#1a73e8
style CF fill:#0f9d58,color:#fff,stroke:#0f9d58
style A fill:#ea4335,color:#fff,stroke:#ea4335

⚠

最重要（試験頻出）: Google Cloud は予算の上限に達してもリソースを自動停止しません。自動停止にはPub/Sub + Cloud Functions のアーキテクチャが必要。

セキュリティインシデントによるコスト急増リスク

リスク	原因	対策
暗号資産マイニング	SA キー漏洩	キー生成禁止ポリシー・Secret Manager 使用
DDoS によるオートスケール課金	大量リクエスト	Cloud Armor + MIG スケーリング上限設定

ベストプラクティス

1Cloud Billing データをBigQuery にエクスポート — 詳細分析・監査証跡の確保
250% / 90% / 100% の 3 段階でアラートを設定 — 段階的な把握と対応が可能
3100% 閾値にはPub/Sub も設定 — 自動コスト制御の起点
4すべてのリソースにラベルを付与 — コストセンター別の細粒度分析
5Cloud Armor + MIG 上限設定を必ず実施 — セキュリティ起因のコスト暴走を防止

docs.cloud.google.com — 予算・アラートの設定 amnic.com — Billing レポート活用ガイド

D1-04

gcloud CLI & ADC

≈ 23%

ADC（Application Default Credentials）の検索順序

ADC Resolution Flow

ADC

flowchart TD
A[アプリがGCP APIを呼び出し] --> B{"GOOGLE_APPLICATION_CREDENTIALS<br/>環境変数が設定されているか?"}
B -->|Yes| C[指定されたキーファイルを使用]
B -->|No| D{"gcloud auth application-default login<br/>認証情報が存在するか?"}
D -->|Yes| E[ユーザー認証情報を使用]
D -->|No| F{"GCE / GKE / Cloud Run等の<br/>実行環境か?"}
F -->|Yes| G["メタデータサーバーから<br/>トークンを自動取得"]
F -->|No| H[認証エラー]
style G fill:#0f9d58,color:#fff,stroke:#0f9d58
style H fill:#ea4335,color:#fff,stroke:#ea4335

主要コマンド一覧

コマンド	説明
`gcloud config set project PROJECT_ID`	デフォルトプロジェクトを変更
`gcloud config set compute/region asia-northeast1`	デフォルトリージョンを変更
`gcloud config configurations create dev-profile`	新しい設定プロファイルを作成
`gcloud config configurations activate prod-profile`	設定プロファイルを切り替え
`gcloud auth application-default login`	ADC（ローカル開発用認証情報）を設定
`gcloud services enable compute.googleapis.com`	API を有効化

cloud.google.com — gcloud CLI 設定ドキュメント

D2-01

コンピューティングサービス選定

≈ 30%

サービス選定フローチャート

Compute Selection Decision Tree

COMPUTE-SELECT

flowchart TD
START[アプリケーション要件を確認] --> VM{VMが必要?}
VM -->|Yes| SPOT{"停止されても<br/>問題ない?"}
SPOT -->|Yes| SVM["Spot VM + MIG<br/>最大91%コスト削減"]
SPOT -->|No| GCE["Compute Engine<br/>OS レベルの完全制御"]
VM -->|No| CONT{コンテナを使う?}
CONT -->|Yes| K8S{Kubernetes が必要?}
K8S -->|Yes| PRIV{"特権コンテナ or<br/>DaemonSet が必要?"}
PRIV -->|Yes| STD["GKE Standard<br/>ノードを自己管理"]
PRIV -->|No| AUTO["GKE Autopilot<br/>Googleが全管理・推奨"]
K8S -->|No| RUN["Cloud Run<br/>HTTPステートレス・ゼロスケール"]
CONT -->|No| FUNC["Cloud Functions<br/>軽量イベント駆動"]
style AUTO fill:#0f9d58,color:#fff,stroke:#0f9d58
style RUN fill:#1a73e8,color:#fff,stroke:#1a73e8
style SVM fill:#fbbc04,color:#000,stroke:#fbbc04

コンピューティングサービス比較

サービス	管理レベル	課金モデル	最適なユースケース
Compute Engine	フル制御 (IaaS)	vCPU/時間	レガシー移行・特定 OS・特定ライセンス
Spot VM	フル制御 (IaaS)	最大 91% 割引	バッチ・ML・レンダリング（停止 OK）
GKE Autopilot	フルマネージド	Pod リソース単位	大規模マイクロサービス・運用負荷削減
GKE Standard	半マネージド	ノード (VM) 単位	特権コンテナ・カーネル設定・DaemonSet
Cloud Run	サーバーレス	リクエスト単位	HTTP API・ゼロスケール・イベント駆動
Cloud Functions	サーバーレス	呼び出し回数	Webhook・軽量グルーロジック

D2-02

Compute Engine (GCE)

≈ 30%

セキュアな SSH アクセス管理

✕ アンチパターン：静的 SSH キー

VM のメタデータに SSH 公開鍵を登録。退職した社員の鍵が残り続け、不正アクセスのリスクが継続。鍵の棚卸し作業が膨大。

✓ 推奨：OS Login

IAM ポリシーで SSH アクセスをリアルタイム管理。退職者の IAM ロール削除で即時アクセス無効化。詳細な監査ログが自動記録。

OS Login Access Flow

OSLOGIN

flowchart LR
E["エンジニア<br/>SSH接続試行"] --> OL["OS Login<br/>IAM リアルタイム照会"]
OL -->|ロール有効| VM["VM 接続 OK ✅"]
OL -->|ロール削除済み<br/>退職処理後| NG["接続 NG ❌"]
IAM["IAM ポリシー<br/>ユーザー削除"] -.->|即時反映| OL
style VM fill:#34A853,color:#fff
style NG fill:#EA4335,color:#fff

マシンファミリーの選択基準

ファミリー	シリーズ例	用途	特徴
General Purpose	N2, E2, T2D	汎用 Web・開発環境	コストとパフォーマンスのバランス。E2 が最安
Compute Optimized	C2, C2D	HPC・ゲームサーバー	CPU 性能を最優先
Memory Optimized	M2, M3	SAP HANA・大型 DB	最大 12TB のメモリ
Accelerator Optimized	A2, A3, G2	ML トレーニング・推論	GPU/TPU 搭載

ベストプラクティス

1OS Login + 2FA を本番環境で必須化 — 静的キーの漏洩・管理コストを排除
2外部 IP を持たない VM 構成（Cloud NAT でアウトバウンド） — アタックサーフェスを最小化
3本番 VM への SSH はJIT アクセスで一時的に付与 — 常時権限による被害を防止
4Shielded VM を有効化 — UEFI セキュアブートで VM の完全性を保証

docs.cloud.google.com — OS Login の設定 docs.cloud.google.com — SSH ベストプラクティス

D2-03

Spot VM

≈ 30%

Spot VM vs Preemptible VM

項目	Preemptible VM（旧）	Spot VM（現在推奨）
最大稼働時間	24時間（強制停止）	制限なし
停止通知	30秒前	30秒前
最大割引率	≈80%	≈91%
推奨度	非推奨（レガシー）	✅ 推奨

プリエンプション対応の設計パターン

Preemption Recovery Flow

PREEMPTION

sequenceDiagram
participant G as Google Cloud
participant VM as Spot VM
participant CS as Cloud Storage
participant MIG as Managed Instance Group
G->>VM: プリエンプション通知(30秒前)
VM->>CS: チェックポイントを GCS に保存
VM->>VM: シャットダウンスクリプト実行
G->>VM: 強制停止
MIG->>VM: 新しい Spot VM を自動作成
VM->>CS: チェックポイントを読み込み
VM->>VM: 処理を途中から再開

ベストプラクティス

1MIG（Managed Instance Group）と組み合わせてプリエンプト後に自動再作成
2チェックポイント機能を必ず実装（Cloud Storage に進捗を保存）
3終了アクションはSTOPを基本に（データ保持・キャパシティ回復後に再起動）
4複数ゾーンにわたる MIG を構成してリスクを分散

docs.cloud.google.com — Spot VM の作成と使用 cloud.google.com — Spot VM ベストプラクティス

D2-04

Google Kubernetes Engine (GKE)

最重要

Autopilot vs Standard の使い分け

GKE Mode Selection

GKE-SELECT

flowchart TD
START[GKE クラスタを作成したい] --> PRIV{特権コンテナが必要?}
PRIV -->|Yes| STD
PRIV -->|No| KERN{"カーネルパラメータ<br/>の変更が必要?"}
KERN -->|Yes| STD
KERN -->|No| DS{"DaemonSet が必要<br/>カスタムエージェント配置?"}
DS -->|Yes| STD
DS -->|No| GPU2{"特定 GPU/TPU<br/>ノードプール設定?"}
GPU2 -->|Yes| STD["GKE Standard<br/>ノードを自己管理"]
GPU2 -->|No| AUTO["GKE Autopilot ✅<br/>推奨: Google が全管理"]
style AUTO fill:#0f9d58,color:#fff,stroke:#0f9d58
style STD fill:#fbbc04,color:#000,stroke:#fbbc04

Autopilot vs Standard の詳細比較

項目	Autopilot	Standard
ノード管理	Google が自動管理	ユーザーが管理
セキュリティ標準	Kubernetes Baseline 強制	ユーザー設定
特権コンテナ	不可	可能
Workload Identity	自動有効化	手動設定
DaemonSet	DaemonSet は GKE Autopilot でサポートされるが、リソース要求やセキュリティポリシー等によりカスタム DaemonSet のデプロイは制限され得る（例：⚠️ 制約あり — ポリシー準拠が必要）	可能
課金モデル	Pod リソース単位（アイドルコストなし）	ノード（VM）単位
新規クラスタ推奨	✅ デフォルト推奨	特殊要件のみ

Workload Identity（最重要）

✕ アンチパターン：JSON キーを Secret に保存

サービスアカウントの JSON キーを Kubernetes Secret としてクラスタ内に保存し、Pod からマウントする。キー漏洩リスク・ローテーション管理の煩雑さが問題。

✓ 推奨：Workload Identity

Kubernetes Service Account (KSA) と Google Cloud IAM Service Account (GSA) を紐付け。JSON キー不要。メタデータサーバーから自動的に短期トークンを取得。

Workload Identity Flow

WORKLOAD-IDENTITY

flowchart LR
KSA["Kubernetes<br/>Service Account<br/>KSA"] -->|紐付け| GSA["Google Cloud<br/>IAM Service Account<br/>GSA"]
POD[Pod] -->|KSA を使用| KSA
GSA -->|IAM ロール付与| GCP["GCP API<br/>Secret Manager<br/>Cloud Storage 等"]
style POD fill:#1a73e8,color:#fff,stroke:#1a73e8
style GCP fill:#0f9d58,color:#fff,stroke:#0f9d58

ベストプラクティス

1新規クラスタはAutopilot モードをデフォルトで選択 — 運用負荷ゼロ・セキュリティが自動強化
2GCP API アクセスには必ずWorkload Identity を使用（JSON キー禁止）
3プライベートクラスタ（外部 IP なし）で構築 — ノードへの直接攻撃を遮断
4Binary Authorization を有効化 — 未承認イメージのデプロイを阻止
5Security Posture Dashboard を定期確認 — CVE と設定ミスをプロアクティブに解消

docs.cloud.google.com — GKE Autopilot セキュリティ docs.cloud.google.com — Autopilot vs Standard 比較 oneuptime.com — GKE モード選択ガイド

D2-05

Cloud Run

≈ 30%

第1世代 vs 第2世代実行環境

項目	第1世代	第2世代（推奨）
ネットワーク接続	VPC コネクタ	Direct VPC Egress（高速）
スループット	制限あり	最大 1Gbps（Direct VPC 送出のインスタンスあたり上限。詳細は Google Cloud ドキュメントを参照）
並行処理数	最大 250/インスタンス	最大 1,000/インスタンス
CPU	リクエスト中のみ	常時利用可能

カナリアデプロイ（トラフィック分割）

Canary Deployment Flow

RUN-TRAFFIC

flowchart TD
REQ[ユーザーリクエスト] --> LB["Cloud Run<br/>トラフィック分割"]
LB -->|90%| V1["リビジョン v1<br/>安定版"]
LB -->|10%| V2["リビジョン v2<br/>新バージョン"]
V2 -->|問題なし| PROMO[100% に切り替え]
V2 -->|問題あり| ROLL[v1 に 100% ロールバック]
style PROMO fill:#0f9d58,color:#fff,stroke:#0f9d58
style ROLL fill:#ea4335,color:#fff,stroke:#ea4335

docs.cloud.google.com — Cloud Run ネットワーキングベストプラクティス

D2-06

Cloud Storage

≈ 30%

ストレージクラスの選択基準

クラス	GB 単価	取り出し料金	最小保存期間	アクセス頻度目安
Standard	$0.020	無料	なし	頻繁（日次以上）
Nearline	$0.010	$0.01/GB	30日	月 1 回程度
Coldline	$0.004	$0.02/GB	90日	四半期 1 回程度
Archive	$0.0012	$0.05/GB	365日	年 1 回以下

⚠

試験頻出:最小保存期間より前に削除しても、最小保存期間分の料金が発生します。

Object Lifecycle Management (OLM) の自動化フロー

Object Lifecycle Management

GCS-LIFECYCLE

flowchart LR
UPLOAD["オブジェクト作成<br/>Standard"] -->|30日後| N["Nearline<br/>自動移行"]
N -->|90日後| C["Coldline<br/>自動移行"]
C -->|365日後| A["Archive<br/>自動移行"]
A -->|730日後| DEL[自動削除]
style UPLOAD fill:#1a73e8,color:#fff,stroke:#1a73e8
style DEL fill:#ea4335,color:#fff,stroke:#ea4335

ベストプラクティス

1統一バケットレベルアクセスを有効化 — ACL の複雑さを排除、IAM で一元管理
2OLM を必ず設定してストレージクラスを自動移行 — コスト最適化の自動化
3バケット名に PII・機密情報を含めない — バケット名は URL に公開される
4規制データには保持ポリシー + バケットロックを適用 — コンプライアンス要件

docs.cloud.google.com — Cloud Storage ベストプラクティス

D2-07

データベースサービス選定

頻出

データベース選定フローチャート

Database Selection Decision Tree

DB-SELECT

flowchart TD
START[データの種類は?] --> SQL{"構造化データ<br/>SQLが必要?"}
SQL -->|Yes| SCALE{"グローバル分散<br/>99.999%可用性?"}
SCALE -->|Yes| SPANNER["Cloud Spanner<br/>グローバル分散・水平スケール"]
SCALE -->|No| PERF{"PostgreSQL互換で<br/>4倍の性能が必要?"}
PERF -->|Yes| ALLOY["AlloyDB<br/>PG互換・AI最適化"]
PERF -->|No| CSQL["Cloud SQL<br/>MySQL/PG/SQL Server"]
SQL -->|No| NOSQL{どんな特性?}
NOSQL -->|大規模時系列・IoT| BT["Cloud Bigtable<br/>PB規模・ミリ秒レイテンシ"]
NOSQL -->|リアルタイム同期<br/>モバイル| FS["Firestore<br/>サーバーレス・強整合性"]
NOSQL -->|マイクロ秒キャッシュ| MEM["Memorystore<br/>Redis/Memcached"]
START --> DWH{分析・DWH?}
DWH -->|Yes| BQ["BigQuery<br/>サーバーレス分析エンジン"]
START --> ORACLE{"Oracle を<br/>リフトシフト?"}
ORACLE -->|Yes| BMS[Bare Metal Solution]
style SPANNER fill:#1a73e8,color:#fff,stroke:#1a73e8
style ALLOY fill:#0f9d58,color:#fff,stroke:#0f9d58
style BQ fill:#fbbc04,color:#000,stroke:#fbbc04

データベース完全比較表

サービス	種別	可用性 SLA	水平スケール	主要ユースケース
Cloud SQL	リレーショナル	99.95%	❌	Web アプリ・ERP・EC サイト
Cloud Spanner	リレーショナル	99.999%	✅	グローバル金融・在庫管理
AlloyDB	リレーショナル(PG互換)	99.99%	読取スケール可	高性能 OLTP・分析混在
Firestore	NoSQL（ドキュメント）	99.999%	✅	モバイルアプリ・IoT バックエンド
Cloud Bigtable	NoSQL（ワイドカラム）	99.9%	✅	時系列データ・ML フィーチャーストア
Memorystore	インメモリ	99.9%	Redis Cluster	キャッシュ・セッション・リーダーボード
BigQuery	データウェアハウス	99.9%	✅ 自動	BI・大規模ログ分析・ML

cloud.google.com — GCP データベースオプション解説 dataroots.io — GCP データベース選定ベストプラクティス

D2-08

ネットワーク設計

≈ 30%

Shared VPC アーキテクチャ

Shared VPC Architecture

SHARED-VPC

flowchart TD
HOST["ホストプロジェクト<br/>ネットワーク管理チーム"] --> VPC["VPC ネットワーク<br/>サブネット・ファイアウォール集中管理"]
VPC --> SP1["サービスプロジェクト 1<br/>フロントエンドチーム"]
VPC --> SP2["サービスプロジェクト 2<br/>バックエンドチーム"]
VPC --> SP3["サービスプロジェクト 3<br/>DB チーム"]
SP1 -.->|Network User ロール付与| VPC
SP2 -.->|Network User ロール付与| VPC
SP3 -.->|Network User ロール付与| VPC
style HOST fill:#1a73e8,color:#fff,stroke:#1a73e8

VPC Network Peering の制約

VPC Peering Transitivity Limitation

VPC-PEERING

flowchart LR
A[VPC A] <-->|ピアリング| B[VPC B]
B <-->|ピアリング| C[VPC C]
A -. "直接通信 ❌<br/>(推移的でない)" .-> C
style A fill:#1a73e8,color:#fff,stroke:#1a73e8
style B fill:#0f9d58,color:#fff,stroke:#0f9d58
style C fill:#fbbc04,color:#000,stroke:#fbbc04

⚠

VPC Peering の制約:推移的（Transitive）ではない。A-B-C で Peering しても、A-C 間の通信は不可。また IP アドレスが重複していると Peering 不可。

docs.cloud.google.com — Shared VPC docs.cloud.google.com — VPC 設計ベストプラクティス cloud.google.com — Cloud NAT ベストプラクティス docs.cloud.google.com — Cloud DNS ベストプラクティス

D2-09

ロードバランサ選定

頻出

ロードバランサ選定フローチャート

Load Balancer Selection

LB-SELECT

flowchart TD
START[どんなトラフィック?] --> HTTP{HTTP/HTTPS?}
HTTP -->|Yes| ALB[Application Load Balancer L7]
ALB --> GLOB{グローバル配信?}
GLOB -->|Yes| GALB[Global External ALB Premium Tier 使用]
GLOB -->|No| COMP{"コンプライアンス要件<br/>データ主権?"}
COMP -->|Yes| RALB["Regional ALB<br/>⚠️ 必ずリージョナルを選択"]
COMP -->|No| RALB2[Regional ALB]
HTTP -->|No TCP/UDP 等| NLB[Network Load Balancer L4]
NLB --> SSL{SSL オフロードが必要?}
SSL -->|Yes| PNLB["Proxy Network LB<br/>SSL 終端・送信元 IP 失われる"]
SSL -->|No| PASS["Passthrough Network LB<br/>送信元 IP 保持・DSR"]
style GALB fill:#1a73e8,color:#fff,stroke:#1a73e8
style RALB fill:#ea4335,color:#fff,stroke:#ea4335
style PASS fill:#0f9d58,color:#fff,stroke:#0f9d58

ロードバランサ比較表

ロードバランサ	レイヤ	送信元 IP 保持	SSL オフロード	スコープ
Global External ALB	L7	❌	✅	グローバル
Regional External ALB	L7	❌	✅	リージョン
Proxy Network LB	L4	❌	✅	グローバル/リージョン
Passthrough Network LB	L4	✅	❌	リージョン

⚠

試験頻出:データ主権・コンプライアンス要件がある場合は必ずリージョナルロードバランサを選択！グローバル ALB はエッジで SSL 終端するため海外 PoP で処理される可能性がある。

docs.cloud.google.com — ロードバランサ選定ガイド

D2-10

Infrastructure as Code（Terraform）

≈ 30%

State ファイルの管理

Terraform State Management

TF-STATE

flowchart TD
CODE["Terraform コード<br/>.tf ファイル"] <-->|マッピングを管理| STATE["terraform.tfstate<br/>State ファイル"]
STATE <-->|実際のリソース情報| GCP[GCP リソース]
subgraph 推奨バックエンド
GCS["Cloud Storage バケット<br/>リモートバックエンド"]
GCS -->|バージョニング有効| VER[変更履歴を保存]
GCS -->|State ロック有効| LOCK[並行 apply を防止]
end
STATE -.->|保存| GCS

🚫

絶対禁止:terraform.tfstateを手動で直接編集してはいけません。設定破損・リソースの意図しない削除を招きます。

安全なデプロイフロー

Safe Terraform Deploy Flow

TF-FLOW

flowchart LR
COMMIT["コードを<br/>git commit"] --> PLAN["terraform plan<br/>-out=tfplan"]
PLAN --> REVIEW["変更内容を<br/>レビュー"]
REVIEW --> APPLY["terraform apply<br/>tfplan"]
APPLY --> VERIFY["デプロイ結果<br/>を確認"]
style PLAN fill:#1a73e8,color:#fff,stroke:#1a73e8
style APPLY fill:#0f9d58,color:#fff,stroke:#0f9d58

ベストプラクティス

1State は必ずCloud Storage リモートバックエンドに保存 — 競合・紛失防止
2terraform plan -out=tfplanを必ず実施してからレビュー — 意図しない変更の防止
3CI/CD 認証はWorkload Identity / ADC を使用（JSON キー禁止）
4環境ごとに別ディレクトリ・別 State バケットを使用 — 誤った環境への適用防止
5Terraform ≥ 1.5 ではimport ブロックで既存リソースを管理下へ

docs.cloud.google.com — Terraform ベストプラクティス cloud.google.com — Cloud Foundation Toolkit with Terraform

D3-01

Cloud Monitoring

≈ 27%

Ops Agent のアーキテクチャ

Ops Agent Architecture

OPS-AGENT

flowchart LR
VM[Compute Engine VM] --> OPS[Ops Agent]
OPS --> FB["Fluent Bit<br/>ログ収集エンジン"]
OPS --> OT["OpenTelemetry Collector<br/>メトリクス収集エンジン"]
FB --> LOG[Cloud Logging]
OT --> MON[Cloud Monitoring]
style OPS fill:#1a73e8,color:#fff,stroke:#1a73e8
style LOG fill:#0f9d58,color:#fff,stroke:#0f9d58
style MON fill:#0f9d58,color:#fff,stroke:#0f9d58

エージェントなしで取得できる vs Ops Agent が必要なメトリクス

カテゴリ	メトリクス例	Ops Agent 必要?
CPU 使用率	`compute.googleapis.com/instance/cpu/utilization`	自動取得
ネットワーク I/O	`compute.googleapis.com/instance/network/sent_bytes_count`	自動取得
メモリ使用量	`agent.googleapis.com/memory/percent_used`	✅ 必要
ディスク使用率	`agent.googleapis.com/disk/percent_used`	✅ 必要
アプリケーションログ	nginx / mysql / custom ログ	✅ 必要

⚠

試験頻出: メモリ使用量は Ops Agent がないと取得できません！

SLO（サービスレベル目標）の概念

概念	説明	例
SLI	測定する指標	リクエスト成功率
SLO	目標値	成功率 ≥ 99.9%
SLA	契約上の約束	99.9% を下回ったら返金
エラーバジェット	許容できる失敗量	月間 43.8 分のダウンタイム（99.9% SLO の場合）

docs.cloud.google.com — Ops Agent の概要 cloud.google.com — Managed Service for Prometheus

D3-02

スナップショット管理

≈ 27%

整合性レベルの比較（試験頻出）

種類	取得方法	整合性	アプリ停止	推奨用途
クラッシュ整合性	アプリ停止なしで取得	OS 再起動後の整合性	不要	OS ディスク・ステートレスアプリ
アプリケーション整合性	データをフラッシュしてから取得	完全な整合性	必要	DB（MySQL / PostgreSQL 等）

アプリケーション整合性スナップショットの取得フロー

Application-Consistent Snapshot Flow

APP-CONSISTENT

sequenceDiagram
participant A as アプリ(MySQL)
participant OS as Linux OS
participant GCP as Google Cloud
Note over A: fsfreeze または FLUSH TABLES WITH READ LOCK
OS->>OS: sudo fsfreeze --freeze /data
Note over OS: ファイルシステムを凍結(書き込み停止)
OS->>GCP: gcloud compute disks snapshot
GCP-->>OS: スナップショット取得完了
OS->>OS: sudo fsfreeze --unfreeze /data
Note over OS: ⚠️ 必ずフリーズ解除！忘れると書き込み不可

ベストプラクティス

1本番環境はスナップショットスケジュールで 1 時間ごとに自動取得— RPO を最大 1 時間以内に
2DB は必ずアプリケーション整合性スナップショットを取得
3Linux ではfstrim を事前実行 — スナップショットサイズを削減・高速化
4別リージョンに DR コピー（--storage-locationで指定） — リージョン障害対策

docs.cloud.google.com — スナップショットベストプラクティス

D3-03

Cloud Logging & 監査ログ

最重要

Cloud Logging のデータフロー

Cloud Logging Data Flow

LOGGING-FLOW

flowchart TD
subgraph ログ発生源
GCP_SVC["GCP サービス<br/>GKE / Cloud SQL / Cloud Run / LB"]
VM_OPS["Compute Engine VM<br/>Ops Agent 経由"]
APP["アプリケーション<br/>Cloud Logging API"]
end
subgraph Cloud Logging
INGEST["ログ受信・保存<br/>インデックス作成"]
ROUTER["Log Router<br/>シンク振り分け"]
end
subgraph エクスポート先
BKT["Cloud Logging バケット<br/>デフォルト 30日保持"]
BQ["BigQuery<br/>長期保存・SQL 分析"]
GCS["Cloud Storage<br/>アーカイブ・低コスト"]
PS["Pub/Sub<br/>リアルタイム処理・SIEM 連携"]
end
GCP_SVC --> INGEST
VM_OPS --> INGEST
APP --> INGEST
INGEST --> ROUTER
ROUTER --> BKT
ROUTER --> BQ
ROUTER --> GCS
ROUTER --> PS
style BQ fill:#1a73e8,color:#fff,stroke:#1a73e8
style PS fill:#ea4335,color:#fff,stroke:#ea4335

監査ログの 3 種類（試験最重要）

種別	内容	デフォルト	料金	無効化
管理アクティビティ	リソースの作成・削除・設定変更（IAM 変更等）	✅ 常時有効	無料	❌ 不可
データアクセス	データの読み書き（GCS オブジェクト読み取り等）	❌ 無効	有料	—
システムイベント	Google による自動操作（ライブマイグレーション等）	✅ 常時有効	無料	❌ 不可

⚠

試験頻出:データアクセス監査ログはデフォルトで無効。機密データを扱う API では手動で有効化が必要。

ログバケットの保持期間

ログバケット	デフォルト保持期間	変更可否	備考
`_Required`（必須）	400 日	❌ 変更不可	管理アクティビティ監査ログを含む
`_Default`（デフォルト）	30 日	✅（最大 3650 日）	ほとんどのログ
カスタムバケット	設定値	✅	独自に作成

ベストプラクティス

1管理アクティビティ監査ログを BigQuery にエクスポート— 長期保存・詳細分析・監査証跡
2機密データを扱う API はデータアクセス監査ログを有効化— コンプライアンス対応
3GKE の auditd ログを有効化（COS ノード） — バイナリ実行履歴の追跡
4Cloud Storage の Coldline にアーカイブシンクを設定— 低コストで長期保管

cloud.google.com — Cloud Logging コスト管理ベストプラクティス

D3-04

Gemini Cloud Assist & Cloud Asset Inventory

≈ 27%

Gemini Cloud Assist の機能

🔍

根本原因分析（RCA）

ログ・メトリクス・設定変更を横断的に AI 分析。障害調査の自動化。

📝

IaC テンプレート生成

自然言語から Terraform テンプレートを自動生成。インフラ構築の加速。

💰

コスト最適化提案

FinOps Hub 連携でリソース稼働率を AI 分析、節約案を提示。

🏗

アーキテクチャ図生成

インフラ構成図を自動生成。設計レビューの効率化。

cloud.google.com — Gemini Cloud Assist cloud.google.com — Gemini RCA 機能

D4-01

IAM ロール設計

最重要

ロール選択のフローチャート

IAM Role Selection

ROLE-SELECT

flowchart TD
NEED[権限を付与したい] --> PRED{"事前定義ロールで<br/>要件を満たせるか?"}
PRED -->|Yes| USE["事前定義ロールを使用 ✅"]
PRED -->|No - 過剰権限 or 組み合わせが必要| CUSTOM["カスタムロールを作成<br/>最小限の権限で定義"]
BASIC["基本ロール<br/>Viewer / Editor / Owner"] --> DANGER["⚠️ 本番環境での使用は原則禁止<br/>粒度が粗すぎる"]
style USE fill:#0f9d58,color:#fff,stroke:#0f9d58
style DANGER fill:#ea4335,color:#fff,stroke:#ea4335

主要な事前定義ロール一覧

サービス	ロール	権限概要
Compute Engine	`roles/compute.osLogin`	OS Login での SSH 接続
Compute Engine	`roles/compute.osAdminLogin`	SSH 接続（sudo 権限付き）
Cloud Storage	`roles/storage.objectViewer`	オブジェクトの閲覧のみ
Cloud Run	`roles/run.invoker`	Cloud Run へのリクエスト送信
Cloud Run	`roles/run.developer`	デプロイ・設定変更
IAM	`roles/iam.serviceAccountTokenCreator`	SA の短期トークン生成（権限借用）
IAM	`roles/iam.workloadIdentityUser`	Workload Identity 経由でのアクセス
Secret Manager	`roles/secretmanager.secretAccessor`	シークレット値の読み取り

ベストプラクティス

1基本ロール（Editor/Owner）の本番環境での使用を禁止— 過剰権限によるリスク
2ユーザーではなくグループにロールを付与 — メンバー変更時の管理を自動化
3定期的に Policy Recommender で不要な権限を削除 — クリープ（権限の肥大化）防止
4IAM Conditions で一時的な権限を付与 — 永続権限のリスクを排除

cloud.google.com — IAM ベストプラクティスガイド cloudoptimo.com — IAM ロール階層解説

D4-02

サービスアカウントの安全な管理

≈ 20%

SA キーを使わない認証方法の全体図

Keyless Authentication Patterns

KEYLESS-AUTH

flowchart TD
NEED[GCP API にアクセスしたい] --> WHERE{どこから?}
WHERE -->|GCE / GKE / Cloud Run| META["インスタンスに SA をアタッチ<br/>メタデータサーバーから自動取得 ✅"]
WHERE -->|開発者のローカル PC| ADC["gcloud auth application-default login<br/>ADC を使用 ✅"]
WHERE -->|GitHub Actions / GitLab CI| WIF["Workload Identity Federation<br/>キーレス認証 ✅"]
WHERE -->|AWS / Azure / オンプレ| WIF2["Workload Identity Federation<br/>外部 IdP トークンを交換 ✅"]
WHERE -->|一時的な特権操作| IMP["SA Impersonation<br/>短期トークン・監査ログ付き ✅"]
AVOID["❌ SA JSON キー<br/>ほぼ使うべきシナリオなし"]
style META fill:#0f9d58,color:#fff,stroke:#0f9d58
style ADC fill:#0f9d58,color:#fff,stroke:#0f9d58
style WIF fill:#0f9d58,color:#fff,stroke:#0f9d58
style WIF2 fill:#0f9d58,color:#fff,stroke:#0f9d58
style IMP fill:#0f9d58,color:#fff,stroke:#0f9d58
style AVOID fill:#ea4335,color:#fff,stroke:#ea4335

Workload Identity Federation のフロー

Workload Identity Federation (GitHub Actions)

WIF-FLOW

sequenceDiagram
participant GH as GitHub Actions
participant STS as Google STS<br>Security Token Service
participant SA as IAM Service Account
participant GCP as GCP API
GH->>GH: GitHub OIDC トークンを生成
GH->>STS: OIDC トークンを提示
STS->>STS: トークンを検証
STS-->>GH: 短期 Google アクセストークンを発行
GH->>GCP: アクセストークンで API 呼び出し
Note over GH,GCP: SA の JSON キーをどこにも保存しない！

ベストプラクティス

1SA JSON キーの生成を組織ポリシーで禁止 — 漏洩リスクの根本排除
2CI/CD は Workload Identity Federation を設定 — キー不要・自動失効
3ローカル開発は ADC（gcloud auth application-default login）
4特権操作は SA Impersonation または PAM — 監査ログ + 自動失効
51 SA = 1 アプリケーション / 1 目的 — 最小権限・追跡可能性の確保

cloud.google.com — Workload Identity Federation cloud.google.com — PAM（Privileged Access Manager）

D4-03

Secret Manager & Cloud KMS

≈ 20%

シークレット管理の禁止事項 vs 推奨

✕ 絶対禁止

🚫 コードにハードコード
🚫 環境変数に平文で設定
🚫 Git にコミット

✓ 推奨

✅ Secret Manager に安全に保存
✅ IAM でアクセス制御
✅ 監査ログでアクセス追跡
✅ 自動ローテーション設定

デフォルト暗号化 vs CMEK（Cloud KMS）

項目	Google 管理キー（デフォルト）	CMEK（顧客管理）
設定	自動（設定不要）	手動で設定が必要
コスト	無料	有料（KMS 課金）
キー管理	Google が管理	自分で管理
データへのアクセス遮断	不可	キー削除でアクセスを即時遮断可能
コンプライアンス	標準要件	規制が厳しい業界向け

D4-04

ネットワークセキュリティ

≈ 20%

VM への深層防御（多層セキュリティ）

Defense in Depth for VM Access

VM-SECURITY

flowchart TD
INTERNET[インターネット] --> CA["Layer 1: Cloud Armor<br/>DDoS / WAF 防御"]
CA --> FW["Layer 2: ファイアウォールルール<br/>IAP IP レンジのみ SSH 許可<br/>35.235.240.0/20"]
FW --> IAP["Layer 3: Identity-Aware Proxy<br/>Google アカウント認証・IAM 認可"]
IAP --> OSLOGIN["Layer 4: OS Login + 2FA<br/>IAM ベースの SSH 管理"]
OSLOGIN --> VM["VM<br/>外部 IP なし構成"]
style CA fill:#1a73e8,color:#fff,stroke:#1a73e8
style FW fill:#0f9d58,color:#fff,stroke:#0f9d58
style IAP fill:#fbbc04,color:#000,stroke:#fbbc04
style OSLOGIN fill:#ea4335,color:#fff,stroke:#ea4335
style VM fill:#333,color:#fff,stroke:#555

Cloud Armor のルールタイプ

タイプ	説明	例
WAF ルール	OWASP Top 10 対策（事前設定済み）	`evaluatePreconfiguredExpr('sqli-v33-stable')`
IP ベース	特定 IP をブロック / 許可	既知の悪意ある IP をブロック
地理情報ベース	特定の国からのアクセスを制御	`origin.region_code == 'XX'`
レート制限	1 IP あたりのリクエスト数を制限	100 req/60 秒を超えたら 10 分間 BAN
アダプティブ保護	ML で大規模 DDoS を自動検出	自動でブロックルールを提案

cloud.google.com — Cloud Armor ドキュメント cloud.google.com — Identity-Aware Proxy

D4-05

Security Command Center (SCC)

≈ 20%

SCC が自動検出する設定ミス

カテゴリ	検出内容の例
IAM の問題	プロジェクトオーナーが複数・allUsers への権限付与
ネットワーク設定	0.0.0.0/0 からの SSH/RDP 許可・パブリックアクセス
Cloud Storage	パブリックバケット・暗号化なし
Compute Engine	Shielded VM 無効・OS Login 無効・外部 IP
GKE	認証の弱い設定・特権コンテナ・古いバージョン
Cloud SQL	パブリック IP・SSL 無効・バックアップなし

cloud.google.com — Security Command Center cloud.google.com — Binary Authorization

EXAM

引っかけ問題パターン

必読

以下は ACE 試験で繰り返し問われる「引っかけ問題」パターンです。正しい答えとよくある誤答をセットで覚えてください。

問題

予算上限に達したらリソースはどうなるか?

正しい答え

✅ 通知が来るだけ（停止しない）

よくある誤答

❌ 自動停止される

問題

自動停止を実現するには?

正しい答え

✅ Pub/Sub + Cloud Functions のアーキテクチャが必要

よくある誤答

❌ 予算設定だけで対応できる

問題

メモリ使用量を監視したい

正しい答え

✅ Ops Agent をインストール

よくある誤答

❌ Cloud Monitoring で自動取得できる

問題

VPC A→B, B→C Peering で A→C は通信できるか?

正しい答え

✅ できない（推移的でない）

よくある誤答

❌ 通信できる

問題

データ主権でデータを特定リージョンに限定したい

正しい答え

✅ リージョナル LB を使用（グローバル ALB は不可）

よくある誤答

❌ グローバル ALB を使用

問題

CI/CD から GCP リソースを操作する最も安全な方法

正しい答え

✅ Workload Identity Federation

よくある誤答

❌ SA JSON キーを CI/CD に保存

問題

データアクセス監査ログのデフォルト状態

正しい答え

✅ デフォルトで無効（手動で有効化が必要）

よくある誤答

❌ デフォルトで有効

問題

GKE で GCP API にアクセスするための最善の方法

正しい答え

✅ Workload Identity を使用

よくある誤答

❌ SA JSON キーを Secret にマウント

問題

DB のバックアップで完全な整合性が必要な場合

正しい答え

✅ アプリケーション整合性スナップショット（fsfreeze 後に取得）

よくある誤答

❌ クラッシュ整合性スナップショット

問題

送信元 IP アドレスをバックエンドで確認したい

正しい答え

✅ Passthrough Network LB を選択

よくある誤答

❌ Proxy Network LB（送信元 IP が失われる）

CHECK

試験直前チェックリスト

直前確認

Domain 1（≈ 23%）

IAM ポリシーが上位から下位へ継承され、下位で取り消せないことを理解している
Project ID はグローバルに一意で変更不可だと知っている
予算アラートが上限達成時にリソースを停止しないことを知っている
自動コスト制御には Pub/Sub + Cloud Functions が必要だと知っている
組織ポリシーと IAM の役割の違いを説明できる

Domain 2（≈ 30%）

GKE Autopilot と Standard の使い分けを説明できる
Workload Identity Federation が JSON キーより安全な理由を説明できる
Cloud SQL / Spanner / AlloyDB / Bigtable / Firestore を正しく使い分けられる
VPC Peering が推移的でないことを知っている
コンプライアンス要件がある場合は必ずリージョナル LB を選択することを知っている
Terraform の State ファイルをリモートバックエンドで管理できる

Domain 3（≈ 27%）

メモリ使用量には Ops Agent が必要（デフォルトでは取得不可）を知っている
管理アクティビティ・データアクセス・システムイベントの 3 種類の監査ログを説明できる
データアクセス監査ログはデフォルトで無効（手動で有効化が必要）を知っている
_Required バケットは 400 日保持・変更不可だと知っている
クラッシュ整合性 vs アプリケーション整合性スナップショットの違いを説明できる

Domain 4（≈ 20%）

基本ロール（Editor/Owner）を本番で使うべきでない理由を説明できる
SA JSON キーのリスクと代替手法（ADC / WIF / Impersonation）を説明できる
IAP + OS Login で VM への SSH を多層防御する方法を説明できる
Cloud Armor が DDoS / WAF として ALB を保護することを知っている
Secret Manager でシークレットを安全に管理する方法を知っている

cloud.google.com — ACE 試験公式ページ services.google.com — ACE 試験ガイド PDF cloudskillsboost.google — Google Cloud Skills Boost（ハンズオン）cloud.google.com — Cloud Architecture Center

Associate Cloud Engineer完全試験対策ガイド

学習ロードマップ

リソース階層（Resource Hierarchy）

階層構造の全体像

各レベルの役割と特性

IAM ポリシーの継承メカニズム（最重要）

プロジェクトの識別子

プロジェクトのライフサイクル

ベストプラクティス

組織ポリシー（Organization Policy）

IAM vs 組織ポリシーの違い

主要な制約（Constraints）一覧

請求管理 & コスト制御

予算アラートの自動制御アーキテクチャ

セキュリティインシデントによるコスト急増リスク

ベストプラクティス

gcloud CLI & ADC

ADC（Application Default Credentials）の検索順序

主要コマンド一覧

コンピューティングサービス選定

サービス選定フローチャート

コンピューティングサービス比較

Compute Engine (GCE)

セキュアな SSH アクセス管理

マシンファミリーの選択基準

ベストプラクティス

Spot VM

Spot VM vs Preemptible VM

プリエンプション対応の設計パターン

ベストプラクティス

Google Kubernetes Engine (GKE)

Autopilot vs Standard の使い分け

Autopilot vs Standard の詳細比較

Workload Identity（最重要）

ベストプラクティス

Cloud Run

第1世代 vs 第2世代 実行環境

カナリアデプロイ（トラフィック分割）

Cloud Storage

ストレージクラスの選択基準

Object Lifecycle Management (OLM) の自動化フロー

ベストプラクティス

データベースサービス選定

データベース選定フローチャート

データベース完全比較表

ネットワーク設計

Shared VPC アーキテクチャ

VPC Network Peering の制約

ロードバランサ選定

ロードバランサ選定フローチャート

ロードバランサ比較表

Infrastructure as Code（Terraform）

State ファイルの管理

安全なデプロイフロー

ベストプラクティス

Cloud Monitoring

Ops Agent のアーキテクチャ

エージェントなしで取得できる vs Ops Agent が必要なメトリクス

SLO（サービスレベル目標）の概念

スナップショット管理

整合性レベルの比較（試験頻出）

アプリケーション整合性スナップショットの取得フロー

ベストプラクティス

Cloud Logging & 監査ログ

Cloud Logging のデータフロー

監査ログの 3 種類（試験最重要）

ログバケットの保持期間

ベストプラクティス

Gemini Cloud Assist & Cloud Asset Inventory

Gemini Cloud Assist の機能

根本原因分析（RCA）

IaC テンプレート生成

コスト最適化提案

アーキテクチャ図生成

IAM ロール設計

ロール選択のフローチャート

主要な事前定義ロール一覧

ベストプラクティス

サービスアカウントの安全な管理

SA キーを使わない認証方法の全体図

Associate Cloud Engineer
完全試験対策ガイド

第1世代 vs 第2世代実行環境