MENU
会員登録（無料）
  1. ホーム
  2. Google Cloud認定 Professional Cloud Developer WEB問題集

Google Cloud認定 Professional Cloud Developer WEB問題集

WEB問題集

Question#1(Professional Cloud Developer)

あなたは App Engine と Cloud SQL for PostgreSQL を使用してアプリケーションを開発しています。新しいアプリケーションのバージョンを他の開発者と共有している開発環境にデプロイする前に、ローカルでアプリケーションコードをテストしたいと考えています。

Cloud SQL インスタンスへのすべてのトラフィックを暗号化し、Cloud IAM と PostgreSQL に対して認証された状態を維持しながら、アプリケーションをテストするために App Engine のローカル開発環境をセットアップする必要があります。ローカル開発サーバーを起動する前に、何をすべきですか？

ディスカッション 0

正解：B

この問題の核心は、「ローカル環境からリモートの Cloud SQL へ、安全かつ簡単に接続する方法」を問うている点にあります。

なぜ B が正解なのか？

  1. 暗号化と認証の簡略化: Cloud SQL Auth Proxy は、TLS 1.3 を使用してトラフィックを自動的に暗号化します。また、IAM（Identity and Access Management）を使用した認証をサポートしているため、SSL 証明書の管理を自分で行う必要がありません。

  2. ローカル開発のベストプラクティス: プロキシをローカルで起動すると、アプリケーションからは localhost（またはローカルの Unix ソケット）に接続しているように見えます。これにより、コード内で複雑な IP 制限や SSL 構成を書く必要がなくなります。

  3. 要件の充足: 問題文にある「すべてのトラフィックを暗号化」「Cloud IAM と PostgreSQL で認証」という要件を、最小限の手間で満たす標準的な手法です。

Question#2(Professional Cloud Developer)

あなたは Cloud Run 上で公開 Web アプリケーションを開発しており、Cloud Run サービスを公開 IP アドレスで直接公開しています。現在、高トラフィック負荷に対するアプリケーションの復元力を確認するために負荷テストを実施しています。

テストの結果、少量のトラフィックでは期待通りに動作しますが、高い負荷をかけると Web サーバーの動作が遅くなり、エラーメッセージが返されることがわかりました。この問題をどのようにトラブルシューティングすべきですか？

ディスカッション 0

正解：D

この問題のポイントは、**「低負荷では正常だが、高負荷でエラーが出る ＝ リソースが足りていない」**という状況の特定です。

なぜ D が正解なのか？

  1. スケーリングの限界: Cloud Run はトラフィックに応じて自動的にインスタンスを増やしますが、max-instances 設定によってその上限が決められています。この上限に達すると、それ以上のリクエストを処理できなくなり、リクエストがキューに溜まって応答が遅くなったり、最終的にタイムアウトエラーを返したりします。

  2. トラブルシューティングの定石: 「負荷が高まるとパフォーマンスが低下する」場合、最初に確認すべきなのは「サービスが十分にスケールアウトできているか」です。

Question#3(Professional Cloud Developer)
あなたは、画像のサイズ変更、切り抜き、透かし入れなど、さまざまなタスクを処理する新しい画像処理アプリケーションを開発しています。また、ワークフローを監視し、大量の画像がある場合に効率的にスケーリングされるようにする必要があります。最小限の手間で、画像処理タスクとワークフローの監視を自動化したいと考えています。あなたは何をすべきですか？
ディスカッション 0

正解：C

この問題のキーワードは、**「最小限の手間（least effort）」と「ワークフローのオーケストレーション」**です。

なぜ C が正解なのか？

  1. Workflows の適合性: Google Cloud Workflows は、HTTP ベースのサービス（Cloud Functions や Cloud Run など）を連結して一連のプロセスを作るための、サーバーレスでフルマネージドなオーケストレーション サービスです。

  2. 最小限の手間: Workflows はサーバーレスであるため、インフラの管理が一切不要です。YAML や JSON で定義するだけで、リトライ処理や並列処理、条件分岐などを簡単に実装できます。

  3. 監視の統合: Workflows は Cloud Logging とネイティブに統合されており、各ステップの実行状況やエラーを簡単かつ詳細に監視できます。

Question#4(Professional Cloud Developer)

あなたは Cloud Run にデプロイする予定の Web アプリケーションを開発しています。このアプリケーションは複数のマイクロサービスで構成されており、一部は公開アクセス可能ですが、他の一部は Google ID による認証後のみアクセス可能にする必要があります。

公開サービスへの無制限のアクセスを許可しつつ、制限されたサービスには認証されたユーザーのみがアクセスできるようにする必要があります。管理の手間と複雑さを最小限に抑えながら、最も安全なアプローチを採用したいと考えています。アクセスをどのように構成すべきですか？

ディスカッション 0

正解：D

この問題のポイントは、Identity-Aware Proxy (IAP) を適切に使い分け、外部公開用と内部用の境界を明確にすることです。

なぜ D が正解なのか？

  1. IAP の役割: IAP は、Google Cloud のロードバランサ（HTTPS）と連携して動作し、ユーザーの ID に基づいてアクセスを制御するフルマネージドなサービスです。コードを書き換えることなく認証レイヤーを追加できるため、管理の複雑さを最小限に抑えられます。

  2. Ingress 設定による保護: Cloud Run の ingress 設定を「Internal and Cloud Load Balancing」にすることで、Cloud Run のデフォルトの *.run.app URL への直接アクセスを遮断し、必ずロードバランサ（および IAP）を経由するように強制できます。これが「最も安全なアプローチ」です。

  3. 分離によるシンプル化: 公開サービスと制限付きサービスを分けて構成することで、公開サービスには IAP をかけず、機密サービスにだけ強固な認証を適用するという切り分けが最も単純で確実です。

Question#5(Professional Cloud Developer)

あなたは、金融リスク計算 API を提供する企業のリード開発者です。この API は Cloud Run 上に構築されており、gRPC インターフェースを備えています。あなたは頻繁にリスク計算機の最適化を行っています。

すべての顧客に展開する前に、最適化を試用するために登録した特定の顧客に対してのみ、これらの最適化を有効にしたいと考えています。あなたの CI/CD パイプラインはすでに新しいイメージをビルドし、Artifact Registry に保存しています。

どのロールアウト戦略を使用すべきですか？

ディスカッション 0

正解：C

この問題の鍵は、**「特定の条件（登録済みかどうか）に基づいて、特定のユーザーだけに新機能を公開する」**という点にあります。

なぜ C が正解なのか？

  1. きめ細かな制御: Cloud Run の標準機能である「トラフィック分割（A案）」は、リクエストの**割合（％）**でランダムに振り分けることはできますが、「特定の顧客（IDや属性）」を識別して振り分けることはできません。

  2. 機能フラグ（Feature Flag）の役割: アプリケーションコード内で「もしこのユーザーが試用登録済みなら、新しいロジックを使う」という条件分岐を行う手法です。これにより、インフラ側の設定変更なしに、特定のユーザーに対してのみ安全に新機能をリリースできます。

  3. gRPC との親和性: gRPC を使用している場合でも、ヘッダー情報やメタデータに含まれるユーザー識別子を利用して機能フラグを適用するのが一般的で確実な方法です。

次のページ