[2024年07月31日]Google Professional-Cloud-Network-Engineer日本語リアル試験問題と解答を無料で提供いたします [Q19-Q36]

Share

[2024年07月31日]Google Professional-Cloud-Network-Engineer日本語リアル試験問題と解答を無料で提供いたします

合格できるGoogle Professional-Cloud-Network-Engineer日本語試験情報と無料練習テスト問題

質問 # 19
Virtual Private Cloud (VPC) 内の仮想マシン (VM) インスタンスが Google API にアクセスできるようにプライベート Google アクセスを有効にするのはお客様の責任です。すべての VM インスタンスにはプライベート IP アドレスのみがあり、Cloud Storage にアクセスする必要があります。既存の Cloud Interconnect 接続を介してトラフィック スクラビングを行うために、すべての VM トラフィックがオンプレミスのデータセンターにルーティングされていることを確認する必要があります。ただし、Google API への VM トラフィックは VPC 内に残る必要があります。あなたは何をするべきか?

  • A. VPC 内のデフォルト ルートを削除します。
    googleapis.com のプライベート Cloud DNS ゾーンを作成し、制限付き googleapis.com に対する *.googleapis.com の CNAME を作成し、199.36.153.4/30 のアドレスに解決される制限付き googleapis com の A レコードを作成します。
    ネクストホップとしてデフォルトのインターネットゲートウェイを使用して、範囲 199.36.153.4/30 の静的ルートを VPC に作成します。
  • B. デフォルトの VPC ルートよりも低い優先度 (MED) を持つボーダー ゲートウェイ プロトコル (BGP) 経由で 0.0.0.0/0 をアドバタイズするようにオンプレミス ルーターを構成します。
    googleapis.com のプライベート Cloud DNS ゾーンを作成し、* googieapis.com の CNAME をプライベート googleapis com に作成し、199 .36.153.8/30 のアドレスに解決される private.googleapis.com の A レコードを作成します。
    VPC 内に範囲 199.36 の静的ルートを作成します。153.8/30、デフォルトのインターネットゲートウェイをネクストホップとして使用します。
  • C. VPC 内のデフォルト ルートを削除し、ボーダー ゲートウェイ プロトコル (BGP) 経由で 0.0.0.0/0 をアドバタイズするようにオンプレミス ルーターを構成します。
    googleapis.com のプライベート Cloud DNS ゾーンを作成し、* googieapis.com の CNAME をプライベート googleapis.com に作成し、199.36.153.8/30 のアドレスに解決される private.googleapis.com の A レコードを作成します。
    ネクストホップとしてデフォルトのインターネットゲートウェイを使用して、範囲 199.36.153.8/30 の静的ルートを VPC に作成します。
  • D. VPC 内のデフォルト ルートを削除し、ボーダー ゲートウェイ プロトコル (BGP) 経由で 0.0.0.0/0 をアドバタイズするようにオンプレミス ルーターを構成します。
    *.google.com からプライベート googleapis com への CNAME を持つパブリック Cloud DNS ゾーンを作成し、* googleapis.com からプライベート googleapis com への CNAME を作成し、199.36 のアドレスに解決されるプライベート googleapis.com の A レコードを作成します。 .153 8/30。
    ネクストホップとしてデフォルトのインターネットゲートウェイを使用して、範囲 199 .36.153.8/30 の静的ルートを VPC に作成します。

正解:B


質問 # 20
Google Cloud 組織には、Dev と Prod という 2 つのフォルダがあります。最小限のコストですべての仮想マシン (VM) に次のファイアウォール ルールを適用する、スケーラブルで一貫した方法が必要です。
ポート 8080 は、Dev フォルダー内のプロジェクト内の VM に対して常に開いている必要があります。
ポート 8080 へのトラフィックは、Prod フォルダー内のプロジェクト内のすべての VM に対して拒否される必要があります。
あなたは何をするべきか?

  • A. Anthos Config Connector を使用して、開発 VM でポート 8080 を開き、本番 VM でポート 8080 へのトラフィックを拒否するセキュリティ ポリシーを適用します。
  • B. 開発プロジェクト用の共有 VPC と本番プロジェクト用の共有 VPC を作成します。開発用の共有 VPC でポート 8080 を開くための VPC ファイアウォール ルールを作成します。Prod 用の共有 VPC でポート 8080 へのトラフィックを拒否するファイアウォール ルールを作成します。これらの共有 VPC に VM をデプロイします。
  • C. 開発プロジェクトのすべての VPC で、ポート 8080 を開く VPC ファイアウォール ルールを作成します。本番プロジェクトのすべての VPC で、ポート 8080 へのトラフィックを拒否する VPC ファイアウォール ルールを作成します。
  • D. ファイアウォール ポリシーを作成し、ポート 8080 を開くルールを使用して Dev フォルダーに関連付けます。ファイアウォール ポリシーを作成し、ポート 8080 へのトラフィックを拒否するルールを使用して Prod フォルダーに関連付けます。

正解:D


質問 # 21
組織には、us-east1、us-west2、us-central1 に Compute Engine インスタンスがあります。また、あなたの組織には、米国東海岸に単一の VLAN アタッチメントと Cloud Router を us-east1 に備えた既存の Cloud Interconnect 物理接続もあります。高可用性を備えた設計を提供し、リージョンがダウンした場合でも他のすべての Virtual Private Cloud (VPC) サブネットにアクセスできるようにする必要があります。これは、可能な限り最もコスト効率の高い方法で達成する必要があります。あなたは何をするべきか?

  • A. VPC ルーティングをグローバル モードで構成します。
    us-east1 リージョンに Cloud Interconnect VLAN アタッチメントを追加し、us-east1 で Cloud Router を構成します。
  • B. VPC ルーティングをリージョン モードで構成します。
    us-east1 リージョンに Cloud Interconnect VLAN アタッチメントを追加し、us-east1 で Cloud Router を構成します。
  • C. VPC ルーティングをリージョン モードで構成します。
    us-west2 リージョンと us-central1 リージョンに Cloud Interconnect VLAN アタッチメントを追加し、us-west2 と us-central1 で Cloud Router を構成します。
  • D. VPC ルーティングをグローバル モードで設定します。
    us-west2 リージョンに Cloud Interconnect VLAN アタッチメントを追加し、us-west2 で Cloud Router を構成します。

正解:A


質問 # 22
あなたは組織のネットワーク アーキテクチャを設計しています。あなたの組織には、Web、アプリ、データベースの 3 つの開発者チームがあります。すべての開発者チームは、重要なタスクを実行するために Compute Engine インスタンスにアクセスする必要があります。あなたは、開発者にネットワーク アクセスを提供する必要がある小規模なネットワークおよびセキュリティ チームの一員です。サブネット、ルート、ファイアウォールなどのネットワーク リソースに対する集中制御を維持する必要があります。運用上のオーバーヘッドを最小限に抑えたい。このトポロジをどのように設計すればよいでしょうか?

  • A. 共有 VPC を使用してホスト プロジェクトを構成します。Web、アプリ、データベースのサービス プロジェクトを作成します。
  • B. 3 つの共有 VPC ホスト プロジェクトを構成します。それぞれにサービス プロジェクトが含まれます (Web 用に 1 つ、アプリ用に 1 つ、データベース用に 1 つ)。
  • C. Web 用に 1 つの VPC、アプリ用に 1 つの VPC、データベース用に 1 つの VPC を構成します。各 VPC 間に HA VPN を構成します。
  • D. Web 用に 1 つの VPC、アプリ用に 1 つの VPC、データベース用に 1 つの VPC を構成します。VPC ネットワーク ピアリングを使用して、すべての VPC をフルメッシュで接続します。

正解:B


質問 # 23
オンプレミスからアクセスできる既存の VPC に GKE クラスタを作成する必要があります。次の要件を満たす必要があります。
ポッドとサービスの IP 範囲は可能な限り小さくする必要があります。
ノードとマスターにはインターネットからアクセスできないようにしてください。
クラスターを管理するには、オンプレミスのサブネットから kubectl コマンドを使用できる必要があります。
GKE クラスタはどのように作成すればよいですか?

  • A. * ユーザー管理の IP 範囲を使用して VPC ネイティブ GKE クラスタを作成します。
    * クラスターマスターで privateEndpoint を有効にします。
    * ポッドとサービス範囲を /24 に設定します。
    * マスターにアクセスするためにネットワーク プロキシを設定します。
  • B. * GKE が管理する IP 範囲を使用して VPC ネイティブ GKE クラスタを作成します。
    * ポッド IP 範囲を /21 に設定し、サービス IP 範囲を /24 に設定します。
    * マスターにアクセスするためにネットワーク プロキシを設定します。
  • C. * VPC アドバンスト ルートを使用するプライベート クラスターを作成します。
    * ポッドとサービス範囲を /24 に設定します。
    * マスターにアクセスするためにネットワーク プロキシを設定します。
  • D. * ユーザー管理の IP 範囲を使用して VPC ネイティブ GKE クラスタを作成します。
    * GKE クラスタ ネットワーク ポリシーを有効にし、ポッドとサービス範囲を /24 に設定します。
    * マスターにアクセスするためにネットワーク プロキシを設定します。
    * マスター承認ネットワークを有効にします。

正解:A

解説:
* Enable master authorized networks.
Explanation:
Creating GKE private clusters with network proxies for controller access When you create a GKE private cluster with a private cluster controller endpoint, the cluster's controller node is inaccessible from the public internet, but it needs to be accessible for administration. By default, clusters can access the controller through its private endpoint, and authorized networks can be defined within the VPC network. To access the controller from on-premises or another VPC network, however, requires additional steps. This is because the VPC network that hosts the controller is owned by Google and cannot be accessed from resources connected through another VPC network peering connection, Cloud VPN or Cloud Interconnect. https://cloud.google.com/solutions/creating-kubernetes-engine-private-clusters-with-net-proxies


質問 # 24
インターネットに接続された標準の Voice-over-IP (VOIP) アプリケーションの負荷分散を構成したいと考えています。
どのタイプのロードバランサーを使用する必要がありますか?

  • A. TCP/SSL プロキシ ロード バランサ
  • B. 内部 TCP/UDP ロード バランサ
  • C. HTTP(S) ロードバランサ
  • D. ネットワークロードバランサー

正解:D


質問 # 25
プロジェクト my-project には、Virtual Private Cloud (VPC) 内に 2 つのサブネットがあります。IP 範囲 10.128.0.0/20 の subnet-a と IP 範囲 172.16.0.0/24 の subnet-b です。データベース サーバーをサブネットに展開する必要があります。また、アプリケーション サーバーと Web サーバーを subnet-b に展開します。アプリケーション サーバーからデータベース サーバーへのデータベース トラフィックのみを許可するファイアウォール ルールを構成したいと考えています。あなたは何をするべきか?

  • A. Create network tags app-server and db-server. Add the app-server tag to the application servers, and add the db-server tag to the database servers. Run the following command:
    gcloud compute firewall-rules create app-db-firewall-rule \
    --action allow \
    --direction ingress \
    --rules tcp:3306 \
    --source-ranges 10.128.0.0/20 \
    --source-tags app-server \
    --target-tags db-server
  • B. ネットワーク タグ app-server とサービス アカウント [email protected] を作成します。タグをアプリケーション サーバーに追加し、サービス アカウントをデータベース サーバーに関連付けます。次のコマンドを実行します。
    gcloud compute firewall-rules create app-db-firewall-rule \
    --アクション許可\
    --方向入力 \
    --allow TCP:3306 \
    --source-service-accounts sa-app@democloud-idp-
    demo.iam.gserviceaccount.com \
    --target-service-accounts sa-db@my-
    project.iam.gserviceaccount.com
  • C. Create service accounts [email protected] and [email protected]. Associate the service account sa-app with the application servers, and associate the service account sa-db with the database servers. Run the following command:
    gcloud compute firewall-rules create app-db-firewall-ru
    --allow TCP:3306 \
    --source-ranges 10.128.0.0/20 \
    --source-service-accounts sa-app@my-
    project.iam.gserviceaccount.com \
    --target-service-accounts sa-db@my-
    project.iam.gserviceaccount.com

正解:A


質問 # 26
次のルーティング設計があります。asia-southeast1 リージョンの Subnet-2 にある Compute Engine インスタンスがオンプレミスのコンピューティング リソースと通信できないことがわかりました。あなたは何をするべきか?

  • A. Cloud Router でカスタム ルート アドバタイズメントを構成します。
  • B. asia-southeast1 リージョンで IP 転送を有効にします。
  • C. VPC 動的ルーティング モードをグローバルに変更します。
  • D. 2 番目のボーダー ゲートウェイ プロトコル(BGP)セッションを Cloud Router に追加します。

正解:C


質問 # 27
VPC ネットワーク ピアリングを使用してスポークをハブに接続するハブアンドスポーク アーキテクチャを Google Cloud 環境にデプロイしました。セキュリティ上の理由から、コントロール プレーンのプライベート エンドポイントを備えたスポーク プロジェクトの 1 つにプライベート Google Kubernetes Engine (GKE) クラスターをデプロイしました。承認済みネットワークが、GKE ノードがデプロイされるサブネット範囲になるように構成しました。別のスポーク プロジェクトから GKE コントロール プレーンにアクセスしようとしても、アクセスできません。他のスポーク プロジェクトから GKE コントロール プレーンへのアクセスを許可する必要があります。あなたは何をするべきか?

  • A. GKE ノードがデプロイされているサブネットで限定公開の Google アクセスを有効にします。
  • B. 他のスポーク プロジェクトからのポート 443 を許可するファイアウォール ルールを追加します。
  • C. 承認されたネットワークが他のスポーク プロジェクトのサブネット範囲になるように構成します。
  • D. GKE ノードがデプロイされているスポーク プロジェクトにプロキシをデプロイし、プロキシを通じてコン​​トロール プレーンに接続します。

正解:C


質問 # 28
あなたの組織には、リージョン us-west2 の仮想マシンからのすべての出力トラフィック ペイロードを監視することを要求する新しいセキュリティ ポリシーがあります。新しいポリシーを満たすために、同じリージョンに侵入検知システム (IDS) 仮想アプライアンスをデプロイしました。us-west2 からのすべての出力トラフィック ペイロードを監視するには、IDS を環境に統合する必要があります。あなたは何をするべきか?

  • A. パケット ミラーリング用の内部 HTTP(S) ロード バランサを作成し、出力トラフィック用のパケット ミラーリング ポリシー フィルタを追加します。
  • B. VPC フロー ログを有効にします。Cloud Logging でシンクを作成し、フィルタリングされた下り VPC フロー ログを IDS に送信します。
  • C. ファイアウォール ログを有効にし、フィルタリングされたすべての出力ファイアウォール ログを IDS に転送します。
  • D. パケット ミラーリング用の内部 TCP/UDP ロード バランサーを作成し、出力トラフィック用のパケット ミラーリング ポリシー フィルターを追加します。

正解:B


質問 # 29
あなたの会社は最近、EMEA ベースの事業を APAC に拡大しました。世界中に分散しているユーザーから、SMTP サービスと IMAP サービスが遅いと報告されています。あなたの会社ではエンドツーエンドの暗号化が必要ですが、SSL 証明書にアクセスできません。
どの Google Cloud ロードバランサを使用する必要がありますか?

  • A. TCP プロキシ ロード バランサ
  • B. HTTPS ロードバランサ
  • C. SSL プロキシ ロード バランサ
  • D. ネットワークロードバランサー

正解:A

解説:
https://cloud.google.com/security/encryption-in-transit/ Automatic encryption between GFEs and backends For the following load balancer types, Google automatically encrypts traffic between Google Front Ends (GFEs) and your backends that reside within Google Cloud VPC networks: HTTP(S) Load Balancing TCP Proxy Load Balancing SSL Proxy Load Balancing


質問 # 30
あなたは組織用に Google Kubernetes Engine (GKE) クラスターを設計しています。現在のクラスター サイズは、ノードあたり 20 個のポッドと 150 個のサービスを備えた 10 ノードをホストすると予想されます。今後 2 年間で新しいサービスが移行されるため、ノード数は 100、ノードあたり 200 ポッド、サービス数は 1500 に増加する予定です。アドレスの消費を最小限に抑えながら、エイリアス IP 範囲を持つ VPC ネイティブ クラスターを使用したいと考えています。
このトポロジをどのように設計すればよいでしょうか?

  • A. ポッドの場合は /24、サービスの場合は /24 の 2 つのセカンダリ範囲を持つサイズ /28 のサブネットを作成します。VPC ネイティブ クラスターを作成し、それらの範囲を指定します。サービスを展開する準備ができたら、サブネットのサイズを変更します。
  • B. ポッドの場合は /17、サービスの場合は /21 の 2 つのセカンダリ範囲を持つサイズ /25 のサブネットを作成します。VPC ネイティブ クラスターを作成し、それらの範囲を指定します。
  • C. gcloudcontainerclusterscreate[クラスター名] を使用して、VPC ネイティブクラスターを作成します。
  • D. gcloudcontainerclusterscreate[クラスター名]--enable-ip-alias を使用して VPC ネイティブ クラスターを作成します。

正解:B

解説:
The service range setting is permanent and cannot be changed. Please see https://stackoverflow.com/questions/60957040/how-to-increase-the-service-address-range-of-a-gke-cluster I think the correc tanswer is A since: Grow is expected to up to 100 nodes (that would be /25), then up to 200 pods per node (100 times 200 = 20000 so /17 is 32768), then 1500 services in a /21 (up to 2048)
https://docs.netgate.com/pfsense/en/latest/book/network/understanding-cidr-subnet-mask-notation.html


質問 # 31
HTTP、HTTPS、および SSH ポート経由のトラフィックのみを許可するルールを使用してファイアウォールを作成しました。テスト中は、具体的には複数のポートとプロトコルを介してサーバーにアクセスしようとします。ただし、ファイアウォール ログには拒否された接続は表示されません。あなたは問題を解決したいと考えています。
あなたは何をするべきか?

  • A. デフォルトの「拒否」ファイアウォール ルールでログを有効にします。
  • B. トラフィックを受信する VM インスタンスでのログ記録を有効にします。
  • C. フィルターなしですべてのファイアウォール ログを転送するログ シンクを作成します。
  • D. 明示的な拒否ルールを作成し、新しいルールでのログ記録を有効にします。

正解:D

解説:
https://cloud.google.com/vpc/docs/firewall-rules-logging#egress_deny_example You can only enable Firewall Rules Logging for rules in a Virtual Private Cloud (VPC) network. Legacy networks are not supported. Firewall Rules Logging only records TCP and UDP connections. Although you can create a firewall rule applicable to other protocols, you cannot log their connections. You cannot enable Firewall Rules Logging for the implied deny ingress and implied allow egress rules. Log entries are written from the perspective of virtual machine (VM) instances. Log entries are only created if a firewall rule has logging enabled and if the rule applies to traffic sent to or from the VM. Entries are created according to the connection logging limits on a best effort basis. The number of connections that can be logged in a given interval is based on the machine type. Changes to firewall rules can be viewed in VPC audit logs. https://cloud.google.com/vpc/docs/firewall-rules-logging#specifications


質問 # 32
Virtual Private Cloud (VPC) 内の将来の新しい Google Kubernetes Engine (GKE) クラスターのアドレス プランを定義する必要があります。これは VPC ネイティブ クラスターとなり、デフォルトのポッド IP 範囲割り当てが使用されます。クラスターを作成する前に、必要なすべての VPC サブネットとそれぞれの IP アドレス範囲を事前にプロビジョニングする必要があります。クラスターには最初は 1 つのノードがありますが、必要に応じて最大 3 つのノードに拡張されます。最小限の数のポッド IP アドレスを割り当てたいと考えています。ポッドの IP アドレス範囲にはどのサブネット マスクを使用する必要がありますか?

  • A. /25
  • B. /22
  • C. /21
  • D. /23

正解:C


質問 # 33
あなたは、3 層アプリケーション アーキテクチャをオンプレミスから Google Cloud に移行しています。移行の最初のステップとして、外部 HTTP(S) ロード バランサを使用して新しい Virtual Private Cloud (VPC) を作成します。このロード バランサーは、プレゼンテーション層を実行するオンプレミスのコンピューティング リソースにトラフィックを転送します。悪意のあるトラフィックが VPC に入り、エッジでリソースを消費するのを阻止する必要があるため、IP アドレスをフィルタリングし、クロスサイト スクリプティング (XSS) 攻撃を阻止するようにこのポリシーを構成する必要があります。あなたは何をするべきか?

  • A. Google Cloud Armor ポリシーを作成し、アンマネージド インスタンス グループ バックエンドを使用するバックエンド サービスに適用します。
  • B. 階層型ファイアウォール ルールセットを作成し、VPC の親組織リソース ノードに適用します。
  • C. VPC ファイアウォール ルールセットを作成し、それを非マネージド インスタンス グループ内のすべてのインスタンスに適用します。
  • D. Google Cloud Armor ポリシーを作成し、インターネット ネットワーク エンドポイント グループ (NEG) バックエンドを使用するバックエンド サービスに適用します。

正解:D


質問 # 34
これで、インフラストラクチャを Google Cloud にデプロイできました。次の要件を満たすように DNS を構成する必要があります。
オンプレミス リソースは Google Cloud ゾーンを解決する必要があります。
Google Cloud リソースはオンプレミス ゾーンを解決する必要があります。
Google Cloud によってプロビジョニングされた「.internal」ゾーンを解決する機能が必要です。
あなたは何をするべきか?

  • A. オンプレミスの DNS リゾルバーを使用して Cloud DNS を DNS ピアに構成します。Google Cloud ゾーンのクエリを Google のパブリック DNS 8.8.8.8 に転送するようにオンプレミスの DNS リゾルバーを構成します。
  • B. 送信サーバー ポリシーを構成し、代替ネーム サーバーをオンプレミスの DNS リゾルバーとして設定します。Google Cloud ゾーンのクエリを Google のパブリック DNS 8.8.8.8 に転送するようにオンプレミスの DNS リゾルバーを構成します。
  • C. オンプレミスの DNS リゾルバーとしてターゲットを使用して、受信サーバー ポリシーと送信 DNS 転送ゾーンの両方を構成します。Google Cloud ゾーンのクエリを Google Cloud の DNS リゾルバに転送するようにオンプレミスの DNS リゾルバを構成します。
  • D. 送信 DNS サーバー ポリシーを構成し、代替ネーム サーバーをオンプレミスの DNS リゾルバーとして設定します。Google Cloud ゾーンのクエリを Google Cloud の DNS リゾルバに転送するようにオンプレミスの DNS リゾルバを構成します。

正解:B


質問 # 35
単一の Compute Engine ゾーンにインスタンスを手動で配置して、概念実証アプリケーションをデプロイしました。これからアプリケーションを実稼働環境に移行するため、アプリケーションの可用性を高め、自動スケーリングできるようにする必要があります。
インスタンスをどのようにプロビジョニングする必要がありますか?

  • A. リージョンごとにマネージド インスタンス グループを作成し、その場所で [単一ゾーン] を選択し、そのリージョン内のゾーン全体にインスタンスを手動で分散します。
  • B. 単一ゾーンにアンマネージド インスタンス グループを作成し、そのインスタンス グループの HTTP ロード バランサを作成します。
  • C. ゾーンごとに非マネージド インスタンス グループを作成し、目的のゾーン全体にインスタンスを手動で分散します。
  • D. 単一のマネージド インスタンス グループを作成し、目的のリージョンを指定して、その場所として [複数のゾーン] を選択します。

正解:D

解説:
https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances


質問 # 36
......

最新のProfessional-Cloud-Network-Engineer日本語試験問題集でGoogle試験が合格できます:https://jp.fast2test.com/Professional-Cloud-Network-Engineer-JPN-premium-file.html


弊社を連絡する

我々は12時間以内ですべてのお問い合わせを答えます。

我々の働いている時間: ( GMT 0:00-15:00 )
月曜日から土曜日まで

サポート: 現在連絡 

English Deutsch 繁体中文 한국어