Q1. Cloud Runにアプリケーションをデプロイしています。
アプリケーションは起動時にパスワードを必要とします。
組織はすべてのパスワードを24時間ごとにローテーションすることを求めており、アプリケーションは常に最新のパスワードを保持する必要があります。
ダウンタイムなしでアプリケーションをデプロイする必要があります。
どうすればよいですか？
A. パスワードをSecret Managerに保存し、環境変数を使用してシークレットをアプリケーションに渡す。
B. パスワードをSecret Managerに保存し、シークレットをアプリケーション内のボリュームとしてマウントする。
C. Cloud Buildを使用して、ビルド時にアプリケーションコンテナへパスワードを追加する。Artifact Registryが公開アクセスから保護されていることを確認する。
D. パスワードをコードに直接保存する。パスワードが変更されるたびにCloud Buildを使用してアプリケーションを再ビルドおよび再デプロイする。
回答
- B
-
正解はBです。
Secret Managerに保存したシークレットをボリュームとしてマウントすると、Cloud Runはマウントされたファイルを約30秒ごとに更新するため、アプリケーションは再デプロイなしで最新のパスワードを取得できます。ボリュームマウント方式なら無停止で最新シークレットを反映できる点が本問の要点です。
環境変数方式（選択肢A）はシークレットが起動時に固定され最大10分間キャッシュされるため、24時間ローテーションに追随しづらく、値がプレーンテキストで露出する欠点もあります。
CやDはビルド時にパスワードを埋め込むため再デプロイが必要で、無停止という要件を満たしません。
シークレットの構成 | Cloud Run ドキュメント
Q2. 会社では最近、本番サービスで複数の障害が発生しました。
障害のトラブルシューティングのためにCloud Monitoringダッシュボードを作成する必要があり、そのダッシュボードを使って、自社サービスの障害と、利用しているGoogle Cloudサービスに起因する障害とを区別したいと考えています。
どうすればよいですか？
A. ダッシュボードでPersonalized Service Health（パーソナライズド サービス ヘルス）のアノテーションを有効にする。
B. システムエラー指標に対するアラートポリシーを作成する。
C. クラウドサービスのエラーを追跡するログベースの指標を作成し、その指標をダッシュボードに表示する。
D. Cloud Loggingのシステムエラーを表示するログウィジェットをダッシュボードに作成する。
回答
- A
-
正解はAです。
Personalized Service Health（パーソナライズド サービス ヘルス）は、自分のプロジェクトに影響を与えるGoogle Cloud側のインシデント情報を提供する機能です。
これをCloud Monitoringと統合してアノテーションを有効にすると、Google Cloudの障害イベントを自社サービスの指標グラフ上に重ねて表示できます。自社障害とGoogle Cloud側障害を直接切り分けられる点が正解の根拠です。
アラートポリシー（B）は閾値超過の通知が目的で原因の切り分けはできません。
ログベース指標（C）やログウィジェット（D）は自社ログの解析には有効ですが、Google Cloud側の障害有無を権威ある形で示すものではありません。
Personalized Service Health の概要 | Google Cloud
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アノテーションを使用して、GoogleサービスアカウントとKubernetesサービスアカウントを紐付ける。
Kubernetesサービスアカウントをワークロードにマッピングする。
ワークロードごとに繰り返す。
B. Googleサービスアカウントを作成する。
ノードプールを作成し、GoogleサービスアカウントをデフォルトのIDとして設定する。
ノードセレクタ、taint、tolerationを使用して、ワークロードが指定したノードプールでのみ実行されるようにする。
ワークロードごとに繰り返す。
C. Googleサービスアカウントを作成する。
Googleサービスアカウントのサービスアカウントキーを作成する。
サービスアカウントキーを含むKubernetesシークレットを作成する。
ワークロードがそのシークレットをマウントし、GOOGLE_APPLICATION_CREDENTIALS環境変数がマウントパスを指すように設定する。
ワークロードごとに繰り返す。
D. Googleサービスアカウントを作成する。
taintのないノードプールを作成し、GoogleサービスアカウントをデフォルトのIDとして設定する。
GoogleサービスアカウントにIAM権限を付与する。
回答
- A
-
正解は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 ドキュメント
Q4. 本番環境のGoogle Kubernetes Engine（GKE）で動作するNode.jsアプリケーションをサポートしています。
このアプリケーションは、依存する複数のアプリケーションへHTTPリクエストを行います。
どの依存アプリケーションがパフォーマンス問題を引き起こす可能性があるかを事前に把握したいと考えています。
どうすればよいですか？
A. すべてのアプリケーションをStackdriver Profiler（現Cloud Profiler）で計測する。
B. すべてのアプリケーションをStackdriver Trace（現Cloud Trace）で計測し、サービス間のHTTPリクエストを確認する。
C. Stackdriver Debugger（現Cloud Debugger）を使用して各アプリケーション内のロジックの実行を確認し、すべてのアプリケーションを計測する。
D. Node.jsアプリケーションを変更して、依存アプリケーションへのHTTPリクエストとレスポンスの時間をログに記録する。Stackdriver Logging（現Cloud Logging）を使用して、パフォーマンスの低い依存アプリケーションを見つける。
回答
- B
-
正解はBです。
Cloud Trace（旧Stackdriver Trace）は分散トレーシングのサービスで、リクエストがサービス間をどのように伝播したか、各区間のレイテンシがどこで発生しているかを可視化できます。
サービス間のHTTPリクエストを追跡することで、遅延の原因となる依存アプリケーションを特定できます。分散トレースはサービス間のレイテンシ内訳を示すため、遅い依存先の特定に最適です。
Profiler（A）はコードのリソース消費分析、Debugger（C）は稼働中コードの状態確認が目的で、依存関係の遅延特定には向きません。
ログ記録（D）は実装負担が大きく回りくどい方法です。
なおStackdriver系の各サービスは現在Cloud Operationsに改称されています。
Cloud Trace の概要 | Google Cloud
Q5. 再利用可能なInfrastructure as Code（IaC）モジュールを開発しています。
各モジュールには、テストプロジェクトでそのモジュールを起動する統合テストが含まれています。
ソース管理にはGitHubを使用しています。
フィーチャーブランチを継続的にテストし、変更が受け入れられる前にすべてのコードがテストされることを保証する必要があります。
統合テストを自動化するソリューションを実装する必要があります。
どうすればよいですか？
A. CI/CDパイプラインにJenkinsサーバーを使用する。フィーチャーブランチのすべてのテストを定期的に実行する。
B. Cloud Buildを使用してテストを実行する。プルリクエストがマージされた後にすべてのテストを実行するようトリガーする。
C. コードを承認する前に、プルリクエストのレビュー担当者に統合テストの実行を依頼する。
D. Cloud Buildを使用して特定のフォルダ内のテストを実行する。GitHubのプルリクエストごとにCloud Buildをトリガーする。
回答
- D
-
正解はDです。
変更が受け入れられる（マージされる）前にテストを行う必要があるため、プルリクエスト作成時点でCloud Buildをトリガーするのが適切です。
Cloud BuildのGitHubアプリを使えば、プルリクエストごとにビルドを起動し、特定フォルダの統合テストのみを実行できます。マージ前に検証するにはプルリクエスト単位でのトリガー実行が必須です。
マージ後に実行するB、レビュー担当者に手動実行を依頼するC、定期実行のJenkinsを使うAはいずれも「受け入れ前の自動テスト」という要件を満たしません。
GitHub リポジトリからのビルド | Cloud Build ドキュメント
Q6. Compute Engineで動作するアプリケーションを管理しています。
このアプリケーションはカスタムHTTPサーバーを使用してAPIを公開しており、そのAPIは内部TCP/UDPロードバランサを介して他のアプリケーションからアクセスされます。
ファイアウォールルールにより、0.0.0.0/0からAPIポートへのアクセスが許可されています。
最小限の手順で、APIにアクセスする各IPアドレスをCloud Loggingに記録する必要があります。
どうすればよいですか？
A. VPCでパケットミラーリングを有効にする。
B. Compute EngineインスタンスにOps Agentをインストールする。
C. ファイアウォールルールでロギングを有効にする。
D. サブネットでVPCフローログを有効にする。
回答
- C
-
正解はCです。
すでにAPIポートへのアクセスを許可するファイアウォールルールが存在するため、そのルールでロギングを有効にするだけで済み、最小限の手順で実現できます。
ファイアウォールルールログは接続ごとに接続レコードを生成し、送信元・宛先IPアドレスを記録します。ファイアウォールルールログはサンプリングされず全接続を記録するため、各IPを漏れなく取得できます。
VPCフローログ（D）はパケットをサンプリングするため「各IP」を確実に記録する要件に劣り、サブネットでの新規設定も必要です。
パケットミラーリング（A）やOps Agent（B）はこの目的には過剰または不適切です。
ファイアウォール ルール ロギング | Cloud NGFW ドキュメント
Q7. Cloud BuildでCI/CDパイプラインを作成し、アプリケーションのコンテナイメージをビルドしています。
アプリケーションコードはGitHubに保存されています。
会社では、本番用イメージのビルドはmainブランチに対してのみ実行され、mainブランチへのすべてのプッシュは変更管理チームが承認することを求めています。
イメージのビルドをできる限り自動化したいと考えています。
どうすればよいですか？（2つ選択してください）
A. Cloud Buildジョブにトリガーを作成する。リポジトリのイベント設定を「プルリクエスト」に設定する。
B. トリガーの「含めるファイル」フィルタにownersファイルを追加する。
C. Cloud Buildジョブにトリガーを作成する。リポジトリのイベント設定を「ブランチへのプッシュ」に設定する。
D. リポジトリのmainブランチに対してブランチ保護ルールを構成する。
E. トリガーで承認（Approval）オプションを有効にする。
回答
- C・D
-
正解はCとDです。
本番イメージをmainブランチに対してのみビルドするには、リポジトリイベントを「ブランチへのプッシュ」に設定したトリガーを作成し、対象ブランチをmainに限定します（C）。
また、mainへのすべてのプッシュを変更管理チームが承認するには、GitHub側でmainブランチに対しブランチ保護ルールを構成します（D）。ビルド起動はCloud Buildトリガー、承認統制はGitHubのブランチ保護ルールで分担するのが要点です。
Cloud Build側の承認オプション（E）はビルド実行の承認であり、ブランチへのマージ承認ではありません。
プルリクエストトリガー（A）やownersフィルタ（B）は要件を直接満たしません。
GitHub リポジトリからのビルド | Cloud Build ドキュメント
Q8. 会社のマルチクラウド環境で、アプリケーション用のCI/CDパイプラインを実装しています。
アプリケーションは、カスタムのCompute Engineイメージと、他のクラウドプロバイダにおける同等のイメージを使用してデプロイされます。
現在の環境向けにイメージをビルドおよびデプロイでき、かつ将来の変更にも適応できるソリューションを実装する必要があります。
どのソリューションスタックを使用すべきですか？
A. Cloud BuildとPacker
B. Cloud BuildとGoogle Cloud Deploy
C. Google Kubernetes EngineとGoogle Cloud Deploy
D. Cloud Buildとkpt
回答
- A
-
正解は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 ドキュメント
Q9. 主力サービスについて、半期ごとのキャパシティプランニングを行っています。
今後6か月間、サービス利用者は前月比10%の割合で増加すると見込んでいます。
サービスは完全にコンテナ化されており、クラスタオートスケーラーを有効にした3ゾーン構成のGoogle Kubernetes Engine（GKE）Standardリージョナルクラスタで、Google Cloud Platform（GCP）上で稼働しています。
現在、デプロイ済みのCPU容量の約30%を消費しており、1ゾーンの障害に対する耐性が必要です。
この増加やゾーン障害の結果としてユーザーへの悪影響を最小限に抑えつつ、不要なコストを回避したいと考えています。
予測される増加にどう備えるべきですか？
A. ノードプールの最大サイズを確認し、水平Pod自動スケーラー（Horizontal Pod Autoscaler）を有効にしたうえで、負荷テストを実施して想定されるリソース需要を検証する。
B. GKEにデプロイしクラスタオートスケーラーを使用しているため、増加率にかかわらずGKEクラスタは自動的にスケールする。
C. 利用率が30%にすぎないため十分な余裕があり、この増加率に対して追加の容量は不要である。
D. 6か月分の10%増加を見込んで、先行してノード容量を60%増やし、その後負荷テストを実施して十分な容量があることを確認する。
回答
- A
-
正解はAです。
適切なスケーリングには、ノードプールの最大サイズが将来の需要を満たせることを確認し、水平Pod自動スケーラー（HPA）でPod数をCPU/メモリ消費に応じて自動増減させ、さらに負荷テストで実際に必要なリソースを検証する多層的な備えが必要です。最大サイズ確認・HPA・負荷テストを組み合わせて実需を裏付ける点が正解の要点です。
クラスタオートスケーラーだけに依存するB、余裕を過信するC、根拠なく60%増設するDは、いずれも検証や自動スケーリング設定を欠き、コスト効率や信頼性の面で不適切です。
水平 Pod 自動スケーラー | GKE ドキュメント
Q10. 会社は本番システムをGoogle Cloudに移行しています。
将来のインシデントによる顧客への影響を最小限に抑えるため、移行中にサイトリライアビリティエンジニアリング（SRE）のプラクティスを実装する必要があります。
どの2つのSREプラクティスを実装すべきですか？（2つ選択してください）
A. 完全な自律性と権限は、オンコールチームにのみ付与されるようにする。
B. 一般的なタスクを自動化し、重要な影響情報を分析して、オンコールチームに緩和策をインテリジェントに提案する。
C. すべてのチームが問題解決のために本番環境を変更できるようにする。
D. システムの内部的な挙動に基づいて、SREチーム向けのアラートの仕組みを作成する。
E. 問題のデバッグと緩和の手順を記載した、最新のプレイブックを作成する。
回答
- B・E
-
正解はBとEです。
SREでは、反復作業（toil）の自動化と、影響分析に基づく緩和策の提示によって、検知から復旧までの時間を短縮します（B）。
また、デバッグと緩和の手順を記した最新のプレイブックは、オンコール担当者が迅速かつ一貫して対応するために不可欠です（E）。自動化による対応迅速化と、常に最新のプレイブック整備がSREの中核プラクティスです。
権限をオンコールチームに限定するAはボトルネックや最小権限違反を招き、全チームに本番変更を許すCは変更管理を損ないます。
内部挙動のみに基づくアラートDは、ユーザー影響（SLO）に基づくべきという原則に反し、アラート疲れを生みます。
信頼性の柱 | Google Cloud アーキテクチャ フレームワーク