PDF問題(2025年最新)実際のGoogle Professional-Cloud-Network-Engineer日本語試験問題 [Q50-Q68]

Share

PDF問題(2025年最新)実際のGoogle Professional-Cloud-Network-Engineer日本語試験問題

問題集返金保証付きのProfessional-Cloud-Network-Engineer日本語問題集には90%オフされます

質問 # 50
組織には、複数の Virtual Private Cloud (VPC) を含む 1 つのプロジェクトがあります。企業のパブリック ネットワーク内のリソースからのみ API アクセスを許可することで、Cloud Storage バケットと BigQuery データセットへの API アクセスを保護する必要があります。あなたは何をするべきか?

  • A. 企業のパブリック ネットワークの IP 範囲を許可するアクセス コンテキスト ポリシーを使用して、プロジェクトの VPC Service Controls 境界を作成します。
  • B. ファイアウォール ルールを作成して、未承認のネットワークから Cloud Storage と BigQuery への API アクセスをブロックします。
  • C. VPC と企業のパブリック ネットワークの IP 範囲を許可するアクセス コンテキスト ポリシーを作成し、そのポリシーを Cloud Storage と BigQuery にアタッチします。
  • D. 企業のパブリック ネットワークの IP 範囲を許可するアクセス コンテキスト ポリシーを使用して、VPC ごとに VPC Service Controls 境界を作成します。

正解:A


質問 # 51
標準の 3 層 (Web、アプリケーション、データベース) アプリケーションの負荷分散を構成しています。Web サーバー用に外部 HTTP(S) ロード バランサを構成しました。サーバーのアプリケーション層の負荷分散を構成する必要があります。あなたは何をするべきか?

  • A. トラフィックをアプリケーション層にルーティングするために、既存のロード バランサー上で URL マップを構成します。
  • B. アプリケーション サーバー上で等コスト マルチパス ルーティングを構成します。
  • C. アプリケーション層の既存のロード バランサーに転送ルールを構成します。
  • D. アプリケーション層の新しい内部 HTTP(S) ロード バランサを構成します。

正解:C


質問 # 52
Google Cloud 内に HA VPN をデプロイしています。オンプレミス ゲートウェイと Google Cloud の間でルートを動的に交換する必要があります。HA VPN ゲートウェイとピア VPN ゲートウェイ リソースはすでに作成されています。何をすればよいでしょうか。

  • A. Cloud Router を作成し、VPN トンネルを追加して、グローバル動的ルーティングを有効にします。
  • B. Cloud Router を作成し、VPN トンネルを追加して、サブネット範囲への静的ルートを構成します。
  • C. 2 番目の HA VPN ゲートウェイを作成し、VPN トンネルを追加して、グローバル動的ルーティングを有効にします。
  • D. Cloud Router を作成し、VPN トンネルを追加して、BGP セッションを構成します。

正解:D

解説:
Explanation: To dynamically exchange routes between Google Cloud and your on-premises gateway, you need to create a Cloud Router and configure BGP sessions after adding VPN tunnels. BGP allows for dynamic route exchange, which is essential for establishing proper communication between the environments.
Google Cloud HA VPN with BGP


質問 # 53
図に示されているネットワーク構成があります。2 つの Dended Interconnect 接続に関連付けられた 2 つの VLAN アタッチメントは、同じ Cloud Router (mycloudrouter) 上で終端します。相互接続接続は 2 つの別個のオンプレミス ルーターで終了します。各 VLAN アタッチメントに関連付けられたボーダー ゲートウェイ プロトコル (BOP) セッションから同じプレフィックスをアドバタイズします。
2 つのインターコネクト接続間で非対称のトラフィック フローが発生していることがわかります。非対称トラフィック フローのトラブルシューティングを行うには、次のどのアクションを実行する必要がありますか?

  • A. Google Cloud コンソールから Cloud Logging に移動して VPC フロー ログを表示し、結果を確認します。
  • B. Google Cloud コンソールからハイブリッド接続に移動し、Cloud Router を選択し、BGP セッションを表示します。
  • C. Cloud CLI から gcloud compute -protect_ID router get-status mycloudrouter --region REGION を実行し、結果を確認します。
  • D. クラウド CLI から。gcloud compute router を実行して mycloudrouter を説明します

正解:C

解説:
--region REGION and review the results
Explanation:
The correct answer is B. From the Cloud CLI, run gcloud compute --project_ID router get-status mycloudrouter --region REGION and review the results.
This command will show you the BGP session status, the advertised and learned routes, and the last error for each VLAN attachment. You can use this information to troubleshoot the asymmetric traffic flow and identify any issues with the BGP configuration or the Interconnect connections.
The other options are not correct because:
Option A will only show you the BGP session status, but not the advertised and learned routes or the last error for each VLAN attachment.
Option C will only show you the VPC Flow Logs, which are useful for monitoring and troubleshooting network performance and security issues within your VPC network, but not for your Interconnect connections.
Option D will only show you the basic information about the Cloud Router, such as its name, region, network, and BGP settings, but not the detailed status of each VLAN attachment.


質問 # 54
組織では最近、Network Connectivity Center を使用するためにクラウド環境を再設計しました。しかし、vpc-dev という新しい VPC をスポークとして追加しようとしたときにエラーが発生しました。エラーは、既存のスポークと vpc-pre-prod という VPC の IP 空間に問題があることを示しています。移行を迅速かつ効率的に完了する必要があります。どうすればよいでしょうか。

  • A. vpc-dev の VPC スポークを接続するときに、ハブで --exclude-export-ranges フラグを使用して競合する IP 範囲を除外します。
  • B. 競合するサブネットに関連付けられている VM を削除し、vpc-dev 内の競合するサブネットを削除します。新しい IP 範囲でサブネットを再作成し、以前に削除した VM を新しいサブネットに再デプロイします。vpc-dev の VPC スポークを追加します。
  • C. vpc-dev の VPC スポークを作成するときに、--exclude-export-ranges フラグを使用して競合する IP 範囲を除外します。
  • D. Network Connectivity Center の VPC スポークのセットから、競合している vpc-pre-prod の VPC スポークを削除します。vpc-dev の VPC スポークを追加します。以前削除した vpc-pre-prod を VPC スポークとして追加します。

正解:D

解説:
Explanation: The most efficient way to resolve the conflict is to temporarily remove the conflicting vpc-pre- prod spoke, add the vpc-dev spoke, and then re-add vpc-pre-prod. This ensures that the migration happens quickly without the need to change IP ranges or delete resources.
: Google Network Connectivity Center Documentation


質問 # 55
質問:
組織には VPC ネットワーク ピアリングを使用したハブ アンド スポーク アーキテクチャがあり、ハイブリッド接続はハブで集中管理されています。ハブ VPC の Cloud Router はサブネット ルートをアドバタイズしていますが、オンプレミス ルーターは VPC スポークからサブネット ルートを受信して​​いないようです。この問題を解決する必要があります。
何をすべきでしょうか?

  • A. ハブの Cloud Router でカスタムルートを作成し、VPC スポークのサブネットをアドバタイズします。
  • B. Cloud Router で BGP ルートポリシーを作成し、VPC スポークのサブネットがオンプレミス環境に向けて通知されていることを確認します。
  • C. ハブの Cloud Router でカスタム学習ルートを作成し、VPC スポークのサブネットをアドバタイズします。
  • D. スポークの Cloud Router でカスタムルートを作成し、VPC スポークのサブネットをアドバタイズします。

正解:C

解説:
Creating custom learned routes at the hub's Cloud Router is required for advertising VPC spokes' subnets to the on-premises environment. This centralizes route configuration and ensures that all spoke subnet routes are propagated to the hybrid network.


質問 # 56
あなたは、組織の Google Cloud 環境で Cloud Router の新しいインスタンスを構成し、新しい Dended Interconnect を介してデータセンターに接続できるようにしています。営業、マーケティング、IT のそれぞれが、組織のホスト プロジェクトに接続されているサービス プロジェクトを持っています。
Cloud Router インスタンスはどこに作成する必要がありますか?

  • A. セールス、マーケティング、IT プロジェクトの VPC ネットワーク
  • B. ホスト プロジェクトの VPC ネットワーク
  • C. IT プロジェクトの VPC ネットワーク
  • D. すべてのプロジェクトの VPC ネットワーク

正解:B

解説:
Reference: https://cloud.google.com/interconnect/docs/how-to/dedicated/using-interconnects-other-projects


質問 # 57
us-east1 および us-west1 リージョンに高可用性ウェブ アプリケーションをデプロイするには、ネットワーク インフラストラクチャを作成する必要があります。アプリケーションは Compute Engine インスタンス上で実行され、データベースを使用する必要はありません。Google が推奨するプラクティスに従う必要があります。どうすればよいでしょうか。

  • A. 各リージョンに 1 つのサブネットを持つ 1 つの VPC を作成します。
    静的 IP アドレスを持つ HTTP(S) ロード バランサを作成します。
    ネットワークの標準層を選択します。
    ロードバランサで Cloud CDN を有効にします。
    Cloud DNS でロードバランサの IP アドレスを使用して CNAME レコードを作成します。
  • B. 各リージョンに 1 つの VPC を作成し、両方の VPC をピアリングします。
    グローバル ロード バランサーを作成します。
    ロードバランサで Cloud CDN を有効にします。
    Cloud DNS でロードバランサの CNAME を作成します。
  • C. 各リージョンに 1 つのサブネットを持つ 1 つの VPC を作成します。
    静的 IP アドレスを持つグローバル ロード バランサーを作成します。
    ロードバランサで Cloud CDN と Google Cloud Armor を有効にします。
    Cloud DNS でロードバランサの IP アドレスを使用して A レコードを作成します。
  • D. 各リージョンに 1 つのサブネットを持つ 1 つの VPC を作成します。
    静的 IP アドレスを使用して、各リージョンにリージョン ネットワーク ロード バランサーを作成します。
    ロードバランサーで Cloud CDN を有効にします。
    ロードバランサの両方の IP アドレスを使用して、Cloud DNS に A レコードを作成します。

正解:B


質問 # 58
最近、ネットワーク チームは、外部アプリケーション ロード バランサを通じて公開される外部向けサービスの 1 つに対して Cloud CDN を有効にしました。アプリケーション チームは、レスポンス内でどのコンテンツをキャッシュするかをすでに定義しています。ロード バランサをテストしたところ、Cloud CDN を有効にした後のパフォーマンスの変化は確認されませんでした。この問題を解決する必要があります。何をすべきでしょうか。

  • A. Cloud CDN で FORCE_CACHE_ALL キャッシュ モードを構成して、適切なコンテンツがすべてキャッシュされるようにします。
  • B. Cloud CDN で CACHE_ALL_STATIC キャッシュ モードを構成して、Cloud CDN がすべての静的コンテンツとバックエンドによって定義されたコンテンツをキャッシュするようにします。
  • C. Cloud CDN で USE_ORIGIN_HEADERS キャッシュ モードを構成して、Cloud CDN がバックエンドからのレスポンス ヘッダーに基づいてコンテンツをキャッシュするようにします。
  • D. Cloud CDN で CACHE_MAX_STATIC キャッシュ モードを構成して、バックエンドからの応答に応じて Cloud CDN がコンテンツをキャッシュするようにします。

正解:C

解説:
When enabling Cloud CDN, for caching behavior to follow the application-defined caching headers, you need to configure the USE_ORIGIN_HEADERS caching mode. This setting ensures that the Cloud CDN respects the cache control headers specified by the backend, allowing the application-defined caching rules to dictate what content gets cached. This is often required when specific caching directives are already set by the application.


質問 # 59
あなたは、組織のオンプレミス データセンターと Google Cloud Virtual Private Cloud (VPC) ネットワーク間の新しい接続ソリューションを設計する責任を負います。現在、エンドツーエンドの接続はありません。99.99% の可用性のサービス レベル アグリーメント (SLA) を保証する必要があります。

  • A. 1 つの大都市圏で 2 つの Dended Interconnect 接続を使用します。1 つの Cloud Router を構成し、VPC でグローバル ルーティングを有効にします。
  • B. 1 つの大都市圏で 1 つの Dended Interconnect 接続を使用します。1 つの Cloud Router を構成し、VPC でグローバル ルーティングを有効にします。
  • C. オンプレミス データセンターと Google Cloud の間でダイレクト ピアリング接続を使用します。2 つのトンネルと 1 つの Cloud Router を使用して Classic VPN を構成します。
  • D. HA VPN を使用します。オンプレミスのピア ゲートウェイ上の対応するインターフェイスに接続するために、VPN ゲートウェイの各インターフェイスから 1 つのトンネルを構成します。1 つの Cloud Router を構成し、VPC でグローバル ルーティングを有効にします。

正解:D

解説:
For Dedicated Interconnects: At least four Dedicated Interconnect connections, two connections in one metropolitan area (metro) and two connections in another metro. Connections that are in the same metro must be placed in different edge availability domains (metro availability zones) to achieve 99.99% availability.
For HA VPN:
HA VPN to peer VPN gateways Connect an HA VPN gateway to one or two separate peer VPN devices 99.99% HA VPN between two Google Cloud networks Connect two Google Cloud VPC networks in a single region by using an HA VPN gateway in each network 99.99%


質問 # 60
あなたの組織は、ホスト プロジェクトと 3 つのサービス プロジェクトを持つ共有 VPC アーキテクチャを使用しています。サービス プロジェクト内に Compute Engine インスタンスが存在します。オンプレミスのデータセンターには重要なワークロードがあります。ハイブリッド接続を確立するためにデプロイした D dedicated Interconnect を介して、Google Cloud インスタンスがオンプレミスのホスト名を解決できることを確認する必要があります。あなたは何をするべきか?

  • A. プライベート ゾーンをオンプレミス DNS サーバーに転送する、共有 VPC のホスト プロジェクトに Cloud DNS プライベート転送ゾーンを作成します。
    Cloud Router で、IP 169.254 169.254 のカスタム ルート アドバタイズメントをオンプレミス環境に追加します。
  • B. プライベート ゾーンをオンプレミス DNS サーバーに転送する、共有 VPC のホスト プロジェクトに Cloud DNS プライベート転送ゾーンを作成します。
    Cloud Router で、IP 35.199.192.0/19 のカスタム ルート アドバタイズメントをオンプレミス環境に追加します。
  • C. 共有 VPC のホスト プロジェクトで Cloud DNS プライベート ゾーンを構成します。
    オンプレミス DNS サーバー上の Google Cloud プライベート ゾーンへの DNS 転送を設定し、ホスト プロジェクトの受信フォワーダー IP アドレスを指すようにします。
    共有 VPC で DNS ポリシーを構成し、オンプレミスの DNS サーバーを代替 DNS サーバーとして使用した受信クエリの転送を許可します。
  • D. 共有 VPC のホスト プロジェクトで Cloud DNS プライベート ゾーンを構成します。
    オンプレミス DNS サーバー上の Google Cloud プライベート ゾーンへの DNS 転送を設定し、ホスト プロジェクトの受信フォワーダー IP アドレスを指すようにします。 Cloud Router で、IP 169.254 169 254 のカスタム ルート アドバタイズメントをオンプレミスに追加します。環境。

正解:C


質問 # 61
あなたの会社はパートナーと協力して顧客にソリューションを提供しています。あなたの会社とパートナー組織は両方とも GCP を使用しています。パートナーのネットワークには、会社の VPC 内の一部のリソースにアクセスする必要があるアプリケーションがあります。VPC 間に CIDR の重複はありません。
セキュリティを損なうことなく望ましい結果を達成するには、どの 2 つのソリューションを実装できますか? (2つお選びください。)

  • A. クラウド NAT
  • B. 専用インターコネクト
  • C. クラウドVPN
  • D. 共有 VPC
  • E. VPC ピアリング

正解:C、E

解説:
Google Cloud VPC Network Peering allows internal IP address connectivity across two Virtual Private Cloud (VPC) networks regardless of whether they belong to the same project or the same organization.


質問 # 62
質問:
Google Cloud の Cloud Next Generation Firewall (Cloud NGFW) 侵入防止サービスの一部としてファイアウォール エンドポイントを構成しています。脅威防止セキュリティ プロファイルを構成したので、トラフィック検査用のエンドポイントを作成する必要があります。何をすればよいでしょうか。

  • A. リージョン内にファイアウォール エンドポイントを作成し、エンドポイントを VPC ネットワークに関連付け、ファイアウォール ポリシー ルールを使用して L7 検査を適用します。
  • B. ゾーン内にファイアウォール エンドポイントを作成し、エンドポイントを VPC ネットワークに関連付け、ファイアウォール ポリシー ルールを使用して L7 検査を適用します。
  • C. ゾーン内に Private Service Connect エンドポイントを作成し、エンドポイントを VPC ネットワークに関連付け、ファイアウォール ポリシー ルールを使用して L7 検査を適用します。
  • D. プロファイルを VPC ネットワークに接続し、ゾーン内にファイアウォール エンドポイントを作成し、ファイアウォール ポリシー ルールを使用して L7 検査を適用します。

正解:A

解説:
For Cloud NGFW in Google Cloud, firewall endpoints are typically created at the regional level, allowing you to associate these with your VPC network for Layer 7 traffic inspection. This regional setup ensures high availability and scales the inspection service across the network.


質問 # 63
(オンプレミスのデータセンターから Google Cloud に複数の PostgreSQL データベースを移行する必要があります。
データ スキーマとアプリケーション コードの変更を最小限に抑えながら、データベースのパフォーマンスを大幅に向上させたいと考えています。地理的な地域ごとに 150 TB を超えるデータが見込まれます。Google が推奨するプラクティスに従い、運用コストを最小限に抑えたいと考えています。どうすればよいですか?

  • A. データを Spanner に移行します。
  • B. データを Firebase に移行します。
  • C. データを Bigtable に移行します。
  • D. データを AlloyDB に移行します。

正解:D

解説:
Comprehensive and Detailed In Depth Explanation:
Let's analyze each option based on the requirements: PostgreSQL compatibility, significant performance improvement, minimal schema/code changes, handling large data volumes, Google-recommended practices, and cost minimization:
A). Migrate your data to AlloyDB: AlloyDB for PostgreSQL is a fully managed, PostgreSQL-compatible database service that offers significant performance improvements over standard PostgreSQL due to its architectural optimizations. It is designed to handle large data volumes and minimizes the need for schema and application code changes as it's wire-compatible with PostgreSQL. This aligns well with the requirements for performance improvement, minimal changes, large data, and being a Google-recommended option for PostgreSQL workloads.
B). Migrate your data to Spanner: Spanner is a globally distributed, horizontally scalable database with strong consistency. While it offers excellent scalability and performance, it's not directly PostgreSQL-compatible.
Migrating to Spanner would likely require significant schema and application code changes due to differences in data modeling and SQL dialect.
C). Migrate your data to Firebase: Firebase is a suite of mobile and web development tools, with its primary database offering being Firestore (a NoSQL document database) and Realtime Database. These are not PostgreSQL-compatible and would require substantial changes to the data model and application code.
D). Migrate your data to Bigtable: Bigtable is a highly scalable NoSQL wide-column store. It's not compatible with PostgreSQL and requires a completely different data model and application logic.
Therefore, AlloyDB is the most suitable option as it provides PostgreSQL compatibility for minimal migration effort, significant performance improvements, scalability for large data volumes, and is a recommended Google Cloud database service for PostgreSQL workloads.
Google Cloud Documentation References:
AlloyDB for PostgreSQL Overview: https://cloud.google.com/alloydb/docs/overview - This document highlights AlloyDB's PostgreSQL compatibility, performance benefits, scalability, and suitability for migrating existing PostgreSQL workloads.
Spanner Overview: https://cloud.google.com/spanner/docs/overview - This emphasizes Spanner's unique features and differences from traditional relational databases like PostgreSQL.
Firebase Documentation: https://firebase.google.com/docs - This outlines the features of Firebase, including Firestore and Realtime Database, highlighting their NoSQL nature and incompatibility with PostgreSQL.
Cloud Bigtable Overview: https://cloud.google.com/bigtable/docs/overview - This describes Bigtable as a NoSQL database, emphasizing its differences from relational databases like PostgreSQL.


質問 # 64
あなたは、新しいプライベート Google Kubernetes Engine (GKE) クラスターの IP アドレス スキームを設計しています。企業内の RFC 1918 アドレス空間の IP アドレスが枯渇したため、新しいダスターにはプライベートに使用されるパブリック IP 空間を使用する予定です。Google が推奨するプラクティスに従いたいと考えていますが、IP スキームを設計した後は何をすべきですか?

  • A. クラスタに使用可能な最小限の RFC 1918 プライマリおよびセカンダリ サブネット IP 範囲を作成します。複数のプライベート GKE クラスタにわたるサービスのセカンダリ アドレス範囲を再利用します。
  • B. クラスター用にプライベートに使用されるパブリック IP のプライマリおよびセカンダリのサブネット範囲を作成します。次のオプションを選択し、 - siable-default-snat、--enable-ip-alias、および -enable-private-nodes を使用して、プライベート GKE クラスタを作成します。
  • C. クラスター用にプライベートに使用されるパブリック IP のプライマリおよびセカンダリのサブネット範囲を作成します。--enab1e-ip-a1ias と --enable-private-nodes のオプションを選択して、プライベート GKE クラスタを作成します。
  • D. クラスターに使用可能な最小限の RFC 1918 プライマリおよびセカンダリ サブネット IP 範囲を作成します。複数のプライベート GKE クラスタにわたってポッドのセカンダリ アドレス範囲を再利用します。

正解:B

解説:
The correct answer is D. Create privately used public IP primary and secondary subnet ranges for the clusters.
Create a private GKE cluster with the following options selected: --disable-default-snat, --enable-ip-alias, and
--enable-private-nodes.
This answer is based on the following facts:
* Privately used public IP (PUPI) addresses are any public IP addresses not owned by Google that a customer can use privately on Google Cloud1. You can use PUPI addresses for GKE pods and services in private clusters to mitigate address exhaustion.
* A private GKE cluster is a cluster that has no public IP addresses on the nodes2. You can use private clusters to isolate your workloads from the public internet and enhance security.
* The --disable-default-snat option disables source network address translation (SNAT) for the cluster3.
This option allows you to use PUPI addresses without conflicting with other public IP addresses on the internet.
* The --enable-ip-alias option enables alias IP ranges for the cluster4. This option allows you to use separate subnet ranges for nodes, pods, and services, and to specify the size of those ranges.
* The --enable-private-nodes option enables private nodes for the cluster5. This option ensures that the nodes have no public IP addresses and can only communicate with other Google Cloud resources in the same VPC network or peered networks.
The other options are not correct because:
* Option A is not suitable. Creating RFC 1918 primary and secondary subnet IP ranges for the clusters does not solve the problem of address exhaustion. Re-using the secondary address range for pods across multiple private GKE clusters can cause IP conflicts and routing issues.
* Option B is also not suitable. Creating RFC 1918 primary and secondary subnet IP ranges for the clusters does not solve the problem of address exhaustion. Re-using the secondary address range for services across multiple private GKE clusters can cause IP conflicts and routing issues.
* Option C is not feasible. Creating privately used public IP primary and secondary subnet ranges for the clusters is a valid step, but creating a private GKE cluster with only --enable-ip-alias and --enable- private-nodes options is not enough. You also need to disable default SNAT to avoid IP conflicts with other public IP addresses on the internet.


質問 # 65
あなたは共有 VPC アーキテクチャを設計しています。ネットワークおよびセキュリティ チームは、部門間でどのルートが公開されるかを厳密に制御しています。制作部門とステージング部門は相互に通信できますが、特定のネットワーク経由でのみ通信できます。Google が推奨する慣行に従いたいと考えています。
このトポロジをどのように設計すればよいでしょうか?

  • A. 共有 VPC ホスト プロジェクト内に 1 つの VPC を作成し、個々のサブネットをサービス プロジェクトと共有して、特定のネットワーク間のアクセスをフィルターします。
  • B. 共有 VPC ホスト プロジェクト内に 2 つの共有 VPC を作成し、それらの間にクラウド VPN/クラウド ルーターを作成します。フレキシブル ルート アドバタイズメント (FRA) を使用して、特定のネットワーク間のアクセスをフィルタリングします。
  • C. 共有 VPC サービス プロジェクト内に 2 つの共有 VPC を作成し、それらの間に Cloud VPN/Cloud Router を作成します。フレキシブル ルート アドバタイズメント (FRA) を使用して、特定のネットワーク間のアクセスをフィルタリングします。
  • D. 共有 VPC ホスト プロジェクト内に 2 つの共有 VPC を作成し、それらの間の VPC ピアリングを有効にします。ファイアウォール ルールを使用して、特定のネットワーク間のアクセスをフィルタリングします。

正解:A


質問 # 66
Google Cloud とパブリック SaaS プロバイダ間の接続の問題をトラブルシューティングしています。2 つの環境間の接続はパブリック インターネットを介して行われます。TCP を使用して接続すると、ユーザーから断続的な接続エラーが報告されますが、ICMP テストではエラーは表示されません。ユーザーによると、エラーは毎日ほぼ同じ時間に発生します。Google Cloud 内で何が起こっているかについての洞察が得られる可能性が最も高い Google Cloud ツールを使用して、トラブルシューティングと情報収集を行いたいと考えています。どうすればよいでしょうか。

  • A. TCP、テスト VM の送信元 IP アドレス、パブリック SaaS プロバイダーの宛先 IP アドレスを使用して接続テストを作成します。ライブ データ プレーン分析を確認し、テスト結果に基づいて次の手順を実行します。
  • B. ファイアウォール インサイト API を有効にします。拒否ルール インサイトの観察期間を 1 日に設定します。インサイトを確認して、トラフィックを拒否するファイアウォール ルールがないことを確認します。
  • C. Cloud NAT ゲートウェイで Cloud Logging を有効にして確認します。パブリック SaaS プロバイダの宛先 IP アドレスに一致するエラーのあるログを探します。
  • D. Cloud Armor の Cloud Logging を有効にして確認します。パブリック SaaS プロバイダーの宛先 IP アドレスに一致するエラーのあるログを探します。

正解:A

解説:
When troubleshooting connectivity issues, especially over public internet connections with intermittent errors, Connectivity Tests in Network Intelligence Center are crucial. This tool allows you to simulate the connectivity and understand the data plane status of Google Cloud resources. Since ICMP tests pass but TCP tests fail intermittently, using Connectivity Tests with TCP parameters will provide detailed insight into possible network issues like route misconfigurations, peering issues, or other transient problems affecting only specific protocols.


質問 # 67
あなたは GCP に移行中の大学で働いています。
クラウドの要件は次のとおりです。
* 10 Gbps のオンプレミス接続
* クラウドへのアクセスのレイテンシが最も低い
* 集中ネットワーク管理チーム
新しい部門は、プロジェクトへのオンプレミス接続を求めています。キャンパスを Google Cloud に接続するために、最もコスト効率の高い相互接続ソリューションをデプロイしたいと考えています。
あなたは何をするべきか?

  • A. スタンドアロン プロジェクトを使用し、個々のプロジェクトのそれぞれに VLAN アタッチメントとインターコネクトを展開します。
  • B. 共有 VPC を使用し、サービス プロジェクトに VLAN アタッチメントをデプロイします。VLAN アタッチメントを共有 VPC のホスト プロジェクトに接続します。
  • C. 共有 VPC を使用し、VLAN アタッチメントと相互接続をホスト プロジェクトにデプロイします。
  • D. スタンドアロン プロジェクトを使用し、個々のプロジェクトに VLAN アタッチメントを展開します。VLAN アタッチメントをスタンドアロン プロジェクトの相互接続に接続します。

正解:C

解説:
https://cloud.google.com/interconnect/docs/how-to/dedicated/using-interconnects-other-projects Using Cloud Interconnect with Shared VPC You can use Shared VPC to share your VLAN attachment in a project with other VPC networks. Choosing Shared VPC is preferable if you need to create many projects and would like to prevent individual project owners from managing their connectivity back to your on-premises network. In this scenario, the host project contains a common Shared VPC network usable by VMs in service projects. Because VMs in the service projects use this network, Service Project Admins don't need to create other VLAN attachments or Cloud Routers in the service projects. In this scenario, you must create VLAN attachments and Cloud Routers for a Cloud Interconnect connection only in the Shared VPC host project. The combination of a VLAN attachment and its associated Cloud Router are unique to a given Shared VPC network. https://cloud.google.com/network-connectivity/docs/interconnect/how-to/enabling-multiple-networks-access-same-attachment#using_with
https://cloud.google.com/vpc/docs/shared-vpc


質問 # 68
......

更新された2025年12月合格させるProfessional-Cloud-Network-Engineer日本語試験リアル練習テスト問題:https://www.goshiken.com/Google/Professional-Cloud-Network-Engineer-JPN-mondaishu.html