Google Cloud認定資格Professional Cloud Developer100題 問題集全問解答＋全問解説付き
Google Cloud認定資格Professional Cloud Developerの過去問100題を全問解答＋全問解説付き
Google Cloud Professional Cloud Developerの最新の問題になります。
筆者が実際に受験して、問題を収集し解答とその解説を全問付けております。
問題数は合計100題。
実際に受験し、重複問題や類似問題を削除しています。
この100問の問題の解答を理解できれば、ほぼ間違いなく、合格すると思います。
ここから問題と解答/解説になります。
100題、全問解答＋全問解説付きになります。
1.
あなたのチームは、金融機関向けのアプリケーションを構築しています。アプリケーションのフロントエンドは Compute Engine で実行され、データは Cloud SQL と 1 つの Cloud Storage バケットに存在します。アプリケーションは PII を含むデータを収集し、Cloud SQL データベースと Cloud Storage バケットに保存します。PII データを保護する必要があります。あなたは何をするべきか？
A. 1) Cloud SQL のプライベート IP アドレスを構成する
2) VPC-SC を使用してサービス境界を作成する
3) Cloud SQL データベースと Cloud Storage バケットを異なるサービス境界に追加する
B. 1) 関連するファイアウォール ルールを作成して、フロントエンドのみが Cloud SQL データベースと通信できるようにする
2) プライベート アクセスを有効にして、フロントエンドが Cloud Storage バケットに非公開でアクセスできるようにします
C. 1) Cloud SQL のプライベート IP アドレスを構成する
2) VPC-SC を使用してサービス境界を作成する
3) Cloud SQL データベースと Cloud Storage バケットを同じサービス境界に追加する
D. 1) 関連するファイアウォール ルールを作成して、フロントエンドのみが Cloud SQL データベースと通信できるようにする
2) IAM を使用して、フロントエンド サービス アカウントのみに Cloud Storage バケットへのアクセスを許可する
正解：C
解説:
A. Cloud SQL のプライベート IP アドレスを構成するのは、公開インターネット経由でのアクセスを避け、データベースへのアクセスをプライベートネットワーク内に限定する良い手法ですが、PIIデータの保護の観点からサービス境界を異なるものにすると、データの管理とセキュリティが複雑になります。
B. ファイアウォール ルールを使用して Cloud SQL へのアクセスをフロントエンドに限定するのは良い手法です。しかし、プライベートアクセスをCloud Storageバケットに設定すると、VPC内からのアクセスが可能になりますが、これだけではPIIデータを十分に保護しているとは言えません。
C. Cloud SQL にプライベートIPアドレスを構成し、VPC-SC（VPC Service Controls）を使用してサービス境界を作成し、Cloud SQLデータベースとCloud Storageバケットを同じサービス境界に配置することで、PIIデータを含む環境全体のセキュリティを向上させます。この方法はデータの隔離を強化し、不正アクセスを防ぐのに効果的です。
D. ファイアウォール ルールとIAM（Identity and Access Management）を使用してアクセスを制御するのは、基本的なセキュリティ手段ですが、VPC-SCのような追加的な保護メカニズムを設定しなければ、PIIデータの保護において不十分かもしれません。IAMでフロントエンドサービスアカウントのみにアクセス権を付与することは、プリンシパルに基づく最小限のアクセス制御の一環としては良いですが、サービスレベルでの隔離やデータエクスフィルトレーションを防ぐためにはVPC-SCの設定が推奨されます。
2.
Cloud Build ビルドを使用して、Docker イメージを開発、テスト、本番環境に昇格させています。これらの各環境に同じ Docker イメージがデプロイされていることを確認する必要があります。
ビルド内の Docker イメージをどのように特定する必要がありますか?
A. 一意の Docker イメージ名を使用します。
B. Docker イメージのダイジェストを使用します。
C. 最新の Docker イメージ タグを使用します。
D. セマンティック バージョンの Docker イメージ タグを使用します。
正解：D
解説:
A. 一意の Docker イメージ名を使用することは、イメージを識別する際の基本ですが、これだけでは開発、テスト、本番環境で同じイメージが使われていることを保証するには不十分です。イメージ名は通常、プロジェクトやアプリケーションを識別するのに使われ、特定のビルドやリリースに対してのみ一意であるとは限りません。
B. Docker イメージのダイジェストを使用すると、イメージの内容が一致することを保証できます。ダイジェストはイメージの内容に基づいたハッシュ値であり、内容が変わればダイジェストも変わるため、同じダイジェストを持つイメージは同一の内容を保持していると確実に言えます。しかし、人間が覚えやすい形式ではないため、実際のプロセスでの使用には不便さが伴うことがあります。
C. 最新の Docker イメージ タグを使用すると、常に最新のビルドを指すため、開発、テスト、本番環境に昇格する際に各環境で異なるイメージがデプロイされる可能性があります。"latest" タグは動的であり、新しいビルドが作成されるたびに更新されるため、環境間で一貫性を保証するための適切な方法ではありません。
D. セマンティック バージョニングの Docker イメージ タグを使用すると、ソフトウェアのバージョン管理のベストプラクティスに従い、マイナー、メジャー、パッチのレベルでバージョンを管理することができます。これにより、バージョン番号が同じであれば同じイメージ内容であることが保証され、開発、テスト、本番環境で一貫性のあるデプロイを行うことができます。
3.
あなたは、Google Kubernetes Engine (GKE) でホストされている JPEG 画像サイズ変更 API を開発しています。サービスの呼び出し元は、同じ GKE クラスタ内に存在します。クライアントがサービスの IP アドレスを取得できるようにします。
あなたは何をするべきか？
A. GKE サービスを定義します。クライアントは Cloud DNS の A レコードの名前を使用して、サービスのクラスタ IP アドレスを見つける必要があります。
B. GKE サービスを定義します。クライアントは、URL でサービス名を使用してサービスに接続する必要があります。
C. GKE エンドポイントを定義します。クライアントは、クライアント コンテナー内の適切な環境変数からエンドポイント名を取得する必要があります。
D. GKE エンドポイントを定義します。クライアントは Cloud DNS からエンドポイント名を取得する必要があります。
正解：C
解説: A. この選択肢は不正解です。GKE クラスタ内でサービスを発見するためには、Cloud DNS の A レコードを使う必要はありません。GKE 内部では、サービス名は内部DNSを通じて自動的にサービスのクラスタIPに解決されるため、直接サービス名を使用してアクセスすることが一般的です。
B. この選択肢も不正解です。URLにサービス名を使用することは正しいが、これはGKE内のサービスを見つけるためのDNS解決の標準的な方法であり、特に「GKE サービスを定義します」という文言がこれを補強します。しかし、この方法ではサービスのIPアドレスを直接取得するわけではなく、DNS解決を通じてアクセスするため、質問の要件を完全には満たしません。
C. 正解です。GKEクラスタ内で他のサービスに接続する際には、Kubernetesのサービスディスカバリー機能を利用します。Kubernetesは各サービスに対して環境変数を提供し、これを用いてサービスのエンドポイントを容易に見つけることができます。この環境変数は、サービス名とサービスが属するネームスペースを組み合わせた形で定義され、これによりクライアントはエンドポイントの名前を取得して接続できます。
D. この選択肢も不正解です。Cloud DNSはインターネットのDNSと同様の機能を提供しますが、GKEクラスタ内でサービス間通信を行う際にCloud DNSを使う必要はありません。クラスタ内通信はKubernetesの内部DNSを使用し、エンドポイントは環境変数やサービスディスカバリーによって取得されます。また、エンドポイントを定義するという言葉は、Kubernetesの文脈では正確ではありません。通常はサービスを定義し、それによってエンドポイントが作成されます。
4.
継承した App Engine でアプリケーションを実行しています。アプリケーションが安全でないバイナリを使用しているかどうか、または XSS 攻撃に対して脆弱であるかどうかを確認したいと考えています。どのサービスを使用する必要がありますか?
A. クラウドアモール
B. Stackdriver Debugger
C. クラウド セキュリティ スキャナー
D. Stackdriver エラー レポート
正解：C
解説: A. クラウドアモールは、Google Cloudリソースへのアクセスを管理するためのツールです。アクセスポリシーを設定し、ユーザーやサービスアカウントの権限を管理するために使用します。しかし、アプリケーションのセキュリティスキャンや脆弱性の検出には使用されません。
B. Stackdriver Debuggerは、実行中のアプリケーションのデバッグを支援するツールです。ソースコードにブレークポイントを設定し、アプリケーションがそのポイントで実行されるときに変数の状態やコールスタックを検査することができますが、セキュリティ脆弱性のスキャンには使用されません。
C. クラウド セキュリティ スキャナーは、Google App Engineアプリケーションの共通のセキュリティ脆弱性を自動的にスキャンし、特定するために使用されるサービスです。これには、クロスサイトスクリプティング（XSS）攻撃や、フラッシュコンテンツ、混在コンテンツなどの脆弱性の検出が含まれます。従って、XSS攻撃に対する脆弱性を探すためには最適なサービスです。
D. Stackdriver エラー レポートは、アプリケーションで発生するランタイムエラーを自動的に検出し、それらを集約して報告するサービスです。エラーレポートは、アプリケーションの安定性を監視し、障害を診断するのに役立ちますが、セキュリティの脆弱性を特定するためのツールではありません。
5.
あなたは小さなスタートアップ企業の Web 開発チームで働いています。あなたのチームは、Cloud Storage や Cloud Build などの Google Cloud サービスを使用して Node.js アプリケーションを開発しています。チームはバージョン管理に Git リポジトリを使用しています。上司から週末に電話があり、会社の Web サイトの 1 つを緊急に更新するように指示されました。開発者はあなただけです。更新を行うには Google Cloud にアクセスする必要がありますが、仕事用のノートパソコンがありません。ソース コードを会社以外のコンピューターにローカルに保存することはできません。開発者環境をどのように設定する必要がありますか?
A. テキスト エディターと Git コマンド ラインを使用して、公共のコンピューターからソース コードの更新をプル リクエストとして送信します。
B. テキスト エディターと Git コマンド ラインを使用して、公共のコンピューターで実行されている仮想マシンからソース コードの更新をプル リクエストとして送信します。
C. 開発には Cloud Shell と組み込みのコード エディターを使用します。ソース コードの更新をプル リクエストとして送信します。
D. Cloud Storage バケットを使用して、編集する必要があるソースコードを保存します。バケットを公共のコンピューターにドライブとしてマウントし、コード エディターを使用してコードを更新します。バケットのバージョニングを有効にして、チームの Git リポジトリを参照します。
正解：C
解説: A. この選択肢は不正解です。公共のコンピューターから直接ソースコードを更新することは、セキュリティ上推奨されません。Gitコマンドラインを使えば可能ではありますが、これはコードをそのコンピューターにダウンロードすることを意味し、問題の条件で禁じられています。
B. この選択肢も不正解です。公共のコンピューターで仮想マシンを使用して作業することは、会社のセキュリティポリシーに違反する可能性があります。また、公共のコンピューターからVMを操作することは、セキュリティリスクを伴います。
C. 正解です。Google Cloud Shellはセキュアな開発環境を提供し、組み込みのコードエディタを使用してソースコードを編集できます。これにより、ローカルマシンにソースコードを保存することなく、直接クラウド上で作業を行うことができます。プルリクエストを送信することで、変更をバージョン管理システムに統合することができます。
D. この選択肢は不正解です。Cloud Storageバケットにソースコードを直接保存することは可能ですが、この方法ではバージョン管理が行われません。さらに、公共のコンピューターにCloud Storageバケットをドライブとしてマウントすることは、セキュリティ上のリスクを高める可能性があります。バージョニングを有効にすると以前のバージョンに戻せるようにはなりますが、Gitリポジトリのような本格的なバージョン管理機能を提供するわけではありません。
6.
新しいアプリケーションを Google Kubernetes Engine にデプロイしましたが、パフォーマンスが低下しています。ログは Cloud Logging に書き込まれ、Prometheus サイドカー モデルを使用して指標を取得しています。ログからのメトリックとデータを関連付けて、パフォーマンスの問題をトラブルシューティングし、コストを最小限に抑えながらリアルタイムのアラートを送信する必要があります。あなたは何をするべきか？
A. Cloud Logging のログをエクスポートし、Prometheus 指標を BigQuery にストリーミングします。繰り返しクエリを実行して結果を結合し、Cloud Tasks を使用して通知を送信します。
B. Prometheus 指標をエクスポートし、Cloud Monitoring を使用してそれらを外部指標として表示します。Cloud Monitoring を構成して、ログからログベースの指標を作成し、それらを Prometheus データと関連付けます。
C. Cloud Logging のログと Prometheus 指標を Cloud Bigtable にエクスポートします。クエリを実行して結果を結合し、Google データポータルで分析します。
D. Cloud Logging ログからカスタム指標を作成し、Prometheus を使用して、Cloud Monitoring REST API を使用して結果をインポートします。
正解：B
解説: A. この選択肢は不正解です。BigQueryはログとメトリックスの大規模な分析に使用できますが、リアルタイムのアラートを設定する目的には適していません。また、Cloud Tasksはバックグラウンドタスクや非同期タスクの実行には適していますが、パフォーマンス問題に対するリアルタイムのアラート通知には直接使用されません。
B. 正解です。PrometheusのメトリックスをCloud Monitoringで外部メトリックスとして扱い、Cloud Loggingでログベースのメトリックスを作成し、それらを関連付けることができます。Cloud Monitoringはリアルタイムのアラートを設定し、パフォーマンス問題を効率的にトラブルシューティングするための機能を提供します。
C. この選択肢は不正解です。Cloud Bigtableは高性能なNoSQLデータベースであり、リアルタイム分析や運用ワークロードに適していますが、Cloud LoggingのログやPrometheusメトリックスのエクスポートには最適ではない場合があります。また、リアルタイムのアラート通知機能を直接提供していません。
D. この選択肢は不正解です。Cloud Loggingからカスタムメトリックスを作成することは可能ですが、Prometheusを介してCloud Monitoring REST APIを使用して結果をインポートするのは一般的なプロセスではありません。この方法では、リアルタイムのアラート通知やパフォーマンスの問題を効率的にトラブルシューティングするためのCloud Monitoringの統合機能を十分に活用できません。
7.
Compute Engine にデプロイされたアプリケーションのメモリ使用量を表示したいと考えています。あなたは何をするべきか？
A. Stackdriver クライアント ライブラリをインストールします。
B. Stackdriver Monitoring エージェントをインストールします。
C. Stackdriver Metrics Explorer を使用します。
D. Google Cloud Platform Console を使用します。
正解：C
解説: A. Stackdriver クライアント ライブラリのインストール自体は、Compute Engine インスタンス上のアプリケーションのメモリ使用量を直接表示することにはつながりません。クライアント ライブラリは主にアプリケーションからStackdriver APIへのデータの送信に使用されますが、既存のメトリクスの表示には使用されません。
B. Stackdriver Monitoring エージェントのインストールはメトリクスの収集を可能にするため、正解と考えることもできます。しかし、このエージェントをインストールすることで、インスタンスからメトリクスをStackdriverに送信できるようになりますが、それらのメトリクスを「表示」することはできません。メトリクスの表示は、ウェブインターフェースやAPIクエリを通じて行う必要があります。
C. Stackdriver Metrics Explorer は正解です。Metrics Explorerを使用すると、Compute Engine インスタンスなどのリソースのメトリクスを視覚的に表示し、分析することができます。メモリ使用量などの既存のメトリクスを調べる際には、このツールが直接的で効果的です。
D. Google Cloud Platform Console は、Compute Engine インスタンスの概要としてのメトリクスを表示することができるので、これも一つの正解となる場合があります。ただし、より詳細なメトリクス分析やカスタムメトリクスを見るためには、Stackdriver Monitoring の機能を使う必要があるため、この文脈では最適な選択とは言えないかもしれません。
8.
本番環境にデプロイされたアプリケーションがあります。新しいバージョンがデプロイされると、アプリケーションが本番環境のユーザーからトラフィックを受信するまで、いくつかの問題は発生しません。影響と影響を受けるユーザー数の両方を減らしたいと考えています。
どの展開戦略を使用する必要がありますか?
A. 配置を再作成します
B. カナリア デプロイ
C. ローリング展開
D. ブルー/グリーン展開
正解：D
解説:
A. 再作成の配置は、既存のバージョンを完全に停止してから新しいバージョンを起動する方法です。これにより、ダウンタイムが発生し、すべてのユーザーに影響を与えるため、要件には適していません。
B. カナリアデプロイは、新しいバージョンを少数のユーザーにロールアウトして問題を検出し、リスクを減らす方法です。しかし、本番環境のすべてのユーザーに新しいバージョンをデプロイする前に問題を特定し解決することが可能であるとは限りません。
C. ローリング展開は、新しいバージョンを段階的に導入し、古いバージョンを徐々に置き換える方法です。これは影響を受けるユーザーの数を減らすことができますが、新しいバージョンに問題がある場合は、その問題をすぐに全ユーザーに拡散するリスクがあります。
D. ブルー/グリーン展開は、現行バージョン（ブルー）と新しいバージョン（グリーン）を並行して稼働させる方法です。新しいバージョンが問題なく動作することを確認した後でのみ、全てのトラフィックを新しいバージョンに切り替えます。この方法では、問題がある場合には早急に旧バージョンにロールバックすることができるため、影響と影響を受けるユーザーの数を最小限に抑えることができます。したがって、問題の影響を最小限に抑えたいという要件に対して最も適した戦略です。正解はDです。
9.
あなたのチームは、Go ogle Kubernetes Engine (GKE) で実行されるステートレス サービスを開発しています。GKE クラスタで実行されている他のサービスのみがアクセスできる新しいサービスをデプロイする必要があります。サービスは、変化する負荷に対応するために、できるだけ迅速にスケーリングする必要があります。あなたは何をするべきか？
A. Vertical Pod Autoscaler を使用してコンテナーをスケーリングし、ClusterIP サービスを介して公開します。
B. Vertical Pod Autoscaler を使用してコンテナーをスケーリングし、NodePort サービスを介して公開します。
C. 水平ポッド オートスケーラーを使用してコンテナーをスケーリングし、ClusterIP サービスを介して公開します。
D. 水平ポッド オートスケーラーを使用してコンテナーをスケーリングし、NodePort サービスを介して公開します。
正解：C
解説:
A. Vertical Pod Autoscaler (VPA) は、ポッドが使用するCPUやメモリなどのリソースの量を自動的に調整するためのものですが、クラスタ内の負荷の変動に応じてポッドの数自体をスケーリングするわけではありません。ClusterIP サービスはクラスタ内部からのみアクセス可能なため、この要件には適合していますが、迅速なスケーリングを実現するための手段としては不適切です。
B. この選択肢もVPAを使用していますが、NodePort サービスはクラスタ外からのアクセスを可能にするためのもので、問題の要件であるクラスタ内のサービスのみがアクセスできる状態とは異なります。したがって、これも不適切な選択です。
C. 水平ポッドオートスケーラー (HPA) は、実行中のポッドの数を動的にスケーリングするために使用され、変化する負荷に対応することができます。ClusterIP サービスはクラスタ内部からのみアクセス可能であり、要件に合っています。この選択肢は迅速なスケーリングとクラスタ内のみへのアクセスという二つの要件を満たしています。
D. HPAはスケーリングに適していますが、NodePort サービスはクラスタ外への公開に使われるため、このケースには適さない選択です。クラスタ内のサービスだけがアクセスできるようにする要件に反しています。
正解のCは、要件に最も適したオプションです。水平ポッドオートスケーラーを使用して迅速なスケーリングを実現し、ClusterIPでクラスタ内部からのみアクセス可能にすることで、要求されたプライバシーとスケーラビリティを提供します。
10.
あなたの会社には、アプリケーション情報を BigQuery に保持するデータ ウェアハウスがあります。BigQuery データ ウェアハウスは、2 PB のユーザー データを保持します。最近、あなたの会社は EU ユーザーを含むようにユーザー ベースを拡大し、次の要件に準拠する必要があります。
会社は、ユーザーの要求に応じてすべてのユーザー アカウント情報を削除できる必要があります。
すべての EU ユーザー データは、EU ユーザー専用の 1 つのリージョンに保存する必要があります。
どの 2 つのアクションを実行する必要がありますか? （2つ選んでください。）
A. BigQuery 連携クエリを使用して、Cloud Storage からデータをクエリします。
B. EU ユーザーに関する情報のみを保持する EU 地域でデータセットを作成します。
C. EU ユーザーのみの情報を保存するために、EU リージョンに Cloud Storage バケットを作成します。
D. ユーザー レコードをフィルター処理して、Cloud Dataflow パイプラインを使用してデータを再アップロードします。
E. BigQuery で DML ステートメントを使用して、リクエストに基づいてユーザー レコードを更新または削除します。
正解：C,E
解説:
A. BigQueryの連携クエリは、Cloud Storageから直接データをクエリする機能を提供しますが、これはEUユーザーデータをEUリージョンに限定して保持するという要件には直接対応していません。また、ユーザーが要求した場合にユーザーアカウント情報を削除する機能も提供しません。
B. EUのユーザーデータをEU地域に限定して保存する要件に対応するためには、EU地域にデータセットを作成することが一つの解決策です。ただし、この選択肢だけでは、ユーザーが要求した場合に情報を削除する要件には対応していません。
C. EUリージョンにCloud Storageバケットを作成することで、EUユーザーの情報をEUリージョン内に保存する要件に対応できます。これは、データの地理的な配置に関する規制や法律に準拠する一般的な方法です。
D. ユーザーレコードをフィルター処理してCloud Dataflowパイプラインを使用してデータを再アップロードすることは、データの整理や移行に役立ちますが、これ自体がEUユーザーデータをEUリージョンに保存する要件や、ユーザーデータを削除する要件には直接対応していません。
E. BigQueryでDMLステートメントを使用することにより、特定のユーザーのレコードを更新または削除できます。これにより、ユーザーの要求に応じて特定のアカウント情報を削除する要件に対応することができます。
正解の組み合わせは、EUリージョンでデータを保存する要件（C）と、ユーザーの要求に応じてアカウント情報を削除する要件（E）に対応しています。
ここから先は
¥ 2,000
この記事が気に入ったらサポートをしてみませんか？