Professional Cloud DevOps Engineer

Question 122

あなたのチームは、Google Kubernetes Engine (GKE) にデプロイするための新しいアプリケーションを設計しています。様々なアプリケーションレベルのメトリクスを一元的な場所に収集・集約するための監視を設定する必要があります。監視の設定に必要な作業量を最小限に抑えつつ、Google Cloud Platform のサービスを利用したいと考えています。どうすべきでしょうか?

A.
アプリケーションから様々なメトリクスを直接 Cloud Monitoring API (旧 Stackdriver Monitoring API) に発行し、これらのカスタムメトリクスを Cloud Monitoring (旧 Stackdriver) で監視する。
B.
Cloud Pub/Sub クライアントライブラリをインストールし、アプリケーションから様々なメトリクスを様々なトピックにプッシュし、集約されたメトリクスを Cloud Monitoring (旧 Stackdriver) で監視する。
C.
アプリケーションに OpenTelemetry クライアントライブラリをインストールし、Cloud Monitoring (旧 Stackdriver) をメトリクスのエクスポート先として設定し、アプリケーションのメトリクスを Cloud Monitoring (旧 Stackdriver) で監視する。
D.
すべてのメトリクスをアプリケーション固有のログメッセージの形式で出力し、これらのメッセージをコンテナから Cloud Logging (旧 Stackdriver Logging) コレクタに渡し、Cloud Monitoring (旧 Stackdriver) でメトリクスを監視する。
Question 123

あなたは、単一のCompute Engineインスタンスで実行される本番サービスをサポートしています。クラッシュしたインスタンスを削除し、関連するイメージに基づいて新しいインスタンスを作成することでサービスを再作成するために、定期的に時間を費やす必要があります。サイト信頼性エンジニアリング(SRE)の原則に従いながら、手動操作に費やす時間を削減したいと考えています。何をすべきですか?

A.
開発チームにバグを報告し、インスタンスがクラッシュする根本原因を特定してもらう。
B.
単一インスタンスのマネージドインスタンスグループを作成し、ヘルスチェックを使用してシステムの状態を判断する。
C.
Compute Engineインスタンスの前にロードバランサを追加し、ヘルスチェックを使用してシステムの状態を判断する。
D.
Stackdriver Monitoring(現 Cloud Monitoring)ダッシュボードをSMSアラート付きで作成し、クラッシュしたインスタンスがクラッシュした直後に迅速に再作成を開始できるようにする。
Question 124

あなたのアプリケーションの成果物は、CI/CDパイプライン経由でビルドおよびデプロイされています。CI/CDパイプラインがアプリケーションのシークレットに安全にアクセスできるようにし、セキュリティ侵害が発生した場合にシークレットをより簡単にローテーションできるようにしたいと考えています。どうすればよいですか?

A.
ビルド時に開発者にシークレットの入力を求める。開発者にはシークレットを保存しないように指示する。
B.
Git上の別の設定ファイルにシークレットを保存する。選ばれた開発者に設定ファイルへのアクセス権を付与する。
C.
Cloud KMSのキーで暗号化されたシークレットをCloud Storageに保存する。IAM経由でCI/CDパイプラインにCloud KMSへのアクセス権を付与する。
D.
シークレットを暗号化してソースコードリポジトリに保存する。復号キーを別のリポジトリに保存し、パイプラインにそのリポジトリへのアクセス権を付与する。
Question 125

あなたの会社はサイト信頼性エンジニアリング(SRE)のプラクティスに従っています。あなたは、顧客向けアプリケーションに影響を与えている大規模で継続中のインシデントに関するコミュニケーション担当者です。障害解決の見込み時間はまだ立っていません。内部関係者からは障害に関する最新情報を求めるメールが、顧客からは何が起きているのかを知りたいというメールが届いています。あなたは、障害の影響を受けているすべての人に効率的に最新情報を提供したいと考えています。 どうすべきでしょうか?

A.
少なくとも30分ごとに内部関係者への対応に集中する。「次回の更新」時刻を約束する。
B.
すべての関係者(内部および外部)にタイムリーに定期的な更新を提供する。すべてのコミュニケーションにおいて「次回の更新」時刻を約束する。
C.
内部関係者へのメール対応をインシデント対応チームの別のメンバーに委任する。顧客への直接的な対応に集中する。
D.
すべての内部関係者からのメールをインシデントコマンダーに渡し、内部コミュニケーションの管理を任せる。顧客への直接的な対応に集中する。
Question 126

あなたのチームは、すべてのCI/CDパイプラインにCloud Buildを使用しています。Cloud Buildのkubectlビルダーを使用して、新しいイメージをGoogle Kubernetes Engine(GKE)にデプロイしたいと考えています。開発工数を最小限に抑えつつ、GKEに認証する必要があります。どうすればよいですか?

A.
Cloud Buildサービスアカウントにコンテナデベロッパーロールを割り当てます。
B.
cloudbuild.yamlファイル内でCloud Buildにコンテナデベロッパーロールを指定します。
C.
コンテナデベロッパーロールを持つ新しいサービスアカウントを作成し、それを使用してCloud Buildを実行します。
D.
Cloud Buildにサービスアカウントの認証情報を取得し、それをkubectlに渡すための別のステップを作成します。