表示モード
画像位置
文字位置
理解度の自動記録
Q1Google Professional Cloud Devops Engineer
Q1. Cloud Run上で稼働中のサービスがあり、起動時にデータベースのパスワードを必要とします。
社内ポリシーにより全パスワードを24時間おきにローテーションすることが義務付けられており、サービスは常に最新のパスワードを参照できなければなりません。
加えて、パスワード更新のたびにダウンタイムを発生させたくありません。
どのように対応すればよいですか？
解答を見る
正解：B. パスワードをSecret Managerで管理し、シークレットをボリュームとしてコンテナにマウントする。
正解はBです。Secret Managerに保存したシークレットをボリュームとしてマウントすると、Cloud Runはマウントされたファイルを約30秒ごとに更新するため、アプリケーションは再デプロイなしで最新のパスワードを取得できます。ボリュームマウント方式なら無停止で最新シークレットを反映できる点が本問の要点です。
環境変数方式（選択肢A）はシークレットが起動時に固定され最大10分間キャッシュされるため、24時間ローテーションに追随しづらく、値がプレーンテキストで露出する欠点もあります。
CやDはビルド時にパスワードを埋め込むため再デプロイが必要で、無停止という要件を満たしません。
シークレットの構成 | Cloud Run ドキュメント
Q2Google Professional Cloud Devops Engineer
Q2. 社内の基幹サービスで、直近になって障害が立て続けに発生しました。
原因調査を効率化するためCloud Monitoringのダッシュボードを整備し、自社アプリケーション起因の障害と、利用しているGoogle Cloud側の障害とを一目で見分けられるようにしたいと考えています。
どのように実現しますか？
解答を見る
正解：A. ダッシュボード上でPersonalized Service Health（パーソナライズド サービス ヘルス）のアノテーション表示を有効化する。
正解はAです。Personalized Service Health（パーソナライズド サービス ヘルス）は、自分のプロジェクトに影響を与えるGoogle Cloud側のインシデント情報を提供する機能です。
これをCloud Monitoringと統合してアノテーションを有効にすると、Google Cloudの障害イベントを自社サービスの指標グラフ上に重ねて表示できます。自社障害とGoogle Cloud側障害を直接切り分けられる点が正解の根拠です。
アラートポリシー（B）は閾値超過の通知が目的で原因の切り分けはできません。
ログベース指標（C）やログウィジェット（D）は自社ログの解析には有効ですが、Google Cloud側の障害有無を権威ある形で示すものではありません。
Personalized Service Health の概要 | Google Cloud
Q3Google Professional Cloud Devops Engineer
Q3. 取引先向けに、新しいマルチテナント構成のGoogle Kubernetes Engine（GKE）クラスタを設計しています。
取引先は長期間有効な認証情報を使い続けることのリスクを懸念しており、最小権限の原則（PoLP）に従って各GKEワークロードには必要最小限のIdentity and Access Management（IAM）権限だけを付与するよう求めています。
Google推奨のベストプラクティスに沿ってIAMのなりすまし（impersonation）方式を設計する必要があります。
どのように構成しますか？
解答を見る
正解：A. Googleサービスアカウントを用意する。Workload Identityを有効化したクラスタ上でKubernetesサービスアカウントを作成し、roles/iam.workloadIdentityUserロールとiam.gke.io/gcp-service-accountアノテーションを用いて両者を紐付ける。作成したKubernetesサービスアカウントを各ワークロードに割り当て、この手順をワークロードごとに繰り返す。
正解はAです。Workload Identity（ワークロード アイデンティティ）は、GKEワークロードがサービスアカウントキーを管理せずに、短命の認証情報でGoogle Cloud APIへ安全にアクセスするためのGoogle推奨の方法です。
roles/iam.workloadIdentityUserロールとiam.gke.io/gcp-service-accountアノテーションでKubernetesサービスアカウントにGoogleサービスアカウントをなりすまさせることで、ワークロードごとに最小権限を割り当てられます。長期キーを排し、短命の認証情報と最小権限を両立できる点が正解の要件を満たします。
サービスアカウントキーを使うC、ノードプール単位で共通IDを付与するB・Dは、鍵の長期保持やワークロード単位の権限分離ができず不適切です。
Workload Identity について | GKE ドキュメント
Q4Google Professional Cloud Devops Engineer
Q4. 本番のGoogle Kubernetes Engine（GKE）上で稼働するNode.jsアプリケーションの運用を担当しています。
このアプリケーションは複数の依存先アプリケーションへHTTPリクエストを送信する構成です。
将来的にどの依存先がパフォーマンス劣化の原因になり得るかを、あらかじめ把握しておきたいと考えています。
どのように対応しますか？
解答を見る
正解：B. すべての関連アプリケーションをStackdriver Trace（現Cloud Trace）で計測し、サービス間のHTTPリクエストの流れを確認する。
正解はBです。Cloud Trace（旧Stackdriver Trace）は分散トレーシングのサービスで、リクエストがサービス間をどのように伝播したか、各区間のレイテンシがどこで発生しているかを可視化できます。
サービス間のHTTPリクエストを追跡することで、遅延の原因となる依存アプリケーションを特定できます。分散トレースはサービス間のレイテンシ内訳を示すため、遅い依存先の特定に最適です。
Profiler（A）はコードのリソース消費分析、Debugger（C）は稼働中コードの状態確認が目的で、依存関係の遅延特定には向きません。
ログ記録（D）は実装負担が大きく回りくどい方法です。
なおStackdriver系の各サービスは現在Cloud Operationsに改称されています。
Cloud Trace の概要 | Google Cloud
Q5Google Professional Cloud Devops Engineer
Q5. 繰り返し利用できるInfrastructure as Code（IaC）モジュール群を開発しています。
各モジュールには、テスト用プロジェクト上でそのモジュールを実際に起動する統合テストが用意されています。
ソースの管理にはGitHubを利用しており、フィーチャーブランチを継続的にテストして、マージされる前に必ず全コードがテスト済みになる状態を保証したいと考えています。
この統合テストを自動化する仕組みを実装する必要があります。
どのように実現しますか？
解答を見る
正解：D. Cloud Buildで特定フォルダ配下のテストのみを実行する構成にし、GitHub上のプルリクエスト作成のたびにCloud Buildをトリガーする。
正解はDです。変更が受け入れられる（マージされる）前にテストを行う必要があるため、プルリクエスト作成時点でCloud Buildをトリガーするのが適切です。
Cloud BuildのGitHubアプリを使えば、プルリクエストごとにビルドを起動し、特定フォルダの統合テストのみを実行できます。マージ前に検証するにはプルリクエスト単位でのトリガー実行が必須です。
マージ後に実行するB、レビュー担当者に手動実行を依頼するC、定期実行のJenkinsを使うAはいずれも「受け入れ前の自動テスト」という要件を満たしません。
GitHub リポジトリからのビルド | Cloud Build ドキュメント
Q6Google Professional Cloud Devops Engineer
Q6. Compute Engine上で稼働する社内向けアプリケーションを運用しています。
このアプリケーションは独自のHTTPサーバーでAPIを公開し、内部TCP/UDPロードバランサ経由で他のアプリケーションからアクセスされます。
現状、ファイアウォールルールでは0.0.0.0/0からAPIポートへのアクセスが許可されたままです。
できるだけ手間をかけずに、APIへアクセスした各IPアドレスをCloud Loggingへ記録したいと考えています。
どうすればよいですか？
解答を見る
正解：C. 既存のファイアウォールルールでロギングオプションを有効にする。
正解はCです。すでにAPIポートへのアクセスを許可するファイアウォールルールが存在するため、そのルールでロギングを有効にするだけで済み、最小限の手順で実現できます。
ファイアウォールルールログは接続ごとに接続レコードを生成し、送信元・宛先IPアドレスを記録します。ファイアウォールルールログはサンプリングされず全接続を記録するため、各IPを漏れなく取得できます。
VPCフローログ（D）はパケットをサンプリングするため「各IP」を確実に記録する要件に劣り、サブネットでの新規設定も必要です。
パケットミラーリング（A）やOps Agent（B）はこの目的には過剰または不適切です。
ファイアウォール ルール ロギング | Cloud NGFW ドキュメント
Q7Google Professional Cloud Devops Engineer
Q7. Cloud BuildでCI/CDパイプラインを構築し、アプリケーションのコンテナイメージをビルドしています。
アプリケーションのソースコードはGitHub上で管理されています。
社内ルールでは、本番用イメージのビルドはmainブランチに対してのみ行い、mainブランチへのプッシュはすべて変更管理チームの承認を経ることが定められています。
イメージのビルドはできる限り自動化したいと考えています。
どうすればよいですか？（2つ選択してください）
解答を見る
正解：C、D
正解はCとDです。本番イメージをmainブランチに対してのみビルドするには、リポジトリイベントを「ブランチへのプッシュ」に設定したトリガーを作成し、対象ブランチをmainに限定します（C）。
また、mainへのすべてのプッシュを変更管理チームが承認するには、GitHub側でmainブランチに対しブランチ保護ルールを構成します（D）。ビルド起動はCloud Buildトリガー、承認統制はGitHubのブランチ保護ルールで分担するのが要点です。
Cloud Build側の承認オプション（E）はビルド実行の承認であり、ブランチへのマージ承認ではありません。
プルリクエストトリガー（A）やownersフィルタ（B）は要件を直接満たしません。
GitHub リポジトリからのビルド | Cloud Build ドキュメント
Q8Google Professional Cloud Devops Engineer
Q8. 自社のマルチクラウド環境において、アプリケーション用のCI/CDパイプラインを構築しています。
このアプリケーションはカスタムのCompute Engineイメージと、他クラウドプロバイダ上の同等イメージを用いてデプロイされます。
現行環境向けにイメージのビルドとデプロイができ、なおかつ将来の変更にも柔軟に対応できる仕組みが必要です。
どのソリューションスタックを選ぶべきですか？
解答を見る
正解：A. Cloud BuildとPacker
正解はAです。Packerは、単一のソース設定から複数プラットフォーム（Google Cloud、AWS、Azureなど）向けに同一のマシンイメージを作成できるオープンソースツールで、マルチクラウドのカスタムVMイメージという要件に最適です。
Cloud Buildからパイプラインとして実行できます。マルチクラウドのVMイメージを単一設定でビルドできるPackerが、将来の変更にも適応できる正解です。
Google Cloud Deploy（B・C）はGKEやCloud Runなどへのアプリ配信を自動化するもので、他クラウド向けのVMイメージ作成には対応しません。
kpt（D）はKubernetesマニフェスト管理用で用途が異なります。
Packer を使用した VM イメージのビルド | Cloud Build ドキュメント
Q9Google Professional Cloud Devops Engineer
Q9. 自社の中核サービスについて、半年ごとのキャパシティプランニングを実施しています。
今後半年間、利用ユーザー数は月次で10%ずつ増加すると予測されています。
このサービスは全面的にコンテナ化されており、クラスタオートスケーラーを有効化した3ゾーン構成のGoogle Kubernetes Engine（GKE）Standardリージョナルクラスタ上で、Google Cloud Platform（GCP）を用いて稼働しています。
現時点でデプロイ済みCPU容量の約30%を使用しており、1ゾーン障害への耐性も確保しておく必要があります。
この利用増加やゾーン障害が起きた場合でもユーザーへの影響を最小限にとどめつつ、無駄なコストは避けたいと考えています。
見込まれる増加にはどのように備えるべきですか？
解答を見る
正解：A. ノードプールの最大サイズを確認するとともに水平Pod自動スケーラー（Horizontal Pod Autoscaler）を有効にし、負荷テストによって想定リソース需要を実測・検証する。
正解はAです。適切なスケーリングには、ノードプールの最大サイズが将来の需要を満たせることを確認し、水平Pod自動スケーラー（HPA）でPod数をCPU/メモリ消費に応じて自動増減させ、さらに負荷テストで実際に必要なリソースを検証する多層的な備えが必要です。最大サイズ確認・HPA・負荷テストを組み合わせて実需を裏付ける点が正解の要点です。
クラスタオートスケーラーだけに依存するB、余裕を過信するC、根拠なく60%増設するDは、いずれも検証や自動スケーリング設定を欠き、コスト効率や信頼性の面で不適切です。
水平 Pod 自動スケーラー | GKE ドキュメント
Q10Google Professional Cloud Devops Engineer
Q10. 自社の本番システムをGoogle Cloudへ移行している最中です。
将来発生し得るインシデントが顧客に与える影響を最小限にするため、移行作業と並行してサイトリライアビリティエンジニアリング（SRE）のプラクティスを取り入れる必要があります。
どの2つのSREプラクティスを導入すべきですか？（2つ選択してください）
解答を見る
正解：B、E
正解はBとEです。SREでは、反復作業（toil）の自動化と、影響分析に基づく緩和策の提示によって、検知から復旧までの時間を短縮します（B）。
また、デバッグと緩和の手順を記した最新のプレイブックは、オンコール担当者が迅速かつ一貫して対応するために不可欠です（E）。自動化による対応迅速化と、常に最新のプレイブック整備がSREの中核プラクティスです。
権限をオンコールチームに限定するAはボトルネックや最小権限違反を招き、全チームに本番変更を許すCは変更管理を損ないます。
内部挙動のみに基づくアラートDは、ユーザー影響（SLO）に基づくべきという原則に反し、アラート疲れを生みます。
信頼性の柱 | Google Cloud アーキテクチャ フレームワーク