CertPass

Question 192

あなたのチームは、開発、ステージング、本番という3つのGoogle Kubernetes Engine (GKE) 環境にアプリケーションをデプロイしています。信頼できる情報源としてGitHubリポジトリを使用しています。これら3つの環境の一貫性を確保する必要があります。これらの環境内のすべてのGKEクラスタにネットワークポリシーとロギングDaemonSetを適用およびインストールするために、Googleが推奨するプラクティスに従いたいと考えています。何をすべきでしょうか？

Google Cloud Deployを使用してネットワークポリシーとDaemonSetをデプロイします。リポジトリ内のソースからネットワークポリシーとDaemonSetがドリフトした場合にアラートをトリガーするためにCloud Monitoringを使用します。

Google Cloud Deployを使用してDaemonSetをデプロイし、Policy Controllerを使用してネットワークポリシーを設定します。リポジトリ内のソースからのドリフトを検出するためにCloud Monitoringを使用し、ドリフトを修正するためにCloud Functionsを使用します。

Cloud Buildを使用してネットワークポリシーとDaemonSetをレンダリングおよびデプロイします。3つの環境の設定を同期するためにConfig Syncを設定します。

Cloud Buildを使用してネットワークポリシーとDaemonSetをレンダリングおよびデプロイします。3つの環境の設定を強制するためにPolicy Controllerを設定します。

Question 193

あなたはCI/CDパイプライン内でInfrastructure as Code (IaC) としてインフラストラクチャを管理するためにTerraformを使用しています。Google Cloudプロジェクト内にインフラストラクチャスタック全体の複数のコピーが存在し、既存のインフラストラクチャに変更が加えられるたびに新しいコピーが作成されていることに気づきました。インフラストラクチャスタックのインスタンスが常に1つだけ存在するようにすることで、クラウドの支出を最適化する必要があります。Googleが推奨するベストプラクティスに従いたいと考えています。どうすればよいですか？

不要になった古いインフラストラクチャスタックを削除するための新しいパイプラインを作成する。

パイプラインがTerraformのgcsバックエンドを使用して、Cloud Storageからterraform.tfstateファイルを保存および取得していることを確認する。

パイプラインがソース管理からterraform.tfstateファイルを保存および取得していることを確認する。

最新の設定を適用する前に、既存のインフラストラクチャをすべて削除するようにパイプラインを更新する。

Question 194

あなたは、将来の分析のためにCloud LoggingからBigQueryへログエントリをエクスポートするCloud Loggingシンクを作成しています。あなたの組織には、開発プロジェクトを含むDevという名前のGoogle Cloudフォルダと、本番プロジェクトを含むProdという名前のフォルダがあります。開発プロジェクトのログエントリはdev_datasetに、本番プロジェクトのログエントリはprod_datasetにエクスポートする必要があります。作成するログシンクの数を最小限に抑え、ログシンクが将来のプロジェクトにも適用されるようにしたいと考えています。どうすればよいですか？

組織レベルで単一の集約ログシンクを作成する。

各プロジェクトにログシンクを作成する。

組織レベルで2つの集約ログシンクを作成し、プロジェクトIDでフィルタリングする。

DevフォルダとProdフォルダに集約ログシンクを作成する。

Question 195

あなたの会社は、グローバルに分散された複数のGoogle Kubernetes Engine (GKE) クラスターを使用してサービスを運用しています。運用チームは、メトリクス、アラート、ダッシュボード生成のためにPrometheusベースのツールを使用したワークロード監視を設定しています。この設定では、すべてのクラスターにわたるメトリクスをグローバルに表示する方法が提供されていません。あなたは、グローバルなPrometheusクエリをサポートし、管理オーバーヘッドを最小限に抑えるスケーラブルなソリューションを実装する必要があります。何をすべきですか？

中央集権的なデータアクセスのために、Prometheusのクロスサービスフェデレーションを設定する。

GKE向けのCloud Operations内でワークロードメトリクスを設定する。

中央集権的なデータアクセスのために、Prometheusの階層型フェデレーションを設定する。

Google Cloud Managed Service for Prometheusを設定する。

Question 196

あなたはGoogle Cloudでコンテナ化されたアプリケーションのためのCI/CDパイプラインを構築する必要があります。あなたの開発チームは、トランクベース開発のために中央Gitリポジトリを使用しています。品質を向上させるために、アプリケーションの新しいバージョンに対してパイプラインですべてのテストを実行したいと考えています。どうすべきでしょうか？

1. Gitフックをインストールして、開発者が中央リポジトリにコードをプッシュする前にユニットテストを実行するように要求します。 2. Cloud Buildをトリガーしてアプリケーションコンテナをビルドします。アプリケーションコンテナをテスト環境にデプロイし、統合テストを実行します。 3. 統合テストが成功した場合、アプリケーションコンテナを本番環境にデプロイし、受け入れテストを実行します。

1. Gitフックをインストールして、開発者が中央リポジトリにコードをプッシュする前にユニットテストを実行するように要求します。すべてのテストが成功した場合、コンテナをビルドします。 2. Cloud Buildをトリガーしてアプリケーションコンテナをテスト環境にデプロイし、統合テストと受け入れテストを実行します。 3. すべてのテストが成功した場合、コードを本番準備完了としてタグ付けします。Cloud Buildをトリガーしてアプリケーションコンテナをビルドし、本番環境にデプロイします。

1. Cloud Buildをトリガーしてアプリケーションコンテナをビルドし、コンテナでユニットテストを実行します。 2. ユニットテストが成功した場合、アプリケーションコンテナをテスト環境にデプロイし、統合テストを実行します。 3. 統合テストが成功した場合、パイプラインはアプリケーションコンテナを本番環境にデプロイします。その後、受け入れテストを実行します。

1. コードがプッシュされたときにCloud Buildをトリガーしてユニットテストを実行します。すべてのユニットテストが成功した場合、アプリケーションコンテナをビルドし、中央レジストリにプッシュします。 2. Cloud Buildをトリガーしてコンテナをテスト環境にデプロイし、統合テストと受け入れテストを実行します。 3. すべてのテストが成功した場合、パイプラインはアプリケーションを本番環境にデプロイし、スモークテストを実行します。

195問中 191-195問目

最初へ前へ 35 36 37 38 39

Professional Cloud DevOps Engineer