Professional Cloud Architect

Question 31

あなたのチームは、Kubernetes Engine上でマイクロサービスアーキテクチャを用いた新しいアプリケーションの開発を開始します。開発ライフサイクルの一環として、GitHubリポジトリのリモートdevelopブランチにプッシュされたコード変更は、自動的にビルドおよびテストされる必要があります。ビルドとテストが成功した場合、関連するマイクロサービスは自動的に開発環境にデプロイされます。開発環境にデプロイされるすべてのコードがこのプロセスに従うことを保証したいと考えています。どうすればよいですか?

A.
各開発者に、developブランチへのコミット時にコードをテストしコンテナをビルドするプレコミットフックを各自のワークステーションにインストールさせます。コミットが成功した後、開発者に新しくビルドされたコンテナイメージを開発クラスタにデプロイさせます。
B.
リモートgitリポジトリに、developブランチにコードがプッシュされたときにコードをテストしコンテナをビルドするポストコミットフックをインストールします。コミットが成功した後、開発者に新しくビルドされたコンテナイメージを開発クラスタにデプロイさせます。
C.
developブランチに基づいて、コードをテストし、コンテナをビルドし、Container Registryに保存するCloud Buildトリガーを作成します。新しいイメージを監視し、新しいイメージを開発クラスタにデプロイするデプロイパイプラインを作成します。デプロイツールのみが新しいバージョンをデプロイするアクセス権を持つようにします。
D.
developブランチに基づいて、新しいコンテナイメージをビルドし、Container Registryに保存するCloud Buildトリガーを作成します。コードテストが成功することを保証するために脆弱性スキャンに依存します。Cloud Buildプロセスの最終ステップとして、新しいコンテナイメージを開発クラスタにデプロイします。Cloud Buildのみが新しいバージョンをデプロイするアクセス権を持つようにします。
Question 32

あなたの所属する運用チームから、Compute Engine上で稼働している本番アプリケーションのパフォーマンス問題の診断支援を依頼されました。このアプリケーションは、高負荷時に到達したリクエストをドロップしています。影響を受けているインスタンスのプロセスリストには、利用可能なCPUをすべて消費している単一のアプリケーションプロセスが表示されており、オートスケーリングはインスタンス数の上限に達しています。データベースを含む他の関連システムには異常な負荷はありません。できるだけ早く本番トラフィックの処理を再開できるようにしたいと考えています。どのアクションを推奨しますか?

A.
オートスケーリングのメトリックを agent.googleapis.com/memory/percent_used に変更する。
B.
影響を受けているインスタンスを段階的に再起動する。
C.
各インスタンスにSSH接続し、アプリケーションプロセスを再起動する。
D.
オートスケーリンググループの最大インスタンス数を増やす。
Question 33

あなたはGoogle Cloud上にWebサービスのインフラストラクチャを実装しています。このWebサービスは、毎秒50万リクエストのデータを受信して保存する必要があります。データは後で、既知の属性セットの完全一致に基づいてリアルタイムでクエリされます。Webサービスがリクエストを全く受信しない期間もあります。ビジネスはコストを低く抑えたいと考えています。アプリケーションにはどのWebサービスプラットフォームとデータベースを使用すべきですか?

A.
Cloud Run と BigQuery
B.
Cloud Run と Cloud Bigtable
C.
Compute Engine 自動スケーリング マネージド インスタンス グループ と BigQuery
D.
Compute Engine 自動スケーリング マネージド インスタンス グループ と Cloud Bigtable
Question 34

あなたは、クラスター内部に留まるべき複数の異なるマイクロサービスを使用してアプリケーションを開発しています。各マイクロサービスを特定のレプリカ数で構成できるようにしたいと考えています。また、マイクロサービスがスケールするレプリカ数に関係なく、クラスター内の他のマイクロサービスから特定のマイクロサービスに統一された方法でアクセスできるようにしたいと考えています。このソリューションをGoogle Kubernetes Engine (GKE) に実装する必要があります。どうすべきでしょうか?

A.
各マイクロサービスをDeploymentとしてデプロイします。Serviceを使用してクラスター内でDeploymentを公開し、クラスター内の他のマイクロサービスからアクセスするためにServiceのDNS名を使用します。
B.
各マイクロサービスをDeploymentとしてデプロイします。Ingressを使用してクラスター内でDeploymentを公開し、クラスター内の他のマイクロサービスからDeploymentにアクセスするためにIngressのIPアドレスを使用します。
C.
各マイクロサービスをPodとしてデプロイします。Serviceを使用してクラスター内でPodを公開し、クラスター内の他のマイクロサービスからマイクロサービスにアクセスするためにServiceのDNS名を使用します。
D.
各マイクロサービスをPodとしてデプロイします。Ingressを使用してクラスター内でPodを公開し、クラスター内の他のマイクロサービスからPodにアクセスするためにIngressのIPアドレスを使用します。
Question 35

顧客から、最近更新された Google App Engine アプリケーションの読み込みに、一部のユーザーで約30秒かかるとの報告を受けています。 この動作は更新前には報告されていませんでした。 どのような戦略を取るべきですか?

A.
ISP(インターネットサービスプロバイダ)と協力して問題を診断する
B.
サポートチケットを開き、ネットワークキャプチャとフローデータを依頼して問題を診断し、その後アプリケーションをロールバックする
C.
まず、以前の正常なリリースにロールバックし、その後、開発/テスト/ステージング環境で Stackdriver Trace と Logging を使用して問題を診断する
D.
以前の正常なリリースにロールバックし、その後、閑散期に再度リリースをプッシュして調査する。その後、Stackdriver Trace と Logging を使用して問題を診断する