Professional Cloud Developer

Question 211

あなたは、複数の環境にわたるGKEクラスタにデプロイされたアプリケーションを管理しています。Cloud Buildを使用してユーザー受け入れテスト(UAT)を実行しています。Cloud BuildをArtifact Analysisと統合し、環境をホストするすべてのGoogle CloudプロジェクトでBinary Authorization APIを有効にしました。特定の自動UATテストに合格したコンテナイメージのみを本番環境にデプロイしたいと考えています。アテスターはすでに作成済みです。次に何をすべきですか?

A.
UATフェーズの後、Kubernetes Secretとして保存されたキーでアテステーションに署名します。UAT Google CloudプロジェクトのBinary AuthorizationにGKEクラスタ固有のルールを追加します。
B.
UATフェーズの後、Kubernetes Secretとして保存されたキーでアテステーションに署名します。本番Google CloudプロジェクトのポリシーのBinary AuthorizationにGKEクラスタ固有のルールを追加します。
C.
UATフェーズの後、Cloud Key Management Service (KMS)に保存されたキーでアテステーションに署名します。UAT Google CloudプロジェクトのBinary Authorizationにデフォルトルールを追加します。
D.
UATフェーズの後、Cloud Key Management Service (KMS)に保存されたキーでアテステーションに署名します。本番Google CloudプロジェクトのポリシーのBinary AuthorizationにGKEクラスタ固有のルールを追加します。
Question 212

タイムスタンプ、アカウント番号(文字列)、取引金額(数値)の3つの列を含むログファイルを解析しています。一意のアカウント番号ごとに、すべての取引金額の合計を効率的に計算したいと考えています。 どのデータ構造を使用すべきですか?

A.
連結リスト
B.
ハッシュテーブル
C.
二次元配列
D.
カンマ区切り文字列
Question 213

あなたはeコマースウェブサイトを運営する会社で働いています。注文が行われた後のすべての注文処理ステップを管理する新しい統合機能を開発しています。各注文を処理するために複数のCloud Functionsを作成しました。各関数の出力を使用してフローを決定し、関数の実行をオーケストレーションする必要があります。このプロセスのレイテンシを最小限に抑えたいと考えています。どうすればよいですか?

A.
Workflowsを使用して関数を呼び出し、コールバックを使用して実行ロジックを処理する。
B.
Workflowsを使用して関数を呼び出し、条件分岐を使用して実行ロジックを処理する。
C.
Cloud Composerを使用して関数を呼び出し、Apache Airflow HTTPオペレーターを使用して実行ロジックを処理する。
D.
Cloud Composerを使用して関数を呼び出し、Apache Airflowオペレーターを使用して実行ロジックを処理する。
Question 214

現在、コンテナイメージをArtifact Registryにプッシュし、コンテナ化されたマイクロサービスアプリケーションをGKEにデプロイしています。アプリケーションをデプロイした後、サービスが期待どおりに動作しないことに気づきました。`kubectl get pods` コマンドを使用してアプリケーションPodの状態を確認したところ、Podの1つが `CrashLoopBackoff` 状態であることがわかりました。このPodをどのようにトラブルシューティングすべきですか?

A.
`kubectl exec -it POD_NAME -- /bin/bash` コマンドを実行して問題のあるPodに接続します(POD_NAME パラメータは問題のあるPodの名前)。`/var/log/messages` フォルダ内のログを調べて根本原因を特定します。
B.
`gcloud projects get-iam-policy PROJECT_ID` コマンドを実行します(PROJECT_ID パラメータはArtifact Registryが存在するプロジェクトの名前)。ノードプールのサービスアカウントのIAMバインディングを調べます。サービスアカウントに `roles/artifactregistry.reader` ロールがあるかどうかを確認します。
C.
`kubectl logs POD_NAME` コマンドを実行します(POD_NAME パラメータは問題のあるPodの名前)。Podの以前の実行時のログを分析して、Podの起動試行が失敗した根本原因を特定します。
D.
Google Cloudコンソールで、クラスタのVPCのプロジェクトにあるCloud Loggingに移動します。Private Google Access CIDR範囲への拒否されたegressトラフィックを表示するフィルタを入力します。GKEクラスタからPrivate Google Access CIDR範囲へのegressトラフィックが拒否されているかどうかを確認します。
Question 215

あなたはCloud Buildを使用して、Cloud Runにデプロイする前にコンテナイメージをビルドおよびテストしています。イメージはArtifact Registryに保存されています。テストに合格したコンテナイメージのみがデプロイされるようにする必要があります。運用オーバーヘッドは最小限に抑えたいと考えています。どうすればよいですか?

A.
Cloud Runサービスに新しいリビジョンをデプロイします。トラフィックを処理せずに特定のURLでリビジョンにアクセスできるタグを割り当てます。そのリビジョンを再度テストします。新しいリビジョンが期待どおりに動作することを確認した後、トラフィックをCloud Runサービスに移行します。
B.
Cloud RunサービスでBinary Authorizationを有効にします。コンテナイメージがすべてのテストに合格した場合に証明書(attestation)を作成します。適切な証明書を持つイメージのみがCloud RunサービスにデプロイされるようにBinary Authorizationを構成します。
C.
GKEクラスタを作成します。すべてのテストに合格したことを確認し、イメージをGKEクラスタにデプロイします。
D.
Cloud Buildパイプラインでビルド来歴(build provenance)を構成します。すべてのテストに合格したことを確認し、イメージをCloud Runサービスにデプロイします。