Professional Cloud Architect 模擬試験 1

試験について

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

受験の心得

時間配分の目安

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

解答のコツ

PMI（プロジェクト管理）の視点で読む: コストか / 可用性か / セキュリティか / 期日か、シナリオの「制約」を読み取る
Google 推奨アーキテクチャを優先: Customer Managed Encryption Key より Google-managed の方が安価、など「マネージドを使え」が原則
キーワードに反応: 「最小限の運用」「マネージド」→ サーバーレス、「グローバル」→ Spanner / Global LB、「リフト & シフト」→ MIG / VM
2 つ以上の正解候補が残ったら: コスト・運用負荷の低い方を選ぶ
ケーススタディ問題: 必ずビジネス要件 → 技術要件 → 制約の順に読み返す
不明な問題はフラグ: 1 問に 2 分以上かけない。後で戻る

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

責任ある AI: Model Card、Data Card、バイアス評価、Vertex AI Model Garden
Agentic Workflow: Agent Builder、Vertex AI Agent Engine、RAG（Vertex AI Search、Vector Search）
データ準備: BigQuery + Vertex AI 統合、Dataform でのデータパイプライン
MLOps: Vertex AI Pipelines、Model Registry、Continuous Evaluation

ケーススタディ 1: Altostrat Media

会社概要

Altostrat Media はストリーミング、ニュース、ポッドキャストを提供するメディア企業。北米中心だが欧州・アジアへの展開を進めている。技術スタックは GKE をベースに、BigQuery を分析基盤、Cloud Run functions をイベント処理に使用。一部レガシーシステム（コンテンツ管理、課金）が自社データセンターに残存。

既存環境

コンピュート: GKE Standard（北米 us-central1）、Cloud Run functions（メディアトランスコード、メタデータ抽出）
データ: BigQuery（視聴ログ分析）、Cloud Storage（メディアアセット、合計 8 PB）、Cloud SQL for PostgreSQL（ユーザープロファイル）
オンプレ: コンテンツ管理（CMS）、課金（Oracle DB）
ID 管理: Microsoft AD + Google Cloud Identity（Cloud Identity Premium）連携
モニタリング: Cloud Monitoring + 自社 Prometheus / Grafana（メール通知のみ、PagerDuty 未導入）

ビジネス要件

B1: Gen AI を活用してコンテンツ推薦、要約、モデレーション（不適切コンテンツ検出）を自動化
B2: グローバルユーザーへの低レイテンシ配信（DACH、APAC 拡大）
B3: 視聴ログを使った収益化（広告主向け分析）
B4: コスト最適化。視聴ログは過去 30 日のみアクティブクエリで使用、それ以降はアーカイブ

技術要件

T1: GKE クラスタを欧州・APAC リージョンへ展開（マルチリージョン）
T2: ML 推論基盤を本番化。MLOps を整備
T3: オンプレ Oracle 課金 DB の段階的移行
T4: SRE プラクティスを導入。SLO / SLI を定義し、Cloud Monitoring + Prometheus を統合

問題 1

【ケーススタディ: Altostrat Media】

シナリオ: Altostrat Media は Gen AI を使ってユーザーが過去に視聴した履歴に基づいたコンテンツ推薦エンジンを構築したい。要件は「最新のメディアカタログの情報を反映すること」「ハルシネーションを最小化すること」「Vertex AI のマネージドサービスを優先すること」である。BigQuery にメディアカタログとユーザー視聴ログが格納されている。

質問: このユースケースに最も適したアーキテクチャはどれか。

選択肢:

A. Gemini モデルを Vertex AI から直接呼び出し、毎回プロンプトにメディアカタログ全件を含める
B. Vertex AI Search for media を使い、メディアカタログをデータストアとして登録し、検索結果を Gemini モデルにコンテキストとして渡す（RAG）
C. メディアカタログを CSV にエクスポートし、Gemini モデルにファインチューニングを実施する
D. メディアカタログを Cloud SQL に同期し、SQL クエリ結果を Gemini にプロンプトとして渡す

解答と解説

正解: B

解説:

B が正解。Vertex AI Search for media（旧 Vertex AI Search、Retail）は推薦・検索ユースケースに最適化されたマネージドの RAG ソリューション。最新カタログを取り込み、Gemini にコンテキストを渡すことでハルシネーションを抑制できる。
A は実用的でない（プロンプトサイズ超過、コスト高）。
C はカタログ更新ごとにファインチューニングが必要で運用負荷が高い。
D は実装可能だが、推薦エンジンとしての関連度スコアリングが弱く、Vertex AI Search の方が適切。

問題 2

【ケーススタディ: Altostrat Media】

シナリオ: Altostrat Media は GKE Standard クラスタを欧州・APAC へ展開する。グローバルでの低レイテンシ配信が求められる。3 リージョンにクラスタを配置し、ユーザーは最寄りのリージョンに自動ルーティングされる必要がある。コンテンツの一部（PII を含む欧州ユーザーデータ）は EU リージョン外に出してはならない。

質問: 要件を満たす GCP 構成として正しいものを 2 つ 選びなさい。

選択肢:

A. Global External Application Load Balancer + Multi-cluster Ingress でユーザーを最寄りクラスタへルーティング
B. Cloud DNS の Geolocation Routing Policy で各リージョン Network Endpoint Group にルーティング
C. Cloud CDN を有効化し、PII を含む API レスポンスもキャッシュする
D. Cloud Storage の dual-region（asia, eu）バケットを使い、欧州ユーザーデータを格納
E. VPC Service Controls で EU リージョンのプロジェクトを境界に含め、データ越境を防止

解答と解説

正解: A, E

解説:

A は正解。Multi-cluster Ingress（MCI）は Global LB と組み合わせて複数 GKE クラスタへ最寄りルーティングが可能。
E は正解。VPC Service Controls の境界で API レベルでの越境制御ができる。GDPR 対応にも有効。
B も可能だが、L7 のレイテンシ最適化や TLS 終端の点で MCI + Global LB のほうがマネージドで推奨される。
C は誤り。PII をキャッシュするのは原則禁止。
D は dual-region がストレージのレプリケーション設定であり、データ越境制御にはならない。リージョナルバケット + VPC SC が正解。

問題 3

【ケーススタディ: Altostrat Media】

シナリオ: Altostrat Media は視聴ログを BigQuery に保管しているが、データ量は 300 TB に達した。ビジネス要件として「過去 30 日はアクティブクエリで使用、31 日以降はアーカイブ、ただし監査目的で 7 年保持」がある。

質問: 最もコスト最適なアプローチはどれか。

選択肢:

A. BigQuery テーブルをそのまま 7 年保持する
B. BigQuery の Time travel と Fail-safe を 7 年に延長する
C. BigQuery の Partition Expiration を 30 日に設定し、エクスポート結果を Cloud Storage Archive クラスに保管する
D. BigQuery のテーブルパーティショニングで日付分割し、31 日以降のパーティションは Long-term storage 料金（自動適用）に任せ、7 年経過後に削除する

解答と解説

正解: D

解説:

D が正解。BigQuery のパーティションは 90 日連続未編集で自動的に Long-term storage 料金（約半額）に移行する。Active と Long-term は同一 API で同じクエリ性能のため、移行操作が不要。Partition Expiration を 7 年に設定すれば自動削除も可能。
A はストレージコストが Active のままで高い（Active は Long-term の倍）。
B は時間旅行の延長で逆にコスト増。本目的に無関係。
C は技術的に可能だが、再分析時に再ロードが必要となり運用負荷が高い。BigQuery 内 Long-term storage の方がシームレス。

問題 4

【ケーススタディ: Altostrat Media】

シナリオ: Altostrat Media は SRE プラクティスを導入したい。Cloud Monitoring と既存の Prometheus / Grafana を統合し、メール通知のみだったアラートを高優先度はオンコール、中優先度は Slack に送信する設計に変更する。SLO/SLI を整備する。

質問: 推奨される構成として最も適切なものはどれか。

選択肢:

A. Prometheus を廃止し、Cloud Monitoring のみに統一する
B. Managed Service for Prometheus を採用し、Cloud Monitoring に統合してアラート通知チャネルを PagerDuty / Slack に拡張、Cloud Monitoring の SLO 機能で SLI/SLO を定義
C. GKE 各ノードにエージェントレスで Prometheus を立てる、アラートは引き続きメール
D. Cloud Logging で SLI を計算、Prometheus は分析専用に分離

解答と解説

正解: B

解説:

B が正解。Managed Service for Prometheus（GMP）は既存の Prometheus と互換性を保ちながら、Cloud Monitoring の通知チャネル（PagerDuty、Slack、Webhook など）に統合できる。Cloud Monitoring の SLO 機能はビジネス SLO / SLI を定義しエラーバジェットを可視化できる。
A は既存資産（PromQL クエリ、ダッシュボード）を捨てることになり非推奨。
C はオンコール体制が整備されない。
D は SLI の計算に Cloud Logging を使う設計だが、メトリクス系は Cloud Monitoring SLO が標準。

問題 5

【ケーススタディ: Altostrat Media】

シナリオ: Altostrat Media はオンプレ Oracle で動く課金システムを段階的に GCP へ移行したい。要件は「ダウンタイムを最小限に」「短期的には Oracle 互換」「将来的にはマネージド DB へ移行」である。データサイズは 4 TB、月次トランザクション 1.2 億件。

質問: 最も適切な移行戦略はどれか。

選択肢:

A. Database Migration Service で Oracle から Cloud SQL for PostgreSQL に直接移行
B. Bare Metal Solution に Oracle を移行し、運用しながら Cloud SQL for PostgreSQL に段階移行
C. Compute Engine 上で Oracle を実行（BYOL）し、永続化
D. Cloud Spanner に直接データ移行する

解答と解説

正解: B

解説:

B が正解。Bare Metal Solution は Oracle ライセンスをそのまま使え、低レイテンシで GCP と接続可能。短期は Oracle 互換を維持しつつ、Database Migration Service で段階的に Cloud SQL for PostgreSQL に移行できる。
A は Oracle → PostgreSQL のスキーマ・関数変換が大規模で、ダウンタイム最小は困難。
C は GCP プレミアサポートの恩恵が薄く、Oracle の RAC 等の機能が制約される。
D はスキーマ全面再設計が必要で「短期 Oracle 互換」の要件に反する。

ケーススタディ 2: EHR Healthcare

会社概要

EHR Healthcare は電子カルテ（EHR）SaaS を病院・クリニックに提供。米国で最大級の市場シェアを持つ。複数のコロケーション施設で運用しているが、1 施設のリース契約が 2026 年に切れる。これを機に GCP へ移行を加速。

既存環境

コンピュート: 自社 K8s クラスタ（複数コロケーション）、レガシー VM
データ: MySQL（患者情報）、SQL Server（請求）、Redis（セッション）、MongoDB（医療画像メタデータ）
連携: 保険会社レガシー IF（SOAP、SFTP）
ID 管理: Microsoft Active Directory（オンプレ）
コンプライアンス: HIPAA 必須、99.9% 可用性 SLA

ビジネス要件

B1: リース切れの 1 施設を GCP へ完全移行
B2: 99.9% 可用性を確保。複数リージョンで冗長化
B3: HIPAA を遵守。患者データの暗号化と監査ログ
B4: 保険会社レガシー IF を維持しつつ、新規 API をモダン化

技術要件

T1: K8s ワークロードをマネージド化（GKE）
T2: AD と GCP の連携（SSO）
T3: データベース移行（マネージド化）
T4: コロケーション ⇔ GCP 間の高可用接続

問題 6

【ケーススタディ: EHR Healthcare】

シナリオ: EHR Healthcare はオンプレ MS Active Directory を ID マスターとして使い続けたい。GCP の Google Cloud Console、Workspace、各種 GCP API へのアクセスは AD のユーザーアカウントで SSO したい。

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

選択肢:

A. Google Cloud Directory Sync (GCDS) で AD から Cloud Identity にユーザーをプロビジョニングし、Active Directory Federation Services (ADFS) で SAML 2.0 SSO を構成する
B. AD ユーザーごとに Cloud Identity でパスワードを再設定し、手動でアカウントを作成する
C. Workforce Identity Federation を構成し、Cloud Identity を使わない
D. Cloud Identity 内で新規ユーザーを作成し、AD は廃止する

解答と解説

正解: A

解説:

A が正解。GCDS（同期エージェント）でアカウント情報を Cloud Identity にプロビジョニングし、認証は ADFS or Microsoft Entra ID を SAML IdP として使う。これがオンプレ AD を IdP として使う標準パターン。
B は運用負荷が極めて高い。
C は Workforce Identity Federation は Cloud Identity の代替になりうるが、Workspace 連携や Google Cloud Console との連携で Cloud Identity 不要というのは部分的に正しいが、SaaS 業務での EHR の要件（複数の GCP リソース管理）には Cloud Identity の方が安定。
D は AD 廃止が要件に反する。

問題 7

【ケーススタディ: EHR Healthcare】

シナリオ: EHR Healthcare は HIPAA 遵守のため、患者データに対して以下を実装する必要がある:

データの暗号化（保管時、転送中）
鍵管理の組織側コントロール
監査ログの長期保存
データ越境制御

質問: このセキュリティ要件を満たす GCP の組み合わせとして適切なものを 3 つ 選びなさい。

選択肢:

A. Cloud KMS で CMEK（Customer-Managed Encryption Keys）を発行し、Cloud SQL、Cloud Storage、BigQuery に適用
B. VPC Service Controls で患者データを保持する全プロジェクトを境界に追加
C. Cloud Audit Logs の Data Access ログを有効化し、Cloud Logging から BigQuery Sink を経由して長期保存
D. デフォルトの Google-managed Encryption Keys のみで運用
E. Cloud DLP（Sensitive Data Protection）で患者氏名・SSN を全カラム自動マスキングし、暗号化を不要にする

解答と解説

正解: A, B, C

解説:

A: CMEK は HIPAA で「鍵の可視性・ローテーション管理」を顧客が持つ必要がある場合の標準。
B: VPC Service Controls はデータ越境制御の唯一の手段。
C: Cloud Audit Logs Data Access を有効化し、BigQuery Sink に流して長期保存するのは監査要件のベストプラクティス。
D: Google-managed でも保管時暗号化は標準だが、HIPAA で求められる鍵の組織コントロールに不十分。
E: DLP は補助手段であり、暗号化の代替にはならない。

問題 8

【ケーススタディ: EHR Healthcare】

シナリオ: EHR Healthcare は 99.9% 可用性 SLA をデータベース層でも維持する必要がある。MySQL は中核の患者データを保持。マルチリージョン冗長で、リージョン障害時に RPO=0、RTO < 5 分を実現したい。

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

選択肢:

A. Cloud SQL for MySQL（HA 構成、リージョナル）
B. Compute Engine 上で MySQL を自己管理、マルチリージョンレプリケーション
C. AlloyDB for PostgreSQL（マルチリージョン）
D. Cloud SQL for MySQL のクロスリージョンレプリカ + Database Migration Service による Spanner 移行検討

解答と解説

正解: D

解説:

D が正解。Cloud SQL for MySQL はクロスリージョンレプリカで DR 可能（手動 / プログラムでフェイルオーバ）。ただし RPO=0 厳密保証は MySQL ネイティブには弱く、要件に応じて Spanner（MySQL 移行は機能差注意）も検討する。実務的には Cloud SQL の cross-region replica + 手動プロモーションが現実解。
A はリージョナル HA で 99.95% は出るが、リージョン障害時のフェイルオーバが不可。
B は運用負荷が高くマネージド化の方針に反する。
C は AlloyDB が MySQL 互換ではない（PostgreSQL 互換）ため移行困難。

問題 9

【ケーススタディ: EHR Healthcare】

シナリオ: EHR Healthcare はオンプレデータセンターのコロケーションと GCP を高可用な専用線で接続する必要がある。月次トランザクションは 50 TB のデータ転送がある。99.9% 可用性 SLA を必要とする。

質問: 最も適切な接続方式はどれか。

選択肢:

A. Cloud Interconnect: Dedicated 10 Gbps × 1 本
B. Cloud Interconnect: Dedicated 10 Gbps × 2 本（異なる Metropolitan Area）
C. Cloud VPN（HA VPN）のみで運用
D. Partner Interconnect 1 Gbps × 1 本 + Cloud VPN

解答と解説

正解: B

解説:

B が正解。99.9% SLA を得るには 2 本の Interconnect を異なる Metropolitan Area に配置する必要がある（同一 metro 4 本でも 99.9%、異なる metro 2 本で 99.99%）。Dedicated 10 Gbps は 50 TB / 月の転送に十分。
A は 1 本では SLA が低下し冗長性なし。
C は HA VPN で 99.99% SLA だが、50 TB のトラフィックには VPN のスループット（〜3 Gbps × トンネル）がボトルネックになる可能性が高い。
D は SLA 不十分。

問題 10

【ケーススタディ: EHR Healthcare】

シナリオ: EHR Healthcare は K8s ワークロードを GCP へ移行する際、複数の K8s クラスタを統合管理したい。クラスタごとに RBAC、ネットワークポリシー、コンプライアンス監査が必要。さらに、HIPAA 監査に必要な構成ポリシーをコードとして強制したい。

質問: 最も推奨される GCP サービスはどれか。

選択肢:

A. Anthos Config Management（Config Sync + Policy Controller）+ GKE Enterprise
B. Cloud Build で K8s マニフェストをデプロイ
C. 各クラスタごとに kubectl で手動構成
D. Cloud Deploy で各クラスタを CI/CD する

解答と解説

正解: A

解説:

A が正解。Anthos Config Management（現 GKE Enterprise Fleet 統合機能）は Config Sync で Git → クラスタへの宣言型ポリシー反映、Policy Controller（Gatekeeper ベース）で OPA ポリシーを強制できる。HIPAA 遵守のための「Pod に必ずセキュリティコンテキストを設定」「特定の Service Account のみが特権 Pod を作成可能」などをコードで強制可能。
B、D はデプロイの自動化だが、ポリシー強制（Compliance as Code）には不向き。
C はスケールしない。

独立問題

問題 11

シナリオ: あるスタートアップが新規 SaaS アプリケーションを構築する。要件は「グローバルユーザーへ低レイテンシで提供」「強整合性 RDBMS が必要」「自動スケール」「将来 10,000 QPS にも耐える」。

質問: 最も適切なデータベースはどれか。

選択肢:

A. Cloud SQL for PostgreSQL（リージョナル HA）
B. Cloud Spanner（マルチリージョン）
C. Firestore（マルチリージョン）
D. AlloyDB for PostgreSQL（リージョナル）

解答と解説

正解: B

解説:

B が正解。Cloud Spanner はグローバル分散・強整合性・水平自動スケールを兼ね備えた唯一の RDBMS。10,000 QPS 規模に十分対応。
A はリージョナルで Cloud SQL は単一リージョン制限。
C は強整合性 RDBMS の要件に部分的にしか合致しない（NoSQL）。
D は高性能 PostgreSQL だがリージョナル。

問題 12

シナリオ: ある製造業の組織が GCP 上に複数のプロジェクトを持ち、ネットワーク管理は中央 IT が一元化したい。各事業部はワークロードを自身のプロジェクトで運用するが、共通の VPC ネットワークと中央集権的なファイアウォール、Cloud Router を使う。

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

選択肢:

A. 各プロジェクトに VPC を作り、VPC Peering でメッシュ接続
B. Shared VPC（ホストプロジェクト + サービスプロジェクト）
C. Cloud Interconnect で各プロジェクトを接続
D. Cross-Project Service Account を使ってネットワークを共有

解答と解説

正解: B

解説:

B が正解。Shared VPC は中央 IT がネットワーク・FW・Cloud Router を管理し、各サービスプロジェクトは VM やリソースのみを作成する明確な責任分界に最適。
A はメッシュ化が複雑、ピアリング上限・推移制御の制約あり。
C は不要。
D は不可能。

問題 13

シナリオ: あるグローバル企業が GCP 上で複数の Organization、Folder、Project を持ち、共通のポリシー（外部 IP 禁止、特定リージョンのみ許可）を上位階層で適用したい。下位の Folder / Project はそのポリシーを継承する。

質問: 最も適切な機能はどれか。

選択肢:

A. IAM ロール
B. Organization Policy（組織のポリシー）
C. VPC Service Controls
D. Cloud Asset Inventory

解答と解説

正解: B

解説:

B が正解。Organization Policy は Organization → Folder → Project に継承され、制約（Constraint）として強制できる。constraints/compute.vmExternalIpAccess、constraints/gcp.resourceLocations などが該当。
A は「誰が」何をできるかであり「何をしてはいけない」を強制するものではない。
C はネットワーク境界の API レベルアクセス制御。
D は資産可視化ツール。

問題 14

シナリオ: あるアプリケーションが Cloud Storage 上にユーザー画像を保存する。Cloud Run の Web アプリから署名付き URL でユーザーがアップロードする。一時的に画像をアップロードできる権限を、特定ユーザーごとに 15 分間有効化したい。

質問: 最適な実装はどれか。

選択肢:

A. Cloud Storage の Bucket IAM に各ユーザーを追加
B. Cloud Run のサービスアカウントで Cloud Storage に書き込み、ユーザーは Cloud Run 経由でアップロード
C. Cloud Storage の Signed URL（V4）を Cloud Run から発行
D. ユーザーごとに Service Account を作成

解答と解説

正解: C

解説:

C が正解。Signed URL（V4）は時間制限付きでバケットへの直接アップロード / ダウンロードを許可。サーバーサイド処理を経由せずに大容量ファイルのやり取りが可能。15 分という時間制限も自然。
A はスケーラブルでない。
B も可能だが、サーバーリソースを大量に消費。スケール困難。
D は権限管理が複雑。

問題 15

シナリオ: ある企業が GCP の Compute Engine インスタンスでステートフルなデータベースワークロード（MySQL）を実行している。永続ボリュームのスナップショットを毎日取得し、別リージョンへ自動コピーしたい。

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

選択肢:

A. Cloud Scheduler + Cloud Run functions で毎日スナップショット取得
B. Persistent Disk のスナップショットスケジュール（マルチリージョン保存）
C. 自前で cron + gcloud コマンド
D. Database Migration Service を毎日実行

解答と解説

正解: B

解説:

B が正解。Persistent Disk Snapshot Schedule はマネージドの自動スナップショット機能で、ロケーション（マルチリージョン）も指定可能。運用負荷ゼロ。
A、C は自前運用で非推奨。
D は別の用途。

問題 16

シナリオ: ある金融サービスのアプリは PCI DSS 準拠が必要。クレジットカード番号を保存しないこと、検査時のログ提示が必要、Web アプリへの不正アクセス防御を多層で実装することが求められている。

質問: このコンプライアンス要件を満たす GCP の組み合わせとして適切なものを 2 つ 選びなさい。

選択肢:

A. Sensitive Data Protection（DLP）でクレジットカード番号を検出・トークン化
B. Cloud Armor で OWASP Top 10 攻撃をブロック
C. Cloud Storage に直接クレジットカード番号を平文保存し、CMEK で暗号化
D. Cloud Functions に対して認証なしで公開する
E. ファイアウォールルールで全 IP を許可

解答と解説

正解: A, B

解説:

A: DLP（現 Sensitive Data Protection）はクレジットカード番号を検出し、トークン化やマスキングが可能。PCI DSS 対応の標準パターン。
B: Cloud Armor は WAF / DDoS 対策で OWASP 攻撃をブロック。
C: 平文保存は PCI DSS で明確に禁止。
D、E は逆方向のセキュリティ後退。

問題 17

シナリオ: あるアプリケーションが Pub/Sub にイベントを発行し、Cloud Run functions で非同期処理する。処理失敗時にイベントが失われてはならず、リトライ後最終的に失敗したイベントは別の場所で検査したい。

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

選択肢:

A. Pub/Sub の Dead-letter Topic を構成、最大配信試行回数を 5 に設定
B. Cloud Run functions で try/catch して別の Pub/Sub topic に publish する
C. Cloud Logging にエラーを書き込んでいくだけ
D. BigQuery に直接 insert する

解答と解説

正解: A

解説:

A が正解。Pub/Sub の Dead-letter Topic（DLQ）はサブスクリプションの組み込み機能で、最大配信回数を超えたメッセージを自動で DLQ に送る。検査・再処理の標準。
B は自前実装で重複・抜けのリスクあり。
C はメッセージそのものを再処理不可能。
D は非推奨。

問題 18

シナリオ: ある企業が複数の Cloud Run サービスを運用している。各サービスは互いに API を呼び出し合うが、ネットワーク的に完全に内部閉域でセキュアに通信させたい。インターネット経由ではなく VPC 内で通信する必要がある。

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

選択肢:

A. Cloud Run サービスを Direct VPC Egress + 内部 Application Load Balancer 経由で公開する
B. Cloud Run サービスを Public のままにし、IAM で認証する
C. Cloud Functions に書き換える
D. Compute Engine 上にデプロイしなおす

解答と解説

正解: A

解説:

A が正解。Cloud Run の Direct VPC Egress（GA）で VPC 内に直接出ていき、Internal Application Load Balancer で受け取ることでサービス間通信を完全に VPC 内に閉じることができる。これが現代のベストプラクティス。
B は IAM 認証は重要だが、トラフィックがインターネット経由になる。
C、D は不要な再実装。

問題 19

シナリオ: ある AI チームが Vertex AI でモデルを訓練・デプロイしている。本番モデルのドリフト（入力データ分布の変化）と予測パフォーマンスを継続的に監視したい。

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

選択肢:

A. Vertex AI Model Monitoring
B. Cloud Monitoring のカスタム指標
C. BigQuery でログを集計
D. Looker で手動レポート

解答と解説

正解: A

解説:

A が正解。Vertex AI Model Monitoring は本番エンドポイントの入力データ分布のスキュー / ドリフトを検出し、アラートを発火できる。
B はメトリクス自体は出せるが、ドリフト検出のロジックを自前で書く必要がある。

問題 20

シナリオ: あるチームが、ユーザーリクエストに応じて社内ドキュメントから回答を生成する Gen AI チャットボットを構築したい。社内ドキュメントは Google Drive と Confluence に分散。Gemini モデルを使い、社内ドキュメントを参照しながら回答させたい。

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

選択肢:

A. Vertex AI Search を使ってドキュメントをデータストアに取り込み、Agent Builder で Gemini と組み合わせる
B. Gemini にドキュメント全文をプロンプトに毎回貼り付ける
C. Cloud Functions でドキュメントを検索し、結果を Gemini に渡す
D. ドキュメントを使ってモデルをファインチューニング

解答と解説

正解: A

解説:

A が正解。Vertex AI Search はマネージドの RAG ソリューションで、Google Drive、Confluence などのコネクタを内蔵。Agent Builder（Vertex AI Agent Engine / Conversational Agents）で Gemini と組み合わせることでチャットボットが構築できる。これが 2025 改訂で重要な「Agentic Workflow」のベストプラクティス。
B は実用的でない。
C は自前 RAG で運用負荷高。
D は社内ドキュメントの頻繁な更新に追随できない。

問題 21

シナリオ: ある企業が GKE で本番ワークロードを運用。Pod がノードにスケジュールされる際、特定の GPU 対応ノードに配置する必要がある。さらに、GPU を必要としない Pod が GPU ノードを占有しないようにしたい。

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

選択肢:

A. ノードプールに NodePool taint を設定（例: nvidia.com/gpu=true:NoSchedule）
B. GPU を必要とする Pod に対応する toleration を設定
C. Pod の hostNetwork を true にする
D. すべての Pod に GPU を要求する resource request を追加
E. Cluster Autoscaler を無効化する

解答と解説

正解: A, B

解説:

A: ノードに taint を打つことで、tolerate しない Pod は配置されない。
B: GPU 必要 Pod に toleration を設定すれば、taint をくぐり抜けて GPU ノードに配置可能。
A + B のセットが「特定 Pod のみ特定ノードに配置」の標準パターン。
C、D、E は不適切。

問題 22

シナリオ: あるアプリケーションが Cloud Run でホストされ、Cloud SQL for PostgreSQL に接続する。Cloud Run は VPC 外、Cloud SQL はプライベート IP を有効化している。VPC 内のリソースから Cloud SQL に接続したい。

質問: 最適な接続方式はどれか。

選択肢:

A. Serverless VPC Access Connector を構成し、Cloud SQL の Private IP に接続
B. Cloud Run に Direct VPC Egress を構成し、Cloud SQL Auth Proxy 経由で接続
C. Cloud SQL を Public IP に変更
D. Cloud Storage 経由でデータ転送

解答と解説

正解: B

解説:

B が正解。Direct VPC Egress（GA）は Serverless VPC Connector に置き換わる新しい推奨方式で、Connector のインフラ管理が不要、レイテンシも低い。Cloud SQL Auth Proxy or Private IP で直接接続。
A は実装可能だが、現在は Direct VPC Egress が推奨。
C はセキュリティ後退。
D は別目的。

問題 23

シナリオ: ある組織が Terraform で GCP リソースを管理している。複数のチームが Terraform Module を共有し、State ファイルを安全に保管したい。

質問: 最も適切な GCP の構成はどれか。

選択肢:

A. Cloud Storage バケットを Backend として使う（Object Versioning + State Locking）
B. Git に State ファイルを push する
C. Compute Engine 上で Terraform Enterprise を運用
D. Cloud Source Repositories に State を保管

解答と解説

正解: A

解説:

A が正解。GCS Backend は Terraform 公式の標準的な Backend で、State Locking もサポート（オブジェクトロック）。
B は機密情報漏洩リスクあり、絶対禁止。
C はオーバーキル。
D は別目的。

問題 24

シナリオ: あるアプリケーションが Pub/Sub → Dataflow → BigQuery のパイプラインを構築している。Pub/Sub のスループットがピーク時に変動するため、Dataflow のスケーリングが必要。

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

選択肢:

A. Dataflow Streaming Engine + Horizontal Autoscaling
B. Dataflow Batch Job を 5 分ごとに実行
C. Cloud Run functions で Pub/Sub を処理し、Dataflow を使わない
D. Compute Engine MIG で自前構成

解答と解説

正解: A

解説:

A が正解。Dataflow Streaming Engine + Horizontal Autoscaling はマネージドで負荷に応じてワーカーを自動スケール。スループット変動への自然な対応。
B はリアルタイム性が失われる。
C は小規模なら可能だが、複雑なウィンドウ処理や状態管理は Dataflow が向く。
D は運用負荷大。

問題 25

シナリオ: ある企業が Cloud Logging のコストを最適化したい。特に GKE のアクセスログが膨大で、ほとんど分析に使われていない。

質問: 最も適切な対策として、適切なものを 2 つ 選びなさい。

選択肢:

A. Log Router の Exclusion Filter で不要なログを除外
B. Logs Bucket の Retention を 30 日に短縮
C. すべてのログを停止する
D. すべてのログを BigQuery Sink にして Cloud Logging から削除
E. ログを暗号化する

解答と解説

正解: A, B

解説:

A: Exclusion Filter は Log Router で取り込み前に除外可能。コスト削減の最有効策。
B: Retention 短縮も直接的にコスト削減。
C は監査要件違反のリスク。
D は BigQuery 側のストレージコストが発生し、必ずしも安くならない。
E は無関係。

問題 26

シナリオ: あるアプリケーションが、複数の Cloud Run サービスと Cloud SQL を組み合わせて、Cloud Build で CI/CD を回している。本番デプロイ前にカナリアリリースを実装したい。

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

選択肢:

A. Cloud Deploy + Cloud Run の Traffic Splitting で 10% → 50% → 100% と段階的に切替
B. Cloud Build で 100% トラフィックを切替
C. すべてのトラフィックを古いリビジョンに留め、手動でテスト
D. Cloud Functions に書き換える

解答と解説

正解: A

解説:

A が正解。Cloud Deploy は GCP のマネージド Continuous Delivery で、Cloud Run の Traffic Splitting と組み合わせてカナリアリリースが自然に実装できる。
B は段階的でない。
C は CI/CD でない。

問題 27

シナリオ: ある SaaS の利用者が複数のテナントとなる B2B サービスを構築したい。テナント分離・ロール管理・SSO 連携を提供したい。テナントは複数の OIDC IdP（Okta、Auth0、Microsoft Entra ID）を利用している。

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

選択肢:

A. Identity Platform（多テナント対応）
B. Cloud Identity
C. Cloud IAM のみ
D. Workforce Identity Federation

解答と解説

正解: A

解説:

A が正解。Identity Platform は CIAM（Customer Identity and Access Management）の Google Cloud マネージド。多テナント、SAML / OIDC IdP 連携、MFA、パスキー対応。B2B SaaS の標準。
B は自社従業員向け。
C は GCP リソースアクセス制御。
D は GCP リソースに対する Workforce 連携。

問題 28

シナリオ: あるサーバレスアプリケーションが Cloud Run functions で動作する。本番障害時のデバッグのため、特定のリクエストの実行トレースを取得し、レイテンシのボトルネックを特定したい。

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

選択肢:

A. Cloud Trace + OpenTelemetry 計装
B. Cloud Logging のみ
C. Cloud Monitoring のメトリクスのみ
D. Profiler のみ

解答と解説

正解: A

解説:

A が正解。Cloud Trace は分散トレースのマネージド。OpenTelemetry 標準で自動計装も可能。レイテンシ・ボトルネック特定の最も直接的な手段。
B はレイテンシ詳細は取れない。
C はマクロな数値のみ。
D は CPU プロファイル。

問題 29

シナリオ: ある組織が複数の GCP プロジェクトのコストを可視化し、部門ごとに按分したい。さらに月次予算を超過した場合に自動でアラートを発火させたい。

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

選択肢:

A. Cloud Billing Account を組織紐づけし、Billing Export で BigQuery にエクスポート、Looker Studio で可視化、Budget Alerts を設定
B. Cloud Logging で IAM ログを集計
C. Cloud Asset Inventory で資産可視化
D. 手動で月次明細を取得

解答と解説

正解: A

解説:

A が正解。Billing Export to BigQuery が標準。Looker Studio で部門タグ別ダッシュボード作成、Budget Alerts で閾値超過時に Pub/Sub or メール通知。
B、C は別目的。

問題 30

シナリオ: ある eコマースサイトが Cloud Run でホストされており、ピーク時に DDoS 攻撃を受けた。Layer 7 攻撃、特に SQL Injection、XSS、Bot のブロックが必要。

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

選択肢:

A. Cloud Armor で WAF ルール（OWASP Top 10 のプリセット）を有効化
B. reCAPTCHA Enterprise を導入し Bot を判定
C. すべてのファイアウォールルールを 0.0.0.0/0 で許可
D. Cloud CDN を有効化して攻撃リクエストをキャッシュ層で吸収
E. Cloud Run を停止する

解答と解説

正解: A, B, D

解説:

A: Cloud Armor の WAF プリセットルールで OWASP Top 10 攻撃をブロック。
B: reCAPTCHA Enterprise は Bot 判定で偽トラフィック削減。
D: Cloud CDN はキャッシュ可能なリクエストをエッジで吸収し、オリジンへの負荷軽減。L3/L4 / L7 攻撃の影響を緩和。
C は逆方向。
E はサービス停止で論外。

問題 31

シナリオ: あるチームが GKE で動作する Java アプリケーションのパフォーマンスを改善したい。GC によるレイテンシ、メソッドごとの CPU 使用、ヒープ使用パターンを継続的に分析したい。

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

選択肢:

A. Cloud Profiler
B. Cloud Trace
C. Cloud Monitoring
D. Cloud Logging

解答と解説

正解: A

解説:

A が正解。Cloud Profiler は本番アプリのプロファイリングをサンプリングで取得（オーバーヘッド < 1%）。CPU、ヒープ、ロック、コンテンションを可視化。
B はトレース。
C はメトリクス。
D はログ。

問題 32

シナリオ: ある法務部門が、機密文書を S3 ストレージで管理している。GCP への移行を検討しており、保管要件は「7 年間、削除不可、改ざん不可」。

質問: 最も適切なストレージはどれか。

選択肢:

A. Cloud Storage の Bucket Lock + Retention Policy（7 年）
B. Cloud Storage Nearline
C. Cloud Storage の Object Versioning のみ
D. Cloud SQL に保管

解答と解説

正解: A

解説:

A が正解。Bucket Lock + Retention Policy（7 年）で WORM（Write Once Read Many）相当の Immutability を実現。Retention 期間中は削除不可、ロック後は変更不可。
B はストレージクラスの話で改ざん防止にならない。
C は復元可能だが削除可能。
D は不適切。

問題 33

シナリオ: あるグローバル企業が GCP に新規プロジェクトを多数作成し、組織のベストプラクティスとして「すべてのプロジェクトに監査ログを有効化」「外部 IP 禁止」「特定リージョンのみ許可」を強制したい。Terraform で組織レベルから定義したい。

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

選択肢:

A. Terraform で Organization Policy を Folder / Project に階層的に適用
B. 各プロジェクトに手動でログを有効化
C. Cloud Asset Inventory で違反を検出
D. Cloud Build でデプロイ前にチェック

解答と解説

正解: A

解説:

A が正解。Organization Policy を Folder / Project に階層的に適用するのが標準。Terraform でコード化することで再現性とレビューが可能。
B は運用負荷が高くスケールしない。
C は事後検出、未然防止にならない。
D は CI/CD 時のチェックで Organization 全体に強制できない。

問題 34

シナリオ: ある AI スタートアップが Vertex AI で Gemini Pro を Fine-tuning して特定ドメインに特化させたい。データセットは 1,000 件程度のチャットログ。応答品質を継続的に評価したい。

質問: 最適なアプローチはどれか。

選択肢:

A. Vertex AI の Supervised Fine-tuning（SFT）を使い、Vertex AI Experiments で評価メトリクスを追跡
B. オープンソースの LLaMA に切り替える
C. すべてのデータをプロンプトに毎回貼り付ける
D. BigQuery ML で別モデルを訓練

解答と解説

正解: A

解説:

A が正解。Vertex AI の Supervised Fine-tuning は Gemini モデルのドメイン特化に対応するマネージド機能。Vertex AI Experiments / Evaluation で BLEU、ROUGE、人手評価などのメトリクスを継続的に追跡可能。2025 改訂のキー項目。
B はサービス変更でコスト・運用負荷増。
C はトークン制限とコストの問題。
D は別目的（構造化データの ML）。

問題 35

シナリオ: あるグローバル企業が GCP で複数のチームが独立したワークロードを動かしている。チーム間でリソースのコストを按分するため、リソースに統一的なラベルを付けたい。さらに、特定ラベルが付いていないリソースは作成を拒否したい。

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

選択肢:

A. Resource Labels の規約をドキュメント化し、Terraform Module で強制
B. Organization Policy（カスタム制約）でラベル必須化を強制
C. すべてのリソースを手動でリネーム
D. Cloud Asset Inventory で違反検出のみ実装
E. Cloud Logging で違反者にアラート

解答と解説

正解: A, B

解説:

A: Terraform Module でラベル付与を強制するのが Infrastructure as Code のベストプラクティス。
B: Organization Policy のカスタム制約（Custom Constraints）で特定ラベル必須を組織レベルで強制可能。
C はスケールしない。
D は事後対応。
E は事後アラート。

問題 36

シナリオ: ある製造業の IoT プラットフォームで、工場の機器から 50 万 / 秒のテレメトリを GCP で取り込む必要がある。リアルタイム分析と長期保存の両方が必要。

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

選択肢:

A. Pub/Sub → Dataflow → BigQuery（リアルタイム）+ Cloud Storage（アーカイブ）
B. Cloud Functions → Cloud SQL
C. Compute Engine + Kafka 自己管理
D. Cloud Run → Firestore

解答と解説

正解: A

解説:

A が正解。Pub/Sub は数百万 QPS のスループットに対応。Dataflow（Streaming Engine）でリアルタイム処理と BigQuery 書き込み、並列で Cloud Storage に長期アーカイブ。これが GCP の標準 IoT パイプライン。
B はスループット不足。
C は運用負荷大。
D は不適切（リアルタイム分析弱い）。

問題 37

シナリオ: あるバックエンドアプリが GKE 上で動作し、Cloud SQL に接続する。Cloud SQL の認証情報（パスワード）を K8s Secret に保存しているが、より安全に管理したい。

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

選択肢:

A. Secret Manager に認証情報を保管し、Workload Identity Federation で GKE Pod が取得
B. ConfigMap に平文で保存
C. ノードのファイルシステムに保存
D. アプリケーションコード内にハードコード

解答と解説

正解: A

解説:

A が正解。Secret Manager + Workload Identity Federation は GKE のシークレット管理のベストプラクティス。Pod は Service Account を介して Secret Manager から動的に取得、ローテーションも容易。
B、C、D はすべてセキュリティ違反。

問題 38

シナリオ: ある分析チームが BigQuery で大規模クエリを定期実行している。コストを予測可能にしたい。クエリ単価よりも固定費の方が望ましい。

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

選択肢:

A. BigQuery Editions（Enterprise / Enterprise Plus）の Capacity Commitments + Reservations
B. BigQuery オンデマンドクエリのまま
C. すべてのクエリを Looker に移行
D. データウェアハウスを Cloud SQL に変更

解答と解説

正解: A

解説:

A が正解。BigQuery Editions（旧 Flat-rate）の Capacity Commitments + Reservations で固定費スロット予約が可能。大規模分析チームのコスト予測性を高める。
B はクエリ単価で予測困難。
C、D は別目的。

問題 39

シナリオ: あるアプリケーションが Cloud Run に複数のリビジョンをデプロイしている。本番障害発生時に、前のリビジョンへ即座にロールバックしたい。

質問: 最適な操作はどれか。

選択肢:

A. Cloud Run の Traffic を前のリビジョンへ 100% 切替
B. すべてのリビジョンを削除して再デプロイ
C. Cloud Build で再ビルド
D. Compute Engine を再起動

解答と解説

正解: A

解説:

A が正解。Cloud Run のリビジョンは履歴として保持され、Traffic Splitting で 100% を前リビジョンに切替えれば即時ロールバック。これが Cloud Run のリビジョン管理の利点。
B、C は時間がかかる。
D は無関係。

問題 40

シナリオ: ある企業が複数の GCP プロジェクトを持ち、各プロジェクトに対する IAM 権限を一元的に管理したい。さらに、休暇中の従業員の権限を一時的に剥奪したい。

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

選択肢:

A. Google Groups を Folder / Organization レベルで IAM Role 付与し、グループメンバ管理で権限制御
B. IAM Conditions（時間条件付きアクセス）を使う
C. ユーザー個別に各プロジェクトで Role を直接付与
D. Cloud Build で権限管理スクリプトを実行
E. すべてのユーザーに Owner を付与

解答と解説

正解: A, B

解説:

A: Google Groups + IAM Role 付与は組織の標準パターン。グループからメンバを外せば一括で権限剥奪可能。
B: IAM Conditions の時間条件で特定期間のみ権限付与（PAM の代替）。
C はスケールしない。
D は別目的。
E はセキュリティ違反。

問題 41

シナリオ: あるオンプレミスのデータセンターから GCP へ 100 TB のデータを一度に移行したい。インターネット経由では時間がかかりすぎる。

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

選択肢:

A. Transfer Appliance（物理デバイス）で大量データを輸送し、GCP にアップロード
B. Cloud Storage Transfer Service（ネットワーク経由）
C. gsutil で並列アップロード
D. Cloud VPN で接続

解答と解説

正解: A

解説:

A が正解。Transfer Appliance は 100 TB 以上の大規模データを物理デバイスで輸送する Google マネージド。ネットワーク帯域に依存しない一発移行に最適。
B はネットワーク経由で時間がかかる（100 TB は 10 Gbps でも数日）。
C も同様。
D は接続線だが、転送そのもののスピードは変わらない。

問題 42

シナリオ: ある金融機関が、リアルタイム不正検知システムを構築。1 秒以内にトランザクションを判定する必要がある。Vertex AI で訓練したモデルを本番運用する。

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

選択肢:

A. Vertex AI Online Prediction（Endpoint）+ Cloud Run の前段で前処理
B. Vertex AI Batch Prediction
C. BigQuery ML でクエリベース判定
D. AutoML を毎時再訓練

解答と解説

正解: A

解説:

A が正解。Vertex AI Online Prediction（Endpoint）は低レイテンシのリアルタイム推論に対応。Cloud Run で前処理ロジックを保持。
B はバッチで非リアルタイム。
C はクエリレイテンシが秒以下保証されにくい。
D は再訓練の話で推論ではない。

問題 43

シナリオ: あるアプリケーションが Cloud Storage に画像をアップロードする際、特定の画像（個人情報を含むもの）を自動検出してマスキングしたい。

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

選択肢:

A. Cloud Storage の Object Finalize イベント → Cloud Run functions → Sensitive Data Protection（DLP）で個人情報検出 → 結果を別バケットに保存
B. すべての画像を手動でレビュー
C. Compute Engine で画像処理パイプラインを構築
D. Cloud Vision API のみ

解答と解説

正解: A

解説:

A が正解。Cloud Storage Object Finalize イベントで Cloud Run functions をトリガし、Sensitive Data Protection（旧 DLP）の画像検査機能で個人情報を自動検出・マスキング。
B はスケールしない。
C は運用負荷大。
D は補助手段だが個人情報検出には DLP が直接的。

問題 44

シナリオ: ある E コマースサイトのバックエンドに Memorystore for Redis を採用したい。要件は「セッションキャッシュ」「99.9% 可用性」「リージョン障害時の DR」。

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

選択肢:

A. Memorystore for Redis Cluster（リージョナル）+ Memorystore for Redis Cluster をリージョン間で複製
B. Memorystore for Redis Basic Tier（単一ノード）
C. Compute Engine で Redis を自己管理
D. Firestore に置換

解答と解説

正解: A

解説:

A が正解。Memorystore for Redis Cluster はクラスタ構成で水平スケールとリージョナル可用性を提供。クロスリージョンレプリケーションで DR も実現可能。
B は単一ノードで HA なし。
C は運用負荷大。
D は別目的（NoSQL DB）。

問題 45

シナリオ: あるグローバルゲーム会社が、複数リージョンでマッチメイキングサーバーを運用する。リージョン間でプレイヤーステータスを強整合性で同期したい。

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

選択肢:

A. Cloud Spanner（マルチリージョン構成）
B. Cloud SQL（各リージョンに独立配置）
C. Firestore Datastore モード
D. Cloud Bigtable（マルチリージョン）

解答と解説

正解: A

解説:

A が正解。Cloud Spanner はマルチリージョン強整合性 RDBMS で、グローバルマッチメイキング、ゲーム内通貨残高、リーダーボードなどに最適。
B はリージョン間整合性なし。
C は強整合性だがマルチリージョンの整合性モデルが弱い。
D は KV ストアで複雑クエリ困難。

問題 46

シナリオ: あるアプリケーションが GKE 上で動作し、Pod が個別の Service Account を持って GCP API を呼び出したい（Cloud Storage、BigQuery など）。シークレット鍵をマウントしたくない。

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

選択肢:

A. GKE Workload Identity Federation（Workload Identity）で KSA と GSA を紐づけ
B. Pod に Service Account JSON Key をマウント
C. すべての Pod がノード SA を共有
D. Compute Engine SA を Pod 内に挿入

解答と解説

正解: A

解説:

A が正解。GKE Workload Identity は Kubernetes Service Account（KSA）を Google Service Account（GSA）に紐づけ、Pod がキーレスで GCP API を呼び出せる。シークレット鍵管理が不要。
B はキー漏洩リスク。
C は最小権限違反。
D は非推奨。

問題 47

シナリオ: ある組織が GCP に Landing Zone を構築する。複数のフォルダ構造、ネットワーク（Shared VPC）、IAM、ログ集約を初期設定したい。

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

選択肢:

A. Cloud Foundation Toolkit / Cloud Foundation Fabric を使って Terraform で Landing Zone を構築
B. Resource Manager で Folder 階層を作成し Organization Policy を継承
C. Cloud Logging 集約 Sink を Organization レベルに設定
D. すべてのプロジェクトを手動で作成
E. Cloud Functions で各プロジェクトを動的に作成

解答と解説

正解: A, B, C

解説:

A: Cloud Foundation Toolkit / Fabric は GCP の Landing Zone を構築する公式の Terraform モジュール群。
B: Folder 階層 + Organization Policy 継承は Landing Zone の根幹。
C: 集約 Sink で全プロジェクトのログを中央集権的に管理。
D は非効率。
E は別目的。

問題 48

シナリオ: あるチームが Gen AI Agent を構築。ユーザーの質問に対して、社内 API（顧客情報取得、在庫照会、注文作成など）を必要に応じて呼び出して回答する。Gemini モデルに「ツール呼び出し」機能を実装したい。

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

選択肢:

A. Vertex AI Agent Builder（Conversational Agents / Agent Engine）で Function Calling / Tools を定義
B. プロンプトに API ドキュメントを毎回貼り付ける
C. Cloud Functions で API を組み合わせる
D. Gemini を Fine-tuning する

解答と解説

正解: A

解説:

A が正解。Vertex AI Agent Builder は Tool Use / Function Calling をマネージドで提供。Agentic Workflow の標準。2025 改訂の重要項目。
B は実用的でない。
C は自前実装で運用負荷高。
D は別目的。

問題 49

シナリオ: あるアプリケーションが、Cloud Storage バケットへのアクセスパターン異常（短時間に大量ダウンロードなど）を検知してアラートを発火させたい。

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

選択肢:

A. Cloud Audit Logs（Data Access）+ Cloud Logging のメトリクスフィルタ + Cloud Monitoring アラートポリシー
B. Cloud Storage のオブジェクト ACL を頻繁にチェック
C. Cloud Build で毎日監査
D. Cloud DNS で監視

解答と解説

正解: A

解説:

A が正解。Cloud Audit Logs の Data Access ログを有効化し、Cloud Logging Metrics Filter でカウントメトリクスを定義、Cloud Monitoring Alert Policy で閾値超過時にアラート発火が標準。
B はリアクティブで遅い。
C は監査タイミングが粗い。
D は別目的。

問題 50

シナリオ: ある SRE チームが本番システムの SLO を「99.9%」に設定し、エラーバジェットを管理したい。エラーバジェット残量がリリースの可否判断に直接連動する。

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

選択肢:

A. Cloud Monitoring SLO 機能で SLI / SLO を定義し、Error Budget Burn Rate を監視、Cloud Deploy のデプロイ可否ポリシーに連動
B. SRE 担当者が毎週手動レビュー
C. Cloud Logging のみ
D. Cloud Build で SLO を計算

解答と解説

正解: A

解説:

A が正解。Cloud Monitoring の SLO 機能は SRE プラクティスを直接サポート。Burn Rate Alert で「短期に多く消費」「長期で消費」の両軸監視。リリース可否との連動も SRE の基本。
B は属人化。
C はメトリクス系でない。
D は別目的。

採点

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

セクション別正答数

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

問題	セクション	内容
1, 2, 3, 4, 5	1-5	ケーススタディ: Altostrat Media（設計、ネットワーク、データ、運用、移行）
6, 7, 8, 9, 10	1-5	ケーススタディ: EHR Healthcare（ID、セキュリティ、DB、ネットワーク、K8s）
11, 12, 13, 22, 36, 41	Section 1	アーキ設計と計画
15, 23, 24, 26, 39, 47	Section 2	インフラ管理とプロビジョニング
14, 16, 27, 32, 35, 37, 40, 46	Section 3	セキュリティとコンプライアンス
19, 20, 25, 28, 29, 30, 31	Section 4	技術ビジネスプロセス分析
17, 21, 33, 38, 42, 43, 44, 45	Section 5	実装管理
18, 34, 48, 49, 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 週目では時間を計らず、各選択肢の正誤理由を言語化できるか確認
ケーススタディは要件 → 設計 → 検証の順で何度も読み直す