CertPass

Question 41

あなたの会社は規制の厳しいドメインで事業を運営しています。セキュリティチームは、信頼されたコンテナイメージのみを Google Kubernetes Engine (GKE) にデプロイすることを要求しています。あなたは、セキュリティチームの要件を満たしつつ、管理オーバーヘッドを最小限に抑えるソリューションを実装する必要があります。どうすべきでしょうか？

GKEクラスタでバイナリ認証を設定し、デプロイ時のセキュリティポリシーを適用する。

Cloud Build サービスアカウントに roles/artifactregistry.writer ロールを付与する。従業員が Artifact Registry の書き込み権限を持たないことを確認する。

Cloud Run を使用してカスタムバリデーターを作成しデプロイする。新しいイメージがアップロードされたときに検証を実行するために Eventarc トリガーを有効にする。

GKEクラスタで Kritis を実行するように設定し、デプロイ時のセキュリティポリシーを適用する。

Question 42

あなたの会社のCTO（最高技術責任者）から、社内で使用する目的で、全てのインシデントに対して事後検証ポリシーを導入するよう指示がありました。あなたはそのポリシーが会社で成功するように、良い事後検証とは何かを定義したいと考えています。何をすべきですか？（2つ選択してください。）

全ての事後検証に、インシデントの原因、インシデント発生の責任を負う個人またはチームの特定、およびインシデントの再発防止策が含まれるようにする。

全ての事後検証に、インシデントの原因、インシデントがどのように悪化し得たか、およびインシデントの再発防止策が含まれるようにする。

全ての事後検証に、インシデントの重大度、インシデントの再発防止策、および内部システムコンポーネント名を伏せたインシデントの原因が含まれるようにする。

全ての事後検証に、インシデントがどのように解決されたか、および顧客情報を伏せたインシデントの原因が含まれるようにする。

全ての事後検証において、全てのインシデント関係者を事後検証の作成に参加させ、事後検証を可能な限り広く共有するようにする。

Question 43

あなたは再利用可能なIaC (Infrastructure as Code) モジュールを開発しています。各モジュールには、テストプロジェクトでモジュールを起動する統合テストが含まれています。ソース管理にはGitHubを使用しています。フィーチャーブランチを継続的にテストし、変更が受け入れられる前にすべてのコードがテストされることを保証する必要があります。統合テストを自動化するソリューションを実装する必要があります。どうすればよいですか？

CI/CDパイプラインにJenkinsサーバーを使用します。フィーチャーブランチですべてのテストを定期的に実行します。

プルリクエストのレビュー担当者に、コードを承認する前に統合テストを実行するように依頼します。

Cloud Buildを使用してテストを実行します。プルリクエストがマージされた後、すべてのテストが実行されるようにトリガーします。

Cloud Buildを使用して特定のフォルダ内のテストを実行します。GitHubのプルリクエストごとにCloud Buildをトリガーします。

Question 44

あなたの会社は、Pub/Sub、App Engine スタンダード環境、そしてGoで書かれたアプリケーションを使用して、大規模なIoTデータを処理しています。ピーク負荷時にパフォーマンスが一貫性なく低下することに気づきました。この問題はあなたのワークステーションでは再現できませんでした。コード内の遅いパスを特定するために、本番環境でアプリケーションを継続的に監視する必要があります。パフォーマンスへの影響と管理オーバーヘッドを最小限に抑えたいと考えています。どうすべきでしょうか？

Cloud Monitoring を使用して、App Engine の CPU 使用率メトリックを評価する。

継続的なプロファイリングツールを Compute Engine にインストールする。アプリケーションがプロファイリングデータをそのツールに送信するように設定する。

アプリケーションインスタンスに対して定期的に go tool pprof コマンドを実行する。フレームグラフを使用して結果を分析する。

Cloud Profiler を設定し、アプリケーション内で cloud.google.com/go/profiler ライブラリを初期化する。

Question 45

あなたの会社では、Google Kubernetes Engine (GKE) を使用してサービスを運用しています。開発環境のGKEクラスタでは、詳細ログを有効にしたアプリケーションが実行されています。開発者は `kubectl logs` コマンドを使用してログを閲覧しており、Cloud Logging は使用していません。アプリケーションには、統一されたログ構造が定義されていません。GKEの運用ログは収集し続けながら、アプリケーションのロギングに関連するコストを最小限に抑える必要があります。どうすればよいですか？

開発クラスタに対して `gcloud container clusters update --logging=SYSTEM` コマンドを実行する。

開発クラスタに対して `gcloud container clusters update --logging=WORKLOAD` コマンドを実行する。

開発環境に関連付けられたプロジェクトで `gcloud logging sinks update _Default --disabled` コマンドを実行する。

開発環境に関連付けられたプロジェクトの `_Default` ログシンクに `severity >= DEBUG resource.type = "k8s_container"` の除外フィルタを追加する。

Professional Cloud DevOps Engineer