Professional Cloud DevOps Engineer

Question 16

あなたは、Google Kubernetes Engine (GKE) で実行され、ブルー/グリーンデプロイメント方式を使用するアプリケーションを管理しています。以下にKubernetesマニフェストの抜粋を示します。 デプロイメント app-green は、アプリケーションの新しいバージョンを使用するように更新されました。デプロイ後のモニタリング中に、ユーザーリクエストの大部分が失敗していることに気づきました。この動作はテスト環境では観察されませんでした。ユーザーへのインシデントの影響を軽減し、開発者が問題をトラブルシューティングできるようにする必要があります。どうすればよいですか?

Question
A.
デプロイメント app-blue を更新して、アプリケーションの新しいバージョンを使用するようにします。
B.
デプロイメント app-green を更新して、アプリケーションの以前のバージョンを使用するようにします。
C.
サービス app-svc のセレクターを app: my-app に変更します。
D.
サービス app-svc のセレクターを app: my-app, version: blue に変更します。
Question 17

あなたは、Compute Engineのマネージドインスタンスグループにデプロイされたウェブアプリケーションを実行しています。すべてのインスタンスにOps Agentがインストールされています。最近、特定のIPアドレスからの不審なアクティビティに気づきました。最小限の運用オーバーヘッドで、その特定のIPアドレスからのリクエスト数を表示するようにCloud Monitoringを設定する必要があります。どうすればよいですか?

A.
Ops Agentにロギングレシーバーを設定し、ログベースのメトリクスを作成する。 ウェブサーバーのログをスクレイピングするスクリプトを作成し、IPアドレスのリクエストメトリクスをCloud Monitoring APIにエクスポートする。
B.
アプリケーションを更新して、IPアドレスのリクエストメトリクスをCloud Monitoring APIにエクスポートする。
C.
Ops Agentにメトリクスレシーバーを設定する。
Question 18

あなたの組織では、コンテナ化されたアプリケーションのパッケージングにHelmを使用しています。アプリケーションはパブリックとプライベートの両方のチャートを参照しています。セキュリティチームは、パブリックHelmリポジトリを依存関係として使用することはリスクであると指摘しました。あなたは、ネイティブなアクセス制御とVPCサービスコントロールを使用して、すべてのチャートを一元的に管理したいと考えています。どうすべきでしょうか?

A.
Artifact Registryを使用して、パブリックおよびプライベートのチャートをOCI形式で保存する。
B.
IDプロバイダーとしてGoogle Workspaceを使用して、GitHub Enterpriseでパブリックおよびプライベートのチャートを保存する。
C.
Gitリポジトリを使用してパブリックおよびプライベートのチャートを保存する。リポジトリの内容をCloud Storageバケットに同期するようにCloud Buildを設定する。Helmリポジトリとして https://[bucket].storage-googleapis.com/[helmchart] を使用してHelmをバケットに接続する。
D.
ストレージバックエンドとしてCloud Storageバケットを使用して、Google Kubernetes Engine (GKE) で実行するHelmチャートリポジトリサーバーを設定する。
Question 19

あなたはTerraformを使用して、Google Cloud環境にデプロイされたアプリケーションを管理しています。アプリケーションは、マネージドインスタンスグループによってデプロイされたインスタンス上で実行されます。TerraformコードはCI/CDパイプラインを使用してデプロイされます。マネージドインスタンスグループが使用するインスタンステンプレートのマシンタイプを変更すると、パイプラインは`terraform apply`ステージで以下のエラーメッセージを出して失敗します。 ``` Error waiting for Deleting Instance Template: The instance_template resource 'project/my-project/global/instanceTemplates/my-it-202201010101000000001' is already being used by 'projects/my-project/regions/us-central1/instanceGroupManagers/my-mig' ``` 日本語訳: ``` インスタンステンプレートの削除待機中にエラーが発生しました: インスタンステンプレートリソース 'project/my-project/global/instanceTemplates/my-it-202201010101000000001' は、'projects/my-project/regions/us-central1/instanceGroupManagers/my-mig' によって既に使用されています。 ``` インスタンステンプレートを更新し、アプリケーションへの影響とパイプラインの実行回数を最小限に抑える必要があります。 どうすればよいですか?

Question
A.
マネージドインスタンスグループを削除し、インスタンステンプレートを更新した後に再作成します。
B.
新しいインスタンステンプレートを追加し、マネージドインスタンスグループが新しいインスタンステンプレートを使用するように更新し、古いインスタンステンプレートを削除します。
C.
Terraformステートファイルからマネージドインスタンスグループを削除し、インスタンステンプレートを更新し、マネージドインスタンスグループを再インポートします。
D.
インスタンステンプレートのライフサイクルブロックで、`create_before_destroy`メタ引数を`true`に設定します。
Question 20

あなたの会社は、組織のすべてのログを7年間保存することが義務付けられている、規制の厳しいドメインで事業を展開しています。マネージドサービスを利用してロギングインフラストラクチャの複雑さを最小限に抑えたいと考えています。また、設定ミスや人的エラーによる将来のログ取得の損失や保存済みログの損失を回避する必要があります。何をすべきでしょうか?

A.
Cloud Logging を使用して組織レベルで集約シンクを設定し、すべてのログを BigQuery データセットにエクスポートする。
B.
Cloud Logging を使用して組織レベルで集約シンクを設定し、すべてのログを7年間の保持ポリシーとバケットロックが設定された Cloud Storage にエクスポートする。
C.
Cloud Logging を使用して各プロジェクトレベルでエクスポートシンクを設定し、すべてのログを BigQuery データセットにエクスポートする。
D.
Cloud Logging を使用して各プロジェクトレベルでエクスポートシンクを設定し、すべてのログを7年間の保持ポリシーとバケットロックが設定された Cloud Storage にエクスポートする。