Google Cloud ハンズオン教科書|2026-08 版
第 18 章 試験ガイド 1.1 試験ガイド 1.2 試験ガイド 1.3 試験ガイド 1.4 試験ガイド 2.1 試験ガイド 3.1 試験ガイド 4.2 試験ガイド 6.1

ケーススタディ攻略と試験対策

EHR・Helicopter Racing League・Mountkirk Games・TerramEarth を設計し切って本番へ

この章で学ぶこと

試験ガイド対応: セクション 1.1〜1.4、2.1、3.1、4.2、6.1(ケーススタディ問題は特定セクションに閉じず、全セクションを横断して出題されます)

ケーススタディの読み方 — 原文を翻訳表に落とす型

Professional Cloud Architect 試験の最大の特徴は、架空企業のシナリオ(ケーススタディ)を参照して答える問題群です。公式ページによれば、標準試験は 2 時間・50〜60 問で、そのうち 20〜30% がケーススタディ由来(2026-08 時点)。試験中はケーススタディ原文を分割画面で参照できますが、本番で初見だと読むだけで時間が溶けます。事前に「諳んじて要約できる」水準まで読み込み、本番では確認だけで済ませるのが合格者の定石です。

ケーススタディは版が更新される(2026-08 時点の重要な注意): 最新の英語版試験ガイド v6.1 が参照するケーススタディは Altostrat Media / Cymbal Retail / EHR Healthcare / KnightMotives Automotive の 4 本で、複数の企業が生成 AI ソリューションを使う設定に刷新されています。本章で扱う Helicopter Racing League / Mountkirk Games / TerramEarth は長年出題されてきた旧版の題材(EHR Healthcare は新旧共通)ですが、要件をプロダクトへ翻訳する「読み解きの型」は版が変わっても同じです。受験登録の前に必ず公式ページから最新の試験ガイドとケーススタディ一覧を確認してください。

ケーススタディの原文はどれも同じ 6 部構成です。各セクションから拾うべき情報は決まっています。

原文のセクションここから拾うもの
会社概要(Company overview)業種と規制の文脈。医療なら HIPAA、決済なら PCI DSS が裏にある
ソリューションコンセプト移行の「北極星」。何のためにクラウドへ行くのかの 1 文
既存環境(Existing technical environment)制約の宝庫。移行元・残すもの・使っている技術スタック
ビジネス要件優先順位の源泉。正解選択肢を最後に 1 つへ絞る根拠になる
技術要件プロダクト選定への直接のヒント。1 行 = 1 翻訳
役員声明(Executive statement)最優先事項の宣言。「レイテンシが最優先、次にコスト」のような順位付け

読んだら、内容を 2 つに仕分けします。制約は動かせない前提(リース期限、残すレガシー、既存の技術選定)、要求は満たすべきゴール(可用性 99.9%、レイテンシ最小化)です。制約は選択肢を消し、要求は選択肢を選びます。そのうえで要件 1 行ごとに「Google Cloud のどのプロダクトで、なぜ満たせるか」を書いた翻訳表を作ります。この章の 4 節で見せる表がその完成形です。

会社概要 コンセプト 既存環境 ビジネス要件 技術要件 1 行ずつ仕分ける 制約(動かせない前提) 既存環境・リース・規制 要求(満たすべきゴール) 要件リストと役員声明 候補を絞る 1 行 = 1 翻訳 要件 → プロダクト翻訳表 1 行ごとに根拠を書き残す 消去法で比較 ビジネス要件を最も満たす解答
図 18-1 ケーススタディ読解の型。上段の原文セクションをそのまま暗記するのではなく、制約と要求に仕分けてから翻訳表に落とす。最後の絞り込みの基準は技術的な優劣ではなくビジネス要件である。
試験の視点: ケーススタディ問題で問われるのは「どのプロダクトが最強か」ではなく「この会社の優先順位では何が正解か」です。同じ技術要件でも、レイテンシ最優先と明言する Mountkirk Games とコスト削減を明言する TerramEarth では正解が変わります。選択肢を 2 つまで絞って迷ったら、役員声明の優先順位に立ち返ってください。

4 大ケーススタディを設計し切る

ここからは 4 本を 1 本ずつ、翻訳表と推奨アーキテクチャに落とします。原文 PDF(各 3 ページ・英語)は必ず一度は通読してください。なお機械学習系の要件は、本書では Gemini Enterprise Agent Platform(旧称 Vertex AI。以下 Agent Platform)へ翻訳します。マネージドなモデル学習(AutoML / カスタムトレーニング)とオンライン予測を提供するプラットフォームで、TensorFlow をはじめとする主要な ML フレームワークをサポートします。

EHR Healthcare — コロケーション脱出と階層化ハイブリッド

電子カルテ(EHR)SaaS の大手。コロケーション DC のリース期限が迫るなか、Google Cloud への移行を決めた——という設定です(原文 PDF)。鍵は 3 つ。①顧客向け Web アプリはコンテナ化済みで複数の Kubernetes クラスタで動いている、②保険会社とのレガシー連携(ファイル / API ベース)は数年はオンプレに残す、③ユーザー管理は Microsoft Active Directory。つまり全面移行ではなく、フロントはクラウド・レガシーはオンプレの階層化ハイブリッド(tiered hybrid)パターンです(アーキテクチャセンター参照)。

要件(原文の要旨)Google Cloud への翻訳と根拠参照章
コンテナ化済みアプリを一貫した方法で管理し、動的にスケールGKE。複数環境(本番 / 開発 / テスト)をクラスタとして統一運用第 6 章
顧客向けシステムの可用性 99.9% 以上・全顧客のレイテンシ低減リージョナル GKE クラスタ + グローバル外部アプリケーション LB + Cloud CDN第 5 章
オンプレのレガシー保険連携と、安全で高性能な接続を維持Cloud Interconnect(Dedicated / Partner)。帯域と SLA が要るので VPN より優先第 12 章
MySQL / MS SQL Server / Redis / MongoDB の混在データ層Cloud SQL(MySQL・SQL Server)/ Memorystore(Redis)/ Firestore(ドキュメント指向の移行先候補)第 9 章・第 10 章
Microsoft AD によるユーザー管理を維持Managed Service for Microsoft AD をデプロイし、オンプレ AD とフォレスト間信頼で接続本章(下記)
一貫したロギング・監視・アラート(現状はメール通知が無視されがち)Google Cloud Observability(Cloud Monitoring / Cloud Logging)に一元化し、アラートポリシーで能動対応第 15 章
規制順守の維持(医療データ)HIPAA を見据えた BAA・監査ログ・Sensitive Data Protection・CMEK第 14 章・第 13 章
業界トレンドの予測とレポート生成BigQuery にプロバイダデータを集約し、Agent Platform で予測モデルを学習・提供第 11 章
新しい保険プロバイダの迅速なオンボーディング取り込みインターフェースをコンテナ / Cloud Run で標準化し、CI/CD で高速展開第 7 章・第 16 章

AD の扱いは EHR 頻出論点です。Managed Service for Microsoft AD は Google Cloud がドメインコントローラーの運用(パッチ適用・冗長化)まで面倒を見るマネージド AD で、既存のオンプレ AD とはフォレスト間の信頼(forest trust)で接続できます。「AD を作り直す」のではなく「信頼でつなぐ」が正解の型です。

医療機関の利用者 HTTPS オンプレミス DC レガシー保険連携 ファイル / API 連携 Active Directory ユーザー管理 Google Cloud GKE 顧客向けコンテナ群 Cloud SQL / Memorystore Firestore ほか Cloud Observability 監視・ログ一元化 Managed Microsoft AD ID をクラウドへ拡張 Interconnect フォレスト信頼
図 18-2 EHR Healthcare の推奨構成。左のオンプレに残るのは「数年後に廃止予定のレガシー連携」と AD で、それぞれ Cloud Interconnect(Dedicated / Partner)とフォレスト間信頼で Google Cloud 側と接続する。利用者トラフィックはグローバル外部アプリケーション LB 経由で GKE に入る。

Helicopter Racing League — 動画配信と ML 予測のクラウド間移行

世界規模のヘリコプターレースリーグ。ライブ中継とレース予測を有料配信しており、別のパブリッククラウドから Google Cloud への移行を検討している設定です(原文 PDF)。動機は 2 つ——マネージド AI/ML でレース予測(勝敗・機体故障・観客感情)を強化すること、新興国の視聴者の近くでコンテンツを配信すること。既存環境は「オブジェクトストレージにコンテンツ、ジョブごとに VM を立ててトランスコード、VM 上の TensorFlow で予測」です。それぞれをマネージドサービスに置き換えるのが軸になります。

要件(原文の要旨)Google Cloud への翻訳と根拠参照章
予測のスループットと精度を維持・向上(現状 VM 上の TensorFlow)Agent Platform のカスタムトレーニング(GPU / TPU)+ オンライン予測エンドポイント。TensorFlow をサポート本章
予測モデルをパートナーへ公開Apigee で API プロダクト化し、認証・レート制限・開発者ポータルを提供本章(TerramEarth 節参照)
視聴者レイテンシ削減・新興国での視聴品質向上・同時視聴者数増Media CDN。動画ストリーミングと大容量配信に特化したエッジ配信本章
トランスコード性能の向上(現状ジョブごとの VM)Transcoder API。MP4 / HLS / DASH を出力するマネージドの非同期ジョブ本章
視聴パターンとエンゲージメントのリアルタイム分析Pub/Sub → Dataflow → BigQuery のストリーミング分析パイプライン第 11 章
大量のレースデータを処理するデータマートBigQuery。パーティショニング / クラスタリングでコストと性能を制御第 11 章
既存コンテンツ(他クラウドのオブジェクトストレージ)の移行Storage Transfer Service で Cloud Storage へクラウド間転送第 8 章
運用の複雑さを最小化・規制順守サーバーレス / マネージド優先の選定。コンテンツの地域規制はロケーション設計で対応第 7 章・第 14 章

配信レイヤーの選定が HRL らしさです。Media CDN は Cloud CDN を補完する動画・大容量配信特化の CDN で、Google のエッジキャッシュ網から配信します。Web サイトの高速化なら Cloud CDN(第 5 章)、ストリーミング動画の大規模配信なら Media CDN、という使い分けです。トランスコードはTranscoder API に任せ、「Cloud Storage に置く → ジョブ投入 → 結果を Cloud Storage へ」という非同期フローに置き換えます。

レース会場 トラック DC Cloud Storage Transcoder API Media CDN 世界の視聴者 Pub/Sub Dataflow BigQuery Agent Platform 予測の学習・提供 Apigee パートナーへ公開 録画映像 テレメトリ 変換ジョブ HLS/DASH エッジ配信 取り込み 集計 学習データ 予測 API
図 18-3 HRL の推奨データフロー。上段は映像パイプライン(保存 → マネージドトランスコード → 動画特化 CDN)、下段はテレメトリのストリーミング分析。BigQuery に溜まったレースデータで Agent Platform(旧称 Vertex AI)のモデルを学習させ、予測は Apigee 経由でパートナーにも提供する。

Mountkirk Games — GKE とグローバルリーダーボード

モバイルゲーム会社。オンプレからの移行はすでに完了しており、次の新作——数百人同時対戦の FPS——をクラウドネイティブ前提で新規設計する攻めのケースです(原文 PDF)。ソリューションコンセプトに答えの骨格が明記されています: バックエンドは GKE、プレイヤーは Google のグローバル LB で最寄りのリージョンのアリーナへ、全アリーナ横断のリーダーボードはマルチリージョン Spanner。役員声明の「レイテンシが最優先、コスト管理が次点」が選択肢を絞る最終基準です。

要件(原文の要旨)Google Cloud への翻訳と根拠参照章
複数プラットフォーム・複数リージョンから最寄りアリーナへ接続複数リージョンの GKE クラスタ + グローバル外部アプリケーション LB(エニーキャストで近接ルーティング)第 5 章・第 6 章
ほぼリアルタイムの全世界リーダーボードマルチリージョン構成の Spanner。強整合の読み書きと水平スケールを両立第 9 章
ゲームアクティビティに応じた動的スケールGKE のオートスケール(HPA + クラスタオートスケーラ)。Autopilot ならノード管理も不要第 6 章
活動ログを構造化ファイルとして保存し将来分析Cloud Storage へ書き出し、BigQuery で分析(外部テーブル / ロード)第 8 章・第 11 章
サーバーサイド GPU レンダリングでマルチプラットフォーム対応GKE の GPU ノードプール(Standard モードで GPU マシンタイプを指定)第 6 章・第 4 章
ゲーム機能の高速イテレーションCloud Build + Cloud Deploy によるカナリアリリース第 16 章
ゲームごとに隔離されたプロジェクト + フォルダで権限・ネットワークポリシーを集中管理リソース階層の教科書例。フォルダに IAM / 組織ポリシーを継承させる第 2 章
マネージドサービスとプールされたリソースの活用・コスト最小化マネージド優先 + オートスケールで需要追従。分析系バッチには Spot VM第 17 章

リーダーボードに Spanner を選ぶ根拠は言語化できるようにしてください。Spanner はリレーショナルな強整合トランザクションを保ちながら水平スケールし、リージョナル / デュアルリージョン / マルチリージョン構成を選べます。公式ドキュメントもゲームデータベースを明示的なユースケースに挙げています。「世界中のアリーナから書き込まれ、順位の整合が崩れてはならない」——この 1 行が Cloud SQL でも Firestore でもなく Spanner を指します。

世界中のプレイヤー 最寄りへ接続 グローバル外部 ALB 近接ルーティング 近接ルーティング リージョン A GKE ゲームアリーナ リージョン B GKE ゲームアリーナ スコア書き込み スコア書き込み Spanner(マルチリージョン) グローバルリーダーボード 活動ログ Cloud Storage 構造化ログ→分析
図 18-4 Mountkirk Games の推奨構成。地理分散した GKE アリーナへの振り分けはグローバル外部 ALB が担い、全アリーナのスコアは 1 つのマルチリージョン Spanner に集まる。ログは Cloud Storage に構造化ファイルとして落とし、後段の BigQuery 分析(第 11 章)につなぐ。

TerramEarth — IoT テレメトリとパートナー API 基盤

鉱業・農業向け重機メーカー。200 万台の車両が稼働し、年 20% 成長。重要データだけをリアルタイム送信し、残りのセンサーデータ(1 台あたり 1 日 200〜500MB)は帰還時に一括アップロードする——というデータ量の設計が主役です(原文 PDF)。すでに Google Cloud 上にデータ基盤があり、工場からのデータを受けるオンプレ DC とは複数の Interconnect で接続済み。5 年計画は「データへのアクセスを開放してパートナーエコシステムを作る」ことで、これが API 管理(Apigee)を軸にした問題を生みます。

要件(原文の要旨)Google Cloud への翻訳と根拠参照章
重要データのリアルタイム送信(走行中のフリート管理)Pub/Sub で取り込み、Dataflow でストリーム処理して BigQuery へ第 11 章
帰還時の一括アップロード(200〜500MB/日 × 200 万台)Cloud Storage へ直接アップロードし、バッチで BigQuery にロード。転送量と回線帯域の見積もりが先第 8 章・第 17 章
故障の予測・検知と部品のジャストインタイム供給BigQuery の走行データで Agent Platform の予測モデルを学習・提供本章・第 11 章
ディーラー / パートナー向けカスタム API 基盤と API エンドポイントの集中管理Apigee(API プロキシ・API プロダクト・開発者ポータル)+ Cloud Run バックエンド本章・第 7 章
レガシーシステムへの HTTP API 抽象化層(段階的クラウド移行)Apigee のプロキシでレガシーを包み、Interconnect 経由でオンプレへ到達第 12 章
CI/CD の近代化とコンテナワークロードのデプロイCloud Build + Artifact Registry + GKE / Cloud Run第 16 章
リモート開発者がコード・データを危険に晒さず開発できるIAP によるゼロトラストアクセス(VPN・踏み台なしで ID ベース制御)第 13 章
クラウドネイティブな鍵・シークレット管理と ID ベースアクセスCloud KMS + Secret Manager + サービスアカウント(キーレス運用)第 13 章・第 2 章
開発者向けセルフサービスポータル(プロジェクト作成・リソース申請)IaC(Terraform)によるプロジェクト払い出しの自動化 + リソース階層で統制第 16 章・第 2 章
クラウド運用コストの削減と季節変動への適応オートスケール + 従量課金で需要追従。定常分だけ確約利用割引(CUD)第 17 章

Apigee は Google Cloud の API 管理プラットフォームで、バックエンドの前に API プロキシを立て、分析・公開管理・開発者ポータルまで提供します。「パートナーに API を公開し、収益化や利用制御まで求められたら Apigee」は PCA の頻出パターンです(軽量なら API Gateway / Cloud Endpoints という選択肢もあります)。

車両 200 万台 センサー計測 Pub/Sub 即時取り込み Dataflow ストリーム処理 Cloud Storage 日次アップロード Dataflow バッチ 変換・ロード BigQuery 全走行データ Agent Platform 故障予測 Apigee パートナー API 重要データのみ即時 帰還時に一括 pull 書き込み 日次 書き込み 学習 予測 API
図 18-5 TerramEarth のデータ経路は「即時」と「一括」の 2 本立て。この分岐がそのまま試験の選択肢の分岐になる(走行中の重要データを Cloud Storage 直行にしたり、日次の全量を Pub/Sub ストリームにする選択肢は誤り)。予測結果はディーラー・パートナーへ Apigee 経由で公開する。

解答テクニックと本番までの流れ

3 つの解答原則

試験の形式と更新(2026-08 時点)

項目標準試験更新試験(Renewal)
時間 / 問題数2 時間 / 50〜60 問(多肢選択・複数選択)1 時間 / 25 問
受験料$200(税別)$100(税別)
ケーススタディの比重試験全体の 20〜30%。1 回の試験には 4 本中 2 本が登場(分割画面で原文参照可)生成 AI 関連のケーススタディ 1 本(2 本から選出)が 90〜100%
言語 / 受験方法英語・日本語 / 遠隔監視オンラインまたはテストセンター同左
有効期間2 年2 年(このほか指定コース / スキルバッジ完了による更新は 1 年)
前提条件なし(推奨: 業界経験 3 年以上、うち Google Cloud 設計・管理 1 年以上)有効な認定を保持し更新適格期間内であること

受験登録・最新の試験ガイド・サンプル問題はすべて認定資格の公式ページが起点です。英語版ガイド v6.1(2026-08 時点)ではセクション 1(設計と計画)が約 25% と最大の配点で、生成 AI 関連の考慮事項(Model Garden、AI Hypercomputer、Gemini Cloud Assist など)がセクション 1〜2 に明示的に入っています。当日は前半で自信のある問題を素早く確定し、ケーススタディ問題は「事前に作った翻訳表の記憶 → 原文の該当行だけ分割画面で確認」の順で処理すると、1 問あたり約 2 分のペースを守れます。

試験の視点: 更新試験は生成 AI ケーススタディがほぼすべてを占めます。初回合格がゴールではなく、2 年後の更新までが認定のライフサイクルです。本書の範囲(インフラ・データ・セキュリティ)に加えて、Agent Platform・Model Garden 周辺の公式ドキュメントを更新前に一巡する計画を立てておきましょう。

ハンズオン

ハンズオン 18-1|TerramEarth のテレメトリ経路をミニ再現する(Pub/Sub → BigQuery)

図 18-5 の「即時」経路の最小構成を作ります。Pub/Sub の BigQuery サブスクリプションを使うと、サブスクライバーのコードや Dataflow を書かずにメッセージを BigQuery テーブルへ直接書き込めます(公式ドキュメント)。所要 15 分。費用の目安: メッセージ数件と数 KB のストレージなので実質 0 円(Cloud Shell 実行を想定。ローカルの gcloud + bq でも可)。

  1. トピックと、書き込み先の BigQuery データセット・テーブルを作ります。スキーマオプションを使わない場合、テーブルには data という名前の列(BYTES / STRING / JSON のいずれか)が必要です。
gcloud pubsub topics create te-telemetry
bq mk --location=asia-northeast1 --dataset case18
bq mk --table case18.telemetry data:STRING
  1. Pub/Sub のサービスエージェント(Google 管理のサービスアカウント)に、テーブルへ書き込む権限を与えます。PROJECT_ID は自分のプロジェクト ID に置き換えてください(gcloud config get-value project で確認できます)。
PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)")
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataEditor"
  1. BigQuery サブスクリプションを作り、車両テレメトリを模したメッセージを発行します。
gcloud pubsub subscriptions create te-to-bq \
  --topic=te-telemetry \
  --bigquery-table="${PROJECT_ID}.case18.telemetry"
gcloud pubsub topics publish te-telemetry \
  --message='{"vehicle_id":"TE-0001","engine_temp_c":92,"fuel_pct":41}'
gcloud pubsub topics publish te-telemetry \
  --message='{"vehicle_id":"TE-0002","engine_temp_c":105,"fuel_pct":12}'
  1. 数十秒待ってからテーブルを照会し、メッセージ本文が data 列に入っていることを確認します。
bq query --nouse_legacy_sql 'SELECT data FROM case18.telemetry'

2 行の JSON 文字列が返れば成功です。サブスクライバー VM もストリーム処理コードも書いていないのに「デバイス → Pub/Sub → 分析基盤」の背骨が通ったことを確認してください。実運用でメッセージの変換・集約が要るときに初めて Dataflow(第 11 章)が登場します。

後片付け:

gcloud pubsub subscriptions delete te-to-bq --quiet
gcloud pubsub topics delete te-telemetry --quiet
bq rm -r -f case18
gcloud projects remove-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataEditor"
ハンズオン 18-2|模擬試験セッションと弱点マップ

本番のリハーサルです。所要 60〜90 分。費用の目安: 0 円(クラウドリソースは作成しません)。

  1. 認定資格の公式ページから最新の試験ガイドを開き、ケーススタディ一覧が本章の 4 本からどう変わっているかを自分の目で確認します。新しいケーススタディがあれば、図 18-1 の型で翻訳表を 1 本作ってみてください。
  2. 同ページのサンプル問題(練習問題フォーム)を開き、1 問 2 分の制限時間を計りながら通しで解きます。わからない問題も飛ばさず仮回答して印を付けます。
  3. 答え合わせをして、誤答を試験ガイドのセクション番号に対応付けた弱点マップを作ります。
誤答の弱点マップ(例)
セクション            誤答  再読する章
1. 設計と計画          2    第 5 章 / 第 7 章 / 第 9 章
3. セキュリティ        1    第 13 章
6. 信頼性              1    第 15 章
  1. 誤答が集中したセクションに対応する章の「理解度チェック」を解き直し、正答率が上がったら受験登録に進みます。

後片付け: クラウドリソースを作成しないため、削除作業はありません(第 1 章で作った学習用プロジェクトの掃除は、まとめの節を参照)。

つまずきポイント

「技術的に最良」を選んでしまう: 模試で最も多い失点は、要件にない高性能・高可用を選ぶことです。「99.9% でよい」と書かれているのにマルチリージョン Spanner を選ぶと、コスト最小化の要件に負けます。解答の前に必ず「この会社は何を最優先すると言っていたか」を 1 秒思い出してください。
プロダクトの旧称に惑わされる: 市販の対策本・過去問サイトには旧称が残っています。Cloud Functions は現在 Cloud Run functions、DLP は Sensitive Data Protection、Vertex AI は Gemini Enterprise Agent Platform、gsutil は gcloud storage が現行です(第 1 章参照)。旧称と現行名を対応付けて覚えておくと、教材の新旧に振り回されません。
ケーススタディを本番で初めて精読する: 分割画面で原文を読めるからと準備を省くと、1 問 2 分のペースが崩壊します。逆に、暗記した「つもり」の記憶だけで答えて原文の確認を怠るのも危険です。事前に翻訳表まで作り込み、本番は該当行の確認だけに使うのが正しいバランスです。
ハンズオン 18-1 で書き込みが失敗する: BigQuery サブスクリプション作成時や書き込み時のエラーは、ほぼサービスエージェント(service-プロジェクト番号@gcp-sa-pubsub.iam.gserviceaccount.com)への roles/bigquery.dataEditor 付与漏れです。また IAM 変更の反映には少し時間がかかることがあるので、直後に失敗したら 1〜2 分待って再試行してください。

理解度チェック

Q1. ケーススタディの「既存環境」と「役員声明」は、それぞれ解答のどの段階で使うか?

既存環境は制約として選択肢の消去(残すもの・移行元・技術スタックに反する選択肢を消す)に、役員声明は優先順位として最後まで残った選択肢の 1 択への絞り込みに使います。

Q2. EHR Healthcare で、オンプレに残るレガシー保険連携と Google Cloud を接続する第一候補は何か。またそのアーキテクチャパターンの名前は?

Cloud Interconnect(Dedicated / Partner)です。「安全で高性能な接続」という技術要件が VPN より Interconnect を指します。フロントエンドをクラウド、バックエンドの一部をオンプレに残す構成は階層化ハイブリッド(tiered hybrid)パターンと呼ばれます(第 12 章)。

Q3. Mountkirk Games のグローバルリーダーボードに Spanner が選ばれる根拠を 2 つ挙げよ。

①複数リージョンからの書き込みに対して強整合な読み書きを保てること(順位の整合が崩れない)、②リレーショナルな整合性を維持したまま水平スケールし、マルチリージョン構成を選べることです。結果整合の NoSQL やリージョナルな Cloud SQL では「全世界でほぼリアルタイムに正しい順位」を満たせません(第 9 章)。

Q4.(試験形式)Helicopter Racing League は録画コンテンツの視聴品質を新興国で改善し、同時視聴者数を増やしたい。最も適切な配信構成はどれか。
A. リージョナル Cloud Storage バケットから直接配信する B. Cloud Storage をオリジンに Media CDN で配信する C. 各国に Compute Engine のキャッシュ VM を建てる D. Filestore に置き VM 経由で配信する

B。Media CDN は動画ストリーミング・大容量配信に特化し、Google のエッジキャッシュから視聴者の近くで配信できます。A はオリジン直撃でレイテンシも負荷も悪化、C はマネージド優先の原則に反し運用負荷が過大、D の Filestore はファイル共有用でグローバル配信の要件に合いません。

Q5.(試験形式)TerramEarth は帰還した車両から 1 台あたり 200〜500MB/日のセンサーデータを収集し、分析基盤に蓄積したい。コスト効率が最も高い取り込み経路はどれか。
A. 車両から Pub/Sub へ全量をストリーミングする B. Cloud Storage へ一括アップロードし、バッチで BigQuery にロードする C. Cloud SQL に直接 INSERT する D. 各拠点の VM で受けてから gcloud storage で転送する

B。リアルタイム性が不要な全量データは、オブジェクトストレージへの一括アップロード + バッチロードが最も安く単純です。A はストリーミングの必要がない大容量データに過剰、C は分析ワークロードに Cloud SQL が不向きでスケールも費用も破綻、D は VM という管理対象と単一障害点を無駄に増やします。

まとめ — 本書の総仕上げ

参考リンク: