Associate Cloud Engineer (ACE) 重要ポイント全まとめ【全5セクション対応・試験直前チェックリスト付き】

Last updated at 2026-06-01Posted at 2026-06-01

この記事でわかること

シラバス全5セクションの重要ポイントを網羅した解説
試験で問われる「サービスの使い分け」「シナリオ問題の考え方」の整理
各セクションの出題比率と優先度
試験直前30分の確認チェックリスト

この記事の使い方

この記事は、Associate Cloud Engineer（以降 ACE）試験の全体像の把握や、試験直前の最終チェックにご利用いただくことを想定しております。本記事と併せて、公式ドキュメントや模擬試験での学習をしていただくことを強く推奨いたします。

試験の基本情報

試験形式

項目	内容
問題数	50問（多肢選択式・複数選択式）
試験時間	2時間
受験料	$125 USD（税別）
受験方法	オンライン（遠隔監視）または認定テストセンター
推奨経験	Google Cloud での実務経験6ヶ月以上
有効期限	3年

ACEの立ち位置と特徴

CDL・Gen AI Leaderが「ビジネス向け知識確認」であるのに対し、ACEは実際にGCPを操作・設定できるかを問う実技寄りの試験です。

試験の特徴として以下が挙げられます：

シナリオベースの問題が多い：「〇〇という要件がある。最適な構成はどれか」という形式
「最もシンプルな正解」を選ぶ問題が多い：オーバースペックな選択肢を排除する判断力が問われる
GCPの哲学への理解が問われる：最小権限・フルマネージドサービス優先・責任共有モデルの理解が前提

セクション別出題比率

セクション	テーマ	出題比率
Section 1	クラウドソリューション環境のセットアップ	約20%
Section 2	クラウドソリューションの計画と設定	約17.5%
Section 3	クラウドソリューションのデプロイと実装	約25%
Section 4	クラウドソリューションの運用管理	約20%
Section 5	アクセスとセキュリティの設定	約17.5%

Section 1：クラウドソリューション環境のセットアップ（約20%）

Section 1はリソース階層・IAM基礎・課金設定を問うセクションです。GCP全体の「土台」となる知識が問われます。

1-1. リソース階層と組織ポリシー

組織（Organization）
  └─ フォルダ（Folder）
       └─ プロジェクト（Project）
            └─ リソース（Resource）

IAMポリシーは上位から下位に継承されます。上位で付与したロールは配下のすべてのリソースに適用されます。

組織ポリシーとIAMの違い

種類	制御対象	例
IAM	「誰が」何をできるか（アクセス制御）	ユーザーAにCloud Storageの閲覧権限を付与
組織ポリシー	リソースの「動作・設定」を制限	全VMにOS Loginを必須化、外部IPの付与を禁止

ここが出る：組織ポリシーはIAMより強制力が高い。IAMでOwnerロールを持っていても、組織ポリシーで禁止された操作は実行できない。

紛らわしいポイント：フォルダとプロジェクトの使い分け

フォルダ：部門・環境（本番/開発）単位でまとめる論理グループ。課金の管理単位ではない
プロジェクト：課金・APIの管理単位。リソースはすべてプロジェクトに属する

1-2. APIの有効化

GCPサービスを使用する前に、プロジェクトごとに対応するAPIを有効化する必要があります。APIを有効化していないサービスは利用できません。

1-3. 課金の設定

概念	内容
課金アカウント	支払い管理の単位。1つの課金アカウントを複数プロジェクトにリンクできる
予算とアラート	指定金額を超えたらメール通知（自動停止はしない）
課金エクスポート	使用データをBigQueryにエクスポートして詳細分析が可能

ここが出る：予算アラートは通知のみで、自動的にリソースを停止する機能ではない。自動停止が必要な場合はPub/SubとCloud Functionsを組み合わせる必要がある。

Section 2：クラウドソリューションの計画と設定（約17.5%）

Section 2は「どのサービスを選ぶか」の判断力を問うセクションです。各サービスの特性と選択基準の理解が重要です。

2-1. コンピュートリソースの選択

サービス	インフラ管理	スケール	選ぶ場面
Compute Engine	OS・ミドルウェアも自分で管理	手動（MIGで自動化可）	既存VMのリフト&シフト・フルコントロールが必要
GKE	コンテナのオーケストレーション	設定次第	マイクロサービス・コンテナ化されたアプリ
Cloud Run	管理不要（サーバーレス）	自動（ゼロスケール含む）	HTTPリクエスト駆動のコンテナ
App Engine	管理不要（PaaS）	自動	インフラを意識せずWebアプリを動かしたい
Cloud Functions	管理不要（FaaS）	自動	イベント駆動の軽量処理

VMの購入オプション

オプション	特徴	向いているワークロード
オンデマンド	通常料金。いつでも起動・停止可	一般的な用途
Spot VM（旧プリエンプティブル）	最大91%安価。24時間以内に停止される可能性あり	バッチ処理・ML学習など中断可能な処理
Committed Use Discounts（CUD）	1年/3年のコミットで最大70%割引	使用量が予測可能な安定ワークロード

ここが出る：Spot VMを選ぶシナリオ
「コストを最小化したい。処理が中断されても再実行できる」→ Spot VMが正解。「中断できない重要な処理」には使えない。

2-2. データストレージオプションの選択

データベース選択

サービス	種別	選ぶ場面
Cloud SQL	リレーショナル（マネージド）	既存RDB（MySQL/PostgreSQL）のリフト&シフト
Cloud Spanner	リレーショナル（グローバル分散）	グローバルスケール＋強整合性が必要
Firestore	NoSQL（ドキュメント）	モバイル・Webアプリのリアルタイムデータ
Bigtable	NoSQL（超大規模）	IoT・時系列データ・大規模低レイテンシ処理
BigQuery	データウェアハウス	大規模なデータ分析・SQL
AlloyDB	PostgreSQL互換（高性能）	高負荷な分析混在ワークロード

Cloud Storageクラス選択

クラス	最低保存期間	用途
Standard	なし	頻繁にアクセスするデータ
Nearline	30日	月1回程度のバックアップ
Coldline	90日	四半期に1回程度の災害対策
Archive	365日	年1回以下の長期アーカイブ

紛らわしいポイント：ストレージクラス変更のコスト
Standard → Archive に変更するとストレージコストは下がるが、取り出し時に高額のデータ取得料金が発生する。アクセス頻度の見積もりが重要。

2-3. ネットワークリソースの計画

ロードバランサーの種別

種別	プロトコル	スコープ	用途
Application LB（HTTP(S)）	HTTP/HTTPS（L7）	グローバル or リージョナル	Webアプリの負荷分散・URLルーティング
Network LB（外部）	TCP/UDP（L4）	リージョナル	TCP/UDPトラフィックの負荷分散
Internal LB	TCP/UDP or HTTP(S)	リージョナル	VPC内部トラフィックの負荷分散

Network Service Tiers

ティア	経路	用途
Premium（デフォルト）	Googleのグローバルネットワーク	低レイテンシ・高品質が必要
Standard	インターネット経由	コスト重視・レイテンシ許容

Section 3：クラウドソリューションのデプロイと実装（約25%）

最も出題比率が高いセクションです。「どのサービス・どの構成を選ぶか」というシナリオ形式の問題が中心です。

3-1. Compute Engineリソースのデプロイ

マネージドインスタンスグループ（MIG）
インスタンステンプレートをもとに同一構成のVMを複数起動し、ヘルスチェック・オートスケール・ローリングアップデートを自動化する仕組みです。

ここが出る：MIGのシナリオ
「急激なトラフィック増加に対応できるよう、自動でVMを増減させたい」→ MIG＋オートスケーラーが正解。単独VMはスケールしない。

OS Login
VMへのSSHアクセスをIAMで管理する仕組みです。メタデータのSSHキーを直接管理する方法と比べて、IAMによるアクセス制御と監査ログが得られます。

紛らわしいポイント：スナップショット vs カスタムイメージ

スナップショット：特定時点のディスクバックアップ。増分保存でコスト効率が良い。障害時の復元用
カスタムイメージ：同じ構成のVMを量産するためのテンプレート。MIGのインスタンステンプレートにも使える

3-2. GKEリソースのデプロイ

GKEクラスタの設定は3つの独立した軸で決まります。それぞれ異なる観点の選択であり、組み合わせが可能です（例：Autopilot＋Regional＋Private）。

① ノード管理モード（誰がノードを管理するか）

モード	管理者	課金単位	選ぶ場面
Autopilot	Googleが完全管理	Pod単位	インフラ管理を省きたい
Standard	自分で管理	ノード単位	カスタム設定・GPUノードが必要

② クラスタのトポロジ（何ゾーンに配置するか）

トポロジ	コントロールプレーン	耐障害性	選ぶ場面
Zonal	単一ゾーン	ゾーン障害でクラスタ全体が停止	開発・検証環境
Regional	複数ゾーンに分散	ゾーン障害でも継続稼働	本番環境

③ ネットワーク設定（ノードの外部公開可否）

設定	ノードの外部IP	アクセス元	選ぶ場面
Public cluster	あり	インターネットからアクセス可	一般的な用途
Private cluster	なし	VPC内部からのみアクセス可	セキュリティ要件が厳しい環境

ここが出る：本番環境での推奨構成
高可用性とセキュリティが求められる本番環境では Regional＋Private cluster が推奨。ノード管理モード（Autopilot/Standard）は要件に応じて選択する。

3-3. Cloud Run / Cloud Functionsのデプロイ

観点	Cloud Run	Cloud Functions
デプロイ形式	コンテナイメージ	コードのみ
実行時間	長時間実行に対応	短時間の処理向け
依存関係	複雑な依存関係に対応	シンプルな処理向け
Pub/Subトリガー	Eventarc経由で対応	ネイティブ対応

3-4. データソリューションのデプロイ

データのロード方法の使い分け

方法	使う場面
コンソール / CLIの手動アップロード	少量ファイルの一度限りの転送
BigQueryへのバッチロード	Cloud StorageからBigQueryへの定期的なデータロード
Storage Transfer Service	大量データの定期的な転送（オンプレミス・他クラウドから）
Dataflow	リアルタイムETLパイプライン

ここが出る：Storage Transfer Service vs 手動転送
「毎日深夜にオンプレミスのデータをCloud Storageに転送したい」→ Storage Transfer Serviceが正解。手動や単純なCLIでは対応できない。

3-5. ネットワークリソースのデプロイ

VPCの種類

種類	概要
デフォルトVPC	プロジェクト作成時に自動生成される。本番環境では削除して再構成が推奨
カスタムモードVPC	サブネットを自分で定義する。本番環境での推奨構成
自動モードVPC	全リージョンにサブネットが自動生成される。テスト向け

ファイアウォールルールの重要概念

設定項目	内容
Ingress / Egress	受信（Ingress）/ 送信（Egress）のトラフィックを制御
ターゲットタグ	特定のネットワークタグが付いたVMにのみルールを適用
サービスアカウント指定	特定のSAを持つVMにのみルールを適用（タグより安全）
優先度	数値が低いほど優先（デフォルト1000）。一致した最初のルールが適用される

紛らわしいポイント：Shared VPC vs VPC Network Peering

Shared VPC：ホストプロジェクトのVPCを複数のサービスプロジェクトで共有。ネットワーク管理を一元化
VPC Network Peering：別々のVPC同士をプライベート接続。推移的ピアリングは不可（A-B-Cの場合AとCは通信不可）

3-6. Infrastructure as Code（IaC）

ツール	概要
Terraform	HashiCorpのオープンソースIaC。GCPのProviderで幅広いリソースを管理
Cloud Foundation Toolkit	GoogleのTerraformモジュール集。ベストプラクティスが組み込み済み
Config Connector	KubernetesのカスタムリソースでGCPリソースを管理
Helm	Kubernetesのパッケージマネージャー

Section 4：クラウドソリューションの運用管理（約20%）

Section 4は稼働中のリソースの管理・監視・トラブルシュートを問うセクションです。

4-1. Compute Engineリソースの管理

スナップショットとイメージの管理

スナップショットはスケジュール設定による自動取得が可能
スナップショットから別のディスクを作成して復元する
カスタムイメージはリージョン間でコピー可能

VM Manager
OSパッチの適用・インベントリ管理・設定管理をフリートレベルで自動化するサービスです。

4-2. GKEリソースの管理

ノードプール
クラスタ内で異なるマシンタイプ・設定のVMグループを管理する仕組みです。GPUノードや高メモリノードを特定のワークロード向けに追加できます。

GKEのオートスケール

種類	スケール対象	概要
HPA（Horizontal Pod Autoscaler）	Pod数	CPU使用率などに応じてPod数を増減
VPA（Vertical Pod Autoscaler）	PodのCPU・メモリ	リソース要求量を自動調整
Cluster Autoscaler	ノード数	Podが入りきらない場合にノードを追加・不要になったら削除

4-3. Cloud Runの管理

概念	内容
リビジョン	デプロイのたびに新しいリビジョンが作成される
トラフィック分割	複数リビジョンにトラフィックを割合で振り分けられる（カナリアリリースに活用）
最小インスタンス数	ゼロスケールを無効化し、常時起動しておく設定（コールドスタート防止）
最大インスタンス数	スケールアウトの上限を設定してコスト制御

4-4. ストレージ・データベースの管理

Cloud Storageライフサイクル管理
バケットにルールを設定することで、一定期間後に自動でストレージクラスを変更したりオブジェクトを削除したりできます。コスト最適化に有効です。

Cloud SQLの可用性構成

構成	概要	用途
リードレプリカ	読み取り専用のレプリカ。読み取り負荷の分散	読み取りが多いワークロード
高可用性（HA）構成	同一リージョン内にスタンバイを用意。障害時に自動フェイルオーバー	本番環境・ダウンタイム許容なし

紛らわしいポイント：リードレプリカ vs HA構成

リードレプリカ：マスター障害時に自動でマスターには切り替わらない（手動昇格が必要）
HA構成：マスター障害時に自動でスタンバイに切り替わる

4-5. ネットワークリソースの管理

Cloud NAT
外部IPを持たないプライベートVMがインターネットへアウトバウンド通信するためのNATゲートウェイ。インバウンド接続は許可しません。

静的IPアドレス
VMを停止・再作成しても同じIPアドレスを維持したい場合に予約します。エフェメラル（一時的）IPはVM停止で解放されます。

4-6. モニタリングとロギング

サービス	役割
Cloud Monitoring	メトリクス収集・ダッシュボード・アラートポリシー設定
Cloud Logging	ログの収集・保存・検索・エクスポート
Ops Agent	VMにインストールしてシステムメトリクス・ログをCloud Monitoringに送信
Managed Service for Prometheus	GKE上のPrometheusメトリクスをCloud Monitoringで一元管理

ログエクスポート先の使い分け

エクスポート先	用途
BigQuery	大規模なログ分析・SQLで検索したい
Cloud Storage	長期アーカイブ・コストを抑えたい
Pub/Sub	リアルタイムにSIEMや外部システムへ転送したい

監査ログ

種別	デフォルト	保存期間	コスト
Admin Activity	常時有効・無効化不可	400日	無料
Data Access	無効（BigQueryのみ有効）	30日	有料
System Event	常時有効・無効化不可	400日	無料
Policy Denied	常時有効・無効化不可	30日	有料

Section 5：アクセスとセキュリティの設定（約17.5%）

Section 5はIAM・サービスアカウントの知識を問うセクションです。最小権限の原則を常に意識することが重要です。

5-1. IAM管理

IAMロールの種類

種類	概要	試験での扱い
基本ロール（Owner/Editor/Viewer）	権限が広すぎる	問題の誤りの選択肢として登場することが多い
事前定義ロール	サービス別の細かいロール	最小権限の原則に沿った正解の選択肢
カスタムロール	必要な権限のみ組み合わせ	より厳密な最小権限が必要な場合の正解

ここが出る：IAMシナリオ問題の解き方
「〇〇さんにCloud Storageの読み取りのみを許可したい」→ roles/storage.objectViewer（事前定義ロール）が正解。roles/editorやroles/ownerを選んだら誤り。

紛らわしいポイント：個人 vs グループへのロール付与
個人ユーザーに直接ロールを付与するより、グループにロールを付与してユーザーをグループに追加する方が管理しやすい。GCPのベストプラクティスでもある。

5-2. サービスアカウントの管理

サービスアカウント（SA）はアプリケーション・VM・GKE Podなどが使用するアイデンティティです。

サービスアカウントキーの代替手段

サービスアカウントキー（JSONファイル）は漏洩リスクが高く、できる限り使わない設計を選ぶことが重要です。

ユースケース	推奨手段
GKE上のワークロード	Workload Identity Federation for GKE
GCP外部（GitHub Actions・AWS等）	Workload Identity Federation
GCP内リソース間の通信	SAをリソースに直接アタッチ

ここが出る：サービスアカウントキーに関するシナリオ
「GitHub ActionsからGCPリソースにアクセスしたい。SAキーを使わない方法は？」→ Workload Identity Federationが正解。

サービスアカウントのImpersonation（権限借用）
あるSAが別のSAの権限を一時的に借用できる仕組みです。roles/iam.serviceAccountTokenCreatorロールが必要です。短期的な認証情報を発行するため、長期キーより安全です。

試験直前30分チェックリスト

Section 1（約20%）確認項目

組織→フォルダ→プロジェクト→リソースの階層とIAM継承を説明できる
組織ポリシーとIAMの違い（設定制限 vs アクセス制御）を説明できる
課金アカウントは複数プロジェクトにリンクできることを覚えている
予算アラートは自動停止ではなく通知のみと覚えている

Section 2（約17.5%）確認項目

Spot VMを選ぶシナリオ（中断可能なバッチ処理・コスト最小化）を言える
CUD（確約利用割引）が向いているワークロードを説明できる
Cloud SQLとCloud Spannerの使い分けを言える
Cloud Storageの4クラスと最低保存期間を言える
ロードバランサーの種別（Application/Network/Internal）の使い分けを言える

Section 3（約25%）確認項目

MIG＋オートスケーラーでCompute Engineのオートスケールが実現できることを説明できる
スナップショット（バックアップ用）とカスタムイメージ（VM量産用）の違いを言える
GKEのクラスタタイプ（Autopilot / Standard / Regional / Private）の使い分けを言える
ZonalクラスタとRegionalクラスタの可用性の違いを説明できる
HPA / VPA / Cluster Autoscalerの違いを言える
Cloud RunとCloud Functionsの使い分けを言える
Storage Transfer Serviceの用途（大量・定期的な外部データ転送）を言える
Shared VPC vs VPC Network Peeringの違いを言える
ファイアウォールルールのIngress/Egress・ターゲットタグ・優先度を説明できる

Section 4（約20%）確認項目

Cloud Runのトラフィック分割（カナリアリリース）の概念を説明できる
Cloud Storageのライフサイクル管理ポリシーの目的を説明できる
Cloud SQLのリードレプリカ（読み取り負荷分散）とHA構成（自動フェイルオーバー）の違いを言える
Cloud NATの用途（プライベートVMのアウトバウンド通信専用）を説明できる
Admin Activityログ（常時有効・無料・400日）とData Accessログ（無効・有料・30日）の違いを覚えている
Ops Agentの役割（VMメトリクス・ログのCloud Monitoring送信）を説明できる

Section 5（約17.5%）確認項目

基本ロール（Owner/Editor/Viewer）を本番で使わない理由を言える
グループにロールを付与するベストプラクティスの理由を説明できる
サービスアカウントキーの代替手段（Workload Identity Federation）を知っている
SAのImpersonationの目的と必要なロールを説明できる

最後に

この記事は2026年5月時点の公式試験ガイドに基づいて作成しています。Google Cloudのサービスは継続的に更新されるため、受験前に必ず公式の試験ガイドで最新情報を確認してください。

試験に向けて、残りの準備を全力で応援しています。

関連記事

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up