Professional Cloud Developer

Question 76

ケーススタディ - これはケーススタディです。ケーススタディには個別の時間制限はありません。各ケースを完了するために、試験時間を好きなだけ使用できます。ただし、この試験には追加のケーススタディやセクションが含まれる場合があります。試験時間内にすべての問題を完了できるように、時間を管理する必要があります。 ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケーススタディには、シナリオに関する詳細情報を提供する展示資料やその他のリソースが含まれる場合があります。各質問は、このケーススタディの他の質問とは独立しています。 このケーススタディの最後に、確認画面が表示されます。この画面では、試験の次のセクションに進む前に、解答を確認して変更することができます。新しいセクションを開始した後は、このセクションに戻ることはできません。 ケーススタディを開始するには - このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインにあるボタンを使用してケーススタディの内容を確認してください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題点などの情報が表示されます。ケーススタディに「すべての情報」タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。 会社概要 - HipLocalは、近接した人々間のコミュニケーションを促進するために設計されたコミュニティアプリケーションです。イベントの計画やスポーツイベントの開催、企業が地域コミュニティとつながるために使用されています。HipLocalは最近ダラスのいくつかの地域でローンチされ、急速に世界的な現象へと成長しています。その独自のハイパーローカルなコミュニティコミュニケーションとビジネスアウトリーチのスタイルは、世界中で需要があります。 経営幹部の声明 - 私たちはナンバーワンの地域コミュニティアプリです。地域コミュニティサービスをグローバルに展開する時が来ました。当社のベンチャーキャピタル投資家は、メンバーが互いに10マイル離れていても10,000マイル離れていても、オンラインになる新しいローカルおよび仮想コミュニティに対して、急速な成長と同じ優れたエクスペリエンスを期待しています。 ソリューションコンセプト - HipLocalは、既存のサービスを更新された機能で新しい地域に拡大し、グローバルな顧客により良いサービスを提供したいと考えています。これらの地域をそれぞれのタイムゾーンでサポートするために、新しいチームを雇用し、トレーニングしたいと考えています。アプリケーションがスムーズにスケールし、明確な稼働時間データを提供し、発生した問題を分析して対応できるようにする必要があります。 既存の技術環境 - HipLocalの環境は、オンプレミスのハードウェアとGoogle Cloud Platformで実行されているインフラストラクチャが混在しています。HipLocalチームは自社のアプリケーションをよく理解していますが、グローバル規模のアプリケーションに関する経験は限られています。既存の技術環境は次のとおりです。 • 既存のAPIは、GCPでホストされているCompute Engine仮想マシンインスタンス上で実行されています。 • 状態は、GCP内の単一インスタンスのMySQLデータベースに保存されています。 • リリースサイクルには、QAテストを可能にするための開発フリーズが含まれています。 • アプリケーションにはロギングがありません。 • アプリケーションは、平日の夜間のトラフィックが少ない時間帯にインフラストラクチャエンジニアによって手動でデプロイされます。 • 稼働時間の基本的な指標はありますが、APIが応答しない場合にアラートが頻繁に発生します。 ビジネス要件 - HipLocalの投資家は、事業範囲を拡大し、見られる需要の増加に対応したいと考えています。要件は次のとおりです。 • アプリケーションの可用性を新しい地域に拡大する。 • 同時ユーザー数を10倍サポートする。 • ユーザーが異なる地域に移動したときに一貫したエクスペリエンスを確保する。 • 製品の収益化方法をよりよく理解するために、ユーザーアクティビティメトリックを取得する。 • 新しい地域における規制(例:GDPR)への準拠を確保する。 • インフラストラクチャ管理の時間とコストを削減する。 • クラウドコンピューティングに関するGoogle推奨プラクティスを採用する。 ○ アプリケーションライフサイクル管理に関する標準化されたワークフローとプロセスを開発する。 ○ サービスレベル指標(SLI)とサービスレベル目標(SLO)を定義する。 技術要件 - • オンプレミスデータセンターとクラウドでホストされているアプリケーションおよびインフラストラクチャ間の安全な通信を提供する。 • アプリケーションは使用状況メトリックとモニタリングを提供する必要がある。 • APIには認証と認可が必要である。 • 新機能のより迅速かつ正確な検証を実装する。 • ロギングとパフォーマンスメトリックは、デバッグ情報とアラートを提供できるように、実用的な情報を提供する必要がある。 • ユーザーの需要に合わせてスケールする必要がある。 この質問については、HipLocalのケーススタディを参照してください。 ユーザーの大幅な増加に対応するためにアプリケーションがスケールできるように、HipLocalはアーキテクチャをどのように再設計する必要がありますか?

A.
Google Kubernetes Engine (GKE) を使用してアプリケーションをマイクロサービスとして実行します。MySQLデータベースは専用のGKEノードで実行します。
B.
複数のCompute Engineインスタンスを使用してMySQLを実行し、状態情報を保存します。Google Cloudマネージドロードバランサを使用してインスタンス間の負荷を分散します。スケーリングにはマネージドインスタンスグループを使用します。
C.
Memorystoreを使用してセッション情報を保存し、Cloud SQLを使用して状態情報を保存します。Google Cloudマネージドロードバランサを使用してインスタンス間の負荷を分散します。スケーリングにはマネージドインスタンスグループを使用します。
D.
Cloud Storageバケットを使用してアプリケーションを静的ウェブサイトとして提供し、別のCloud Storageバケットを使用してユーザーの状態情報を保存します。
Question 77

ケーススタディ - これはケーススタディです。ケーススタディには個別の時間制限はありません。各ケースを完了するために、試験時間を好きなだけ使用できます。ただし、この試験には追加のケーススタディやセクションが含まれる場合があります。試験時間内にすべての問題を完了できるように、時間を管理する必要があります。 ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケーススタディには、ケーススタディで説明されているシナリオに関する詳細情報を提供する展示資料やその他のリソースが含まれる場合があります。各質問は、このケーススタディの他の質問から独立しています。 このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、解答を確認して変更することができます。新しいセクションを開始した後は、このセクションに戻ることはできません。 ケーススタディを開始するには - このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左ペインのボタンを使用してケーススタディの内容を確認してください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題点などの情報が表示されます。ケーススタディに「すべての情報」タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。 会社概要 - HipLocalは、近接した人々間のコミュニケーションを促進するために設計されたコミュニティアプリケーションです。イベントの計画やスポーツイベントの開催、企業が地域のコミュニティとつながるために使用されています。HipLocalは最近ダラスのいくつかの地域でローンチされ、急速に世界的な現象へと成長しています。そのユニークなスタイルの超ローカルなコミュニティコミュニケーションとビジネスアウトリーチは、世界中で需要があります。 経営陣の声明 - 私たちはナンバーワンのローカルコミュニティアプリです。ローカルコミュニティサービスをグローバルに展開する時が来ました。私たちのベンチャーキャピタル投資家は、メンバーが互いに10マイル離れていても10000マイル離れていても、オンラインになる新しいローカルおよび仮想コミュニティに対して、急速な成長と同じ優れた体験を期待しています。 ソリューションコンセプト - HipLocalは、既存のサービスを更新された機能で新しい地域に拡大し、グローバルな顧客により良いサービスを提供したいと考えています。これらの地域をそれぞれのタイムゾーンでサポートするために、新しいチームを雇用し、トレーニングしたいと考えています。アプリケーションがスムーズにスケールし、明確な稼働時間データを提供し、発生した問題を分析して対応できるようにする必要があります。 既存の技術環境 - HipLocalの環境は、オンプレミスのハードウェアとGoogle Cloud Platformで実行されているインフラストラクチャが混在しています。HipLocalチームは自社のアプリケーションをよく理解していますが、グローバル規模のアプリケーションに関する経験は限られています。既存の技術環境は次のとおりです。 • 既存のAPIは、GCPでホストされているCompute Engine仮想マシンインスタンス上で実行されています。 • 状態は、GCP内の単一インスタンスのMySQLデータベースに保存されています。 • リリースサイクルには、QAテストを可能にするための開発フリーズが含まれています。 • アプリケーションにはログがありません。 • アプリケーションは、平日の夜間のトラフィックが少ない時間帯にインフラストラクチャエンジニアによって手動でデプロイされます。 • 稼働時間の基本的な指標はありますが、APIが応答しない場合にアラートが頻繁に発生します。 ビジネス要件 - HipLocalの投資家は、事業範囲を拡大し、見られる需要の増加をサポートしたいと考えています。彼らの要件は次のとおりです。 • アプリケーションの可用性を新しい地域に拡大する。 • 同時ユーザー数を10倍サポートする。 • ユーザーが異なる地域に旅行したときに一貫した体験を保証する。 • 製品を収益化する方法をよりよく理解するために、ユーザーアクティビティメトリクスを取得する。 • 新しい地域での規制(例:GDPR)への準拠を保証する。 • インフラストラクチャの管理時間とコストを削減する。 • クラウドコンピューティングに関するGoogle推奨のプラクティスを採用する。 ○ アプリケーションライフサイクル管理に関する標準化されたワークフローとプロセスを開発する。 ○ サービスレベル指標(SLI)とサービスレベル目標(SLO)を定義する。 技術要件 - • オンプレミスデータセンターとクラウドでホストされているアプリケーションおよびインフラストラクチャ間の安全な通信を提供する。 • アプリケーションは使用状況メトリクスとモニタリングを提供する必要がある。 • APIには認証と認可が必要である。 • 新機能のより迅速かつ正確な検証を実装する。 • ログとパフォーマンスメトリクスは、デバッグ情報とアラートを提供できるように、実用的な情報を提供する必要がある。 • ユーザーの需要に合わせてスケールする必要がある。 この質問については、HipLocalのケーススタディを参照してください。 HipLocalは、機能要件を満たす安定したテスト環境をQAチームに提供し続けながら、API開発速度をどのように向上させるべきですか?

A.
コードにユニットテストを含め、すべてのテストが合格するまでQAへのデプロイを禁止する。
B.
コードにパフォーマンステストを含め、すべてのテストが合格するまでQAへのデプロイを禁止する。
C.
QA環境のヘルスチェックを作成し、環境が異常な場合は後でAPIを再デプロイする。
D.
トラフィックスプリッティングを使用してAPIをApp Engineに再デプロイする。エラーが見つかった場合は、QAトラフィックを新しいバージョンに移動しない。
Question 78

ケーススタディ - これはケーススタディです。ケーススタディには個別の時間制限はありません。各ケースを完了するために、試験時間を好きなだけ使用できます。ただし、この試験には追加のケーススタディやセクションが含まれる場合があります。試験時間内にすべての問題を完了できるように、時間を管理する必要があります。 ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケーススタディには、ケーススタディで説明されているシナリオに関する詳細情報を提供する展示資料やその他のリソースが含まれる場合があります。各質問は、このケーススタディの他の質問とは独立しています。 このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、解答を確認して変更することができます。新しいセクションを開始した後は、このセクションに戻ることはできません。 ケーススタディを開始するには - このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインにあるボタンを使用してケーススタディの内容を確認してください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題点などの情報が表示されます。ケーススタディに「すべての情報」タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。 会社概要 - HipLocalは、近接した人々間のコミュニケーションを促進するために設計されたコミュニティアプリケーションです。イベントの計画やスポーツイベントの開催、企業が地域コミュニティとつながるために使用されています。HipLocalは最近ダラスのいくつかの地域でローンチされ、急速に世界的な現象へと成長しています。その独自の超ローカルなコミュニティコミュニケーションとビジネスアウトリーチのスタイルは、世界中で需要があります。 経営幹部の声明 - 私たちはナンバーワンのローカルコミュニティアプリです。ローカルコミュニティサービスをグローバルに展開する時が来ました。私たちのベンチャーキャピタル投資家は、メンバーが互いに10マイル離れていても10000マイル離れていても、オンラインになる新しいローカルおよび仮想コミュニティに対して、急速な成長と同じ優れた体験を期待しています。 ソリューションコンセプト - HipLocalは、既存のサービスを更新された機能で新しい地域に拡大し、グローバルな顧客により良いサービスを提供したいと考えています。彼らは、これらの地域をそれぞれのタイムゾーンでサポートするための新しいチームを雇用し、トレーニングしたいと考えています。アプリケーションがスムーズにスケールし、明確な稼働時間データを提供し、発生した問題を分析して対応できるようにする必要があります。 既存の技術環境 - HipLocalの環境は、オンプレミスのハードウェアとGoogle Cloud Platformで実行されているインフラストラクチャが混在しています。HipLocalチームは自社のアプリケーションをよく理解していますが、グローバル規模のアプリケーションに関する経験は限られています。既存の技術環境は次のとおりです。 • 既存のAPIは、GCPでホストされているCompute Engine仮想マシンインスタンス上で実行されています。 • 状態は、GCP内の単一インスタンスのMySQLデータベースに保存されています。 • リリースサイクルには、QAテストを可能にするための開発フリーズが含まれています。 • アプリケーションにはロギングがありません。 • アプリケーションは、平日の夜間のトラフィックが少ない時間帯にインフラストラクチャエンジニアによって手動でデプロイされます。 • 稼働時間の基本的な指標はありますが、APIが応答しない場合にアラートが頻繁に発生します。 ビジネス要件 - HipLocalの投資家は、事業範囲を拡大し、見られる需要の増加をサポートしたいと考えています。彼らの要件は次のとおりです。 • アプリケーションの可用性を新しい地域に拡大する。 • 同時ユーザー数を10倍サポートする。 • ユーザーが異なる地域に移動したときに一貫したエクスペリエンスを確保する。 • 製品を収益化する方法をよりよく理解するために、ユーザーアクティビティメトリックを取得する。 • 新しい地域における規制(例:GDPR)への準拠を確保する。 • インフラストラクチャ管理の時間とコストを削減する。 • クラウドコンピューティングに関するGoogle推奨のプラクティスを採用する。 ○ アプリケーションライフサイクル管理に関する標準化されたワークフローとプロセスを開発する。 ○ サービスレベル指標(SLI)とサービスレベル目標(SLO)を定義する。 技術要件 - • オンプレミスのデータセンターとクラウドでホストされているアプリケーションおよびインフラストラクチャ間の安全な通信を提供する。 • アプリケーションは使用状況メトリックとモニタリングを提供する必要がある。 • APIには認証と認可が必要である。 • 新機能のより迅速かつ正確な検証を実装する。 • ロギングとパフォーマンスメトリックは、デバッグ情報とアラートを提供できるように、実用的な情報を提供する必要がある。 • ユーザーの需要に合わせてスケールする必要がある。 この質問については、HipLocalのケーススタディを参照してください。 HipLocalのアプリケーションは、Cloud Client Librariesを使用してGoogle Cloudと対話します。HipLocalは、アプリケーションに最小権限アクセスを実装するために、Cloud Client Librariesで認証と認可を設定する必要があります。彼らは何をすべきですか?

A.
APIキーを作成します。APIキーを使用してGoogle Cloudと対話します。
B.
デフォルトのComputeサービスアカウントを使用してGoogle Cloudと対話します。
C.
アプリケーション用のサービスアカウントを作成します。アプリケーション用の秘密鍵をエクスポートしてデプロイします。サービスアカウントを使用してGoogle Cloudと対話します。
D.
アプリケーション用、およびアプリケーションで使用される各Google Cloud API用にサービスアカウントを作成します。アプリケーションで使用される秘密鍵をエクスポートしてデプロイします。1つのGoogle Cloud APIを持つサービスアカウントを使用してGoogle Cloudと対話します。
Question 79

あなたのサービスは、Cloud Storageから読み込んだ画像にテキストを追加します。年間を通じて繁忙期には、Cloud StorageへのリクエストがHTTP 429 "Too Many Requests"ステータスコードで失敗します。 このエラーにどのように対処すべきですか?

A.
オブジェクトにcache-controlヘッダーを追加する。
B.
GCP Consoleから割り当て(クォータ)の増加をリクエストする。
C.
切り捨て指数バックオフ戦略を用いてリクエストを再試行する。
D.
Cloud StorageバケットのストレージクラスをMulti-regionalに変更する。
Question 80

あなたはオンプレミスデータセンターから Google Cloud への移行の最終段階にいます。期限が迫っている中で、廃止予定のサーバー上でウェブAPIが稼働していることを発見しました。このAPIを Google Cloud に移行しながらモダナイズするためのソリューションを推奨する必要があります。モダナイズされたウェブAPIは、以下の要件を満たす必要があります。 • 毎月末の高トラフィック期間中に自動スケーリングすること • Python 3.x で記述されていること • 頻繁なコード変更に対応するため、開発者が新しいバージョンを迅速にデプロイできること あなたはこの移行におけるコスト、労力、および運用オーバーヘッドを最小限に抑えたいと考えています。どうすべきでしょうか?

A.
コードをモダナイズし、App Engine フレキシブル環境にデプロイする。
B.
コードをモダナイズし、App Engine スタンダード環境にデプロイする。
C.
モダナイズされたアプリケーションを n1-standard-1 Compute Engine インスタンスにデプロイする。
D.
開発チームに、Google Kubernetes Engine 上で Docker コンテナとして実行するようにアプリケーションを書き直すよう依頼する。