インフラエンジニアの羅針盤

インフラエンジニア1〜3年目のための技術ガイド

Google Cloud Assosiate Cloud Engineer　第8章　試験直前対策と当日の戦い方

公開更新

Google Cloud Assosiate Cloud Engineer
第8章　試験直前対策と当日の戦い方

目次
  1. 8.1　絶対に見直すサービス一覧
    1. 8.1.1 アイデンティティ & プロジェクト周り
    2. 8.1.2 Compute 系：必須 4 本柱
    3. 8.1.3 ストレージ / データベース / メッセージング
    4. 8.1.4 ネットワーク & ロードバランシング
    5. 8.1.5 監視・ロギング・課金・運用
    6. 8.1.6 IaC / CI/CD と補足サービス
    7. 8.1.7 直前チェック用ミニリスト
  2. 8.2　受験者が間違えやすい論点まとめ
    1. 8.2.1 サービス選択での典型的な誤答パターン
    2. 8.2.2 IAM・サービスアカウント周りの誤答パターン
    3. 8.2.3 ネットワークで混乱しやすい論点
    4. 8.2.4 Cloud Storage でのよくある誤答
    5. 8.2.5 サーバーレス選択の誤答パターン
    6. 8.2.6 運用・監視・セキュリティの見落としパターン
    7. 8.2.7 本番で誤答しないためのチェックリスト
  3. 8.3　当日の判断基準
    1. 8.3.1 まず最初に思い出すべき 4 つの軸
    2. 8.3.2 権限まわりの判断基準（最小権限）
    3. 8.3.3 運用容易性の判断基準
    4. 8.3.4 耐障害性・可用性の判断基準
    5. 8.3.5 コストとスケーラビリティの判断基準
    6. 8.3.6 典型シナリオにおける「優先順位」の決め方
    7. 8.3.7 本番で迷ったときの「5 ステップ」

8.1　絶対に見直すサービス一覧

試験直前に「全部やる」のは現実的ではありません。
ここでは、ACE 試験ガイドに明示されているプロダクトの中から、本番前に必ず確認しておきたいものを、講師視点で絞り込んで整理します。

ポイント：

  • 「サービス名を知っている」ではなく、「何を設定できると合格ラインか」という観点でチェックすること

8.1.1 アイデンティティ & プロジェクト周り

Cloud Identity / IAM / リソース階層

試験ガイド対応：セクション 1 / セクション 5（IAM・SA）

最低限、次を説明できるようにします。

  • リソース階層
    • 組織 > フォルダ > プロジェクト > リソース
    • どこにポリシー（IAM / 組織ポリシー）を設定すると、どこまで継承されるか
  • IAM ロール
    • 基本ロール / 事前定義ロール / カスタムロールの違い
    • 最小権限の原則でロールを選ぶ考え方
  • サービス アカウント
    • SA の作成・リソースへの割り当て
    • 「SA 自身の IAM」と「SA に付与されたロール」の違い
    • 権限借用（impersonation）、短期認証情報の意味（長期キーを避けるという文脈）
  • Cloud Identity / ユーザー管理
    • ユーザー・グループを Cloud Identity で管理すること
    • グループにロールを付与して運用する典型パターン

8.1.2 Compute 系：必須 4 本柱

試験ガイド：Compute Engine / GKE / Cloud Run / Cloud Functions が明示されています。

Compute Engine

本番前チェック：

  • インスタンス作成時の主要項目
    • マシンタイプ、ディスク種別（標準 / SSD）、可用性ポリシー（自動再起動 / プリエンプティブ）、SSH 方式（OS Login 含む）
  • マネージド インスタンス グループ（MIG）
    • インスタンステンプレート → MIG 作成 → オートスケーリング・オートヒーリング設定
  • スナップショット / イメージ
    • スナップショットからの復元、イメージ作成と再利用の違い

Google Kubernetes Engine（GKE）

本番前チェック（ACE レベルの「最小セット」）：

  • クラスタ種別
    • Autopilot / Standard、リージョン / ゾーンクラスタの違い
  • 基本リソース
    • ノードプール / Pod / Service / Ingress の役割
  • 接続とデプロイ
    • gcloud からクラスタ作成、kubectl でマニフェスト適用

Cloud Run

本番前チェック：

  • コンテナベースであること（任意言語可）
  • リクエスト駆動 / 自動スケーリング / スケール・トゥ・ゼロの挙動
  • デプロイ時の主要パラメータ
    • 同時リクエスト数（コンカレンシー）、最小 / 最大インスタンス数、メモリ/CPU

Cloud Functions

本番前チェック：

  • イベントドリブン（Pub/Sub / Cloud Storage 変更 / Audit Logs など）であること
  • 1 関数単位のデプロイ・権限制御
  • HTTP トリガーとイベントトリガーの違い

8.1.3 ストレージ / データベース / メッセージング

試験ガイド：Cloud SQL / BigQuery / Firestore / Spanner / Bigtable / Cloud Storage / Pub/Sub / Dataflow 等が列挙されています。

Cloud Storage

本番前チェック：

  • ストレージクラスと最低保存期間
    • Standard / Nearline / Coldline / Archive の用途と 30 / 90 / 365 日などの最低保存期間
  • バケットレベル IAM とオブジェクトライフサイクル
    • オブジェクトのライフサイクル管理（クラス変更 / 削除）
  • 権限まわり
    • Storage Object Viewer / Creator / Admin の違い（書ける・消せる範囲）

Cloud SQL / BigQuery / Firestore / Spanner / Bigtable（概要レベル）

本番前チェック（「どれを選ぶか」の判断軸）：

  • Cloud SQL
    • マネージド RDB（MySQL / PostgreSQL / SQL Server）
  • BigQuery
    • DWH / 分析クエリ向け、ストレージとクエリ課金のイメージ
  • Firestore
    • ドキュメント指向（NoSQL）、モバイル / Web バックエンド向け
  • Spanner
    • グローバル分散 / 水平スケールする RDB
  • Bigtable
    • 大規模時系列 / キー値データ向け

ACE では、「どのワークロードにどれを選ぶか」レベル が主眼です。

Pub/Sub / Dataflow（名前と用途）

  • Pub/Sub
    • 非同期メッセージング / 疎結合なマイクロサービス連携
  • Dataflow
    • ストリーム / バッチ両対応のデータ処理（必要なのは名前と役割レベル）

8.1.4 ネットワーク & ロードバランシング

試験ガイド：VPC / サブネット / ファイアウォール / VPN / VPC ピアリング / Cloud NAT / Cloud DNS / ロードバランシング 等。

VPC / サブネット / ルート / ファイアウォール

本番前チェック：

  • VPC の種類
    • 自動モード / カスタムモード
    • 共有 VPC のイメージ（ホストプロジェクト / サービスプロジェクト）
  • ファイアウォールルール
    • INGRESS / EGRESS、優先度、ターゲット（タグ / SA）、ソース / 宛先の指定
  • サブネット拡張（IP 範囲の拡大）

Cloud VPN / VPC ネットワーク ピアリング

本番前チェック：

  • Cloud VPN
    • オンプレと VPC を IPsec トンネルで接続する
  • VPC ピアリング
    • プライベート IP で VPC 間を相互接続（トランジット不可などの制約も含む）

Cloud NAT / Private Google Access / Cloud DNS

  • Cloud NAT
    • 外部 IP を持たない VM からインターネットへ出るための NAT サービス
  • Private Google Access
    • 外部 IP を持たない VM から Google APIs（Cloud Storage 等）へアクセスする設定
  • Cloud DNS
    • 管理型 DNS サービス（内部 / 外部ゾーンのイメージ）

Cloud Load Balancing

本番前チェック（サービス名より「どの種類を選ぶか」）：

  • Application Load Balancer（HTTP(S) / L7）
  • Network Load Balancer / TCP Proxy / UDP LB（L4）
  • 外部向け / 内部向け（external / internal）の違い
  • MIG と組み合わせてゾーン障害・スケールに対応する 典型構成

8.1.5 監視・ロギング・課金・運用

試験ガイド：Cloud Monitoring / Cloud Logging / 課金・予算 / 割り当て・クォータ。

Cloud Monitoring

本番前チェック：

  • 指標に基づくアラートポリシー作成
    • VM CPU / メモリ、LB の指標などを使ったアラート
  • ダッシュボード
    • プリセットダッシュボードとカスタムダッシュボードの使い分け

Cloud Logging

本番前チェック：

  • ログビューアでのフィルタ（リソース種別・ログ名・テキスト検索）
  • ログルーター / シンク
    • BigQuery / Cloud Storage / Pub/Sub へのエクスポート
  • 監査ログ（Admin / Data Access / System / Policy）の概要

課金・クォータ

  • 課金アカウントとプロジェクトのリンク
  • 予算とアラートの設定
  • 課金データのエクスポート（BigQuery / CSV）
  • 割り当て（quota）の確認と増加リクエストの流れ

8.1.6 IaC / CI/CD と補足サービス

試験ガイド：Infra as Code / Cloud Build 相当のツール / Artifact Registry など。

Infrastructure as Code（IaC）

本番前チェック（名前レベルで十分）：

  • Terraform
  • Config Connector / Cloud Foundation Toolkit / Helm（「Google が推奨する IaC ツール群」として）

「GUI でポチポチ」ではなく、宣言的に構成を書く文化があることを理解しておきます。

コンテナまわり

  • Artifact Registry
    • コンテナイメージやアーティファクトのリポジトリとして利用
  • GKE / Cloud Run からの利用イメージ

8.1.7 直前チェック用ミニリスト

最後に、「試験前日に必ず眺める」レベルまで圧縮したサービスリストです。
これらの名前を見て、「何に使うか」「どのような構成で出てきたか」を 1 行で説明できるかを確認してください。

  • IAM / Cloud Identity / リソース階層 / 組織ポリシー
  • サービス アカウント（権限 / 割り当て / 権限借用）
  • Compute Engine / MIG（Zonal / Regional）
  • GKE（Autopilot / Standard の違い）
  • Cloud Run / Cloud Functions
  • Cloud Storage（クラス・ライフサイクル・IAM）
  • Cloud SQL / BigQuery / Firestore / Spanner / Bigtable（用途の違い）
  • Pub/Sub / Dataflow（役割レベル）
  • VPC / サブネット / ルート / ファイアウォール
  • Cloud VPN / VPC ピアリング / Cloud NAT / Private Google Access / Cloud DNS
  • Cloud Load Balancing（L7 / L4、外部 / 内部）
  • Cloud Monitoring / Cloud Logging（アラート・シンク・監査ログ）
  • 課金アカウント / 予算 / クォータ
  • IaC（Terraform など）

ここに挙げたサービスが、公式試験ガイドに沿って ACE 試験で直接・間接に問われる領域です。

細部を増やすより、「この一覧の各サービスについて、1〜2 行で用途と代表的な構成を説明できるか」を基準に最終確認を行うことが、本番直前の見直しとしては最も効率的です。

8.2　受験者が間違えやすい論点まとめ

この節では、「知識ゼロで解けない問題」ではなく、「ある程度知っているのに間違える問題」を整理します。
ACE 本試験は、暗記よりも判断のクセを見ています。公式ドキュメントと試験ガイドの出題範囲を踏まえると、誤答はだいたい以下のパターンに収束します。

8.2.1 サービス選択での典型的な誤答パターン

パターン1：とりあえず Compute Engine を選ぶ

誤った思考

  • 「とりあえず VM にしておけば何でもできる」
  • 「Kubernetes やサーバーレスは難しそうだから、VM を選んでおく」

正しい考え方

ACE の試験ガイドでは、「ワークロードに応じた適切なコンピュート選択」が明示的に問われます。
最低限、次の軸で即答できるようにしておきます。

  • Cloud Run
    • コンテナを HTTP リクエスト／イベントで実行するフルマネージドなサーバーレス
    • ステートレスコンテナ、自動スケール、スケール to 0、インフラ非管理
  • App Engine（Standard）
    • 特定ランタイム向けの PaaS。アプリケーションのデプロイとスケールをほぼ自動化
    • スパイクの大きい Web アプリ、ゼロスケールでの低コスト運用に向く
  • Cloud Functions / Cloud Run functions
    • イベント駆動の関数実行（Pub/Sub、Storage 変更など）に最適な FaaS モデル
    • 近年は「Cloud Run functions」として Cloud Run 上の関数として提供
  • GKE
    • コンテナオーケストレーションが必要な場合（複数サービス、複雑なデプロイ戦略など）

試験での見抜き方

  • 「イベント駆動」「Storage へのアップロードをトリガー」「Pub/Sub イベント」 → Cloud Functions / Cloud Run functions
  • 「コンテナイメージがあり、HTTP リクエスト処理」「言語・ランタイムに縛られたくない」 → Cloud Run
  • 「既存の Web アプリをフルマネージドで」「標準的な Web/モバイルバックエンド」 → App Engine
  • 「OS レベルで細かく制御」「カスタムミドルウェア」 → Compute Engine

8.2.2 IAM・サービスアカウント周りの誤答パターン

パターン2：Basic ロール（Owner / Editor / Viewer）頼み

誤った思考

  • 「細かいロールはよく分からないので、とりあえず Editor」
  • 「短時間の検証だから Owner でいいだろう」

正しい考え方

  • 公式の IAM ベストプラクティスでは、最小権限の原則と事前定義ロールの優先利用が明示されています。
  • Basic ロールはプロジェクト全体に広範な権限を付与するため、試験シナリオでは「望ましくない選択」として出てくることが多いです。

試験での見抜き方

  • 選択肢に「Editor ロールを付与」が紛れていたら、ほぼ誤答候補と疑う
  • 「Cloud Storage のオブジェクトの読み取りだけ」が要件 → roles/storage.objectViewer 等の事前定義ロールを選ぶ

パターン3：サービスアカウント鍵を配りがち

誤った思考

  • 「オンプレアプリから GCP にアクセスしたい → JSON キーを発行して配る」
  • 「GitHub Actions 用にキーをリポジトリに登録しておく」

正しい考え方

サービスアカウントのベストプラクティスでは、「キーは極力作らない」「作った場合は厳格に管理・ローテーション」と明記されています。

  • 可能ならば Workload Identity Federation や環境固有の ID 連携を利用し、長期鍵を配布しない
  • どうしてもキーが必要な場合も、最小権限のサービスアカウントに限定して付与

試験での見抜き方

  • 正解になりやすい選択肢
    • 「オンプレからのアクセス → Workload Identity Federation を使う」
    • 「GKE からのアクセス → Workload Identity / GKE Workload Identity を使う」
  • 誤答になりやすい選択肢
    • 「全社で共有するサービスアカウントキーを 1 つ発行して配布する」

パターン4：ユーザーとサービスアカウントの役割を混同する

典型的な誤答

  • CI/CD ツールからのデプロイに「人間ユーザーのアカウント」を使う
  • 実行主体が明らかにアプリケーションなのに、ユーザーアカウントに権限を付与している

正しい考え方

  • サービスアカウントは「非人間ユーザー」としてワークロードを表現するもの。
  • 実行主体がアプリ・バッチ・マイクロサービスなら、サービスアカウントにロールを付与するのが基本。

試験での見抜き方

  • 「CI/CD」「アプリケーション」「バッチ処理」「GKE Pod」など → 人ではなく サービスアカウント を使う選択肢が正解候補

8.2.3 ネットワークで混乱しやすい論点

パターン5：Cloud NAT と Private Google Access の役割を逆に覚える

誤った思考

  • 「外部 IP のない VM がインターネットに出ていく → Private Google Access」
  • 「Google APIs へのプライベートアクセス → Cloud NAT」

正しい対応

  • Cloud NAT
    • 外部 IP のない VM / GKE / サーバーレスが「インターネットや他ネットワークへ outbound 通信」するためのフルマネージド NAT。
  • Private Google Access（PGA）
    • 外部 IP を持たない VM から、Google APIs & Services の外部 IP 宛てにプライベートアクセスできるようにする機能。

試験での見抜き方

  • 要件に「GitHub や OS アップデートサーバーなど一般インターネットへアクセス」 → Cloud NAT
  • 「VM に外部 IP を付けずに Cloud Storage / BigQuery / Cloud APIs を使いたい」 → Private Google Access

パターン6：ルートとファイアウォールの役割を混同する

誤った思考

  • 「通信を止めたいからルートを消す」
  • 「サブネット間が疎通しないのは、ルートではなくファイアウォールの問題だろう」と毎回逆に捉える

正しい整理

  • ルート（routes）
    • どの宛先に対してどの next hop に転送するかを決める、経路情報。
  • ファイアウォールルール
    • どの通信（src/dst・ポート・プロトコル）を allow / deny するかを決める、アクセス制御。

試験での見抜き方

  • 「VM からインターネットに出られない」
    • デフォルトルート (0.0.0.0/0 → default-internet-gateway) の有無 + ファイアウォールの egress/ingress を両方チェックする選択肢が正解候補
  • 「特定サブネット間のみ通信させたい」
    • ルートで経路はそのまま、ファイアウォールで制御するパターンが多い

8.2.4 Cloud Storage でのよくある誤答

パターン7：ストレージクラスと最小保存期間を無視する

誤った思考

  • 「どうせバックアップだから Archive 一択」
  • 「頻繁に上書き・削除されるログを Coldline に」

公式仕様のポイント

  • Nearline / Coldline / Archive には最小保存期間があり、早期削除するとその期間分まで料金がかかる。
    • Nearline: 30 日
    • Coldline: 90 日
    • Archive: 365 日

試験での見抜き方

  • 「30 日以内に削除される可能性のあるデータ」→ Nearline/Coldline/Archive は不適切
  • 「年単位でほぼ参照しないバックアップ」→ Archive が本命

パターン8：IAM と ACL（オブジェクトレベル）をごちゃ混ぜにする

誤った思考

  • 「一部オブジェクトだけ共有したいから、ACL で何とかする」
  • 「組織としてのベストプラクティスよりも、ACL で細かく制御した方が良い」

正しい考え方

  • 公式ドキュメントでは、Cloud Storage のアクセス制御は IAM を推奨し、Uniform bucket-level access を使うことで ACL を無効化し、一元管理することを推奨しています。

試験での見抜き方

  • 正解になりやすい選択肢
    • 「Uniform bucket-level access を有効化し、IAM ロールでアクセス制御」
  • 誤答になりやすい選択肢
    • 「組織全体では IAM を使っているが、例外的に ACL を使って管理する」

8.2.5 サーバーレス選択の誤答パターン

パターン9：Cloud Run / Cloud Functions / App Engine の境界があいまい

誤った思考

  • 「とりあえず Cloud Functions にしておけばサーバーレスでしょ」
  • 「Cloud Run と App Engine の違いが分からないので、ランダムに選ぶ」

公式仕様からの整理

  • Cloud Run
    • コンテナベース、ステートレス、HTTP/イベント駆動、任意ランタイム
  • Cloud Run functions / Cloud Functions
    • イベント駆動の単機能コード（FaaS）。Cloud Run の実行基盤を利用
  • App Engine Standard
    • サポートランタイムに合わせた PaaS。自動スケール・ゼロスケール・アプリ中心設計

試験での見抜き方

  • 「既存のコンテナイメージをデプロイ」「任意ランタイム」→ Cloud Run
  • 「ファイルアップロードや Pub/Sub などイベントをトリガーに小さな処理」→ Cloud Run functions / Cloud Functions
  • 「典型的な Web アプリ、長期運用、フルマネージド PaaS」→ App Engine

8.2.6 運用・監視・セキュリティの見落としパターン

パターン10：Monitoring / Logging を「おまけ」として扱う

誤った思考

  • 「監視は本番運用の話だから、試験では重要度が低い」
  • 「Stackdriver（旧名）時代の記憶で止まっている」

正しい考え方

  • 試験ガイドでは、「Cloud Monitoring / Cloud Logging を使った運用」が明確に範囲に含まれています。
  • 出題されやすいポイント
    • uptime check と alerting policy の役割
    • 指標（metrics）・ログベース指標の活用
    • ログのエクスポート先（BigQuery / Pub/Sub / Storage）

試験での見抜き方

  • 「障害検知」「SLO を満たすための監視」「特定ログイベント検知」 → Cloud Monitoring / Logging を使う選択肢が正解候補

8.2.7 本番で誤答しないためのチェックリスト

最後に、試験直前に自分の「誤答クセ」を潰すためのチェックポイントです。

  1. サービス選択
    • コンピュート：CE / GKE / Cloud Run / App Engine / Cloud Functions の使い分けを、文章だけ読んで瞬時に判断できるか
  2. IAM
    • Basic ロールを安易に選んでいないか
    • 事前定義ロールの粒度を、代表的なサービス（Compute / Storage / IAM / Logging）でイメージできるか
  3. サービスアカウント
    • 「人」ではなく「ワークロード」にロールを付与する、という基本が身についているか
    • 鍵を配るパターンを「最終手段」として認識しているか
  4. ネットワーク
    • Cloud NAT と Private Google Access の役割を逆に覚えていないか
    • ルートとファイアウォールの違いを説明できるか
  5. ストレージ
    • Nearline / Coldline / Archive の最小保存期間を暗記しているか
    • Uniform bucket-level access を「推奨構成」としてイメージできているか
  6. 運用・監視
    • Monitoring / Logging / Alerting / Export の基礎的なつながりを説明できるか

このあたりを潰しておけば、「なんとなく知っているのに落とされる問題」をかなり減らせます。
以降の節では、ここで挙げた誤答パターンを意識しながら、模擬問題・シナリオ問題で実際に手を動かして確認していきます。

8.3　当日の判断基準

（最小権限・運用容易性・耐障害性をどう優先するか）

この節では、本番の試験問題で「どれを選ぶか迷った」ときに立ち返るための 判断軸 を整理します。
細かい数値やコマンドではなく、「どんな状況では何を優先して考えるか」にフォーカスします。

8.3.1 まず最初に思い出すべき 4 つの軸

どんなシナリオ問題でも、まずは次の 4 つに切り分けて読んでください。

  1. 最小権限（Least Privilege）
  2. 運用容易性・保守性（Operational Simplicity）
  3. 耐障害性・可用性（High Availability）
  4. コスト・スケーラビリティ（Cost & Scale）

ACE の問題は、これらを全部満たせる選択肢か、あるいは「どれを優先すべき状況か」を問う構造になっています。

8.3.2 権限まわりの判断基準（最小権限）

基本ルール

IAM に関しては、公式のベストプラクティスと同じく、常に次の順序で考えます。

  1. Basic ロール（Viewer / Editor / Owner）は極力使わない
  2. 事前定義ロール（プリンシパル単位 / サービス単位）で権限を付与
  3. どうしても足りない場合のみ カスタムロール
  4. ワークロードには ユーザーではなくサービス アカウント を使う

試験では、だいたい次のように出てきます。

  • 選択肢 A: 「Editor ロールを付与する」
  • 選択肢 B: 「対象バケットに roles/storage.objectAdmin を付与する」
  • 選択肢 C: 「対象インスタンスのサービス アカウントに最小限のストレージロールを付与する」

この場合、C ＞ B ＞ A の順で望ましい、という感覚を持てているかが鍵です。

当日のチェックポイント

選択肢を読むとき、次の 3 点を瞬間的にチェックしてください。

  • 権限のスコープはどこか？
    • 組織 / フォルダ / プロジェクト / リソース
    • 必要以上に上位レベルにロールを付けていないか
  • どのロール種別を使っているか？
    • Basic ロールで雑に上げていないか
    • 事前定義ロールで過不足ないか
  • 誰に付けているか？
    • 人間ユーザー vs サービス アカウント
    • グループに付与して運用しやすくしているか

迷ったら：「どの選択肢がいちばん “つよつよロール” を避けているか」という目線で比較する。

8.3.3 運用容易性の判断基準

マネージドか、自前管理か

Google Cloud の公式ドキュメントや試験ガイドでは、可能な限りマネージドサービスを利用する設計が前提になっています。

当日の判断としては、次の順序で選びます。

  1. フルマネージドで要件を満たせるならそれを優先
    • Cloud SQL / Cloud Run / GKE Autopilot / Cloud Functions など
  2. 自前 VM / 自前管理のソフトウェアは、「マネージドで実現できない要件」がある時だけ

運用負荷を比較する視点

選択肢どうしを比較するときは、次の観点で「運用がラクなもの」を選びます。

  • パッチ・アップデートが自動か
    • DB: Cloud SQL vs VM 上の自前 MySQL
    • コンピュート: Cloud Run / App Engine vs Compute Engine VM
  • スケーリングの運用が自動か
    • MIG / Cloud Run / App Engine / GKE Autopilot など、負荷に応じて自動スケールするものを優先
  • 構成変更の反映が簡単か
    • IaC（Terraform 等） / インスタンステンプレート / マネージド設定で統一管理できているか

迷ったら：
「誰かが毎日ダッシュボードを見て、手で増減したりパッチ当てたりする必要がある構成」は、基本的に不正解候補です。

8.3.4 耐障害性・可用性の判断基準

ゾーン・リージョンの考え方

当日の試験で可用性を問う問題では、ほぼ必ず「ゾーン / リージョン」という言葉が登場します。

基本的な優先順位は次の通りです。

  • ゾーン障害に耐えたい
    • → 同一リージョン内の 複数ゾーンに分散（Regional MIG など）
  • リージョン障害にも耐えたい
    • → 複数リージョンに同等の構成をつくり、グローバル LB などで切り替え

ゾーン単位の冗長化は ACE レベルで頻出です。
選択肢で 「Regional Managed Instance Group」 や 「複数ゾーンにまたがるデプロイ」 を選べるかがポイントになります。

ステートレス / ステートフルで判断を変える

  • ステートレス（Web / API サーバなど）
    • MIG + LB / Cloud Run / App Engine など、横に増やしやすい構成を優先
    • Multi-zone が基本
  • ステートフル（DB / 状態を持つシステム）
    • Cloud SQL / Spanner / Datastore / Firestore など、
      公式に HA を提供するマネージドサービスを使えるかをまず確認

迷ったら：「VM 台数を増やす前に、“そもそもマネージドで HA を持っているサービスはないか” を疑う」

8.3.5 コストとスケーラビリティの判断基準

常時稼働か、断続的か

コストとスケールは、おもに「稼働パターン」で判断します。

  • 常時アクセスがある / 24 時間稼働前提
    • MIG（オートスケール）
    • GKE（Autopilot / Standard）
    • 長期利用なら CUD（Committed Use Discounts）なども考慮
  • アクセスが散発的 / イベントベース
    • Cloud Run / Cloud Functions / App Engine Standard
    • スケール to 0 でアイドル時コストを抑える

ACE 試験では、「昼だけアクセスが集中」「夜はほとんどアクセスなし」といった文章がヒントです。
常時 VM を立てっぱなしにする構成は、だいたい不正解候補になります。

割引・スポットを選ぶ条件

割引やスポット系の選択肢が出たときは、次の条件に当てはまるかどうかを確認します。

  • Committed Use Discount（CUD）
    • 1〜3 年以上、安定して稼働する前提のワークロードか
  • Spot VMs
    • 中断に耐えられるバッチ / バックグラウンド処理か

「停止させると困るサービス」に Spot VMs を選んでいたら、それはほぼ罠です。

8.3.6 典型シナリオにおける「優先順位」の決め方

ここからは、よくある ACE 風シナリオに対して「何を優先して読むか」を具体化します。

シナリオ A：社内 Web ポータルの構成を選ぶ問題

要件例：

  • 社員のみが利用
  • 社外からもアクセスする（在宅勤務 etc.）
  • 認証済みユーザだけに限定
  • 運用負荷は最小限にしたい

読むべきポイント

  1. 認証の要件（ID ベース vs ネットワークベース）
    • VPN 前提か？
    • ゼロトラスト（どこからでも ID ベース）か？
  2. 可用性（ゾーン / リージョン）
    • ゾーン障害にも耐える必要があるか
  3. 運用負荷
    • 自前 VM か、Cloud Run / App Engine + IAP か

判断基準

  • ID ベース制御を優先 → IAP + Cloud Run / App Engine / HTTPS LB
  • 社内ネットワークだけで十分なら Internal LB + VPN という選択肢もあり

シナリオ B：VM から Storage にログを書き込む問題

要件例：

  • 監査ログのような追記専用
  • 誤って削除・上書きされたくない
  • VM に外部 IP を付けたくない

読むべきポイント

  1. 権限の粒度
    • 書き込み専用か、読み書きフルか
  2. ネットワーク
    • 外部 IP 禁止 → Private Google Access の有無

判断基準

  • 権限：roles/storage.objectCreator をサービス アカウントに付与（追記専用）
  • ネットワーク：サブネットで Private Google Access 有効化

ここでは「最小権限」と「インターネット非公開」を同時に満たす選択肢を選びます。

シナリオ C：高トラフィック Web API のスケール設計

要件例：

  • 日中はトラフィック急増、夜間は低負荷
  • ゾーン障害にも耐えたい
  • コストも無駄なく

読むべきポイント

  1. 可用性
    • ゾーン障害 → Regional MIG
  2. スケーラビリティ
    • Autoscaling の有無（CPU / LB ベース）

判断基準

  • Regional MIG + HTTP(S) Load Balancer
  • Autoscaling を CPU 利用率やリクエスト負荷で設定

ここでは「耐障害性」と「スケーラビリティ」が最優先で、コストはオートスケールで自動的にある程度最適化されます。

8.3.7 本番で迷ったときの「5 ステップ」

最後に、問題文を読んだときの思考プロセスを 5 ステップにまとめます。
時間がないときでも、この順番だけは崩さないようにしてください。

  1. 誰が（何が）実行するのか？
    • 人か？ サービスか？
    • → ユーザー / グループ / サービス アカウントのどれに権限を付けるかを決める
  2. どこまでの可用性が必要か？
    • ゾーン障害までか？ リージョン障害までか？
    • → Zonal / Regional / Multi-region のどれかを決める
  3. 運用を誰がどこまで担当する前提か？
    • 小規模チームで 24h 運用は無理 → マネージドサービス優先
    • 既に Kubernetes / VM の運用が前提 → それを踏まえて選択
  4. トラフィック・負荷パターンはどうか？
    • 常時 / 断続的 / イベントドリブン
    • → VM / MIG / Cloud Run / Functions / App Engine のどれが自然か
  5. セキュリティ・コストに関するヒントがないか？
    • 「最小権限」「セキュリティポリシー」「予算」などのキーワード
    • → IAM ロールの粒度 / ストレージクラス / 割引モデルを最適化

この 8.3 の内容を頭に入れておくと、本番のシナリオ問題は

  • サービス名を当てるクイズ
    ではなく
  • 判断軸に沿って「一番マシな選択肢」を選ぶ作業

に変わります。

計算問題や個別仕様の暗記よりも、こうした「優先順位づけ」が ACE 合格ラインを超えるうえでの決定打になります。

前の記事
次の記事