Q1. あなたは最近、ホテルの客室予約リクエストを処理するAPIをデプロイしました。
各顧客について、予約が1件成立するごとに、その顧客が実行できるAPI検索リクエストを最大1000件までに制限するクォータを適用する必要があります。
クォータは24時間ごとにリセットされるようにしたいと考えています。
1予約あたり正確に1000回の検索を許可することよりも、APIの速度を優先したいと考えています。
どうすればよいですか。
A. Apigeeのクォータ（Quota）ポリシーを、Synchronous設定をfalseにして構成します。予約のたび、または24時間が経過したときにクォータをリセットします。
B. 顧客IDをキーとするFirestoreドキュメントにクエリカウンターを保存します。予約が発生したとき、または24時間が経過したときにカウンターをゼロにリセットします。ユーザーのカウンターが1000を超えている場合は検索リクエストを拒否します。
C. 各顧客の検索リクエスト数をカウントするクエリカウンターをメモリ（インメモリ）に保存します。予約が発生したとき、または24時間が経過したときにカウンターをゼロにリセットします。ユーザーのカウンターが1000を超えている場合は検索リクエストを拒否します。
D. BigQueryに、検索リクエストと予約リクエストごとに顧客IDと現在時刻を含むテーブル行を保存します。過去24時間に行われた検索および予約リクエストの数をテーブルに対してクエリします。過去の検索リクエスト数が過去の予約リクエスト数の1000倍を超える場合は、検索リクエストを拒否します。
回答
- 正解: A
-
ApigeeのQuotaポリシーでSynchronous設定をfalseにすると、クォータのカウントが非同期で処理され、各リクエストでカウンター更新の完了を待たずに応答できます。
設問は「正確に1000回」よりもAPIの速度を優先しており、非同期カウントは多少の誤差を許容しつつ高いパフォーマンスを実現します。
予約発生時や24時間経過時のクォータリセットもポリシー側で構成できます。
BigQueryやFirestoreを用いる方式はカウントが厳密ですが、リクエストごとに読み書きが発生し速度面で不利です。
インメモリ方式は複数インスタンス間でカウンターを共有できず信頼性に欠けます。
Apigee Quota policy（公式ドキュメント）
Q2. あなたは、ユーザーが昼夜を問わずゲームを操作するため、トラフィックパターンが予測できないシングルプレイヤー向けモバイルゲームのバックエンドを開発しています。
リクエストを処理するのに十分なリソースを確保しつつ、過剰なプロビジョニングを最小限に抑えることでコストを最適化したいと考えています。
また、トラフィックの急増を効率的に処理できるシステムにしたいと考えています。
どのコンピューティングプラットフォームを使用すべきですか。
A. Cloud Run
B. マネージドインスタンスグループを使用するCompute Engine
C. アンマネージドインスタンスグループを使用するCompute Engine
D. クラスタオートスケーリングを使用するGoogle Kubernetes Engine
回答
- 正解: A
-
Cloud Runはリクエスト量に応じて自動的にスケールし、トラフィックがないときはゼロまでスケールインできるフルマネージドのサーバーレスプラットフォームです。
予測不能なトラフィックと急増を効率的に処理しつつ、使用した分だけ課金されるため過剰プロビジョニングを最小化でき、コスト最適化の要件に最も適合します。
Compute Engine（マネージド／アンマネージド）はVM単位のスケールでゼロまで縮小できず、起動も比較的遅いため不向きです。
GKEのクラスタオートスケーリングはノード追加に時間がかかり、過剰プロビジョニングが発生しやすい点で要件に劣ります。
Cloud Run の概要（公式ドキュメント）
Q3. あなたはCI/CDチームと協力し、チームが新たに導入した機能のトラブルシューティングを行っている開発者です。
CI/CDチームはHashiCorp Packerを使用して、あなたの開発ブランチから新しいCompute Engineイメージを作成しました。
イメージのビルドは成功しましたが、起動しません。
CI/CDチームと連携してこの問題を調査する必要があります。
どうすればよいですか。
A. デプロイ済みの仮想マシンをシャットダウンし、ディスクをエクスポートして、ローカルにマウントすることで起動ログにアクセスします。
B. ローカルにPackerをインストールしてCompute Engineイメージをローカルでビルドし、自分の個人用Google Cloudプロジェクトで実行します。
C. 新しい機能ブランチを作成し、ビルドチームにイメージの再ビルドを依頼します。
D. シリアルポートを使用してCompute EngineのOSログを確認し、シリアルポートへのアクセスを確認するためにCloud Loggingのログを確認します。
回答
- 正解: D
-
VMが起動しない問題を調査する際、Googleが推奨する手段はシリアルコンソール（シリアルポート出力）の確認です。
起動に失敗してもシリアルポート出力はブートプロセスのメッセージを記録するため、起動失敗の原因を直接特定できます。
シリアルポート出力はCloud Loggingに転送して保存・確認することも可能です。
ディスクをローカルにマウントする方法（A）は手間が多く、起動段階のログを得にくい場合があります。
ローカルでの再ビルド（B）や再依頼（C）は原因の調査そのものにはつながりません。
シリアルコンソールを使用したトラブルシューティング（公式ドキュメント）
Q4. あなたは、ユーザーに静的コンテンツを配信する、高可用性かつグローバルにアクセス可能なアプリケーションを構築しています。
ストレージと配信のコンポーネントを構成する必要があります。
管理オーバーヘッドとレイテンシを最小限に抑えつつ、ユーザーに対する信頼性を最大化したいと考えています。
どうすればよいですか。
A. 1. マネージドインスタンスグループを作成し、静的コンテンツを各仮想マシン（VM）に複製します。2. 外部HTTP(S)ロードバランサを作成します。3. Cloud CDNを有効にし、トラフィックをマネージドインスタンスグループに送信します。
B. 1. アンマネージドインスタンスグループを作成し、静的コンテンツを各VMに複製します。2. 外部HTTP(S)ロードバランサを作成します。3. Cloud CDNを有効にし、トラフィックをアンマネージドインスタンスグループに送信します。
C. 1. StandardストレージクラスのリージョナルなCloud Storageバケットを作成し、静的コンテンツをバケットに格納します。2. 外部IPアドレスを予約し、外部HTTP(S)ロードバランサを作成します。3. Cloud CDNを有効にし、トラフィックをバックエンドバケットに送信します。
D. 1. StandardストレージクラスのマルチリージョンのCloud Storageバケットを作成し、静的コンテンツをバケットに格納します。2. 外部IPアドレスを予約し、外部HTTP(S)ロードバランサを作成します。3. Cloud CDNを有効にし、トラフィックをバックエンドバケットに送信します。
回答
- 正解: D
-
静的コンテンツの配信では、VMを運用するよりもCloud Storageバケットをバックエンドにする方が管理オーバーヘッドを大幅に削減できます。
高可用性にはマルチリージョンのCloud Storageバケット、グローバルなアクセスには外部HTTP(S)ロードバランサ、低レイテンシ配信にはCloud CDNが最適な組み合わせです。
リージョナルバケット（C）は単一リージョンに限定され可用性で劣ります。
インスタンスグループ方式（A・B）はVMの複製・管理が必要で、要件である管理負荷の最小化に反します。
Cloud Storage バケットでの Cloud CDN 設定（公式ドキュメント）
Q5. あなたのチームは、Cloud StorageのイベントによってトリガーされるCloud Functionを開発しています。
Googleが推奨するベストプラクティスに従いながら、Cloud Functionのテストと開発を高速化したいと考えています。
どうすればよいですか。
A. 元のCloud Functionでcloudfunctions.functions.sourceCodeSet操作がCloud Audit Logsによって検出されたときにトリガーされる新しいCloud Functionを作成します。新しい関数にモックリクエストを送信して機能を評価します。
B. Cloud Functionのコピーを作成し、コードをHTTPトリガー型に書き換えます。HTTPエンドポイントをトリガーして新しいバージョンを編集・テストします。新しい関数にモックリクエストを送信して機能を評価します。
C. Functions Frameworkライブラリをインストールし、localhostでCloud Functionを構成します。関数のコピーを作成し、新しいバージョンに編集を加えます。curlを使って新しいバージョンをテストします。
D. Google CloudコンソールでCloud Functionのコピーを作成します。コンソールのインラインエディタを使って新しい関数のソースコードを変更します。新しい関数を呼び出すようにWebアプリケーションを変更し、本番環境で新しいバージョンをテストします。
回答
- 正解: C
-
Functions Framework（ファンクションフレームワーク）は、Cloud Functionのコードをローカル環境で実行・テストするためにGoogleが提供する公式ライブラリです。
ローカルでcurlなどを使って関数を呼び出して検証できるため、デプロイを待たずに開発サイクルを大幅に高速化でき、これがGoogle推奨のベストプラクティスです。
本番環境でのテスト（D）はリスクが高く推奨されません。
HTTPトリガー型への書き換え（B）や監査ログ連携（A）は本来のトリガー条件を再現できず、余計な複雑さを招きます。
Functions Framework（公式ドキュメント）
Q6. あなたは、次の設計要件を持つ新しいアプリケーションを開発しています。
– アプリケーションインフラの作成と変更がバージョン管理され、監査可能であること。
– アプリケーションとデプロイインフラが、可能な限りGoogleマネージドサービスを使用していること。
– アプリケーションがサーバーレスのコンピューティングプラットフォームで動作すること。
アプリケーションのアーキテクチャをどのように設計すべきですか。
A. 1. アプリケーションとインフラのソースコードをGitリポジトリに格納します。2. Cloud Buildを使用してTerraformでアプリケーションインフラをデプロイします。3. パイプラインのステップとしてアプリケーションをCloud Functionにデプロイします。
B. 1. Google Cloud MarketplaceからJenkinsをデプロイし、Jenkinsで継続的インテグレーションパイプラインを定義します。2. パイプラインのステップで、Gitリポジトリからアプリケーションのソースコードを取得します。3. パイプラインのステップで、アプリケーションのソースコードをApp Engineにデプロイします。
C. 1. Cloud Buildで継続的インテグレーションパイプラインを作成し、Deployment Managerテンプレートを使ってアプリケーションインフラをデプロイするようにパイプラインを構成します。2. 最新のアプリケーションソースコードを含むコンテナを作成するパイプラインステップを構成します。3. パイプラインのステップとしてコンテナをCompute Engineインスタンスにデプロイします。
D. 1. gcloudコマンドを使用してアプリケーションインフラをデプロイします。2. Cloud Buildを使用して、アプリケーションソースコードの変更に対する継続的インテグレーションパイプラインを定義します。3. Gitリポジトリからアプリケーションソースコードを取得し、コンテナ化されたアプリケーションを作成するパイプラインステップを構成します。4. パイプラインのステップとして、新しいコンテナをCloud Runにデプロイします。
回答
- 正解: A
-
インフラの作成・変更をバージョン管理し監査可能にするには、Infrastructure as Code（IaC）をGitで管理する構成が必要です。
ソースコードとインフラ定義をGitに格納し、Cloud BuildとTerraformでデプロイ、サーバーレスのCloud Functionに展開する構成（A）が全要件を満たします。
gcloudコマンド（D）は宣言的なバージョン管理ができず、監査要件に反します。
Jenkins（B）はGoogleマネージドではなく自己管理が必要です。
Compute Engineへのデプロイ（C）はサーバーレス要件を満たしません。
Terraform のベストプラクティス（公式ドキュメント）
Q7. あなたの会社では、Google Cloudに保存されるすべてのデータを顧客管理の暗号鍵（CMEK）で暗号化することを求める新しいセキュリティ施策が導入されました。
Cloud Key Management Service（KMS）を使用して鍵へのアクセスを構成する予定です。
「職務の分離（separation of duties）」の原則と、Googleが推奨するベストプラクティスに従う必要があります。
どうすればよいですか。（2つ選択してください。）
A. Cloud KMSを専用のプロジェクトでプロビジョニングします。
B. Cloud KMSプロジェクトにオーナーを割り当てません。
C. 鍵が使用されるプロジェクト内でCloud KMSをプロビジョニングします。
D. Cloud KMSの鍵が使用されるプロジェクトのオーナーに、roles/cloudkms.admin ロールを付与します。
E. Cloud KMSの鍵が使用されるプロジェクトのオーナーとは別のユーザーに、Cloud KMSプロジェクトのオーナーロールを付与します。
回答
- 正解: A, B
-
職務の分離を実現するには、鍵の管理と鍵の利用を別の権限・別のプロジェクトに分けることが重要です。
Cloud KMSを専用プロジェクトに配置し（A）、そのプロジェクトにはオーナーを割り当てず（B）、組織レベルの管理者でIAMポリシーのみを制御するのがGoogle推奨の構成です。
オーナーがいないことで、鍵を直接管理・使用できる単一の特権者を排除できます。
鍵利用プロジェクトと同居させる（C）構成や、利用側オーナーにKMS管理ロールを付与する（D）構成は分離原則に反します。
Cloud KMS の職務の分離（公式ドキュメント）
Q8. あなたのセキュリティチームは、Google Kubernetes Engineで稼働しているすべてのデプロイ済みアプリケーションを監査しています。
監査の結果、一部のアプリケーションがクラスタ内のトラフィックを平文（クリアテキスト）で送信していることが判明しました。
アプリケーションへの変更を最小限に抑え、Googleのサポートを維持しながら、すべてのアプリケーショントラフィックをできるだけ早く暗号化する必要があります。
どうすればよいですか。
A. ネットワークポリシー（Network Policies）を使用して、アプリケーション間のトラフィックをブロックします。
B. Istioをインストールし、アプリケーションの名前空間でプロキシのインジェクションを有効にし、mTLSを有効にします。
C. アプリケーション内で信頼できるネットワーク範囲を定義し、それらのネットワークからのトラフィックのみを許可するようにアプリケーションを構成します。
D. 自動化されたプロセスを使用してLet’s EncryptからアプリケーションのSSL証明書をリクエストし、それをアプリケーションに追加します。
回答
- 正解: B
-
サービスメッシュ（Istio／現在はGoogle管理のCloud Service Mesh）はサイドカープロキシをインジェクションすることで、アプリケーションコードを変更せずに相互TLS（mTLS）による自動暗号化を実現します。
プロキシインジェクションとmTLSを有効にするだけで、クラスタ内の全トラフィックを最小限の変更で暗号化でき、Googleサポートも維持できます。
ネットワークポリシー（A）はトラフィックを制御しますが暗号化はしません。
アプリ内での信頼範囲定義（C）やLet’s Encrypt証明書の手動追加（D）はアプリ変更が大きく要件に反します。
Cloud Service Mesh の mTLS（公式ドキュメント）
Q9. データ移行の一環として、オンプレミスの仮想マシンからGoogle Cloud Storageにファイルをアップロードしたいと考えています。
これらのファイルは、GCP環境のCloud Dataproc Hadoopクラスタで利用されます。
どのコマンドを使用すべきですか。
A. gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
B. gcloud cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
C. hadoop fs cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
D. gcloud dataproc cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
回答
- 正解: A
-
ローカルのファイルをCloud Storageにコピーする標準的なコマンドは gsutil cp です。
gsutil cp [ローカルオブジェクト] gs://[バケット名]/ の構文でオンプレミスからCloud Storageへ直接アップロードでき、これが正しいコマンドです。
gcloud cp や gcloud dataproc cp はオブジェクトコピー用コマンドとして存在しません。
hadoop fs cp はHDFS内の操作用で、ローカルからの初回アップロードには適しません。
なお現在はより新しい gcloud storage cp も利用できますが、選択肢の中ではgsutil cpが正解です。
gsutil cp コマンド（公式ドキュメント）
Q10. あなたはGoogle Kubernetes Engine（GKE）のクラスタ管理者です。
組織のクラスタはリリースチャンネルに登録されています。
利用可能なアップグレードやセキュリティ情報（セキュリティ速報）など、GKEクラスタに影響する関連イベントについて通知を受けたいと考えています。
どうすればよいですか。
A. クラスタ通知（cluster notifications）をPub/Subトピックに送信するように構成します。
B. google_cloud_release_notes BigQueryデータセットに対してスケジュールされたクエリを実行します。
C. 利用可能なバージョンをGKE APIに対してクエリします。
D. GKEリリースノートの日次サマリーを受け取るRSS購読を作成します。
回答
- 正解: A
-
GKEには、特定のクラスタに影響するアップグレード情報やセキュリティ速報などのイベントをPub/Subトピックに配信する「クラスタ通知」機能があります。
クラスタ通知をPub/Subトピックに送信するよう構成すると、対象クラスタに関連するイベントをリアルタイムかつ自動的に受け取れます。
BigQueryのスケジュールクエリ（B）やGKE APIへのクエリ（C）は能動的なポーリングが必要です。
RSS購読（D）は全体のリリースノートであり、自分のクラスタに固有のイベント通知には適しません。
クラスタ通知（公式ドキュメント）