Google Professional Cloud Network Engineer Exam Practice Test Instant Access

Question 1

Your organization has resources in two different VPCs, each in different Google Cloud projects, and requires connectivity between the resources in the two VPCs. You have already determined that there is no IP address overlap; however, one VPC uses privately used public IP (PUPI) ranges. You would like to enable connectivity between these resources by using a lower cost and higher performance method. What should you do?

ACreate an HA VPN between the two VPCs that includes the PUPI ranges in the custom route advertisements of the Cloud Router. Create the necessary ingress VPC firewall rules that target the specific resources by using IP ranges as the source filter.

BCreate a VPC Network Peering connection between the two VPCs that allows the export and import of custom routes for public IP addresses. Create the necessary ingress VPC firewall rules that target the specific resources by using service accounts as the source filter.

CCreate a VPC Network Peering connection between the two VPCs that allows the export and import of subnet routes with public IP addresses. Create the necessary ingress VPC firewall rules that target the specific resources by using IP ranges as the source filter.

DCreate a VPC Network Peering connection between the two VPCs that allows the export and import of subnet routes with public IP addresses. Create the necessary ingress VPC firewall rules that target the specific resources by using network tags as the source filter.

Answer : C

VPC Network Peering is the most cost-effective and high-performance method for connecting two VPCs. Since one VPC uses privately used public IP (PUPI) ranges, you need to configure peering to allow the export and import of subnet routes with public IP addresses. Firewall rules can be used to control traffic between the resources.

Question 2

Your organization recently re-architected your cloud environment to use Network Connectivity Center. However, an error occurred when you tried to add a new VPC named vpc-dev as a spoke. The error indicated that there was an issue with an existing spoke and the IP space of a VPC named vpc-pre-prod. You must complete the migration quickly and efficiently. What should you do?

ARemove the conflicting VPC spoke for vpc-pre-prod from the set of VPC spokes in Network Connectivity Center. Add the VPC spoke for vpc-dev. Add the previously removed vpc-pre-prod as a VPC spoke.

BDelete the VMs associated with the conflicting subnets, then delete the conflicting subnets in vpc-dev. Recreate the subnets with a new IP range and redeploy the previously deleted VMs in the new subnets. Add the VPC spoke for vpc-dev.

CExclude the conflicting IP range by using the --exclude-export-ranges flag when creating the VPC spoke for vpc-dev.

DExclude the conflicting IP range by using the --exclude-export-ranges flag in the hub when attaching the VPC spoke for vpc-dev.

Answer : A

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.

Question 3

Your organization wants to deploy HA VPN over Cloud Interconnect to ensure encryption-in-transit over the Cloud Interconnect connections. You have created a Cloud Router and two encrypted VLAN attachments that have a 5 Gbps capacity and a BGP configuration. The BGP sessions are operational. You need to complete the deployment of the HA VPN over Cloud Interconnect. What should you do?

ACreate an HA VPN gateway and associate the gateway with your two encrypted VLAN attachments. Configure the HA VPN Cloud Router, peer VPN gateway resources, and HA VPN tunnels. Use the same encrypted Cloud Router used for the Cloud Interconnect tier.

BEnable MACsec for Cloud Interconnect on the VLAN attachments.

CEnable MACsec on Partner Interconnect.

DCreate an HA VPN gateway and associate the gateway with your two encrypted VLAN attachments. Create a new dedicated HA VPN Cloud Router, peer VPN gateway resources, and HA VPN tunnels.

Answer : A

The correct approach is to create an HA VPN gateway and associate it with the encrypted VLAN attachments. The same Cloud Router used for BGP sessions with Cloud Interconnect can be used for the HA VPN. This configuration ensures encryption of the traffic passing over the Cloud Interconnect links.

Question 4

Your frontend application VMs and your backend database VMs are all deployed in the same VPC but across different subnets. Global network firewall policy rules are configured to allow traffic from the frontend VMs to the backend VMs. Based on a recent compliance requirement, this traffic must now be inspected by network virtual appliances (NVAs) firewalls that are deployed in the same VPC. The NVAs are configured to be full network proxies and will source NAT-allowed traffic. You need to configure VPC routing to allow the NVAs to inspect the traffic between subnets. What should you do?

APlace your NVAs behind an internal passthrough Network Load Balancer named ilb1. Add global network firewall policy rules to allow traffic through your NVAs. Create a custom static route with the destination IP range of the backend VM subnet, frontend instance tag, and the next hop of ilb1. Add a frontend network tag to your frontend VMs.

BCreate your NVA with multiple interfaces. Configure NIC0 for NVA in the backend subnet. Configure NIC1 for NVA in the frontend subnet. Place your NVAs behind an internal passthrough Network Load Balancer named ilb1. Add global network firewall policy rules to allow traffic through your NVAs. Create a custom static route with the destination IP range of the backend VM subnet, frontend instance tag, and the next hop of ilb1. Add a frontend network tag to your frontend VMs.

CPlace your NVAs behind an internal passthrough Network Load Balancer named ilb1. Add the global network firewall policy rules to allow traffic through your NVAs. Create a policy-based route (PBR) with the source IP range of the backend VM subnet, destination IP range of the frontend VM subnet, and the next hop of ilb1. Scope the PBR to the VMs with the backend network tag. Add a backend network tag to your backend servers.

DPlace your NVAs behind an internal passthrough Network Load Balancer named ilb1. Add global network firewall policy rules to allow traffic through your NVAs. Create a policy-based route (PBR) with the source IP range of the frontend VM subnet, destination IP range of the backend VM subnet, and the next hop of ilb1. Scope the PBR to the VMs with the frontend network tag. Add a frontend network tag to your frontend servers.

Answer : D

The correct solution requires creating a policy-based route (PBR) to force the traffic from the frontend subnet to the backend subnet through the NVA. The PBR should be scoped to the frontend VMs, with the next hop being the passthrough load balancer (ilb1) behind which the NVAs reside. This ensures that all traffic is inspected by the NVA before reaching the backend.

Question 5

Your team deployed two applications in GKE that are exposed through an external Application Load Balancer. When queries are sent to www.mountkirkgames.com/sales and www.mountkirkgames.com/get-an-analysis, the correct pages are displayed. However, you have received complaints that www.mountkirkgames.com yields a 404 error. You need to resolve this error. What should you do?

AReview the Ingress YAML file. Define the default backend. Reapply the YAML.

BReview the Ingress YAML file. Add a new path rule for the * character that directs to the base service. Reapply the YAML.

CReview the Service YAML file. Define a default backend. Reapply the YAML.

DReview the Service YAML file. Add a new path rule for the * character that directs to the base service. Reapply the YAML.

Answer : A

The 404 error is occurring because there is no default backend defined for requests to the root URL. Defining the default backend in the Ingress YAML file ensures that requests to www.mountkirkgames.com are routed to the correct service.

Question 6

Your company's current network architecture has three VPC Service Controls perimeters:

One perimeter (PERIMETER_PROD) to protect production storage buckets

One perimeter (PERIMETER_NONPROD) to protect non-production storage buckets

One perimeter (PERIMETER_VPC) that contains a single VPC (VPC_ONE)

In this single VPC (VPC_ONE), the IP_RANGE_PROD is dedicated to the subnets of the production workloads, and the IP_RANGE_NONPROD is dedicated to subnets of non-production workloads. Workloads cannot be created outside those two ranges. You need to ensure that production workloads can access only production storage buckets and non-production workloads can access only non-production storage buckets with minimal setup effort. What should you do?

ADevelop a design that uses the IP_RANGE_PROD and IP_RANGE_NONPROD perimeters to create two access levels, with each access level referencing a single range. Create two ingress access policies with each access policy referencing one of the two access levels. Update the PERIMETER_PROD and PERIMETER_NONPROD perimeters.

BDevelop a design that removes the PERIMETER_VPC perimeter. Update the PERIMETER_NONPROD perimeter to include the project containing VPC_ONE. Remove the PERIMETER_PROD perimeter.

CDevelop a design that creates a new VPC (VPC_NONPROD) in the same project as VPC_ONE. Migrate all the non-production workloads from VPC_ONE to the PERIMETER_NONPROD perimeter. Remove the PERIMETER_VPC perimeter. Update the PERIMETER_PROD perimeter to include VPC_ONE and the PERIMETER_NONPROD perimeter to include VPC_NONPROD.

DDevelop a design that removes the PERIMETER_VPC perimeter. Update the PERIMETER_PROD perimeter to include the project containing VPC_ONE. Remove the PERIMETER_NONPROD perimeter.

Answer : A

Using IP range-based access levels for VPC Service Controls allows segmentation of production and non-production resources within the same VPC. By creating separate access levels and ingress policies for each IP range, you ensure that only production subnets access production buckets and non-production subnets access non-production buckets, providing the required isolation.

Question 7

Your organization is deploying a mission-critical application with components in different regions due to strict compliance requirements. There are latency issues between different applications that reside in us-central1 and us-east4. The application team suspects the Google Cloud network as the source of the excessive latency despite using the Premium Network Service Tier. You need to use Google-recommended practices with the least amount of effort to verify the inter-region latency by investigating network performance. What should you do?

ASet up the Performance Dashboard in Network Intelligence Center. Select the traffic type (cross-zonal), the metric (latency - RTT), the time period, the desired regions (us-central1 and us-east4), and the network tier.

BEnable VPC Flow Logs for the VPC. Identify major bottlenecks from the application level using Flow Analyzer.

CConfigure two Linux VMs in each zone for each region. Install the application, and run a load test using each zone from different regions.

DConfigure a VM with a probe in Network Intelligence Center in each zone for each region. Choose the traffic type (cross-zonal), metric (latency - RTT), desired regions (us-central1 and us-east4), and the network tier.

Answer : A

The Performance Dashboard in the Network Intelligence Center provides a detailed view of network latency and performance metrics. For inter-region latency issues, you can quickly identify round-trip times (RTT) and latency using this tool by selecting the specific regions and network tiers, which allows you to diagnose any anomalies or patterns impacting performance.