CertPass

Question 171

あなたはコンテナファーストのアプローチを採用している金融サービス企業で働いています。あなたのチームはマイクロサービスアプリケーションを開発しています。Cloud Build パイプラインは、コンテナイメージを作成し、回帰テストを実行し、そのイメージを Artifact Registry に公開します。回帰テストに合格したコンテナのみが Google Kubernetes Engine (GKE) クラスタにデプロイされるようにする必要があります。GKE クラスタではすでに Binary Authorization を有効にしています。次に何をすべきでしょうか？

アテスターとポリシーを作成します。コンテナイメージが回帰テストに正常に合格した後、Cloud Build を使用して Kritis Signer を実行し、コンテナイメージのアテステーションを作成します。

Voucher Server と Voucher Client コンポーネントをデプロイします。コンテナイメージが回帰テストに正常に合格した後、Cloud Build パイプラインのステップとして Voucher Client を実行します。

関連する名前空間に対して Pod Security Standard レベルを Restricted に設定します。Cloud Build を使用して、回帰テストに合格したコンテナイメージにデジタル署名します。

アテスターとポリシーを作成します。回帰テストに合格したコンテナイメージのアテステーションを、Cloud Build パイプラインのステップとして作成します。

Question 172

あなたはベストプラクティスに従うために、Cloud Buildのステップを見直し、更新しています。現在、ビルドステップには以下の手順が含まれています。 1. ソースリポジトリからソースコードをプルする。 2. コンテナイメージをビルドする。 3. ビルドされたイメージをArtifact Registryにアップロードする。ビルドされたコンテナイメージの脆弱性スキャンを実行するステップを追加する必要があり、スキャンの結果をGoogle Cloudで実行されているデプロイメントパイプラインで利用できるようにしたいと考えています。他のチームのプロセスを中断する可能性のある変更を最小限に抑えたいと考えています。どうすべきでしょうか？

Binary Authorizationを有効にし、コンテナイメージに脆弱性が存在しないことを証明するように構成する。

ビルドされたコンテナイメージをDocker Hubインスタンスにアップロードし、脆弱性をスキャンする。

Artifact RegistryでContainer Scanning APIを有効にし、ビルドされたコンテナイメージの脆弱性をスキャンする。

Aqua SecurityインスタンスにArtifact Registryを追加し、ビルドされたコンテナイメージの脆弱性をスキャンする。

Question 173

あなたは、Google Kubernetes Engine (GKE) 上でマイクロサービスアプリケーションとしてオンラインゲームプラットフォームを開発しています。ソーシャルメディアのユーザーから、アプリケーションへの特定のURLリクエストの読み込み時間が長いという苦情が寄せられています。アプリケーションのパフォーマンスボトルネックを調査し、ユーザーリクエストの中で特にレイテンシが高いHTTPリクエストを特定する必要があります。どうすればよいですか？

kubectlを使用してGKEワークロードメトリクスを設定します。すべてのPodがメトリクスをCloud Monitoringに送信するように選択します。Cloud Monitoringでアプリケーションメトリクスのカスタムダッシュボードを作成し、GKEクラスタのパフォーマンスボトルネックを特定します。

マイクロサービスを更新して、HTTPリクエストメソッドとURLパスをSTDOUTにログ出力するようにします。ログルーターを使用してコンテナログをCloud Loggingに送信します。Cloud Loggingでフィルタを作成し、異なるメソッドとURLパスにわたるユーザーリクエストのレイテンシを評価します。

OpenTelemetryトレースパッケージをインストールしてマイクロサービスを計装します。アプリケーションコードを更新して、検査と分析のためにトレースをCloud Traceに送信します。Cloud Traceで分析レポートを作成し、ユーザーリクエストを分析します。

GKEノードにtcpdumpをインストールします。tcpdumpを実行して長期間にわたりネットワークトラフィックをキャプチャし、データを収集します。Wiresharkを使用してデータファイルを分析し、高レイテンシの原因を特定します。

Question 174

Cloud Runにデプロイされた一連のREST APIエンドポイントに対して負荷テストを実施する必要があります。APIはHTTP POSTリクエストに応答します。負荷テストは以下の要件を満たす必要があります： • 負荷は複数の並列スレッドから開始されること。 • APIへのユーザートラフィックは複数の送信元IPアドレスから発生すること。 • 追加のテストインスタンスを使用して負荷をスケールアップできること。 Googleが推奨するベストプラクティスに従いたいと考えています。負荷テストはどのように構成すべきですか？

cURLがインストールされたイメージを作成し、テストプランを実行するようにcURLを設定します。そのイメージをマネージドインスタンスグループにデプロイし、VMごとにイメージのインスタンスを1つ実行します。

cURLがインストールされたイメージを作成し、テストプランを実行するようにcURLを設定します。そのイメージを非マネージドインスタンスグループにデプロイし、VMごとにイメージのインスタンスを1つ実行します。

プライベートGoogle Kubernetes Engineクラスタに分散負荷テストフレームワークをデプロイします。必要に応じてPodを追加し、より多くのトラフィックを開始し、同時ユーザー数をサポートします。

Cloud Shell上で分散負荷テストフレームワークのコンテナイメージをダウンロードします。APIへの負荷を増やすために、Cloud Shell上でコンテナのインスタンスを複数、順次起動します。

Question 175

あなたのチームはCloud Runでサーバーレスウェブアプリケーションを作成しています。このアプリケーションは、プライベートなCloud Storageバケットに保存されている画像にアクセスする必要があります。Googleが推奨するベストプラクティスに従ってサービスを保護しつつ、アプリケーションにバケット内の画像へのアクセス権限をIdentity and Access Management (IAM)で付与したいと考えています。どうすべきでしょうか？

対象のバケットに対して署名付きURLを強制します。バケットに対するStorageオブジェクト閲覧者IAMロールをCompute Engineのデフォルトサービスアカウントに付与します。

対象のバケットに対して公開アクセス防止を強制します。バケットに対するStorageオブジェクト閲覧者IAMロールをCompute Engineのデフォルトサービスアカウントに付与します。

対象のバケットに対して署名付きURLを強制します。ユーザー管理のサービスアカウントを作成し、Cloud Runサービスを更新してそのサービスアカウントを使用するようにします。バケットに対するStorageオブジェクト閲覧者IAMロールをそのサービスアカウントに付与します。

対象のバケットに対して公開アクセス防止を強制します。ユーザー管理のサービスアカウントを作成し、Cloud Runサービスを更新してそのサービスアカウントを使用するようにします。バケットに対するStorageオブジェクト閲覧者IAMロールをそのサービスアカウントに付与します。

Professional Cloud Developer