Google Professional Cloud Network Engineer Exam Practice Test Instant Access

Question 1

Your organization recently created a sandbox environment for a new cloud deployment. To have parity with the production environment, a pair of Compute Engine instances with multiple network interfaces (NICs) were deployed. These Compute Engine instances have a NIC in the Untrusted VPC (10.0.0.0/23) and a NIC in the Trusted VPC (10.128.0.0/9). A HA VPN tunnel has been established to the on-premises environment from the Untrusted VPC. Through this pair of VPN tunnels, the on-premises environment receives the route advertisements for the Untrusted and Trusted VPCs. In return, the on-premises environment advertises a number of CIDR ranges to the Untrusted VPC. However, when you tried to access one of the test services from the on-premises environment to the Trusted VPC, you received no response. You need to configure a highly available solution to enable the on-premises users to connect to the services in the Trusted VPC. What should you do?

AAdd both multi-NIC VMs to a new unmanaged instance group, named nva-uig.
Create an internal passthrough Network Load Balancer in the Untrusted VPC, named ilb-untrusted, with the nva-uig unmanaged instance group designated as the backend.
Create a custom static route in the Untrusted VPC for destination 10.123.0.0/9 and the next hop ilb-untrusted.
Create an internal passthrough Network Load Balancer in the Trusted VPC, named ilb-trusted, with the nva-uig unmanaged instance group designated as the backend.
Create a custom static route in the Trusted VPC for destination 0.0.0.0/0 and the next hop ilb-trusted.

BAdd both multi-NIC VMs to a new unmanaged instance group, named nva-uig.
Create an internal passthrough Network Load Balancer in the Untrusted VPC, named ilb-untrusted, with the nva-uig unmanaged instance group designated as the backend.
Create a custom static route in the Untrusted VPC for destination 10.128.0.0/9 and the next hop ilb-untrusted.
Create an internal passthrough Network Load Balancer in the Trusted VPC, named ilb-trusted, with the nva-uig unmanaged instance group designated as the backend.
Create a custom static route in the Trusted VPC for destination 10.0.0.0/23 and the next hop ilb-trusted.

CAdd both multi-NIC VMs to a new unmanaged instance group, named nva-uigO.
Create an internal passthrough Network Load Balancer in the Untrusted VPC, named ilb-untrusted, with the nva-uigO as backend.
Create a custom static route in the Untrusted VPC for destination 10.128.0.0/9 and the next hop ilb-untrusted.
Add both multi-NIC VMs to a new unmanaged instance group, named nva-uigl.
Create an internal passthrough Network Load Balancer in the Trusted VPC, named ilb-trusted, with the nva-uigl as backend.
Create a custom static route in the Trusted VPC for destination 0.0.0.0/0 and the next hop ilb-trusted.

DAdd both multi-NIC VMs to a new unmanaged instance group, named nva-uig.
Create two custom static routes in the Untrusted VPC for destination 10.128.0.0/9 and set each of the VMs' NIC as the next hop.
Create two custom static routes in the Trusted VPC for destination 10.0.0.0/23 and set each of the VMs' NIC as the next hop.

Answer : B

The solution requires creating internal passthrough load balancers for both VPCs, with custom static routes pointing to each load balancer. This ensures connectivity between the on-premises environment and the Trusted VPC via the Untrusted VPC.

Question 2

Your company's current network architecture has two VPCs that are connected by a dual-NIC instance that acts as a bump-in-the-wire firewall between the two VPCs. Flows between pairs of subnets across the two VPCs are working correctly. Suddenly, you receive an alert that none of the flows between the two VPCs are working anymore. You need to troubleshoot the problem. What should you do? (Choose 2 answers)

AVerify that the dual-NIC instance has not been added to a backend service.

BVerify that a public IP address has not been assigned to any network interface of the dual-NIC instance.

CUse Cloud Logging to verify that there were no modifications to the VPC firewall rules or policies that were applied to the two network interfaces of the dual-NIC instance.

DVerify that a VPC Service Controls perimeter has not been enabled for the project that contains the two VPCs and the dual-NIC instance.

EVerify that the dual-NIC instance has the --can-ip-forward attribute enabled.

Answer : C, E

You should check Cloud Logging to see if any firewall rules or policies were modified, as these could block traffic between the VPCs. Additionally, the --can-ip-forward attribute must be enabled for the dual-NIC instance to allow forwarding traffic between the interfaces.

Question 3

You are configuring the firewall endpoints as part of the Cloud Next Generation Firewall (Cloud NGFW) intrusion prevention service in Google Cloud. You have configured a threat prevention security profile, and you now need to create an endpoint for traffic inspection. What should you do?

ACreate a Private Service Connect endpoint within the zone, associate the endpoint to the VPC network, and use a firewall policy rule to apply the L7 inspection.

BCreate a firewall endpoint within the region, associate the endpoint to the VPC network, and use a firewall policy rule to apply the L7 inspection.

CCreate a firewall endpoint within the zone, associate the endpoint to the VPC network, and use a firewall policy rule to apply the L7 inspection.

DAttach the profile to the VPC network, create a firewall endpoint within the zone, and use a firewall policy rule to apply the L7 inspection.

Answer : C

To apply Layer 7 (L7) inspection for intrusion prevention, you must create a firewall endpoint within the zone where the traffic inspection is required. This endpoint is then associated with the VPC network, and a firewall policy rule is applied for the L7 inspection.

Question 4

You configured a single IPSec Cloud VPN tunnel for your organization to a third-party customer. You confirmed that the VPN tunnel is established; however, the BGP session status states that BGP is not configured. The customer has provided you with their BGP settings:

Local BGP address: 169.254.11.1/30

Local ASN: 64515

Peer BGP address: 169.254.11.2

Peer ASN: 64517

Base MED: 1000

MD5 Authentication: Disabled

You need to configure the local BGP session for this tunnel based on the settings provided by the customer. You already associated the Cloud Router with the Cloud VPN Tunnel. What settings should you use for the BGP session?

APeer ASN: 64517
Advertised Route Priority (MED): 100
Local BGP IP: 169.254.11.2
Peer BGP IP: 169.254.11.1
MD5 Authentication: Disabled

BPeer ASN: 64515
Advertised Route Priority (MED): 100
Local BGP IP: 169.254.11.2
Peer BGP IP: 169.254.11.1
MD5 Authentication: Disabled

CPeer ASN: 64515
Advertised Route Priority (MED): 1000
Local BGP IP: 169.254.11.2
Peer BGP IP: 169.254.11.1
MD5 Authentication: Enabled

DPeer ASN: 64515
Advertised Route Priority (MED): 100
Local BGP IP: 169.254.11.1
Peer BGP IP: 169.254.11.2
MD5 Authentication: Disabled

Answer : A

The correct configuration requires setting the Peer ASN as 64517 (as this is the ASN of the third-party customer). The local and peer BGP IP addresses should also be set correctly based on the provided information, and MD5 authentication should be disabled. The route priority should be set to 100 to reflect standard behavior.

Question 5

There are two established Partner Interconnect connections between your on-premises network and Google Cloud. The VPC that hosts the Partner Interconnect connections is named "vpc-a" and contains three VPC subnets across three regions, Compute Engine instances, and a GKE cluster. Your on-premises users would like to resolve records hosted in a Cloud DNS private zone following Google-recommended practices. You need to implement a solution that allows your on-premises users to resolve records that are hosted in Google Cloud. What should you do?

AAssociate the private zone to 'vpc-a.' Create an outbound forwarding policy and associate the policy to 'vpc-a.' Configure the on-premises DNS servers to forward queries for the private zone to the entry point addresses created when the policy was attached to 'vpc-a.'

BConfigure a DNS proxy service inside one of the GKE clusters. Expose the DNS proxy service in GKE as an internal load balancer. Configure the on-premises DNS servers to forward queries for the private zone to the IP address of the internal load balancer.

CUse custom route advertisements to announce 169.254.169.254 via BGP to the on-premises environment. Configure the on-premises DNS servers to forward DNS requests to 169.254.169.254.

DAssociate the private zone to 'vpc-a.' Create an inbound forwarding policy and associate the policy to 'vpc-a.' Configure the on-premises DNS servers to forward queries for the private zone to the entry point addresses created when the policy was attached to 'vpc-a.'

Answer : A

Associating the private zone to 'vpc-a' and creating an outbound forwarding policy allows DNS queries to be forwarded from on-premises to Google Cloud DNS. The on-premises DNS servers will forward queries to the entry points created when the forwarding policy was applied to 'vpc-a,' enabling proper name resolution.

Question 6

Your organization wants to seamlessly migrate a global external web application from Compute Engine to GKE. You need to deploy a simple, cloud-first solution that exposes both applications and sends 10% of the requests to the new application. What should you do?

AConfigure a global external Application Load Balancer with a Service Extension that points to an application running in a VM, which controls which requests go to each application.

BConfigure a global external Application Load Balancer with weighted traffic splitting.

CConfigure two separate global external Application Load Balancers, and use Cloud DNS geolocation routing policies.

DConfigure a global external Application Load Balancer with weighted request mirroring.

Answer : B

Weighted traffic splitting allows you to gradually route a percentage of traffic to the new GKE application while still serving the majority of requests through the Compute Engine instance. This gradual transition minimizes risks and ensures seamless traffic distribution during migration.

Question 7

You are configuring the final elements of a migration effort where resources have been moved from on-premises to Google Cloud. While reviewing the deployed architecture, you noticed that DNS resolution is failing when queries are being sent to the on-premises environment. You log in to a Compute Engine instance, try to resolve an on-premises hostname, and the query fails. DNS queries are not arriving at the on-premises DNS server. You need to use managed services to reconfigure Cloud DNS to resolve the DNS error. What should you do?

AValidate that the Compute Engine instances are using the Metadata Service IP address as their resolver. Configure an outbound forwarding zone for the on-premises domain pointing to the on-premises DNS server. Configure Cloud Router to advertise the Cloud DNS proxy range to the on-premises network.

BValidate that there is network connectivity to the on-premises environment and that the Compute Engine instances can reach other on-premises resources. If errors persist, remove the VPC Network Peerings and recreate the peerings after validating the routes.

CReview the existing Cloud DNS zones, and validate that there is a route in the VPC directing traffic destined to the IP address of the DNS servers. Recreate the existing DNS forwarding zones to forward all queries to the on-premises DNS servers.

DEnsure that the operating systems of the Compute Engine instances are configured to send DNS queries to the on-premises DNS servers directly.

Answer : A

To resolve DNS resolution issues for on-premises domains from Google Cloud, you should use Cloud DNS outbound forwarding zones. This setup forwards DNS requests for specific domains to on-premises DNS servers. Cloud Router is needed to advertise the range for the DNS proxy service back to the on-premises environment, ensuring that DNS queries from Compute Engine instances reach the on-premises DNS servers.