CertPass

Question 201

この質問については、TerramEarth のケーススタディを参照してください。バックエンドにいくつかの Cloud Functions を使用する新しいアプリケーションの構築を開始します。あるユースケースでは、Cloud Function func_display が別の Cloud Function func_query を呼び出す必要があります。func_query が func_display からの呼び出しのみを受け付けるようにしたいと考えています。また、Google の推奨するベストプラクティスに従いたいと考えています。どうすればよいですか？

トークンを作成し、環境変数として func_display に渡します。func_query を呼び出す際に、リクエストにトークンを含めます。同じトークンを func_query に渡し、トークンが異なる場合は呼び出しを拒否します。

func_query を「認証が必要」に設定します。一意のサービスアカウントを作成し、func_display に関連付けます。そのサービスアカウントに func_query の呼び出し元ロール (invoker role) を付与します。func_display 内で ID トークンを作成し、func_query を呼び出す際にリクエストにトークンを含めます。

func_query を「認証が必要」に設定し、内部トラフィックのみを受け付けるようにします。これら 2 つの関数を同じ VPC 内に作成します。func_query に対する上り（内向き）ファイアウォールルールを作成し、func_display からのトラフィックのみを許可します。

これら 2 つの関数を同じプロジェクトと VPC 内に作成します。func_query が内部トラフィックのみを受け付けるようにします。func_query に対する上り（内向き）ファイアウォールを作成し、func_display からのトラフィックのみを許可します。また、両方の関数が同じサービスアカウントを使用するようにします。

Question 202

この質問については、TerramEarthのケーススタディを参照してください。レガシーなモノリシックアプリケーションを、コンテナ化されたいくつかのRESTfulマイクロサービスに分割しました。これらのマイクロサービスをCloud Runで実行したいと考えています。また、サービスが顧客に対して高可用性かつ低レイテンシであることを保証したいと考えています。どうすればよいですか？

Cloud Runサービスを複数のアベイラビリティゾーンにデプロイします。サービスを指すCloud Endpointsを作成します。グローバルHTTP(S)負荷分散インスタンスを作成し、そのバックエンドにCloud Endpointsをアタッチします。

Cloud Runサービスを複数のリージョンにデプロイします。サービスを指すサーバーレスネットワークエンドポイントグループ（NEG）を作成します。グローバルHTTP(S)負荷分散インスタンスで使用されるバックエンドサービスに、サーバーレスNEGを追加します。

Cloud Runサービスを複数のリージョンにデプロイします。Cloud DNSで、サービスを指すレイテンシベースのDNS名を作成します。

Cloud Runサービスを複数のアベイラビリティゾーンにデプロイします。TCP/IPグローバルロードバランサーを作成します。そのバックエンドサービスにCloud Runのエンドポイントを追加します。

Question 203

この質問については、TerramEarthのケーススタディを参照してください。あなたは、プライベートデータセンターからGoogle CloudへLinuxベースのアプリケーションを移行しています。TerramEarthのセキュリティチームから、Common Vulnerabilities and Exposures (CVE)によって公開された最近のLinuxの脆弱性がいくつか送られてきました。これらの脆弱性が移行にどのように影響するかを理解するための支援が必要です。何をすべきですか？（2つ選択）

CVEに関するサポートケースを開き、サポートエンジニアとチャットする。

Google Cloud Status DashboardでCVEを読み、影響を理解する。

Google Cloud Platform Security BulletinsでCVEを読み、影響を理解する。

Stack OverflowでCVEに関する質問を投稿し、説明を得る。

Google CloudディスカッショングループでCVEに関する質問を投稿し、説明を得る。

Question 204

この質問については、TerramEarthのケーススタディを参照してください。TerramEarthには、クラウドに移行できないレガシーWebアプリケーションがあります。しかし、アプリケーションを監視するためのクラウドネイティブな方法を構築したいと考えています。アプリケーションがダウンした場合、できるだけ早くURLを「サイト利用不可」ページに向けるようにしたいです。また、運用チームが問題に関する通知を受け取るようにしたいです。最小コストで信頼性の高いソリューションを構築する必要があります。どうすべきでしょうか？

Cloud Runでスケジュールジョブを作成し、毎分コンテナを呼び出します。コンテナはアプリケーションURLをチェックします。アプリケーションがダウンしている場合、URLを「サイト利用不可」ページに切り替え、運用チームに通知します。

Compute Engine VMで毎分実行されるcronジョブを作成します。cronジョブはPythonプログラムを呼び出してアプリケーションURLをチェックします。アプリケーションがダウンしている場合、URLを「サイト利用不可」ページに切り替え、運用チームに通知します。

Cloud Monitoringの稼働時間チェックを作成して、アプリケーションURLを検証します。失敗した場合、Pub/Subキューにメッセージを送信し、それがCloud FunctionをトリガーしてURLを「サイト利用不可」ページに切り替え、運用チームに通知します。

Cloud Error Reportingを使用してアプリケーションURLをチェックします。アプリケーションがダウンしている場合、URLを「サイト利用不可」ページに切り替え、運用チームに通知します。

Question 205

この質問については、TerramEarthのケーススタディを参照してください。あなたはTerramEarth向けのマイクロサービスベースのアプリケーションを構築しています。アプリケーションはDockerコンテナに基づいています。Googleが推奨するプラクティスに従って、アプリケーションを継続的にビルドし、ビルドアクティファクトを保存したいと考えています。どうすべきですか？

Cloud Buildで新しいソース変更に対するトリガーを設定します。Cloud Buildを呼び出して各マイクロサービスのコンテナイメージをビルドし、コードのコミットハッシュを使用してタグ付けします。イメージをContainer Registryにプッシュします。

Cloud Buildで新しいソース変更に対するトリガーを設定します。トリガーはビルドジョブを呼び出し、マイクロサービスのコンテナイメージをビルドします。イメージにバージョン番号でタグ付けし、Cloud Storageにプッシュします。

リポジトリを毎分チェックするSchedulerジョブを作成します。新しい変更があるたびに、Cloud Buildを呼び出してマイクロサービスのコンテナイメージをビルドします。現在のタイムスタンプを使用してイメージにタグ付けし、Container Registryにプッシュします。

Cloud Buildで新しいソース変更に対するトリガーを設定します。Cloud Buildを呼び出して1つのコンテナイメージをビルドし、イメージに「latest」ラベルでタグ付けします。イメージをContainer Registryにプッシュします。

Professional Cloud Architect