Q1. あなたの組織は、Google Cloud上の新しいアプリケーションのためにリソース階層を設計しています。
開発環境と本番環境を分離する必要があります。
本番環境はCompute Engine上で2つのリージョンにデプロイされます。
組織はどの構成を選ぶべきですか。
A. すべての環境を1つのプロジェクトに作成し、ラベルを使って環境ごとにリソースを区別する。
B. すべての環境を1つのプロジェクトに作成し、タグを使って環境ごとにリソースを区別する。
C. 開発環境用に1つ、本番環境用に1つのプロジェクトを作成する。
D. 開発環境用に2つ、本番環境用に2つ（各リージョンに1つずつ）のプロジェクトを作成する。
回答
- C. 開発環境用に1つ、本番環境用に1つのプロジェクトを作成する。
-
プロジェクトはGoogle Cloudのリソース階層における基本的な分離・管理の単位です。
開発環境と本番環境はプロジェクト単位で分離するのがベストプラクティスで、IAM・課金・割り当て・ポリシーを独立して管理でき、誤操作の影響範囲を限定できます。
本番環境が2リージョンにまたがっても、1つのプロジェクト内に複数リージョンのリソースを配置すればよく、リージョンごとにプロジェクトを分ける必要はありません。
ラベルやタグは管理用のメタデータであり、環境分離の境界としては不十分です。
Google Cloud リソース階層 | Resource Manager ドキュメント
Q2. あなたの組織の一部の仮想マシンのオペレーティングシステムに、セキュリティ上の脆弱性がある可能性があります。
最新のセキュリティ更新が適用されていないすべての仮想マシンを、組織が最も効果的に特定するにはどうすればよいですか。
A. Security Command Center（セキュリティコマンドセンター）を表示し、脆弱性のあるディスクイメージを実行している仮想マシンを特定する。
B. Compliance Reports Manager（コンプライアンスレポートマネージャー）を表示し、最近のPCI監査レポートを特定してダウンロードする。
C. Security Command Centerを表示し、2週間以上前に起動された仮想マシンを特定する。
D. Compliance Reports Managerを表示し、最近のSOC 1監査レポートを特定してダウンロードする。
回答
- A. Security Command Centerを表示し、脆弱性のあるディスクイメージを実行している仮想マシンを特定する。
-
脆弱性の検出と一元的な可視化を担うのがSecurity Command Center（SCC）です。
Security Health AnalyticsやWeb Security Scannerが脆弱性を検出し、脆弱なディスクイメージを使用しているVMの特定に役立ちます。
Compliance Reports Manager（コンプライアンスレポートマネージャー）はPCIやSOC 1などの監査レポートをダウンロードするための機能で、個々のVMの脆弱性特定には使えません。
「2週間以上前に起動」という起動時期は脆弱性の有無と直接関係しないため誤りです。
脆弱性の検出結果 | Security Command Center ドキュメント
Q3. 組織がリリース頻度を高めるにつれ、VMベースのアプリケーション更新はOSの起動時間のためにローリング更新（rolling update）に時間がかかっています。
アプリケーションのデプロイをより高速にする必要があります。
組織は何をすべきですか。
A. VMをクラウドに移行し、リソースを追加する。
B. アプリケーションをコンテナに変換する。
C. VMのリソースを増強する。
D. アップグレードのロールアウトを自動化する。
回答
- B. アプリケーションをコンテナに変換する。
-
コンテナはOSの起動を伴わず、軽量で起動が高速です。
OSのブート時間がデプロイのボトルネックになっている場合、アプリのコンテナ化が最も効果的で、起動・デプロイを大幅に高速化できます。
VMのリソース増強（C）やクラウドへの移行とリソース追加（A）はブート時間の本質的な短縮にはなりません。
ロールアウトの自動化（D）は手順の自動化であって、OSの起動時間そのものを短縮するものではありません。
コンテナとは | Google Cloud
【古めの問題】Q4. プリエンプティブルVM（Preemptible VM）に関する次の記述のうち、正しいものはどれですか。
A. プリエンプティブルVMには固定価格がない。
B. AとBの両方。
C. 上記のいずれでもない。
D. 高性能計算（HPC）、ビッグデータと分析、継続的インテグレーション／継続的デリバリー（CI/CD）、レンダリング／トランスコーディング、テストなどのフォールトトレラントなワークロードにプリエンプティブルVMは使用できない。
回答
- C. 上記のいずれでもない。
-
プリエンプティブルVMは固定の低価格で提供され、通常インスタンスより最大約80%安価です。
したがって「固定価格でない」とするAは誤りです。
HPC・ビッグデータ・CI/CD・レンダリング・テストなどのフォールトトレラントな処理にはむしろ適しているため、Dも誤りです。
正しい記述が存在しないため、Cが正解となります。
なお現在はより新しいSpot VM（スポットVM）が後継として推奨されており、最大停止時間の制限がない点などが改善されています。
Spot VM | Compute Engine ドキュメント
【古めの問題】Q5. Migrate for Compute EngineとMigrate for Anthosは、どのように異なりますか。
A. Migrate for Anthosと異なり、Migrate for Compute Engineは移行元がVMware vSphereであることを前提とする。
B. Migrate for Compute Engineはイングレス（ingress）に課金するが、Migrate for Anthosは課金しない。
C. Migrate for Compute Engineはクローズドソースであり、Migrate for Anthosはオープンソースである。
D. Migrate for Anthosはコンテナへ移行し、Migrate for Compute Engineは仮想マシンへ移行する。
回答
- D. Migrate for Anthosはコンテナへ移行し、Migrate for Compute Engineは仮想マシンへ移行する。
-
両者の本質的な違いは、移行先がコンテナか仮想マシンかという点です。
Migrate for Anthos（現Migrate to Containers）はワークロードをコンテナへ移行し、Migrate for Compute Engine（現Migrate to Virtual Machines）はVMへ移行します。
よってDが正解です。
移行元がVMware vSphere限定とする記述（A）、オープンソース／クローズドソースの区別（C）、イングレス課金の差（B）はいずれも誤りです。
Migrate to Containers の概要 | Google Cloud ドキュメント
Q6. 標準SQL（Standard SQL）とデータウェアハウス内のデータを使って機械学習モデルを構築できる、Google Cloudのサービスまたは機能はどれですか。
A. BigQuery ML
B. TensorFlow
C. AutoML Tables
D. Cloud Bigtable ML
回答
- A. BigQuery ML
-
BigQuery MLは、データウェアハウスであるBigQuery内で標準SQLだけで機械学習モデルを作成・実行できる機能です。
データを別の環境へ移動させることなく、使い慣れたSQLでモデルを構築できる点が最大の特徴です。
TensorFlowはコード記述が必要なMLフレームワーク、AutoML Tablesは構造化データ向けのノーコードML（現在はVertex AIに統合）であり、Cloud Bigtable MLという製品は存在しません。
BigQuery ML の概要 | BigQuery ドキュメント
Q7. あなたの組織は、Cloud Storageバケットへのアクセスを制限する必要があります。
カナダを拠点とする従業員のみが内容を閲覧できるようにします。
この要件を満たす、最も効果的かつ効率的な方法はどれですか。
A. Cloud StorageバケットをカナダのGoogle Cloudリージョンにデプロイする。
B. カナダのIPアドレスからのみバケットへのアクセスを許可するようにGoogle Cloud Armorを構成する。
C. カナダを拠点とする各従業員に、個別にバケットへのアクセス権を付与する。
D. カナダを拠点とするすべての従業員からなるグループを作成し、そのグループにバケットへのアクセス権を付与する。
回答
- D. カナダを拠点とするすべての従業員からなるグループを作成し、そのグループにバケットへのアクセス権を付与する。
-
アクセス権はユーザーをグループにまとめて付与するのが、最も効率的かつ管理しやすい方法です。
カナダ拠点の従業員でグループを作り、そのグループにバケットへのアクセス権を与えれば、要件を満たしつつ運用負荷を抑えられます。
バケットをカナダリージョンに配置（A）してもデータの保存場所が決まるだけでアクセス制御にはなりません。
Cloud Armor（B）はHTTP(S)ロードバランサ向けの保護機能でCloud Storageの直接制御には不適、個別付与（C）は人数が増えるほど非効率です。
アクセス制御の概要 | Cloud Storage ドキュメント
【古めの問題】Q8. 開発チームが、Cloud Runにデプロイするアプリケーションを構築しています。
あなたは、設計するCI/CDパイプラインを使って、新しいバージョンのアプリケーションを可能な限り少ない手順でデプロイできるようにCI/CDパイプラインを設計しています。
CIパートでビルドしたアプリケーションのイメージを保存する場所を選ぶ必要があります。
どうすべきですか。
A. アプリケーションを含むCompute Engineイメージを作成する。
B. イメージをContainer Registry（コンテナレジストリ）に保存する。
C. イメージをCloud Storageに保存する。
D. アプリケーションを含むCompute Engineディスクを作成する。
回答
- B. イメージをContainer Registry（コンテナレジストリ）に保存する。
-
コンテナイメージは専用のコンテナレジストリに保存するのが、Cloud Runへのデプロイを最小手順で行う最適解です。
試験当時はContainer Registryが正解とされますが、Container Registryは2025年3月に廃止され、現在はArtifact Registry（アーティファクトレジストリ）が後継の推奨サービスとなっています。
Compute Engineのイメージやディスク（A・D）はVM用、Cloud Storage（C）は汎用オブジェクトストレージであり、いずれもコンテナイメージの管理には最適化されていません。
Artifact Registry の概要 | Google Cloud ドキュメント
Q9. あなたの組織はモバイルアプリを開発しており、そのために多機能でクラウドベースのコンピューティングプラットフォームを選びたいと考えています。
組織はどのGoogle Cloud製品または機能を使うべきですか。
A. Google Kubernetes Engine
B. Firebase
C. Cloud Functions
D. App Engine
回答
- B. Firebase
-
Firebaseは、モバイルおよびWebアプリを迅速に構築・拡張できるGoogleのアプリ開発プラットフォームです。
認証、データベース、ホスティング、分析、プッシュ通知など、モバイルアプリ開発に必要な機能を包括的に備えています。
GKE（A）、Cloud Functions（C）、App Engine（D）も計算基盤になり得ますが、モバイルアプリ向けに最も多機能で統合された選択肢はFirebaseです。
Firebase | Google のアプリ開発プラットフォーム
Q10. あなたの組織は、最近開発したアプリケーションのクリティカルな工程にあり、1か月後に本番稼働します。
数百万人のユーザーが新しいアプリケーションを使用すると見込まれています。
本番稼働時の障害を最小限にしたいと考えており、問題が発生した場合は数分以内に対応し、できる限り迅速に解決する必要があります。
どのサポートパッケージを選ぶべきですか。
A. Enhanced Support（エンハンスト サポート）
B. Standard Support（スタンダード サポート）
C. Basic Support（ベーシック サポート）
D. Premium Support（プレミアム サポート）
回答
- D. Premium Support（プレミアム サポート）
-
Premium Supportは、最重要度（P1）の問題に対し15分以内の応答時間と24時間365日のサポートを提供する最上位プランです。
数百万ユーザー規模の本番アプリで、障害を数分単位で迅速に解決したいという要件にはPremium Supportが最適です。
Basic（無料・本番非対応）、Standard、Enhancedは応答時間が長く、ミッションクリティカルな即時対応には不十分です。
なお、応答時間や提供内容は契約時点の公式情報で確認することを推奨します。
Google Cloud カスタマーケア（サポート）
