Professional Cloud Architect 模擬試験 2

試験について

試験時間: 2 時間（120 分）
問題数: 50 問
合格目標: 70 % 以上（35 問以上正解）
ケーススタディ: Cymbal Retail、KnightMotives Automotive
改訂対応: 2025 年 10 月改訂内容（Gen AI、Agent、Vertex AI、AI/ML 統合の責任ある運用）を反映

受験の心得

時間配分の目安

フェーズ	配分	内容
1 周目	80 分	全問にざっと回答（1 問あたり約 1 分 30 秒）
2 周目	30 分	フラグを立てた難問を再検討
最終確認	10 分	マークシートのズレ・記入漏れチェック

解答のコツ

ビジネス要件 → 技術要件 → 制約の順に読む: 何が最重要かを把握
「マネージド優先」「YAGNI（過剰設計回避）」「最小権限」の 3 原則
キーワードに反応:
- 「グローバル / 強整合」→ Spanner
- 「IoT / 高スループット」→ Pub/Sub + Dataflow + Bigtable
- 「リフト & シフト」→ MIG / Compute Engine
- 「迅速」→ Cloud Run / Cloud Run functions
2 つ以上の選択肢が正しそうな場合: コスト・運用負荷の低い方
「複数選択肢」は引っ掛けに注意: 必要数を必ず確認
ケーススタディ問題は冒頭の概要を必ず再確認

Gen AI 時代の新ポイント（2025 改訂）

Vertex AI Search: RAG の中核、Drive / Confluence などのコネクタ内蔵
Vertex AI Agent Builder: Function Calling / Tools の Agentic Workflow
Vertex AI Model Garden: Gemini 以外の OSS / 3rd party モデルもマネージド
Vertex AI Pipelines: MLOps 自動化（Kubeflow Pipelines マネージド）
責任ある AI: Model Card、Data Card、Continuous Evaluation

ケーススタディ 1: Cymbal Retail

会社概要

Cymbal Retail は急成長中の E コマース企業。年商 5 億ドル、過去 3 年で 200% 成長。在庫・販売・物流・カスタマーサポートの IT 基盤を、オンプレ + 既存 GCP のハイブリッドから完全 GCP ネイティブへ移行。Gen AI を活用したカタログ拡張、対話型コマース、技術刷新が必須。

既存環境

コンピュート: K8s クラスタ（複数バージョン混在）、レガシー Windows サーバー
データ:
- MySQL（在庫・販売）
- SQL Server（基幹会計）
- Redis（セッション / 在庫キャッシュ）
- MongoDB（製品カタログ、レビュー）
連携: SFTP / ETL バッチ、IVR（電話応答）
モニタリング: Grafana + Nagios + Elastic（古いスタック）
コスト: クラウドコストが Black Friday に予期せぬスパイク

ビジネス要件

B1: Black Friday などのピーク時に 10 倍トラフィックに耐える
B2: Gen AI でカタログ拡張（製品説明文自動生成）、対話型コマース（チャットで購入）
B3: 物流コストの最適化（在庫予測）
B4: SLA: ユーザー向け 99.9%

技術要件

T1: K8s クラスタを GKE Autopilot に統合
T2: データベースをマネージド化（Cloud SQL、Memorystore、Firestore など）
T3: 観測スタックを Cloud Monitoring + Managed Service for Prometheus に統合
T4: Gen AI ワークロード（推論、RAG）の運用化

問題 1

【ケーススタディ: Cymbal Retail】

シナリオ: Cymbal Retail は Gen AI を使って「ユーザーが自然言語で製品を検索 → 推薦 → 質問対応 → 購入完了まで」を一連の会話で完結させる「対話型コマース」を実現したい。製品カタログは MongoDB に 200 万件、在庫情報は MySQL、注文 API はバックエンドにある。

質問: 最適なアーキテクチャはどれか。

選択肢:

A. Vertex AI Agent Builder（Conversational Agents）で Gemini モデルに Function Calling を設定し、Vertex AI Search で製品カタログを検索、注文 / 在庫 API は Tool 定義として呼び出す
B. Gemini を製品カタログでファインチューニングし、すべての応答を生成
C. Cloud Run で独自に LLM サーバーを構築
D. Dialogflow CX のみで対応

解答と解説

正解: A

解説:

A が正解。Vertex AI Agent Builder（旧 Conversational Agents / Dialogflow CX + Agent Engine）は対話型コマースの標準。Vertex AI Search で製品検索（RAG）、Tool / Function Calling で在庫・注文 API を呼び出すエージェントワークフローを構築できる。2025 改訂のキー項目。
B はカタログが頻繁に変わるためファインチューニングは非現実的。
C は再発明。
D は単独で生成系の応答や RAG ができない。Agent Builder の方が包括的。

問題 2

【ケーススタディ: Cymbal Retail】

シナリオ: Cymbal Retail は Black Friday に通常の 10 倍のトラフィックを処理する必要がある。アプリケーション層は GKE Autopilot、データ層は Cloud SQL for MySQL + Memorystore for Redis を採用予定。突発的なトラフィックスパイクへの対策が必要。

質問: ピーク時のスケーラビリティを確保する構成として、適切なものを 2 つ 選びなさい。

選択肢:

A. GKE Autopilot の Horizontal Pod Autoscaler（HPA）+ Cluster Autoscaler を構成
B. Cloud SQL for MySQL の Read Replica（読み取りトラフィックを分散）と connection pooling（Cloud SQL Proxy / pgbouncer-like 中継）
C. Compute Engine の固定インスタンスを大量に常時起動
D. すべてのトラフィックを単一 Pod で受ける
E. Memorystore を Basic Tier（単一ノード）にする

解答と解説

正解: A, B

解説:

A: GKE Autopilot は自動で Pod とノードを管理。HPA + Cluster Autoscaler で負荷に応じた水平スケール。
B: MySQL Read Replica で読み取りスケール、接続プールでコネクション過多を防止。
C は常時固定で非効率。
D は単一障害点。
E は HA なし。

問題 3

【ケーススタディ: Cymbal Retail】

シナリオ: Cymbal Retail はオンプレの古い MongoDB（製品カタログ、レビュー）を GCP のマネージドサービスに移行したい。スキーマ柔軟性、グローバル展開、低レイテンシ読み取りが必要。

質問: 最も適切なマネージドサービスはどれか。

選択肢:

A. Firestore（マルチリージョン）
B. Cloud SQL for PostgreSQL
C. Cloud Bigtable
D. Compute Engine 上で MongoDB を運用

解答と解説

正解: A

解説:

A が正解。Firestore は NoSQL ドキュメント DB で MongoDB に近いデータモデル、マルチリージョン・低レイテンシ読み取り対応。Cymbal の製品カタログ・レビューに最適。
B は RDBMS で柔軟性が違う。
C は KV ストアでクエリパターンが異なる。
D はマネージド化の方針に反する。

問題 4

【ケーススタディ: Cymbal Retail】

シナリオ: Cymbal Retail のモニタリングスタックを Grafana + Nagios + Elastic から GCP に統合したい。既存の Grafana ダッシュボードと PromQL クエリは多数存在し、運用チームが慣れている。

質問: 最も推奨される構成はどれか。

選択肢:

A. Managed Service for Prometheus（GMP）+ Cloud Monitoring + Managed Service for Grafana（または既存 Grafana の継続）
B. Cloud Monitoring のみに移行し Grafana を廃止
C. Elastic を GCP Marketplace から購入して継続
D. Cloud Logging のみで代替

解答と解説

正解: A

解説:

A が正解。Managed Service for Prometheus（GMP）は PromQL 互換でクエリ・ダッシュボードを保持可能。Cloud Monitoring の SLO / アラートと統合。Grafana も継続使用可能。運用チームの学習コストを最小化。
B は既存資産（PromQL クエリ）を捨てる。
C はマネージドの方向性に反する。
D はメトリクス用途に不向き。

問題 5

【ケーススタディ: Cymbal Retail】

シナリオ: Cymbal Retail は Gen AI で「製品説明文自動生成（カタログ拡張）」をやりたい。現在 50 万製品が登録されており、説明文の品質が一貫しない。新規製品の登録時に Gemini で説明文を生成し、人間がレビュー後に公開する運用にしたい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Workflows + Vertex AI Gemini API + Firestore に Draft 保存 + 人間レビュー用 Web UI を Cloud Run でホスト
B. すべての説明文を自動公開（人間レビューなし）
C. Cloud Functions で Gemini を呼び出し、すべてバッチ処理
D. Vertex AI AutoML で文章生成モデルを訓練

解答と解説

正解: A

解説:

A が正解。Cloud Workflows でステップ管理（生成 → Draft 保存 → レビュー通知）、Firestore で Draft 状態管理、Cloud Run で UI ホスト。人間レビューを組み込んだ「Human-in-the-loop」が責任ある AI の基本。
B は責任ある AI に反する。
C はワークフロー管理が弱い。
D は LLM の方が品質高い。

ケーススタディ 2: KnightMotives Automotive

会社概要

KnightMotives Automotive は自動車メーカー。コネクテッドカー事業を拡大しており、車載センサー（位置、速度、温度、ブレーキ、エンジン状態）から毎秒大量のテレメトリを取得。現在はオンプレでバッチアップロード処理しているが、リアルタイム分析と Gen AI を活用した運転改善提案、故障予測へとシフトしたい。

既存環境

コンピュート: オンプレデータセンター（東京、フランクフルト、デトロイト）
データ:
- バッチアップロードされたテレメトリ（CSV → オンプレ HDFS）
- 顧客情報（PostgreSQL）
- 車両マスター（MySQL）
連携: 自動車修理パートナー API、保険会社 API
規制:
- GDPR（EU データはリージョン外不可）
- データ主権法（中国、ロシア等）
- 米国の自動車サイバーセキュリティ規制

ビジネス要件

B1: バッチアップロードからリアルタイムテレメトリ取り込みへ移行
B2: データローカリティ（リージョナル規制遵守）
B3: 超高速取り込み（毎秒数百万イベント）
B4: パートナー API へのデータ提供（許可された範囲のみ）
B5: AI を使った運転改善 / 故障予測

技術要件

T1: オンプレからの段階的移行（Hybrid 期）
T2: マルチリージョン展開（EU、APAC、AMER）
T3: ストリーム処理（CEP、ML 推論）
T4: パートナー API ゲートウェイ

問題 6

【ケーススタディ: KnightMotives Automotive】

シナリオ: KnightMotives は毎秒 500 万件のテレメトリを取り込む必要がある。データはリージョナル規制に従い保管。リアルタイム異常検知（急ブレーキ、急加速）と長期蓄積（ML 訓練用）が必要。

質問: 最適なアーキテクチャはどれか。

選択肢:

A. Pub/Sub（リージョナル）→ Dataflow（リージョナル Streaming Engine）→ Bigtable（リアルタイム集計）+ Cloud Storage（長期）
B. Cloud SQL に直接書き込み
C. Cloud Run functions が直接受信して BigQuery に insert
D. Compute Engine + Kafka を自前構築

解答と解説

正解: A

解説:

A が正解。Pub/Sub はリージョナル設定で 500 万件 / 秒のスループットに対応。Dataflow（Streaming Engine）で異常検知ロジックを実装。Bigtable は IoT / 時系列の超高スループット書き込みに最適。Cloud Storage は ML 訓練用の長期蓄積。
B は書き込みスループットが不足。
C は同時実行制限と insert 制限。
D は運用負荷大。

問題 7

【ケーススタディ: KnightMotives Automotive】

シナリオ: KnightMotives は EU、APAC、AMER でテレメトリを取り込む必要があるが、各リージョンのデータは原則そのリージョン内に留めなければならない。グローバルダッシュボードでは集計結果のみ閲覧可能（個別レコードは不可）。

質問: 最も適切なアーキテクチャはどれか。

選択肢:

A. リージョナル Pub/Sub + リージョナル Dataflow + リージョナル BigQuery（個別データ）+ BigQuery Authorized View で集計結果のみ別リージョンから参照可能化
B. 単一のグローバル BigQuery にすべてのデータを集約
C. 各リージョンの Cloud Storage バケットで個別管理、集計は手動
D. Cloud Spanner マルチリージョンで全データ統合

解答と解説

正解: A

解説:

A が正解。リージョナル BigQuery でデータを保持し、Authorized View で集計のみ別リージョンに公開する設計でデータローカリティを守れる。VPC Service Controls の境界と組み合わせるとさらに厳格化可能。
B はデータ越境違反。
C は集計が手動で非効率。
D は Spanner マルチリージョンでデータが越境する。

問題 8

【ケーススタディ: KnightMotives Automotive】

シナリオ: KnightMotives はパートナー（修理工場、保険会社）に API を提供したい。パートナーごとに権限を分離し、API のレート制限、認証、課金（オプション）、APIキー / OAuth を統合管理したい。

質問: 最適なサービスはどれか。

選択肢:

A. Apigee + API Gateway
B. Cloud Run + 自前認証
C. Cloud Endpoints + ESPv2 のみ
D. Cloud Load Balancing のみ

解答と解説

正解: A

解説:

A が正解。Apigee は GCP のフルマネージド API 管理プラットフォーム。レート制限、認証（API キー、OAuth）、開発者ポータル、課金、分析を統合提供。複雑な B2B API 提供のデファクト。
B は再発明。
C は軽量だが Apigee より機能少。
D は API 管理機能なし。

問題 9

【ケーススタディ: KnightMotives Automotive】

シナリオ: KnightMotives は AI で「運転改善提案（急ブレーキ多発ドライバーへのアドバイス）」「故障予測（特定パーツの異常パターン）」を実装する。ML モデルの訓練・デプロイ・継続評価が必要。

質問: 最適な MLOps 構成として、必要な要素を 3 つ 選びなさい。

選択肢:

A. Vertex AI Pipelines（Kubeflow Pipelines マネージド）で訓練 / 評価 / デプロイを自動化
B. Vertex AI Model Registry でモデルのバージョン管理
C. Vertex AI Model Monitoring で本番モデルのドリフト / Skew を監視
D. すべてのモデルを手動で再訓練
E. Cloud Functions で訓練ロジックを書く

解答と解説

正解: A, B, C

解説:

A: Vertex AI Pipelines は MLOps の中核。ステージ間の依存性管理、再現性、スケジュール実行。
B: Model Registry でモデルバージョン管理 / A/B テスト。
C: Model Monitoring で本番モデルの品質劣化を検出。
D は自動化の方針に反する。
E は MLOps として不足。

問題 10

【ケーススタディ: KnightMotives Automotive】

シナリオ: KnightMotives は段階的にオンプレから GCP へ移行する。移行期間中はオンプレと GCP 間で大量のデータを同期する必要がある。Hadoop（HDFS）も GCP に移行する必要がある。

質問: 最適な移行戦略として、適切なものを 2 つ 選びなさい。

選択肢:

A. Dataproc（マネージド Hadoop / Spark）+ Cloud Storage（HDFS の代替）で Hadoop ワークロードを移行
B. Storage Transfer Service + Transfer Appliance で大量データを移行
C. すべてのオンプレデータをコピー & ペーストで手動移行
D. Cloud SQL に Hadoop データを直接ロード
E. Compute Engine 上で HDFS を自前運用

解答と解説

正解: A, B

解説:

A: Dataproc は Hadoop / Spark のマネージドサービスで HDFS を Cloud Storage に置換するのが標準。
B: Storage Transfer Service（ネットワーク経由）+ Transfer Appliance（物理輸送）で大規模移行が可能。
C は実用的でない。
D は不適切（KV / 列指向 vs RDBMS）。
E はマネージド化の方針に反する。

独立問題

問題 11

シナリオ: ある企業が GCP 上で複数のリージョンに分散したマイクロサービスを運用する。各サービスは互いに gRPC で通信し、サービスメッシュで認証 / 認可 / トラフィック管理を行いたい。

質問: 最適なサービスはどれか。

選択肢:

A. Cloud Service Mesh（旧 Anthos Service Mesh、Istio ベース）
B. Cloud Load Balancing のみ
C. Cloud Endpoints のみ
D. Compute Engine 上で Linkerd を自己管理

解答と解説

正解: A

解説:

A が正解。Cloud Service Mesh は GCP マネージドの Istio ベースサービスメッシュ。mTLS、トラフィック分割、サーキットブレーカー、可観測性を提供。
B、C は単純な負荷分散 / API 公開で、サービスメッシュ機能なし。
D は運用負荷大。

問題 12

シナリオ: あるアプリケーションが Cloud Run でホストされ、外部からの HTTPS リクエストを受ける。バックエンドの Cloud SQL に SQL Injection 攻撃が試みられた。多層防御を実装したい。

質問: 必要な要素として、適切なものを 3 つ 選びなさい。

選択肢:

A. Cloud Armor で WAF（OWASP Top 10 プリセット）を有効化
B. アプリケーションコードで Parameterized Query / ORM を使う
C. Cloud SQL の DB ユーザーに最小権限を付与
D. すべての DB に root 権限で接続
E. Cloud DNS で DDoS 防御

解答と解説

正解: A, B, C

解説:

A: WAF レイヤで SQLi をブロック。
B: アプリレイヤで Parameterized Query 必須。これが根本対策。
C: DB レイヤで最小権限。万が一の攻撃でも影響範囲を限定。
D は逆方向。
E は DDoS 対策で SQLi に直接関係なし。

問題 13

シナリオ: ある企業が GCP で複数の VPC を持ち、各 VPC 間で通信したい。さらに、オンプレへ Cloud Interconnect で接続している。すべての VPC からオンプレに到達可能にし、トラフィックを中央 Hub VPC でフィルタリングしたい。

質問: 最適な構成はどれか。

選択肢:

A. Network Connectivity Center（NCC）で Hub & Spoke ネットワークを構築
B. VPC Peering をメッシュ状に構成
C. Cloud VPN ですべての VPC をフルメッシュ接続
D. すべてを 1 つの VPC に統合

解答と解説

正解: A

解説:

A が正解。Network Connectivity Center は Hub & Spoke モデルでマルチ VPC + オンプレ + 他クラウドを統合管理。中央 Hub でトラフィック制御。
B はメッシュが複雑、推移ルーティング不可。
C は VPC 内通信に VPN は非効率。
D は組織構造に合わない。

問題 14

シナリオ: あるグローバル企業が、GCP の Cloud Identity を使い、新入社員のオンボーディングを自動化したい。AD グループに基づき、適切な Google Workspace と GCP プロジェクトへのアクセスを自動付与する。

質問: 最適な構成はどれか。

選択肢:

A. Google Cloud Directory Sync（GCDS）+ Google Groups + IAM ロールバインディング
B. すべて手動で個別に付与
C. Cloud Functions で動的に作成
D. Compute Engine で自前 SSO サーバーを構築

解答と解説

正解: A

解説:

A が正解。GCDS で AD のグループメンバーシップを Google Groups に同期し、Google Groups に IAM ロールをバインドすればグループに入った瞬間に権限が付与される。
B は人為ミス・遅延あり。
C は再発明。
D は再発明。

問題 15

シナリオ: ある企業がデータレイクとして Cloud Storage を採用し、BigQuery で分析する。多数のチームがクエリを実行するが、機密データ（PII を含むカラム）のアクセスはチームごとに制限したい。

質問: 最適な構成として、必要な要素を 2 つ 選びなさい。

選択肢:

A. BigQuery のカラムレベル / 行レベルアクセス制御（Policy Tags + Data Catalog）
B. Authorized View で対象カラムを除外
C. すべてのチームに同じテーブルを公開
D. 機密データを別 GCP Organization に保管
E. すべてのデータを匿名化してから格納

解答と解説

正解: A, B

解説:

A: Policy Tags + Data Catalog でカラムレベル / 行レベルでチームごとにアクセス制御。
B: Authorized View でカラム除外 / 集計のみ公開も実用的。
C はアクセス制御不可。
D はオーバーキル。
E は使い物にならない（分析価値低下）。

問題 16

シナリオ: あるサーバーレスアプリケーションが Cloud Run functions（第 2 世代）と Cloud Run の両方を使う。コールドスタートを最小化し、レイテンシを安定させたい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Run の Minimum Instances を 1 以上に設定（CPU Always Allocated を有効化）
B. すべてのリクエストを Compute Engine 上の固定 VM で処理
C. Cloud Build で毎時再ビルド
D. Cloud Functions（第 1 世代）に書き換え

解答と解説

正解: A

解説:

A が正解。Cloud Run の Minimum Instances を 1 以上に設定すれば常時インスタンスが起動しており、コールドスタートを完全に回避可能。CPU Always Allocated（CPU 常時割り当て）で起動後の処理性能も安定。
B は本来のサーバーレスメリット消滅。
C は再ビルドでコールドスタート増加。
D は新世代より機能制約。

問題 17

シナリオ: ある銀行が機密データを処理するシステムを GCP に構築する。Cloud KMS の鍵を顧客側で完全に管理したい。Google にも鍵そのものを渡したくない（鍵そのものは外部 HSM で管理）。

質問: 最適な構成はどれか。

選択肢:

A. Cloud External Key Manager（EKM）で外部 HSM の鍵を Cloud KMS にラップ
B. Customer-Managed Encryption Keys（CMEK）を Cloud KMS で発行
C. Google-Managed Encryption Keys のみ
D. アプリケーション側で AES 暗号化

解答と解説

正解: A

解説:

A が正解。Cloud EKM（External Key Manager）は外部 HSM（Thales、Equinix SmartKey 等）の鍵を Cloud KMS から参照する仕組み。鍵そのものは GCP 外に留まり、Google にもアクセス不可。最高水準の鍵管理。
B は CMEK でも鍵は Cloud KMS 内（Google インフラ）に保管される。
C は Google 管理。
D は実装可能だが鍵管理は別途必要。

問題 18

シナリオ: あるアプリケーションが Compute Engine MIG（Managed Instance Group）で動作する。新しいバージョンをローリングアップデートでデプロイしたい。ダウンタイムなしで実施したい。

質問: 最適な構成はどれか。

選択肢:

A. MIG の Rolling Update を Surge と Max Unavailable を適切に設定して実施
B. 全 VM を一斉にシャットダウンして再起動
C. 新しい MIG を別途作成し、Load Balancer で 100% 切替
D. Cloud Build で再ビルド

解答と解説

正解: A

解説:

A が正解。MIG の Rolling Update は Surge（新規追加可能数）と Max Unavailable（一時停止可能数）を設定することで、ダウンタイムなしの段階デプロイが可能。
B はダウンタイム発生。
C もブルー / グリーン手法として有効だが、よりシンプルな A が標準。
D は再ビルドのみ。

問題 19

シナリオ: ある SaaS 企業が、各顧客のデータを完全に分離したい。同じ GCP インフラ上で、顧客 A のデータを顧客 B が見ることは絶対にできないようにする。

質問: 最適な構成（マルチテナンシー設計）として、必要な要素を 2 つ 選びなさい。

選択肢:

A. 顧客ごとに GCP プロジェクトを分離
B. 共有のデータベースで顧客 ID カラムでフィルタ
C. 顧客ごとに VPC を分離し、IAM 境界を厳格化
D. 各顧客のデータを同じテーブルに混在させる
E. すべての顧客に Owner ロールを与える

解答と解説

正解: A, C

解説:

A: プロジェクト分離が最も強固な分離。リソース・IAM・ログがプロジェクト単位で完全に独立。
C: VPC 分離 + IAM 厳格化で、ネットワーク・アクセス制御も顧客ごとに独立。
B、D は論理分離で同一テーブル混在のため、SQLi 等で漏洩リスク。
E はセキュリティ違反。

問題 20

シナリオ: ある ML チームが Vertex AI で訓練したモデルを REST API でホストし、社内アプリから低レイテンシで呼び出したい。さらに、A/B テスト（古いモデルと新しいモデルを 80% / 20% で分散）したい。

質問: 最適な構成はどれか。

選択肢:

A. Vertex AI Endpoint に複数モデルをデプロイし、Traffic Split を 80 / 20 に設定
B. Cloud Run に手動で 2 つのモデルをデプロイ
C. BigQuery ML で並列クエリ
D. すべてのモデルを Compute Engine で運用

解答と解説

正解: A

解説:

A が正解。Vertex AI Endpoint は同一エンドポイントに複数モデルバージョンをデプロイし、Traffic Split で A/B テスト・カナリアリリースが可能。
B は手動で煩雑。
C はオンライン推論には不向き（バッチ寄り）。
D は再発明。

問題 21

シナリオ: ある企業が GKE クラスタで動作するアプリのログを Cloud Logging に集約しているが、特定のエラーログを検出して即座に Slack に通知したい。さらに、頻度が高い場合は PagerDuty に通知する 2 段階アラート。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Logging のメトリクスフィルタで Log-based Metric を作成 → Cloud Monitoring Alert Policy で Slack（中優先度）と PagerDuty（高優先度）に通知
B. Cloud Logging から Cloud Functions に直接通知
C. メールでのみ通知
D. ログを全件 BigQuery にエクスポートし、定期クエリで通知

解答と解説

正解: A

解説:

A が正解。Log-based Metric + Alert Policy が標準。Notification Channel を複数（Slack、PagerDuty、メール）配分し、閾値ごとに異なる経路へ通知可能。
B は実装可能だが、Monitoring のアラート機能のリッチさには劣る。
C はリアクティブで弱い。
D は遅延あり。

問題 22

シナリオ: ある分析チームが BigQuery で複数のデータソース（オンプレ MySQL、SaaS API、Cloud Storage）を統合分析したい。データロード、変換、品質チェックを自動化したい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Data Fusion（マネージド ETL）+ Dataform（SQL ベース変換とバージョン管理）
B. Cloud Functions で個別にスクリプトを書く
C. Cloud Composer のみで Bash スクリプトを実行
D. 手動で BigQuery に CSV をアップロード

解答と解説

正解: A

解説:

A が正解。Cloud Data Fusion はビジュアル ETL ツール、Dataform は SQL ベースの ELT パイプライン管理。両者を組み合わせて品質チェック・変換・系譜を自動化。BigQuery と一体化したデータパイプラインの標準。
B はスクリプト保守が大変。
C はワークフロー実行のみで変換ロジックは不足。
D はスケールしない。

問題 23

シナリオ: ある企業が GCP で複数のチームに開発環境を提供する。各チームの環境は完全に独立し、IAM、ネットワーク、リソースを分離したい。ベストプラクティスのフォルダ構造を設計したい。

質問: 最適な階層構造はどれか。

選択肢:

A. Organization → Folder（環境別: dev/staging/prod）→ Folder（チーム別）→ Project
B. すべてのチーム / 環境を 1 つのプロジェクトに統合
C. Organization → Project（複数）のみフラットに作成
D. Organization → Folder（チーム別）→ Project（各 1 つ）

解答と解説

正解: A

解説:

A が正解。環境（dev/staging/prod）→ チーム → プロジェクトの階層が標準。Organization Policy を環境別 / チーム別に継承可能。
B は IAM 分離不可。
C は階層管理ができない。
D も妥当だが、環境別の Organization Policy 継承が弱くなる。

問題 24

シナリオ: ある E コマースサイトが、ユーザーごとに動的に変化する商品推薦を表示している。レコメンデーションは Vertex AI から取得するが、トラフィックの 80% は同じユーザーからの繰り返しアクセス。レイテンシとコストを下げたい。

質問: 最適な構成はどれか。

選択肢:

A. Memorystore for Redis にユーザーごとの推薦結果を TTL 付きでキャッシュ
B. すべてのリクエストで Vertex AI を呼び出す
C. BigQuery に毎回クエリ
D. Cloud Storage に保存し続ける

解答と解説

正解: A

解説:

A が正解。Memorystore for Redis に推薦結果をキャッシュすることで、レイテンシ大幅短縮 + Vertex AI API コール削減（コスト削減）。TTL でユーザー嗜好変化に追随。
B はコスト・レイテンシ悪化。
C はクエリレイテンシが大きい。
D は読み取りレイテンシが弱い。

問題 25

シナリオ: ある企業が GCP の Compute Engine と GKE 上のワークロードを Spot VM / Spot Pod で運用してコスト削減したい。バッチ処理が中心で、中断耐性がある。

質問: 最適な構成として、必要な要素を 2 つ 選びなさい。

選択肢:

A. Compute Engine の Spot VM を MIG で運用し、中断時に自動再スケジュール
B. GKE Spot ノードプール + Pod の preemptible: true 設定で中断耐性ワークロードを実行
C. すべてのワークロードを Spot VM で運用（本番含む）
D. オンデマンド VM のみで運用
E. すべての Pod を On-demand ノードプールで運用

解答と解説

正解: A, B

解説:

A: Compute Engine の Spot VM はオンデマンドの最大 91% 割引、MIG で中断時に自動再スケジュール。
B: GKE Spot ノードプールはバッチ / ML 訓練向け。tolerations 設定で中断耐性ワークロードのみ配置。
C は本番含めて Spot は危険。
D、E はコスト最適化されない。

問題 26

シナリオ: ある SaaS 会社が、顧客ごとに別の Google Cloud Storage バケットを作成する設計を採用している。顧客が増えるたびにバケット作成、IAM 設定、暗号化キー作成、ログ Sink 設定を自動化したい。

質問: 最適な構成はどれか。

選択肢:

A. Terraform Module を Cloud Build で実行（顧客 ID をパラメータ化）
B. 手動で gcloud コマンドを実行
C. Cloud Functions で動的にリソースを作成
D. 1 つの巨大バケットを全顧客で共有

解答と解説

正解: A

解説:

A が正解。Terraform Module をパラメータ化し、Cloud Build から CI / CD として実行することで Infrastructure as Code のベストプラクティスを実現。再現性、レビュー、ロールバック可能。
B はスケールしない。
C は実装可能だが、IaC 管理が弱い。
D はマルチテナンシー設計に反する。

問題 27

シナリオ: あるグローバル企業が、機密性の高いワークロード（金融取引）と通常のワークロードを GCP 上で混在運用する。機密ワークロードは特定のリージョンと CMEK のみで運用、外部 IP 禁止、ログは別プロジェクトに集約したい。

質問: 最適な構成として、必要な要素を 3 つ 選びなさい。

選択肢:

A. Organization Policy で機密ワークロード Folder にリージョン制限・外部 IP 禁止を強制
B. VPC Service Controls で機密ワークロードを境界に追加し、データ越境を防止
C. ログ集約 Sink を機密ワークロード Folder から専用ログプロジェクトへ配置
D. すべてのワークロードを同じプロジェクトで運用
E. CMEK を使わず Google-managed Keys のみ

解答と解説

正解: A, B, C

解説:

A: Organization Policy で機密 Folder にポリシー強制（リージョン、外部 IP）。
B: VPC SC で API レベルのアクセス制御。
C: ログ Sink で監査ログを別プロジェクトに集約（職務分離）。
D は分離なし。
E は機密用途には不十分。

問題 28

シナリオ: ある企業が GCP で動かす Java アプリケーションのデプロイで、本番デプロイ前にステージング環境で自動テスト（E2E、Smoke Test）を実施し、合格時のみ本番に進めたい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Deploy のリリースパイプラインで dev → staging → prod のステージを定義し、ステージ間に Approval Gate と Automated Verification を設定
B. Cloud Build で 1 つの巨大なステップで全 deploy を実行
C. 各環境に手動でデプロイ
D. すべて Cloud Functions に書き換える

解答と解説

正解: A

解説:

A が正解。Cloud Deploy はマネージド Continuous Delivery で、宣言型のリリースパイプライン、Approval、Verification（カスタム検証ジョブ）、ロールバックを統合提供。GCP の標準。
B はステージ管理が弱い。
C は人為ミスが多い。
D は別目的。

問題 29

シナリオ: ある組織が GCP リソースの構成変更を継続的に監視し、ポリシー違反（例: 暗号化なしのストレージ、外部 IP 持ち VM）を検出した場合に自動でアラートを発火させたい。

質問: 最適な構成はどれか。

選択肢:

A. Security Command Center（SCC）+ Cloud Asset Inventory + Cloud Functions（自動修復）
B. Cloud Logging で IAM ログだけ監視
C. Cloud Monitoring のメトリクスのみ
D. 月次手動レビュー

解答と解説

正解: A

解説:

A が正解。Security Command Center（SCC）は GCP のセキュリティ姿勢管理（CSPM）で、構成違反、脆弱性、脅威を統合検出。Cloud Asset Inventory と組み合わせて変更を追跡、Cloud Functions / Workflows で自動修復も可能。
B はカバー範囲が狭い。
C はメトリクスで構成違反検出は弱い。
D はリアクティブで遅い。

問題 30

シナリオ: あるアプリケーションが Pub/Sub → Dataflow → BigQuery を使うパイプラインを運用中。Dataflow ジョブのコスト最適化のため、ワーカー数や処理時間を最適化したい。

質問: 最適な構成として、必要な要素を 2 つ 選びなさい。

選択肢:

A. Streaming Engine + Horizontal Autoscaling で負荷追従
B. FlexRS（Flexible Resource Scheduling）を使い、Spot 相当の安価ワーカーで実行（バッチ）
C. すべてのジョブを最大のマシンタイプで実行
D. 単一ワーカーで実行
E. Compute Engine で自前 Dataflow ワーカーを管理

解答と解説

正解: A, B

解説:

A: Streaming Engine + Autoscaling で必要なワーカーのみ確保。
B: FlexRS はバッチワークロードで Spot 相当の割引価格。SLA に応じて柔軟スケジュール。
C はオーバープロビジョン。
D はスループット不足。
E は再発明。

問題 31

シナリオ: あるアプリケーションが Cloud Run でホストされている。本番デプロイ後、特定の地域のユーザーで遅延が発生していることが判明。問題のあるリクエストを特定し、ボトルネックを分析したい。

質問: 最適な構成はどれか。

選択肢:

A. OpenTelemetry で計装 + Cloud Trace で分散トレース取得 + Cloud Profiler で CPU プロファイル
B. Cloud Logging で全リクエストをログ出力
C. Cloud Monitoring のレイテンシダッシュボードのみ
D. アプリケーションの再起動

解答と解説

正解: A

解説:

A が正解。Cloud Trace + Cloud Profiler の組み合わせがレイテンシ分析の標準。OpenTelemetry で計装してマルチクラウド互換性も担保。
B はメッセージ多すぎ、構造化困難。
C はマクロのみ、リクエスト単位の追跡不可。
D は問題未解決。

問題 32

シナリオ: ある企業が GCP で MLOps を実装する。データサイエンティストが Vertex AI Workbench で実験 → モデルが本番品質に達したら Vertex AI Pipelines で訓練 → Vertex AI Endpoint にデプロイの流れを自動化したい。

質問: 最適な構成として、必要な要素を 3 つ 選びなさい。

選択肢:

A. Vertex AI Workbench（マネージド Jupyter）で実験
B. Vertex AI Pipelines で訓練 / 評価 / デプロイを宣言的に定義
C. Vertex AI Experiments でメトリクス比較
D. すべてを手動で実行
E. Cloud Functions のみで MLOps

解答と解説

正解: A, B, C

解説:

A: Vertex AI Workbench はマネージド Jupyter / Colab Enterprise で実験用途。
B: Vertex AI Pipelines（Kubeflow Pipelines マネージド）で本番訓練 / デプロイの自動化。
C: Vertex AI Experiments でモデル比較、再現性確保。
D は MLOps の方針に反する。
E は不十分。

問題 33

シナリオ: あるアプリケーションが Cloud SQL for PostgreSQL を使う。誤って大量データを削除してしまった。10 分前の状態に復旧したい。

質問: 最適な方法はどれか。

選択肢:

A. Cloud SQL の Point-in-Time Recovery（PITR）で 10 分前にリカバリ
B. 最後の自動バックアップから完全リストア
C. Cloud Storage のバックアップから手動復旧
D. すべて諦める

解答と解説

正解: A

解説:

A が正解。Cloud SQL の PITR は WAL ログを利用し、秒精度で過去の任意時点にリカバリ可能。最大保持期間（通常 7 日）以内なら 10 分前を指定可能。
B はバックアップ取得時刻まで戻り、それ以降の更新は失われる。
C は手動で時間がかかる。

問題 34

シナリオ: あるグローバル企業が、欧州のデータを EU 内に閉じ込めながら、グローバル全体の集計分析もしたい。データ越境制御とコスト・複雑性のバランスが必要。

質問: 最適な構成として、必要な要素を 2 つ 選びなさい。

選択肢:

A. リージョナル BigQuery + BigQuery Authorized View で集計のみ別リージョンに公開（生データは越境不可）
B. VPC Service Controls で EU プロジェクトを境界に追加
C. 全データを単一の Global BigQuery に集約
D. すべて手動で集計
E. データを暗号化して越境可能とする

解答と解説

正解: A, B

解説:

A: BigQuery のリージョナルデータセット + Authorized View で生データを越境させずに集計のみ別リージョンに公開。
B: VPC Service Controls の境界で API レベルの越境制御を強制。
C は越境違反。
D はスケールしない。
E は GDPR の越境制限は暗号化では緩和されない。

問題 35

シナリオ: ある企業が AI Agent を構築し、ユーザーの自然言語指示を解析して複数の社内 API を逐次呼び出すワークフローを構築したい。

質問: 最適なアーキテクチャはどれか。

選択肢:

A. Vertex AI Agent Builder（Agent Engine）で Gemini に Tools / Function Calling を定義
B. Cloud Run で独自 LLM を運用
C. Cloud Functions で if-else 分岐
D. Dialogflow ES のみ

解答と解説

正解: A

解説:

A が正解。Vertex AI Agent Builder（Agent Engine）は Gemini ベースの Tool Use（Function Calling）を宣言的に定義し、自然言語から複数 API を順次呼び出す Agentic Workflow を構築できる。
B は再発明、運用負荷大。
C は柔軟性が低い。
D は意図分類のみで Tool Use 不足。

問題 36

シナリオ: ある企業が GCP のリソース変更履歴と現在のリソースインベントリを集中管理したい。コンプライアンス監査時に過去 1 年間の構成を再現可能にしたい。

質問: 最適なサービスはどれか。

選択肢:

A. Cloud Asset Inventory + Cloud Asset Export to BigQuery
B. Cloud Logging のみ
C. Compute Engine 上で自前構成管理ツール
D. Cloud Build で監査スクリプト

解答と解説

正解: A

解説:

A が正解。Cloud Asset Inventory は GCP リソースの統一的なインベントリ。BigQuery Sink で長期保管、SQL で過去構成のクエリが可能。
B はリソース構成スナップショットは取れない。
C は再発明。

問題 37

シナリオ: あるアプリケーションが Cloud Run でホストされ、Cloud Storage にユーザーアップロードファイルを保管する。すべてのアップロードに対して自動でウイルススキャンを実行したい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Storage Object Finalize イベント → Cloud Run functions（VirusTotal API / ClamAV コンテナ）→ 結果ラベリングと隔離
B. ユーザーに手動スキャンを要求
C. すべてのファイルを削除
D. Cloud DNS で検査

解答と解説

正解: A

解説:

A が正解。Cloud Storage のイベントトリガで Cloud Run functions を呼び出し、ClamAV やサードパーティ API でスキャン、感染検出時に隔離 / メタデータで除外を実装するのが標準。
B、C、D は不適切。

問題 38

シナリオ: ある SaaS 企業が、各テナント（顧客）ごとに別々の Firestore データベースを使いたい。テナント数が増えても運用負荷を最小化したい。

質問: 最適な構成はどれか。

選択肢:

A. 単一プロジェクト内に Firestore Multi-Database（複数 DB インスタンス）を作成しテナントごとに分離
B. テナントごとに GCP プロジェクトを作成
C. 共有 Firestore データベースにテナント ID プレフィックスを付けて格納
D. テナントごとに Compute Engine VM で Firestore を運用

解答と解説

正解: A

解説:

A が正解。Firestore Multi-Database 機能（GA）は同一プロジェクト内で複数の Firestore DB を独立運用可能。データ完全分離 + 単一プロジェクト管理。SaaS マルチテナンシーの新標準。
B はオーバーキル、運用コスト増。
C は分離弱い。
D は再発明。

問題 39

シナリオ: あるアプリケーションが、Cloud Storage バケットのオブジェクトに対するアクセスログを残し、誰がいつ何を読んだかを監査したい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Audit Logs の Data Access ログ（読み取り）を有効化し、Log Sink で長期保存
B. Cloud Storage のオブジェクトメタデータを毎回確認
C. Cloud Build で監査
D. Cloud Logging の Admin Activity のみ

解答と解説

正解: A

解説:

A が正解。Data Access ログ（DATA_READ、DATA_WRITE）はオブジェクトアクセスを記録する。デフォルトで無効なので明示的に有効化。Log Sink で BigQuery / Cloud Storage に長期保管。
B はリアルタイムログにならない。
C は別目的。
D は管理操作のみで読み取りは含まない。

問題 40

シナリオ: あるアプリケーションが GKE 上で動作し、複数のマイクロサービスが内部で通信する。マイクロサービス間の認証をシークレットなしで実装したい（mTLS）。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Service Mesh（旧 Anthos Service Mesh）で自動 mTLS を有効化
B. 各 Pod に証明書を手動配布
C. 認証を一切しない
D. すべて API Gateway 経由で通信

解答と解説

正解: A

解説:

A が正解。Cloud Service Mesh は自動 mTLS でサービス間通信を暗号化・認証。Workload Identity と連携し、証明書管理ゼロ。
B は運用負荷大。
C はセキュリティ違反。
D はオーバーキル、L7 オーバーヘッド大。

問題 41

シナリオ: ある企業が、開発者がローカル PC から GCP リソースを操作するときに、長期 Service Account JSON Key を使わないようにしたい。短期トークンで認証したい。

質問: 最適な構成はどれか。

選択肢:

A. Workload Identity Federation（OIDC）+ gcloud auth login（ユーザー認証）
B. すべての開発者に Service Account Key JSON を配布
C. Compute Engine VM 経由でのみ操作
D. 認証なし

解答と解説

正解: A

解説:

A が正解。Workforce Identity Federation または gcloud auth application-default login で短期トークンを取得。Service Account Key は不要。Key 漏洩リスクを排除。
B はキー漏洩リスク（GCP のセキュリティベストプラクティス違反）。
C は煩雑。
D は論外。

問題 42

シナリオ: ある企業が、Cloud Storage 上の動画ファイルを Cloud CDN で配信したい。動画ファイルへの直接アクセスは制限し、有効期限付きの署名付き URL のみで配信したい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Storage の Uniform Bucket Access + Signed URL（V4）+ Cloud CDN で配信
B. Cloud Storage Bucket を Public に設定
C. Cloud Functions で動画をストリーミング再配信
D. Compute Engine 上にメディアサーバーを構築

解答と解説

正解: A

解説:

A が正解。Signed URL（V4）で有効期限付きアクセス制限。Cloud CDN を組み合わせてエッジキャッシュでパフォーマンス向上。
B はセキュリティ違反。
C はコスト・スケーラビリティ悪化。
D は再発明。

問題 43

シナリオ: ある企業が GKE 上でアプリケーションを運用。Pod がコンテナのまま脆弱性スキャンを実施し、本番デプロイ前にブロックしたい。

質問: 最適な構成として、必要な要素を 2 つ 選びなさい。

選択肢:

A. Artifact Registry の脆弱性スキャン（Container Analysis API）を有効化
B. Binary Authorization で署名済み / 脆弱性なしのイメージのみ Deploy 許可
C. 脆弱性チェックを実施しない
D. Cloud Run のみで運用
E. すべて手動レビュー

解答と解説

正解: A, B

解説:

A: Artifact Registry の脆弱性スキャンで CVE を継続検査。
B: Binary Authorization で署名チェック + スキャン結果の Attestation を要求し、未署名 / 脆弱性ありの Pod を Deploy 拒否。
C はセキュリティ違反。
D は別目的。
E はスケールしない。

問題 44

シナリオ: ある企業が複数の GCP リソースを Terraform で管理する。本番への適用前にプルリクエストでレビューし、適用前後の差分を確認したい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Build + Terraform: terraform plan を PR 時に実行し差分を PR コメント、terraform apply をマージ後に実行
B. ローカル PC から terraform apply を実行
C. 手動で gcloud コマンドを実行
D. Cloud Functions で動的に作成

解答と解説

正解: A

解説:

A が正解。Terraform + Cloud Build の標準パターン。GitOps による Infrastructure as Code のベストプラクティス。
B は再現性弱い。
C は IaC でない。
D は別目的。

問題 45

シナリオ: ある E コマースサイトが、ユーザーの問い合わせ対応を AI Agent で自動化したい。Agent は商品仕様、配送状況、返品ポリシーなど社内ドキュメントを参照しながら回答する。データソースは Google Drive、Confluence、ServiceNow。

質問: 最適な構成はどれか。

選択肢:

A. Vertex AI Search + Vertex AI Agent Builder で社内ドキュメントを取り込み、Gemini で回答生成
B. Cloud Run で独自 RAG パイプラインを構築
C. Gemini を社内ドキュメントでファインチューニング
D. Cloud Functions で 1 リクエストあたりすべて検索

解答と解説

正解: A

解説:

A が正解。Vertex AI Search は Drive、Confluence、ServiceNow 等のコネクタを内蔵したマネージド RAG。Agent Builder と組み合わせて Gemini に統合。
B は再発明で運用負荷大。
C はドキュメント更新が頻繁な場合非現実的。
D は実装可能だが Vertex AI Search の方がマネージド。

問題 46

シナリオ: あるアプリケーションが BigQuery にクエリを実行するが、クエリコストを予測したい。事前にコストを計算してから実行する仕組みが必要。

質問: 最適な構成はどれか。

選択肢:

A. BigQuery の --dry-run オプションでクエリのスキャンバイト数を事前計算
B. クエリを実行してから請求書を見る
C. Cloud Functions で見積もり
D. 推測する

解答と解説

正解: A

解説:

A が正解。BigQuery の dry-run は実際にクエリ実行せず、スキャンバイト数を返す。アプリケーションで事前計算して上限超過時はブロック可能。
B はリアクティブ。
C は再発明。

問題 47

シナリオ: あるアプリケーションが Cloud Run 上で動作し、本番リリースを段階的にロールアウトしたい。最初の 1 時間はトラフィックの 10%、次の 1 時間で 50%、最終的に 100% に切り替える。エラー率が閾値を超えたら自動ロールバックしたい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Deploy のリリースパイプラインで段階的トラフィック切替 + Cloud Monitoring でエラー率を監視、Cloud Functions で自動ロールバック
B. すべてのトラフィックを一度に切替
C. 手動で 30 分ごとに監視
D. Cloud Build で再ビルド

解答と解説

正解: A

解説:

A が正解。Cloud Deploy + Cloud Monitoring（SLO / Alert Policy）で自動ロールバック付きの段階リリースが GCP の標準。
B はリスク大。
C は属人的。
D は別目的。

問題 48

シナリオ: ある企業が ML モデルを本番運用中。モデルが特定の属性（性別、年齢）に対してバイアスを持っていないか継続的に評価したい。

質問: 最適な構成はどれか。

選択肢:

A. Vertex AI Model Evaluation でバイアスメトリクス（Demographic Parity、Equal Opportunity 等）を継続評価し、Vertex AI Model Monitoring と組み合わせる
B. 手動で目視確認
C. すべてのモデルを再訓練
D. バイアスは無視

解答と解説

正解: A

解説:

A が正解。Vertex AI Model Evaluation はバイアスメトリクスを評価する責任ある AI 機能。Vertex AI Model Monitoring と組み合わせて継続評価可能。2025 改訂の Responsible AI の核心。
B はスケールしない。
C はオーバーキル。
D は責任ある AI に反する。

問題 49

シナリオ: ある企業が GCP のコストを最適化したい。Compute Engine の長期稼働ワークロードに対して、3 年間の Committed Use Discounts（CUD）で割引を受けたい。

質問: 最適な構成として、必要な要素を 2 つ 選びなさい。

選択肢:

A. 3 年 Resource-based CUD（特定マシンタイプ）または Spend-based CUD（金額ベース）を購入
B. すべて On-demand で運用
C. Sustained Use Discount（自動適用）+ CUD（明示購入）の組み合わせを最大化
D. すべて Spot VM で運用（本番含む）
E. CUD は購入しない

解答と解説

正解: A, C

解説:

A: 3 年 CUD は最大の割引率（最大 70% 程度）。長期稼働ワークロードに最適。
C: Sustained Use Discount は自動適用、CUD は明示購入。両者は併用可能で最適化。
B、D、E は最適化されない。

問題 50

シナリオ: ある企業の SRE チームが、ある重要サービスについて「リクエストの 99.9% を 200 ms 以内に応答する」という SLO を運用している。エラーバジェット消費が急速に進む場合、即座にチームへアラートしたい。

質問: 最適な構成はどれか。

選択肢:

A. Cloud Monitoring SLO で SLI（レイテンシ）を定義し、Burn Rate Alert（短期 / 長期の 2 軸）を設定
B. 毎週 SRE が手動で計算
C. Cloud Build でアラート
D. Cloud Logging のみ

解答と解説

正解: A

解説:

A が正解。Burn Rate Alert は短期（1 時間）と長期（数日）の 2 軸で監視する SRE 推奨パターン。短期で大幅消費なら即時アラート、長期で持続消費なら計画的対応。Google SRE Book の標準実装。
B はリアクティブ。
C、D は別目的。

採点

正答数: ____ / 50
正答率: ____ %
合格ライン: 70 %（35 問以上）

セクション別正答数

問題番号と推奨セクションの対応表（弱点把握用）:

問題	セクション	内容
1, 2, 3, 4, 5	1-5	ケーススタディ: Cymbal Retail（Gen AI、スケール、DB、観測、AI 運用）
6, 7, 8, 9, 10	1-5	ケーススタディ: KnightMotives Automotive（IoT、データローカリティ、API 管理、MLOps、移行）
11, 13, 19, 23, 24, 38	Section 1	アーキ設計と計画
16, 18, 25, 26, 30, 49	Section 2	インフラ管理とプロビジョニング
12, 14, 15, 17, 27, 39, 40, 41, 42	Section 3	セキュリティとコンプライアンス
21, 22, 29, 31, 33, 36, 46	Section 4	技術ビジネスプロセス分析
20, 32, 34, 35, 37, 43, 45, 48	Section 5	実装管理
28, 44, 47, 50	Section 6	運用卓越性

セクション別の正答数を集計してください:

Section 1 (12 問): ___
Section 2 (8 問): ___
Section 3 (8 問): ___
Section 4 (8 問): ___
Section 5 (7 問): ___
Section 6 (7 問): ___

弱点別の復習ガイド

Section 1 で間違い多 → ../02_学習資料/01_アーキ設計と計画/
Section 2 で間違い多 → ../02_学習資料/02_インフラ管理とプロビジョニング/
Section 3 で間違い多 → ../02_学習資料/03_セキュリティとコンプライアンス/
Section 4 で間違い多 → ../02_学習資料/04_技術ビジネスプロセス分析/
Section 5 で間違い多 → ../02_学習資料/05_実装管理/
Section 6 で間違い多 → ../02_学習資料/06_運用卓越性/

復習のコツ

間違えた問題は当日中に解説を読み直す
同じ間違いを繰り返した場合、関連する公式ドキュメントを読む
2 週目では時間を計らず、各選択肢の正誤理由を言語化できるか確認
ケーススタディは要件 → 設計 → 検証の順で何度も読み直す
模擬試験 1 と組み合わせて 4 つのケーススタディ（Altostrat / EHR / Cymbal / KnightMotives）すべてに慣れる