Google Professional Cloud Developer 1-10

表示モード
画像位置
文字位置
理解度の自動記録
STATUS FILTER

表示する理解度を選択

読み込み中...
Q1Google Professional Cloud Developer

Q1. あなたは先週、ホテルの客室予約を受け付けるAPIを本番環境へリリースしました。
顧客ごとに、予約が1件成立するたびに、その顧客が呼び出せるAPI検索リクエスト数を最大1000件までに制限するクォータを設けたいと考えています。
クォータは24時間ごとにリセットされるようにします。
1予約あたり厳密に1000回ちょうどの検索を保証することよりも、APIの応答速度を優先したいと考えています。
どのように構成すればよいでしょうか。

解答を見る
正解：A. Apigeeのクォータ（Quota）ポリシーを構成し、Synchronous属性をfalseに設定します。
予約が成立した時点、または24時間が経過した時点でクォータをリセットします。
Apigeeのクォータポリシーでは、Synchronous属性をfalseに設定するとカウントの更新が非同期で処理され、各リクエストはカウンター更新の完了を待たずに応答を返せます。
設問は「厳密に1000回」を保証することよりもAPIの応答速度を優先しており、非同期カウントは多少の誤差を許容しながら高いパフォーマンスを実現します。
予約成立時や24時間経過時のクォータリセットもポリシー側で構成できます。
BigQueryやFirestoreを使う方式はカウントの正確性は高いものの、リクエストのたびに読み書きが発生し速度面で不利です。
インメモリ方式は複数インスタンス間でカウンターを共有できず信頼性に欠けます。
Apigee Quota policy（公式ドキュメント）
Q2Google Professional Cloud Developer

Q2. あなたは、ユーザーが時間帯を問わずいつでもプレイするため、トラフィックの傾向が予測しづらいシングルプレイヤー向けモバイルゲームのバックエンドを開発しています。
リクエストを処理するのに十分なリソースを確保しつつ、過剰なプロビジョニングを抑えることでコストを最適化したいと考えています。
また、トラフィックが急増した場合にも効率よく対応できる仕組みにしたいと考えています。
どのコンピューティングプラットフォームを選択すべきでしょうか。

解答を見る
正解：A. Cloud Run
Cloud Runはリクエスト量に応じて自動的にスケールし、トラフィックがない間はゼロまでスケールインできるフルマネージドのサーバーレスプラットフォームです。
予測しづらいトラフィックや急激なスパイクにも柔軟に対応しつつ、使用した分だけの課金となるため過剰プロビジョニングを避けられ、コスト最適化の要件に最も適合します。
Compute Engine（マネージド・アンマネージドいずれも）はVM単位のスケールとなりゼロまで縮小できず、起動にも時間がかかるため不向きです。
GKEのクラスタオートスケーリングはノード追加に時間を要し、過剰プロビジョニングが起きやすい点で要件に劣ります。
Cloud Run の概要（公式ドキュメント）
Q3Google Professional Cloud Developer

Q3. あなたはCI/CDチームと連携し、チームが新たに導入した機能のトラブルシューティングを担当している開発者です。
CI/CDチームはHashiCorp Packerを用いて、あなたの開発ブランチから新しいCompute Engineイメージをビルドしました。
イメージのビルド自体は成功しましたが、そのイメージから起動したインスタンスが立ち上がりません。
CI/CDチームと協力してこの問題を調査する必要があります。
どうすればよいでしょうか。

解答を見る
正解：D. シリアルポートを使ってCompute EngineのOSログを確認し、シリアルポートへのアクセスを検証するためにCloud Loggingのログも確認します。
VMが起動しない問題を調査する際、Googleが推奨する手段はシリアルコンソール（シリアルポート出力）の確認です。
起動に失敗した場合でもシリアルポート出力にはブートプロセスのメッセージが記録されるため、起動失敗の原因を直接特定できます。
シリアルポート出力はCloud Loggingへ転送して保存・確認することも可能です。
ディスクをローカルにマウントする方法（A）は手間が多く、起動段階のログを得にくい場合があります。
ローカルでの再ビルド（B）や再依頼（C）は原因の調査そのものにはつながりません。
シリアルコンソールを使用したトラブルシューティング（公式ドキュメント）
Q4Google Professional Cloud Developer

Q4. あなたは、ユーザーへ静的コンテンツを配信する、高可用性でグローバルにアクセス可能なアプリケーションを構築しています。
ストレージと配信の各コンポーネントを構成する必要があります。
管理オーバーヘッドとレイテンシを最小限に抑えつつ、ユーザーに対する信頼性を最大限に高めたいと考えています。
どのように構成すべきでしょうか。

解答を見る
正解：D. 1. Standardストレージクラスのマルチリージョン Cloud Storageバケットを作成し、静的コンテンツを格納します。
2. 外部IPアドレスを予約し、外部HTTP(S)ロードバランサを作成します。
3. Cloud CDNを有効化し、トラフィックをバックエンドバケットへ送信します。
静的コンテンツの配信では、VMを運用するよりもCloud Storageバケットをバックエンドにする方が管理オーバーヘッドを大幅に削減できます。
高可用性にはマルチリージョンのCloud Storageバケット、グローバルなアクセスには外部HTTP(S)ロードバランサ、低レイテンシ配信にはCloud CDNという組み合わせが最適です。
リージョナルバケット（C）は単一リージョンに限定され可用性の面で劣ります。
インスタンスグループ方式（A・B）はVMの複製・管理が必要となり、管理オーバーヘッドを最小化するという要件に反します。
Cloud Storage バケットでの Cloud CDN 設定（公式ドキュメント）
Q5Google Professional Cloud Developer

Q5. あなたのチームは、Cloud Storageのイベントをトリガーとして実行されるCloud Functionを開発しています。
Googleが推奨するベストプラクティスに沿って、Cloud Functionのテストと開発サイクルを高速化したいと考えています。
どうすればよいでしょうか。

解答を見る
正解：C. Functions Frameworkライブラリをインストールし、localhost上でCloud Functionを構成します。
関数のコピーを作成し、新しいバージョンへ変更を加えます。
curlを使って新しいバージョンをテストします。
Functions Framework（ファンクションフレームワーク）は、Cloud Functionのコードをローカル環境で実行・テストするためにGoogleが提供する公式ライブラリです。
ローカルでcurlなどを使って関数を呼び出して検証できるため、デプロイを待たずに開発サイクルを大幅に高速化でき、これがGoogle推奨のベストプラクティスです。
本番環境でのテスト（D）はリスクが高く推奨されません。
HTTPトリガー型への書き換え（B）や監査ログ連携（A）は本来のトリガー条件を再現できず、余計な複雑さを招きます。
Functions Framework（公式ドキュメント）
Q6Google Professional Cloud Developer

Q6. あなたは、次の設計要件を満たす新しいアプリケーションを開発しています。
・アプリケーションインフラの作成と変更をバージョン管理し、監査可能にすること。
・アプリケーションとデプロイ用インフラは、可能な限りGoogleマネージドサービスを利用すること。
・アプリケーションはサーバーレスのコンピューティングプラットフォーム上で動作すること。
アプリケーションのアーキテクチャをどのように設計すべきでしょうか。

解答を見る
正解：A. 1. アプリケーションとインフラのソースコードをGitリポジトリに格納します。
2. Cloud Buildを使用し、Terraformでアプリケーションインフラをデプロイします。
3. パイプラインの1ステップとしてアプリケーションをCloud Functionへデプロイします。
インフラの作成・変更をバージョン管理し監査可能にするには、Infrastructure as Code（IaC）をGitで管理する構成が必要です。
ソースコードとインフラ定義をGitに格納し、Cloud BuildとTerraformでデプロイし、サーバーレスのCloud Functionに展開する構成（A）が全要件を満たします。
gcloudコマンド（D）は宣言的なバージョン管理ができず、監査要件に反します。
Jenkins（B）はGoogleマネージドではなく自己管理が必要です。
Compute Engineへのデプロイ（C）はサーバーレス要件を満たしません。
Terraform のベストプラクティス（公式ドキュメント）
Q7Google Professional Cloud Developer

Q7. あなたの会社では、Google Cloudに保存する全データを顧客管理の暗号鍵（CMEK）で暗号化することを義務付ける、新しいセキュリティポリシーが導入されました。
Cloud Key Management Service（KMS）を使って鍵へのアクセスを構成する予定です。
「職務分掌（separation of duties）」の原則と、Googleが推奨するベストプラクティスの両方に従う必要があります。
どうすればよいでしょうか。（2つ選択してください。）

解答を見る
正解：A、B
職務分掌を実現するには、鍵の管理と鍵の利用を別の権限・別のプロジェクトに分けることが重要です。
Cloud KMSを専用プロジェクトに配置し（A）、そのプロジェクトにはオーナーを割り当てない（B）ことで、鍵を単独で管理・利用できる特権者の存在を排除するのがGoogle推奨の構成です。
組織レベルの管理者がIAMポリシーのみを制御する形にすることで分離が保たれます。
鍵利用プロジェクトと同居させる（C）構成や、利用側オーナーにKMS管理ロールを付与する（D）構成は分離原則に反します。
Cloud KMS の職務の分離（公式ドキュメント）
Q8Google Professional Cloud Developer

Q8. あなたのセキュリティチームは、Google Kubernetes Engine上で稼働する全デプロイ済みアプリケーションを監査しています。
監査の結果、一部のアプリケーションがクラスタ内トラフィックを平文（クリアテキスト）のまま送信していることが判明しました。
アプリケーションへの変更を最小限にとどめ、Googleのサポート対象を維持しながら、できるだけ早く全アプリケーショントラフィックを暗号化する必要があります。
どうすればよいでしょうか。

解答を見る
正解：B. Istioをインストールし、対象アプリケーションの名前空間でサイドカープロキシのインジェクションを有効にし、mTLSを有効化します。
サービスメッシュ（Istio／現在はGoogleが管理するCloud Service Mesh）はサイドカープロキシをインジェクションすることで、アプリケーションコードを変更せずに相互TLS（mTLS）による自動暗号化を実現します。
プロキシインジェクションとmTLSを有効にするだけでクラスタ内の全トラフィックを最小限の変更で暗号化でき、Googleのサポートも維持できます。
ネットワークポリシー（A）はトラフィックを制御しますが暗号化はしません。
アプリ内での信頼範囲定義（C）やLet’s Encrypt証明書の手動組み込み（D）はアプリへの変更が大きく要件に反します。
Cloud Service Mesh の mTLS（公式ドキュメント）
Q9Google Professional Cloud Developer

Q9. データ移行の一環として、オンプレミスの仮想マシン上にあるファイルをGoogle Cloud Storageへアップロードしたいと考えています。
これらのファイルは、Google Cloud環境のCloud Dataproc Hadoopクラスタで利用される予定です。
どのコマンドを使用すべきでしょうか。

解答を見る
正解：A. gsutil cp [LOCAL_OBJECT] gs://[DESTINATION_BUCKET_NAME]/
ローカルのファイルを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 コマンド（公式ドキュメント）
Q10Google Professional Cloud Developer

Q10. あなたはGoogle Kubernetes Engine（GKE）のクラスタ管理者です。
組織のクラスタはリリースチャンネルに登録されています。
利用可能なアップグレードやセキュリティ速報など、GKEクラスタに影響する関連イベントについて通知を受け取りたいと考えています。
どうすればよいでしょうか。

解答を見る
正解：A. クラスタ通知（cluster notifications）をPub/Subトピックへ送信するように構成します。
GKEには、特定のクラスタに影響するアップグレード情報やセキュリティ速報などのイベントをPub/Subトピックへ配信する「クラスタ通知」機能があります。
クラスタ通知をPub/Subトピックへ送信するよう構成すると、対象クラスタに関連するイベントをリアルタイムかつ自動的に受け取れます。
BigQueryのスケジュールクエリ（B）やGKE APIへの問い合わせ（C）は能動的なポーリングが必要です。
RSS購読（D）はGKE全体のリリースノートであり、自分のクラスタに固有のイベント通知には適しません。
クラスタ通知（公式ドキュメント）