Google Cloud認定資格Associate Cloud Engineer100題 問題集全問解答＋全問解説付き
Google Cloud認定資格Associate Cloud Engineerの過去問100題を全問解答＋全問解説付き
Google Associate Cloud Engineerの最新の問題になります。
筆者が実際に受験して、問題を収集し解答とその解説を全問付けております。
問題数は合計100題。
実際に受験し、重複問題や類似問題を削除しています。
この100問の問題の解答を理解できれば、ほぼ間違いなく、合格すると思います。
ここから問題と解答/解説になります。
100題、全問解答＋全問解説付きになります。
1.
Google Cloud Platform（GCP）プロジェクトでユーザーがCloud Spanner Identity Access Management（IAM）の役割に追加された時期を確認する必要があります。GCPコンソールで何をすべきですか？
A. Stackdriver Monitoringコンソールに移動し、CloudSpannerの情報を確認します。
B. IAMと管理コンソールを開いて、CloudSpannerロールのIAMポリシーを確認します。
C. CloudSpannerコンソールを開いて構成を確認します。
D. Stackdriver Loggingコンソールに移動し、管理アクティビティログを確認して、CloudSpannerIAMロール用にフィルタリングします。
正解：D
解説: A. Stackdriver Monitoringコンソールは、リソースの監視とパフォーマンスのメトリクスを提供するツールであり、IAMの役割に関連するログ情報を提供しません。
B. IAMと管理コンソールは、IAMポリシーとその設定を管理するためのものですが、特定の役割にユーザーが追加された具体的な時期を確認する機能はありません。
C. Cloud Spannerコンソールは、データベースの構成や操作に関する情報を提供しますが、IAMの役割の割り当ての時期については管理しません。
D. Stackdriver Loggingコンソール（現在はOperations SuiteのLoggingとして知られています）では、Cloud IAMに関連する管理アクティビティログを検索して確認できます。これには、ユーザーがIAMの役割に追加された時期に関するログが含まれており、適切なフィルタリングを通じて必要な情報を抽出できます。これが、このシナリオで求められるアクションを実行するための正しい手順です。
2.
あなたの会社は、ComputeEngineインスタンスでLinuxワークロードを実行しています。あなたの会社は、Googleアカウントを使用しない新しいオペレーションパートナーと協力します。インストールされたツールを保守できるように、運用パートナーにインスタンスへのアクセスを許可する必要があります。あなたは何をするべきか？
A. ComputeEngineインスタンスに対してCloudIAPを有効にし、運用パートナーをCloudIAPトンネルユーザーとして追加します。
B. すべてのインスタンスに同じネットワークタグを付けます。VPCにファイアウォールルールを作成して、運用パートナーからネットワークタグを持つインスタンスへのトラフィックに対してポート22でTCPアクセスを許可します。
C. GoogleCloudVPCと運用パートナーの内部ネットワークの間にCloudVPNを設定します。
D. 運用パートナーにSSHキーペアを生成するように依頼し、VMインスタンスに公開キーを追加します。
正解：B
解説: A. Cloud Identity-Aware Proxy (Cloud IAP) を使用すると、Google アカウントやサービスアカウントを介して Google Cloud リソースへのアクセスをセキュアに管理できます。しかし、この選択肢は「Googleアカウントを使用しない」パートナーへのアクセス許可には適していません。
B. ネットワークタグをインスタンスに付け、ファイアウォールルールを使用して特定のトラフィックを許可することは、特定のインスタンスへのアクセスを管理するための一般的な方法です。この場合、パートナーの IP アドレス範囲からポート 22 (SSH) を通じてのアクセスを許可することで、オペレーションパートナーがツールを保守するために必要なインスタンスへのアクセスを許可できます。
C. Cloud VPN を設定すると、Google Cloud VPC と他のネットワークとの間で安全な接続を確立できます。ただし、これはインスタンスへの直接アクセスを提供するものではなく、ネットワークレベルでの接続に適用されます。
D. SSH キーペアを生成し、公開キーを VM インスタンスに追加することで、運用パートナーがインスタンスに SSH でログインできるようになります。しかし、これはインスタンスへのアクセスを管理するための最良の方法ではありません。Google Cloud のベストプラクティスは、OS レベルでのアクセス管理ではなく、IAM と組み合わせた Cloud IAP などのサービスを使用することです。ただし、このシナリオでは Google アカウントを使用しないパートナーのため、B の選択肢が最適解となります。
3.
あなたの会社は、完了までに約30時間かかるオンプレミスサーバーで1つのバッチプロセスを実行します。タスクは毎月実行され、オフラインで実行でき、中断された場合は再起動する必要があります。コストを最小限に抑えながら、このワークロードをクラウドに移行する必要があります。あなたは何をするべきか？
A. ワークロードをComputeEngineプリエンプティブルVMに移行します。
B. プリエンプティブルノードを使用してワークロードをGoogleKubernetesEngineクラスタに移行します。
C. ワークロードをComputeEngineVMに移行します。必要に応じてインスタンスを開始および停止します。
D. プリエンプティブVMをオンにしてインスタンステンプレートを作成します。テンプレートからマネージドインスタンスグループを作成し、ターゲットCPU使用率を調整します。ワークロードを移行します。
正解：B
解説: A. Compute Engine のプリエンプティブル VM は、コストを削減するための選択肢として有効ですが、これらのインスタンスはいつでもプリエンプト（取り消し）される可能性があります。長時間実行が必要なバッチプロセスには、再開の仕組みがなければ適しません。
B. Google Kubernetes Engine (GKE) のプリエンプティブルノードはコストを節約できるオプションで、Kubernetes の仕組みを利用してプロセスが中断された場合でも自動的に再起動することができます。これはコストを抑えつつ、中断可能な長時間実行タスクに適しています。
C. 通常の Compute Engine VM を使用してワークロードを実行することは、最もシンプルな移行方法の一つですが、コスト削減の観点からは最適ではありません。必要に応じてインスタンスを手動で開始および停止する必要があり、自動化されたスケーリングやコスト削減の利点を享受できません。
D. プリエンプティブル VM を使用するとコストを節約できますが、これをマネージドインスタンスグループで使用すると、インスタンスがプリエンプトされた場合に自動的に新しいインスタンスを起動する機能を持ちます。しかし、バッチプロセスが中断されるリスクを考えると、プロセスの状態を保存し、再開できるような仕組みがなければ不向きです。また、ターゲット CPU 使用率を調整することは、このバッチプロセスの実行スタイルには必ずしも関連しません。
4.
チームは、個別のアプリケーションごとに1つずつ、合計4つのプロジェクトを作成しました。これらすべてのプロジェクトに対して単一の予算があります。これらすべてのプロジェクトに支払う最良の方法は何ですか？
A. 請求済みのアカウントを使用します。これにより、GoogleCloudアカウント内のすべてのプロジェクトの料金が支払われます。
B. プロジェクトごとに請求先アカウントを作成します。
C. 4つのプロジェクトすべてにリンクされた単一の請求先アカウントを使用します。
D. GoogleCloudアカウントにリンクされた単一の請求先アカウントを使用します。
正解：C
解説: A. 請求済みアカウントという用語は少し不明確ですが、ここでは、単一の請求先アカウントがGoogle Cloud アカウント内の全てのプロジェクトに適用されることを意味していると思われます。これにより、1つのアカウントで複数のプロジェクトの費用を支払うことができ、集中管理が可能になります。
B. プロジェクトごとに個別の請求先アカウントを作成することは可能ですが、このシナリオでは合理的ではありません。なぜなら、チームは単一の予算を持っており、複数の請求先アカウントを使用すると管理が複雑になるからです。
C. これが最も適切な選択です。単一の請求先アカウントを作成し、そのアカウントを4つのプロジェクトすべてにリンクします。この方法により、複数のプロジェクトに対して1つの予算を簡単に管理し、追跡することができます。
D. Google Cloud アカウントにリンクされた単一の請求先アカウントを使用するという選択肢は、Aと同様のアプローチを提案しています。この文脈では、Google Cloud アカウントはすべてのプロジェクトに共通の請求先アカウントを意味しているようですが、この選択肢は不適切な言葉遣いのために誤解を招くかもしれません。正しいアプローチは、請求先アカウントを明確にプロジェクトにリンクすることです（選択肢 C）。
5.
Webリクエストを処理するApacheWebサーバーを使用してComputeEngineでn層アプリケーションを実行しています。すべてのロギングをStackdriverに統合する必要があります。ApacheログをStackdriverに取り込むための最良のアプローチは何ですか？
A. ログシンクを作成し、Stackdriverにエクスポートします。
B. インスタンスの作成時にStackdriverの監視を有効にします。
C. Stackdriverは、デフォルトですべてのインスタンスからのアプリケーションデータをログに記録します。
D. インスタンスにStackdriver監視およびロギングエージェントをインストールします。
正解：D
解説: A. ログシンクは、Google Cloudのサービス間でログデータをルーティングするのに使用されますが、Apacheサーバーのログを自動的にStackdriverに取り込むことはできません。これには、ログデータを適切に取り込んでStackdriverに送信するための追加の構成やツールが必要です。
B. インスタンス作成時にStackdriver Monitoringを有効にすることは重要ですが、これだけではApacheのログがStackdriverに取り込まれるわけではありません。監視とロギングは異なる側面であり、ロギングは特にログデータの収集と分析に関係しています。
C. Stackdriverは、デフォルトでGoogle Cloudの多くのサービスからのログを収集しますが、Compute Engineのインスタンス上で動作するアプリケーション（この場合はApache Webサーバー）からのログを自動的に取り込むわけではありません。アプリケーションログを取り込むためには追加の設定が必要です。
D. これが正解であり最良のアプローチです。Compute EngineインスタンスにStackdriver Loggingエージェントをインストールすることで、ApacheサーバーのログをStackdriverに取り込むことができます。Stackdriver Loggingエージェントは、システムやアプリケーションのログを収集し、それらをStackdriver Loggingに送信する役割を担います。このエージェントをインストールして適切に設定することで、ApacheログをStackdriverに統合できます。
6.
AppEngineの標準環境でホストされているウェブサイトがあります。ユーザーの1％にWebサイトの新しいテストバージョンを表示してもらいたいとします。複雑さを最小限に抑えたい。あなたは何をするべきか？
A. 同じアプリケーションに新しいバージョンをデプロイし、-migrateオプションを使用します。
B. 同じプロジェクトに新しいAppEngineアプリケーションを作成します。そのアプリケーションに新しいバージョンをデプロイします。
App Engineライブラリを使用して、リクエストの1％を新しいバージョンにプロキシします。
C. 同じアプリケーションに新しいバージョンをデプロイし、-splitsオプションを使用して、現在のバージョンに99の重みを与え、新しいバージョンに1の重みを与えます。
D. 同じプロジェクトに新しいAppEngineアプリケーションを作成します。そのアプリケーションに新しいバージョンをデプロイします。
トラフィックの1％をその新しいアプリケーションに送信するようにネットワークロードバランサーを構成します。
正解：C
解説:
A. -migrate オプションは、全てのトラフィックを新しいバージョンに移行する際に使用します。ユーザーの1％のみに新しいテストバージョンを表示したい場合には適切ではありません。
B. App Engineでは、同じプロジェクト内で複数のアプリケーションを実行することは通常行いません。また、App Engineライブラリを使用してリクエストの1％をプロキシするのは複雑さを増すため、最小限の複雑さを求めるシナリオには適していません。
C. -splits オプションを使用することで、特定のバージョンへのトラフィックの割合を指定することができます。この場合、新しいバージョンに1の重みを与えることでユーザーの1％のみが新しいテストバージョンを見ることになります。これは複雑さを最小限に抑えつつ要件を満たす方法です。
D. App Engineでネットワークロードバランサーを使ってトラフィックを分散するのは一般的ではなく、また同じプロジェクトに新しいApp Engineアプリケーションを作成することは推奨されていません。このアプローチも複雑さを増すため、問題の要件には合いません。
したがって、最も単純であり要件を満たす選択肢はCです。
7.
データウェアハウスのアーカイブソリューションを構築しており、データをアーカイブするためにクラウドストレージを選択しています。一部の規制要件のために、ユーザーは四半期に1回このアーカイブデータにアクセスできる必要があります。費用対効果の高いオプションを選択したい。どのストレージオプションを使用する必要がありますか？
A. 冷蔵
B. ニアラインストレージ
C. 地域ストレージ
D. マルチリージョンストレージ
正解：B
解説:
A. "冷蔵"はGoogle Cloudのストレージクラスの一つではありません。彼らが提供しているストレージクラスには "Coldline" があり、これはアクセス頻度が低いデータ向けですが、アクセスするときのコストが高くなる可能性があります。
B. "ニアラインストレージ" または "Nearline Storage" は、月に一度程度のアクセス頻度のデータに適しています。四半期に1回のアクセス要件に適合し、費用対効果が高いオプションとなります。
C. "地域ストレージ" または "Regional Storage" は、よくアクセスされるデータや、特定の地域にデータの保管を限定したい場合に適しています。アーカイブデータに対してはコストが高くなり得るため、このケースには最適ではありません。
D. "マルチリージョンストレージ" または "Multi-Regional Storage" は、世界中の複数の地域にデータを保存し、高い耐久性と可用性を提供するオプションです。アーカイブ用途には過剰でコストが高くなりがちです。
費用対効果とアクセス頻度を考慮すると、Bのニアラインストレージが最も適しています。
8.
新しいファイルがCloudStorageバケットにアップロードされるたびにトリガーされるコードスニペットを作成しました。このコードスニペットをデプロイします。あなたは何をするべきか？
A. App Engineを使用し、Pub/Subを使用してアプリケーションをトリガーするようにCloudSchedulerを構成します。
B. Cloud Functionsを使用して、バケットをトリガーリソースとして構成します。
C. Google Kubernetes Engineを使用し、Pub/Subを使用してアプリケーションをトリガーするようにCronJobを構成します。
D. Dataflowをバッチジョブとして使用し、バケットをデータソースとして構成します。
正解：B
解説:
A. App Engineはアプリケーションをホストするプラットフォームですが、それ自体がファイルのアップロードを直接トリガーする仕組みを提供するものではありません。また、Cloud Schedulerは定期的なスケジュールに基づいてジョブを実行するもので、イベント駆動型のトリガーには使用されません。Pub/Subはメッセージングサービスであり、イベントをリッスンして反応するトリガーとしては使えますが、この選択肢はバケットにファイルがアップロードされるたびに自動的にトリガーされるような設定ではありません。
B. Cloud FunctionsはGoogle Cloudのイベント駆動型コンピューティングサービスであり、特定のイベントに応じて自動的にコードを実行するために設計されています。Cloud Storageバケットに新しいファイルがアップロードされるというイベントをトリガーとしてCloud Functionを起動することができます。したがって、この選択肢はこのシナリオで期待される動作を実現します。
C. Google Kubernetes Engine（GKE）はコンテナ化されたアプリケーションのデプロイ、管理、スケーリングのための管理型サービスです。CronJobは定期的にジョブを実行するために使われますが、Cloud Storageバケットにファイルがアップロードされるたびにトリガーされる仕組みではありません。
D. Dataflowはストリームおよびバッチデータ処理タスクを実行するためのフルマネージドサービスです。バッチジョブは定期的な処理のために使われることが多く、リアルタイムのイベントに基づいてトリガーされるタイプのタスクには向いていません。
9.
IP10.0.3.21でライセンスサーバーを検索するアプリケーションがあります。ComputeEngineにライセンスサーバーを展開する必要があります。アプリケーションの構成を変更せず、アプリケーションがライセンスサーバーに到達できるようにする必要があります。あなたは何をするべきか？
A. gcloudを使用してIP 10.0.3.21を静的内部IPアドレスとして予約し、ライセンスサーバーに割り当てます。
B. gcloudを使用してIP 10.0.3.21を静的パブリックIPアドレスとして予約し、ライセンスサーバーに割り当てます。
C. IP 10.0.3.21をカスタムエフェメラルIPアドレスとして使用し、ライセンスサーバーに割り当てます。
D. 自動エフェメラルIPアドレスを使用してライセンスサーバーを起動し、静的内部IPアドレスに昇格させます。
正解：A
解説:
A. 静的内部IPアドレスを予約することで、Compute Engineインスタンスがシャットダウンされたり再起動されたりしても、そのインスタンスに再び同じIPアドレスが割り当てられることを保証できます。gcloudコマンドラインツールを使用して特定のIPアドレスを予約し、その後、そのIPアドレスをCompute Engineインスタンスに割り当てることで、アプリケーションがライセンスサーバーに到達できるようになります。この選択肢が問題の要件を満たすため、正しいアクションを示しています。
B. gcloudコマンドラインツールを使用して静的パブリックIPアドレスを予約することも可能ですが、この場合はアプリケーションが内部IPアドレスでライセンスサーバーを検索しているため、静的パブリックIPアドレスを使用することは要件を満たしません。
C. エフェメラルIPアドレスは、インスタンスに割り当てられる一時的なIPアドレスであり、インスタンスが停止または削除されるとリリースされます。Compute Engineでは、カスタムエフェメラルIPアドレスを指定してインスタンスを起動することはできず、エフェメラルIPアドレスは自動的に割り当てられます。
D. 自動エフェメラルIPアドレスを使用してCompute Engineインスタンスを起動した後、そのIPアドレスを静的内部IPアドレスに昇格させることはできますが、これはランダムなIPアドレスに対して行われます。このケースでは特定のIPアドレス（10.0.3.21）が要求されているため、この方法は要件を満たしません。
したがって、正しい答えはAです。
10.
自動スケーリングが有効になっているGoogleKubernetesEngineを使用して、新しいアプリケーションをホストしています。
パブリックIPアドレスでHTTPSを使用して、この新しいアプリケーションを公開したいとします。あなたは何をするべきか？
A. アプリケーション用にNodePortタイプのKubernetesサービスを作成し、KubernetesIngressを作成してクラウドロードバランサーを介してこのサービスを公開します。
B. アプリケーション用にClusterIPタイプのKubernetesサービスを作成します。このサービスのIPを使用して、アプリケーションのパブリックDNS名を構成します。
C. タイプNodePortのKubernetesサービスを作成して、Kubernetesクラスターの各ノードのポート443でアプリケーションを公開します。負荷分散を実現するには、クラスターのすべてのノードのIPを使用してアプリケーションのパブリックDNS名を構成します。
D. クラスター内にHAProxyポッドを作成して、アプリケーションのすべてのポッドへのトラフィックを負荷分散します。
iptableルールを使用してパブリックトラフィックをHAProxyに転送します。HAProxyが実行されているノードのパブリックIPを使用して、アプリケーションのDNS名を構成します。
正解：A
解説:
A. NodePortサービスはクラスター内のすべてのノードで同じポートを介してアクセスできるサービスを作成します。これにより、外部のトラフィックが特定のポートで各ノードにアクセスできます。Kubernetes Ingressを使用すると、HTTPSを使用したパブリックIPアドレスを介してアプリケーションにアクセスするためのルールを設定できます。IngressはCloud Load Balancerを自動的にプロビジョニングし、エンドユーザーにHTTPS経由で安全にアクセスできるようにします。これは要件を満たすための一般的な方法です。
B. ClusterIPサービスは、クラスター内の内部IPでサービスを公開します。これは、クラスター外部から直接アクセスするためのものではないため、この方法ではパブリックIPアドレスを介したHTTPSアクセスを提供できません。
C. NodePortを使用してクラスターの各ノードでアプリケーションを公開することは可能ですが、この方法はスケーラビリティやセキュリティの観点から最適ではありません。また、負荷分散を適切に実現するためには、外部の負荷分散機能を設定する必要があり、これはKubernetesの標準的な機能を適切に利用していないことになります。
D. Kubernetesクラスター内にHAProxyなどのリバースプロキシをセットアップすることも一つの手法ですが、これには複数のステップが必要であり、また運用の複雑さが増します。HAProxyを利用する場合も、Kubernetesの標準的なIngress機能を利用するよりも管理が煩雑になる可能性があります。iptablesルールを使ってトラフィックをリダイレクトするのも一つの方法ですが、これはKubernetesの自動化されたロードバランシングやIngressの恩恵を受けられないため、このケースでは推奨されません。
ここから先は
¥ 2,000
この記事が気に入ったらサポートをしてみませんか？