
Google Associate-Cloud-Engineer日本語問題集で必ず試験合格させる
Associate-Cloud-Engineer日本語試験問題(更新されたのは2025年)100%リアル問題解答
質問 # 178
Compute Engineにデプロイする本番ワークロードとテストワークロードがあります。本番VMは、テストVMとは異なるサブネットにある必要があります。すべてのVMは、追加のルートを作成せずに、内部IPを介して相互に到達できる必要があります。 VPCと2つのサブネットを設定する必要があります。これらの要件を満たす構成はどれですか?
- A. それぞれが単一のサブネットを持つ2つのカスタムVPCを作成します。同じサブネット内に同じCIDR範囲で各サブネットを作成します。
- B. それぞれが単一のサブネットを持つ2つのカスタムVPCを作成します。各サブネットを異なるリージョンで、異なるCIDR範囲で作成します。
- C. 2つのサブネットを持つ単一のカスタムVPCを作成します。同じサブネット内に同じCIDR範囲で各サブネットを作成します。
- D. 2つのサブネットを持つ単一のカスタムVPCを作成します。各サブネットを異なるリージョンに、異なるCIDR範囲で作成します。
正解:D
解説:
When we create subnets in the same VPC with different CIDR ranges, they can communicate automatically within VPC. Resources within a VPC network can communicate with one another by using internal (private) IPv4 addresses, subject to applicable network firewall rules Ref: https://cloud.google.com/vpc/docs/vpc
質問 # 179
Google Cloud環境のセキュリティチェックを毎月実行していて、Google CloudProjectに保存されているデータを表示するためのアクセス権を誰が持っているかを知りたいと考えています。あなたは何をすべきですか?
- A. 各リソースのID対応プロキシ設定を確認します。
- B. データ損失防止ジョブを作成します。
- C. データアクセスを許可するすべてのロールのIAM権限を確認します。
- D. データストレージに関連するすべてのAPIの監査ログを有効にします。
正解:C
解説:
Only use audit logs to look at history (PAST)
If you need current, up-to-date, info regarding permissions always go to IAM.
質問 # 180
アプリケーションを Google Kubernetes Engine(GKE)にデプロイしています。アプリケーションは、プライベート Cloud Storage バケットへの API 呼び出しを行う必要があります。Cloud Storage API に対して認証するようにアプリケーション Pod を構成する必要がありますが、組織のポリシーによりサービス アカウント キーの使用が禁止されています。Google が推奨するプラクティスに従う必要があります。どうすればよいでしょうか。
- A. Workload Identity Federation を使用して GKE クラスタを作成します。Google サービス アカウントと Kubernetes ServiceAccount を作成し、両方のサービス アカウントが Workload Identity Federation を使用するように設定します。Kubernetes ServiceAccount をアプリケーション ポッドに接続し、Identity and Access Management(IAM)を使用してバケットにアクセスできるよう Google サービス アカウントを設定します。
- B. Workload Identity Federation を使用して GKE クラスタを作成します。バケットにアクセスするためのデフォルトのノードサービスアカウントを設定します。アプリケーションをクラスタにデプロイし、ノードサービスアカウントの権限をアプリケーションが使用できるようにします。Identity and Access Management (IAM) を使用して、サービスアカウントにバケットへのアクセスを許可します。
- C. GKE クラスタを作成し、アプリケーションをデプロイします。セキュリティ例外をリクエストして、Google サービス アカウント キーを作成します。constraints/iam.serviceAccountKeyExpiryHours 組織ポリシーを 8 時間に設定します。
- D. GKE クラスタを作成し、アプリケーションをデプロイします。セキュリティ例外をリクエストして、Google サービス アカウント キーを作成します。constraints/iam.serviceAccountKeyExpiryHours 組織ポリシーを 24 時間に設定します。
正解:A
解説:
The organization policy explicitly prevents the use of service account keys, so options A and B, which involve requesting exceptions to create them, are not in line with the policy and Google's recommended practices for secure authentication.
質問 # 181
ウェブ アプリケーションは Cloud Run for Anthos で正常に実行されています。特定のパーセンテージの実稼働ユーザー (カナリア デプロイ) を使用して、アプリケーションの更新バージョンを評価する必要があります。あなたは何をするべきか?
- A. 新しいバージョンのアプリケーションで新しいサービスを作成します。このバージョンと現在実行中のバージョンの間でトラフィックを分割します。
- B. アプリケーションの新しいバージョンで新しいリビジョンを作成します。両方のリビジョンの前に HTTP ロード バランサーを追加します。
- C. 新しいバージョンのアプリケーションで新しいサービスを作成します。両方のサービスの前に HTTP ロード バランサーを追加します。
- D. アプリケーションの新しいバージョンで新しいリビジョンを作成します。このバージョンと現在実行中のバージョンの間でトラフィックを分割します。
正解:D
解説:
https://cloud.google.com/kuberun/docs/rollouts-rollbacks-traffic-migration
質問 # 182
まだ存在しない新しいプロジェクトにComputeEngineインスタンスを作成する必要があります。あなたは何をするべきか?
- A. Cloud SDKを使用して、新しいプロジェクトを作成し、そのプロジェクトでCompute Engine APIを有効にしてから、新しいプロジェクトを指定するインスタンスを作成します。
- B. Cloud SDKを使用して新しいインスタンスを作成し、-pprojectフラグを使用して新しいプロジェクトを指定します。
Cloud SDKからComputeEngine APIを有効にするように求められたら、「はい」と答えます。 - C. CloudConsoleでComputeEngine APIを有効にし、Cloud SDKを使用してインスタンスを作成してから、-pprojectフラグを使用して新しいプロジェクトを指定します。
- D. クラウドコンソールでCompute EngineAPIを有効にします。コンソールのComputeEngineセクションに移動して新しいインスタンスを作成し、作成フォームで[Create In A NewProject]オプションを探します。
正解:A
解説:
Before you begin:
1. In the Cloud Console, on the project selector page, select or create a Cloud project.
2. Make sure that billing is enabled for your Google Cloud project. Learn how to confirm billing is enabled for your project.
To use the gcloud command-line tool for this quickstart, you must first install and initialize the Cloud SDK:
1. Download and install the Cloud SDK using the instructions given on Installing Google Cloud SDK.
2. Initialize the SDK using the instructions given on Initializing Cloud SDK.
To use gcloud in Cloud Shell for this quickstart, first activate Cloud Shell using the instructions given on Starting Cloud Shell.
https://cloud.google.com/ai-platform/deep-learning-vm/docs/quickstart-cli#before-you-begin
質問 # 183
Cloud Spannerをバックエンドデータベースとして使用するアプリケーションがあります。アプリケーションには非常に予測可能なトラフィックパターンがあります。トラフィックに応じて、Spannerノードの数を自動的に拡大または縮小したいとします。あなたは何をするべきか?
- A. 定期的に実行されるcronジョブを作成して、Stackdriverモニタリング指標を確認し、それに応じてSpannerインスタンスのサイズを変更します。
- B. Cloud Spanner CPUがしきい値を超えたときにoncall SREメールにアラートを送信するStackdriverアラートポリシーを作成します。 SREはそれに応じてリソースを拡大または縮小します。
- C. Cloud Spanner CPUがしきい値を超えたとき、またはしきい値を下回ったときにアラートをwebhookに送信するStackdriverアラートポリシーを作成します。 HTTPをリッスンし、それに応じてSpannerリソースのサイズを変更するCloud Functionを作成します。
- D. Cloud Spanner CPUがしきい値を超えたときにGoogle Cloudサポートのメールにアラートを送信するStackdriverアラートポリシーを作成します。 Googleサポートはそれに応じてリソースを拡大または縮小します。
正解:C
質問 # 184
あなたは Google Cloud 組織管理者です。会社のセキュリティ ポリシーに準拠するために、プロジェクト ユーザーが削除できない Google Cloud プロジェクト上の組織ポリシーとログシンクを構成する必要があります。セキュリティ ポリシーは会社の部門ごとに異なります。会社の各部門には、プロジェクトに割り当てられたプロジェクト オーナーの役割を持つユーザーがいます。どうすればよいでしょうか。
- A. プロジェクトには、部門名を含む標準の命名規則を使用します。組織に組織ポリシーを構成し、プロジェクトにログシンクを構成します。
- B. プロジェクトには、部門名を含む標準の命名規則を使用します。プロジェクトで組織ポリシーとログシンクの両方を構成します。
- C. 各部門のフォルダーの下にプロジェクトを整理します。組織に組織ポリシーを構成し、フォルダーにログシンクを構成します。
- D. 各部門のフォルダの下にプロジェクトを整理します。フォルダに組織ポリシーとログシンクの両方を構成します。
正解:A
質問 # 185
ComputeEngineインスタンスで実行されるサードパーティアプリケーションを管理する必要があります。他のComputeEngineインスタンスは、デフォルト設定ですでに実行されています。アプリケーションインストールファイルはCloudStorageでホストされます。他の仮想マシン(VM)がこれらのファイルにアクセスすることを許可せずに、新しいインスタンスからこれらのファイルにアクセスする必要があります。あなたは何をするべきか?
- A. 新しいサービスアカウントを作成し、このサービスアカウントを新しいインスタンスに割り当てます。新しいインスタンスのメタデータと一致するメタデータをCloudStorageのオブジェクトに追加します。
- B. 新しいサービスアカウントを作成し、このサービスアカウントを新しいインスタンスに割り当てます。クラウドストレージでのサービスアカウントのアクセス許可を付与します。
- C. デフォルトのComputeEngineサービスアカウントを使用してインスタンスを作成します。CloudStorageに対するサービスアカウントのアクセス許可を付与します。
- D. デフォルトのComputeEngineサービスアカウントでインスタンスを作成します。新しいインスタンスのメタデータと一致するメタデータをCloudStorageのオブジェクトに追加します。
正解:B
解説:
If an application uses third-party or custom identities and needs to access a resource, such as a BigQuery dataset or a Cloud Storage bucket, it must perform a transition between principals.
Because Google Cloud APIs don't recognize third-party or custom identities, the application can't propagate the end-user's identity to BigQuery or Cloud Storage. Instead, the application has to perform the access by using a different Google identity.
https://cloud.google.com/iam/docs/best-practices-for-using-and-managing-service-accounts
質問 # 186
あなたはあなたの会社の組織および課金管理者です。エンジニアリングチームには、組織に対するプロジェクト作成者の役割があります。エンジニアリングチームがプロジェクトを請求先アカウントにリンクできるようにしたくない。プロジェクトを請求先アカウントにリンクできるのは財務チームだけですが、プロジェクトに他の変更を加えることはできません。あなたは何をするべきか?
- A. エンジニアリングチームに請求先アカウントの請求先アカウントユーザーの役割と組織のプロジェクト請求管理者の役割を割り当てます。
- B. 財務チームに請求先アカウントの請求先アカウントユーザーの役割と組織のプロジェクト請求管理者の役割を割り当てます。
- C. 財務チームに請求先アカウントの請求先アカウントユーザーの役割のみを割り当てます。
- D. エンジニアリングチームには、請求先アカウントの請求先アカウントユーザーの役割のみを割り当てます。
正解:C
解説:
Since both the Billing Account User & Project Billing Manager can link a project to a billing account but clearly states the Project Billing Manager will not have access to resources.
Option A is correct, as we don't want the engineering team to link projects to billing account and want only the Finance team. Billing Account User role will help to link projects to the billing account.
https://cloud.google.com/billing/docs/how-to/billing-accessroles/billing.user = Link projects to billing accounts
質問 # 187
Compute Engine を使用してウェブ アプリケーションをデプロイしています。アプリケーションをホストするためのマネージド インスタンス グループ (MIG) を作成しました。あなたは、Google が推奨するプラクティスに従って、安全で可用性の高いソリューションを実装したいと考えています。あなたは何をするべきか?
- A. MIG の HTTP(S) ロード バランシングと、ロード バランサーの IP アドレスを持つ DNS パブリック ゾーンの A レコードを使用します。
- B. MIG の HTTP(S) ロード バランシングと、ロード バランサーの IP アドレスを持つ DNS プライベート ゾーンの CNAME レコードを使用します。
- C. MIG の SSL プロキシ ロード バランシングと、ロード バランサーの IP アドレスを持つ DNS プライベート ゾーンの A レコードを使用します。
- D. MIG の SSL プロキシ ロード バランシングと、ロード バランサーの IP アドレスを持つ DNS パブリック ゾーンの CNAME レコードを使用します。
正解:A
解説:
HTTP(S) load balancing is a Google-recommended practice for distributing web traffic across multiple regions and zones, and providing high availability, scalability, and security for web applications. It supports both IPv4 and IPv6 addresses, and can handle SSL/TLS termination and encryption. It also integrates with Cloud CDN, Cloud Armor, and Cloud Identity-Aware Proxy for enhanced performance and protection. A MIG can be used as a backend service for HTTP(S) load balancing, and can automatically scale and heal the VM instances that host the web application.
To configure DNS for HTTP(S) load balancing, you need to create an A record in your DNS public zone with the load balancer's IP address. This will map your domain name to the load balancer's IP address, and allow users to access your web application using the domain name. A CNAME record is not recommended, as it can cause latency and DNS resolution issues. A private zone is not suitable, as it is only visible within your VPC network, and not to the public internet.
:
HTTP(S) Load Balancing documentation
Setting up DNS records for HTTP(S) load balancing
Choosing a load balancer
質問 # 188
Kubernetes マニフェストを使用して、コンテナ化された新しいアプリケーションを Google Cloud にデプロイしたいと考えています。Kubernetes のデプロイを完全に制御し、同時にインフラストラクチャの構成を最小限に抑えたいと考えています。どうすればよいでしょうか。
- A. Cloud Run にアプリケーションをデプロイします。
- B. GKE Standard にアプリケーションをデプロイします。
- C. アプリケーションを Cloud Functions にデプロイします。
- D. GKE Autopilot にアプリケーションをデプロイします。
正解:D
質問 # 189
事業買収によるアプリケーショントラフィックの予想される増加を促進するために、カスタムCompute Engine仮想マシン(VM)のコピーを作成する必要があります。あなたは何をするべきか?
- A. スナップショットからカスタムComputeEngineイメージを作成します。
そのイメージからインスタンスを作成します。 - B. ベースVMのComputeEngineスナップショットを作成します。
そのスナップショットから画像を作成します。 - C. スナップショットからカスタムComputeEngineイメージを作成します。
その画像から画像を作成します。 - D. ベースVMのComputeEngineスナップショットを作成します。
そのスナップショットからインスタンスを作成します。
正解:A
解説:
A custom image belongs only to your project. To create an instance with a custom image, you must first have a custom image.
Reference: https://cloud.google.com/compute/docs/instances/create-start-instance Preparing your instance for an image You can create an image from a disk even while it is attached to a running VM instance. However, your image will be more reliable if you put the instance in a state that is easier for the image to capture. Use one of the following processes to prepare your boot disk for the image:
Stop the instance so that it can shut down and stop writing any data to the persistent disk.
If you can't stop your instance before you create the image, minimize the amount of writes to the disk and sync your file system.
Pause apps or operating system processes that write data to that persistent disk.
Run an app flush to disk if necessary. For example, MySQL has a FLUSH statement. Other apps might have similar processes.
Stop your apps from writing to your persistent disk.
Run sudo sync.
After you prepare the instance, create the image.
https://cloud.google.com/compute/docs/images/create-delete-deprecate-private- images#prepare_instance_for_image
質問 # 190
複数のGoogle Cloud Platform(GCP)プロジェクトを管理しており、過去60日間のすべてのログへのアクセスが必要です。ログの内容を探索して迅速に分析できるようにしたい。すべてのプロジェクトの結合されたログを取得するために、Googleが推奨するプラクティスに従ってください。あなたは何をするべきか?
- A. Stackdriver Loggingに移動し、resource.labels.project_id = "*"を選択します
- B. BigQueryデータセットへのシンクの宛先を含むStackdriver Loggingエクスポートを作成します。テーブルの有効期限を60日に設定します。
- C. Cloud Storageへのシンク宛先を含むStackdriver Loggingエクスポートを作成します。 60日後にオブジェクトを削除するライフサイクルルールを作成します。
- D. Stackdriverから読み取ってBigQueryにログを保存するようにCloud Schedulerジョブを構成します。テーブルの有効期限を60日に設定します。
正解:B
解説:
Navigate to Stackdriver Logging and select resource.labels.project_id=*. is not right.
Log entries are held in Stackdriver Logging for a limited time known as the retention period which is 30 days (default configuration). After that, the entries are deleted. To keep log entries longer, you need to export them outside of Stackdriver Logging by configuring log sinks.
Ref: https://cloud.google.com/blog/products/gcp/best-practices-for-working-with-google-cloud-audit-logging Configure a Cloud Scheduler job to read from Stackdriver and store the logs in BigQuery. Configure the table expiration to 60 days. is not right.
While this works, it makes no sense to use Cloud Scheduler job to read from Stackdriver and store the logs in BigQuery when Google provides a feature (export sinks) that does exactly the same thing and works out of the box.
Ref: https://cloud.google.com/logging/docs/export/configure_export_v2
Create a Stackdriver Logging Export with a Sink destination to Cloud Storage. Create a lifecycle rule to delete objects after 60 days. is not right.
You can export logs by creating one or more sinks that include a logs query and an export destination.
Supported destinations for exported log entries are Cloud Storage, BigQuery, and Pub/Sub.
Ref: https://cloud.google.com/logging/docs/export/configure_export_v2
Sinks are limited to exporting log entries from the exact resource in which the sink was created: a Google Cloud project, organization, folder, or billing account. If it makes it easier to exporting from all projects of an organication, you can create an aggregated sink that can export log entries from all the projects, folders, and billing accounts of a Google Cloud organization.
Ref: https://cloud.google.com/logging/docs/export/aggregated_sinks
Either way, we now have the data in Cloud Storage, but querying logs information from Cloud Storage is harder than Querying information from BigQuery dataset. For this reason, we should prefer Big Query over Cloud Storage.
Create a Stackdriver Logging Export with a Sink destination to a BigQuery dataset. Configure the table expiration to 60 days. is the right answer.
You can export logs by creating one or more sinks that include a logs query and an export destination.
Supported destinations for exported log entries are Cloud Storage, BigQuery, and Pub/Sub.
Ref: https://cloud.google.com/logging/docs/export/configure_export_v2
Sinks are limited to exporting log entries from the exact resource in which the sink was created: a Google Cloud project, organization, folder, or billing account. If it makes it easier to exporting from all projects of an organication, you can create an aggregated sink that can export log entries from all the projects, folders, and billing accounts of a Google Cloud organization.
Ref: https://cloud.google.com/logging/docs/export/aggregated_sinks
Either way, we now have the data in a BigQuery Dataset. Querying information from a Big Query dataset is easier and quicker than analyzing contents in Cloud Storage bucket. As our requirement is to Quickly analyze the log contents, we should prefer Big Query over Cloud Storage.
Also, You can control storage costs and optimize storage usage by setting the default table expiration for newly created tables in a dataset. If you set the property when the dataset is created, any table created in the dataset is deleted after the expiration period. If you set the property after the dataset is created, only new tables are deleted after the expiration period.
For example, if you set the default table expiration to 7 days, older data is automatically deleted after 1 week.
Ref: https://cloud.google.com/bigquery/docs/best-practices-storage
Reference: https://cloud.google.com/blog/products/gcp/best-practices-for-working-with-google-cloud-audit- logging
質問 # 191
複数のGCP製品を使用するソリューションをGoogle Cloud Platform(GCP)で設計しました。ソリューションのコストを見積もるように会社から要求されました。あなたは毎月の総費用の見積もりを提供する必要があります。あなたは何をするべきか?
- A. GCPでソリューションをプロビジョニングします。ソリューションを1週間プロビジョニングしたままにします。 Google Cloud Platform Consoleの[請求レポート]ページに移動します。 1週間のコストを掛けて、毎月のコストを決定します。
- B. ソリューションの各GCPプロダクトについて、プロダクトの料金ページで料金の詳細を確認します。各製品の予想月額費用をまとめたGoogleシートを作成します。
- C. GCPでソリューションをプロビジョニングします。ソリューションを1週間プロビジョニングしたままにします。 Stackdriverを使用して、プロビジョニングされたリソースと使用されたリソースの量を確認します。 1週間のコストを掛けて、毎月のコストを決定します。
- D. ソリューションの各GCPプロダクトについて、プロダクトの料金ページで料金の詳細を確認します。料金計算ツールを使用して、各GCPプロダクトの月額コストを合計します。
正解:A
質問 # 192
平日の午前9時から午後6時まで使用されるアプリケーションをホストするCompute Engineインスタンスがあります。災害復旧のために、このインスタンスを毎日バックアップしたいとします。バックアップを30日間保持する必要があります。
最小限の管理オーバーヘッドと最小限のサービスでGoogleが推奨するソリューションが必要です。あなたは何をするべきか?
- A. 1.インスタンスのディスクのスナップショットを作成するCloud Functionを作成します。
2. 30日以上経過したスナップショットを削除するCloud Functionを作成します。
3. Cloud Schedulerを使用して、両方のCloud Functionsを毎日午前1時にトリガーします。 - B. 1.クラウドコンソールで、[Compute Engineディスク]ページに移動し、インスタンスのディスクを選択します。
2. [スナップショットスケジュール]セクションで、[スケジュールの作成]を選択し、次のパラメーターを構成します。
-スケジュールの頻度:毎日
-開始時間:1:00 AM-2:00 AM
-30日後にスナップショットを自動削除 - C. 1.ディスクのコンテンツをCloud Storageにコピーするインスタンスでbashスクリプトを作成します。
2.インスタンスでbashスクリプトを作成し、バックアップCloud Storageバケット内の30日より古いデータを削除します。
3.これらのスクリプトを毎日午前1時に実行するようにインスタンスのcrontabを構成します。 - D. 1.インスタンスのメタデータを更新して、次の値を追加します:snapshot-schedule:0 1 * * *
2.インスタンスのメタデータを更新して、次の値を追加します:snapshot-retention:30
正解:B
解説:
Creating scheduled snapshots for persistent disk This document describes how to create a snapshot schedule to regularly and automatically back up your zonal and regional persistent disks. Use snapshot schedules as a best practice to back up your Compute Engine workloads. After creating a snapshot schedule, you can apply it to one or more persistent disks. https://cloud.google.com/compute/docs/disks/scheduled-snapshots
質問 # 193
......
合格させるGoogle Associate-Cloud-Engineer日本語試験最速合格にはGoShiken:https://www.goshiken.com/Google/Associate-Cloud-Engineer-JPN-mondaishu.html