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

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

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 合格ラインを超えるうえでの決定打になります。