Professional Cloud Developer

Question 226

あなたはCloud Runで公開ウェブアプリケーションを開発しています。Cloud Runサービスをその公開IPアドレスで直接公開しています。現在、アプリケーションが高トラフィック負荷に対して回復力があることを確認するために負荷テストを実行しています。軽いトラフィックを開始したときはアプリケーションが期待どおりに動作することに気づきました。しかし、高い負荷を生成すると、ウェブサーバーの動作が遅くなり、エラーメッセージが返されます。この問題をどのようにトラブルシューティングすべきですか?

A.
Cloud MonitoringでCloud Runへのネットワークトラフィックを確認し、トラフィックスパイクが発生したかどうかを検証します。必要に応じて、Cloud Runインスタンスでトラフィック分割を有効にして、トラフィックの一部を以前のインスタンスリビジョンにルーティングします。
B.
Cloud Runサービスのmin-instances値を確認します。必要に応じて、負荷テストの仮想ユーザーの最大数に合わせてmin-instances値を増やします。
C.
Cloud Armorが分散型サービス拒否(DDoS)攻撃を検出し、トラフィックがCloud Runサービスにルーティングされる前にブロックしているかどうかを確認します。必要に応じて、プロジェクト内のCloud Armorポリシーを無効にします。
D.
Cloud Runサービスがmax-instances値と同じ数のインスタンスにスケールしたかどうかを確認します。必要に応じて、max-instances値を増やします。
Question 227

あなたは、画像のサイズ変更、切り抜き、ウォーターマーク挿入などの様々なタスクを処理する必要がある新しい画像処理アプリケーションを開発しています。また、ワークフローを監視し、大量の画像がある場合でも効率的にスケールすることを確認する必要があります。あなたは、最小限の労力で画像処理タスクとワークフロー監視を自動化したいと考えています。どうすべきでしょうか?

A.
Cloud Composer を使用して画像処理ワークフローを管理します。ワークフローの監視と分析には Dataproc を使用します。
B.
Cloud Run を使用して画像処理機能をデプロイします。API を公開するために Apigee を使用します。ワークフローの監視には Cloud Logging を使用します。
C.
Workflows を実装して画像処理タスクをオーケストレーションします。ワークフローの監視には Cloud Logging を使用します。
D.
Cloud Build を使用して画像処理タスク用の Cloud Functions をトリガーします。ワークフローの監視には Cloud Monitoring を使用します。
Question 228

あなたは、Cloud Run 上の本番環境にデプロイされる Web アプリケーションを開発しています。このアプリケーションは複数のマイクロサービスで構成されており、一部は公開アクセス可能で、その他は Google ID による認証後にのみアクセス可能です。認証されたユーザーのみが制限付きサービスにアクセスでき、アプリケーションの公開サービスには無制限のアクセスを許可する必要があります。管理オーバーヘッドと複雑さを最小限に抑えながら、最も安全なアプローチを使用したいと考えています。アクセスをどのように構成すべきですか?

A.
すべてのマイクロサービスに対して Identity-Aware Proxy (IAP) を有効にします。各アプリケーションの認証要件を確認し、それぞれのサービスへのアクセスを制御する新しいマイクロサービスを開発します。
B.
すべてのマイクロサービスに対して Identity-Aware Proxy (IAP) を有効にします。制限付きサービスのアクセス制御リスト (ACL) を管理し、公開サービスへのアクセスには allAuthenticatedUsers を構成します。
C.
すべてのマイクロサービスに対して Cloud Endpoints と Firebase Authentication を使用します。Firebase ルールを構成して各サービスのアクセス制御リスト (ACL) を管理し、公開サービスへのアクセスを許可します。
D.
公開マイクロサービスと制限付きマイクロサービス用に別々の Cloud Run サービスを構成します。制限付きサービスに対してのみ Identity-Aware Proxy (IAP) を有効にし、Cloud Run の Ingress 設定を「内部および Cloud Load Balancing」に構成します。
Question 229

あなたは、金融リスク計算APIを提供する会社のリード開発者です。このAPIはCloud Run上に構築されており、gRPCインターフェースを持っています。あなたは頻繁にリスク計算機の最適化を開発しています。あなたは、すべての顧客に最適化を展開する前に、最適化を試すために登録した一部の顧客に対してこれらの最適化を有効にしたいと考えています。あなたのCI/CDパイプラインは新しいイメージをビルドし、Artifact Registryに保存しました。 どのロールアウト戦略を使用すべきですか?

A.
登録顧客の割合に基づいてCloud Runのトラフィック分割を設定することで、新しいサービスにトラフィックを移行する。
B.
ブルー/グリーンデプロイメントアプローチを使用して、新しいサービスにトラフィックを移行する。
C.
登録顧客に対してフィーチャーフラグを使用して、新しいサービスにトラフィックを移行する。
D.
新しいサービスにトラフィックを移行し、Cloud Runのセッションアフィニティを有効にする。
Question 230

あなたのeコマースアプリケーションはユーザーベースが急速に増加しており、バックエンドAPIへの過剰なリクエストによりパフォーマンスの問題が発生しています。このAPIはあなたのチームが開発および管理しています。Cloud SQLバックエンドデータベースは高い需要への対応に苦慮しており、遅延やタイムアウトが発生しています。APIパフォーマンスを最適化し、ユーザーエクスペリエンスを向上させる解決策を実装する必要があります。どうすべきでしょうか?

A.
Apigeeを使用してAPIを公開します。Memorystore for Redisを使用して頻繁にアクセスされるデータをキャッシュします。アプリケーションに指数バックオフを実装して、失敗したリクエストを再試行します。
B.
Apigeeを使用してAPIを公開します。Apigeeでレート制限とアクセス制御ポリシーを実装してAPIトラフィックを制御します。Pub/Subを使用してリクエストをキューイングし、データベースの過負荷を防ぎます。
C.
Cloud Load Balancingを使用してAPIを公開します。ロードバランサーの前面でCloud CDNを使用してレスポンスをキャッシュします。指数バックオフを実装して、失敗したリクエストを再試行します。
D.
Cloud Load Balancingを使用してAPIを公開します。データベースインスタンスのメモリを増やして、より多くの同時リクエストを処理できるようにします。アプリケーションコードにカスタムのレート制限メカニズムを実装してAPIリクエストを制御します。