PCNE Practice Test 34 — 15 Questions

Question 1

An engineer needs to allow HTTP health checks from the Google Cloud health checker IP ranges to a set of instances. Which two methods can be used to target the firewall rule correctly? (Choose two.)

Accepted Answer

Use target service accounts on the instances.. Options C and D are correct because VPC firewall rules match traffic by target, and the two supported target constructs are target service accounts (C) and target tags (D). Target service accounts apply the rule to instances that run as that service account, while target tags apply it to instances carrying the specified network tag, so both correctly scope the rule to the set of instances receiving the health checks. Options A and B are incorrect because source service accounts and source tags apply to the sender of the traffic, and the Google Cloud health checker IP ranges are not represented by customer-owned service accounts or network tags. Option E is incorrect because firewall rules cannot target instances by their instance names; targets must be service accounts or network tags.

Answer

Use source service accounts on the health checkers.

Answer

Use source tags on the health checkers.

Answer

Use instance names in the firewall rule.

Question 2

Which THREE are valid considerations when planning IP address ranges for VPCs that will be connected via VPC Peering and Cloud VPN? (Choose 3)

Accepted Answer

Plan for future growth by leaving unused CIDR blocks.. Option C is correct because reserving unused CIDR blocks in the VPC address plan allows additional subnets and workloads to be added later without re-addressing existing resources, which is critical since VPC peering and Cloud VPN cannot route overlapping ranges. Option D is correct because RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are the standard, supported addressing for internal VPC subnets and VPN-connected networks, keeping internal traffic private and routable across the peering or tunnel. Option E is correct because VPC peering and Cloud VPN require non-overlapping subnet ranges; if two peered VPCs or a VPN-connected on-premises network share the same CIDR, routes conflict and traffic cannot be delivered correctly. Option A is wrong because overlapping IP ranges break peering and VPN routing rather than conserving space, and Option B is wrong because assigning public IP ranges to all VMs is unnecessary, costly, and does not address private connectivity planning.

Answer

Use overlapping IP ranges to conserve address space.

Answer

Use public IP ranges for all VMs.

Question 3

A company has multiple GCP projects that need to resolve DNS queries for a private zone (e.g., example.internal) that is hosted in a central project. They want to avoid copying zone data. Which TWO features can be used to achieve this? (Choose TWO.)

Accepted Answer

DNS peering. DNS peering (C) is correct because it lets a VPC network in one project forward queries for a specific private zone (e.g., example.internal) to the VPC network that hosts the zone in the central project, so the zone data is not duplicated. Shared VPC (D) is correct because attaching the projects' resources as service projects to a host project places them in the same VPC network as the private zone, allowing them to resolve the zone directly without copying it. Outbound DNS forwarding (A) is not the intended answer because it forwards queries to on-premises or external resolvers, not to another GCP VPC's private zone. Creating duplicate private zones (B) is explicitly what the company wants to avoid since it copies zone data. Inbound DNS forwarding (E) is for allowing on-premises systems to query Cloud DNS, not for cross-project resolution between GCP VPCs.

Answer

Outbound DNS forwarding

Answer

Creating duplicate private zones in each project

Answer

Inbound DNS forwarding

Question 4

A company uses Traffic Director with Envoy proxies to manage east-west traffic. They want to implement fault injection to test the resilience of their service mesh. Which TWO types of faults can they inject? (Choose two.)

Accepted Answer

Delay (add a fixed latency to matching requests). Traffic Director's fault injection capabilities, implemented through Envoy's HTTPFault filter, support two fault types: delay and abort. Option A (Delay) is correct because Envoy can inject a fixed latency into matching requests via the 'fixed_delay' fault, simulating slow backends to test timeout and retry behavior. Option C (Abort) is correct because Envoy can return a specified HTTP status code (e.g., 503) for matching requests via the 'abort' fault, simulating service failures. Option B (Throttle) is not a fault injection type in Envoy; rate limiting is handled by a separate rate limit filter, not the fault injection filter. Option D (Retry) is a resilience policy configured in route or cluster settings, not a fault injection mechanism. Option E (Timeout) is a route-level or cluster-level setting for request deadlines, not a fault injected by the fault filter.

Answer

Throttle (limit the rate of requests)

Answer

Retry (automatically retry failed requests)

Answer

Timeout (set a maximum time for a request to complete)

Question 5

You are deploying a microservices architecture on Google Kubernetes Engine (GKE) with Traffic Director for traffic management. You want to implement fault injection to test the resilience of your services. Which two types of fault injection does Traffic Director support? (Choose two.)

Accepted Answer

Delay. Traffic Director supports two fault injection types in its HTTP route fault injection policy: delay and abort. Option A (Delay) is correct because Traffic Director can inject a fixed delay (specified in seconds via the fixedDelay field) into a percentage of requests to simulate slow upstream services and test timeout/retry behavior. Option B (Abort) is correct because Traffic Director can abort a percentage of requests with a specified HTTP status code (via the httpStatus field), simulating service failures and validating error handling. Options C (CPU exhaustion), D (Packet loss), and E (Bandwidth throttling) are not supported by Traffic Director's fault injection feature; these are network- or resource-level faults typically simulated by other tools (e.g., chaos engineering frameworks or tc/netem), not by Traffic Director's route-level fault injection.

Answer

CPU exhaustion

Answer

Packet loss

Answer

Bandwidth throttling

Question 6

A network engineer needs to design a DNS architecture for a hybrid cloud environment. The requirements: on-premises hosts must resolve GCP private zone names, and GCP instances must resolve on-premises DNS names. Which TWO Cloud DNS features should they use?

Accepted Answer

Outbound DNS server policy. The two required features are the outbound DNS server policy (A) and the inbound DNS server policy (C). An outbound server policy (A) configures Cloud DNS to forward queries from GCP VPCs to an on-premises DNS server, which lets GCP instances resolve on-premises DNS names. An inbound server policy (C) creates a highly available entry point in the VPC that on-premises resolvers can target, allowing on-premises hosts to resolve GCP private zone names. Together they provide bidirectional name resolution across the hybrid environment. Split-horizon DNS (B) only serves different answers for the same name to different clients and does not by itself connect the two environments. A DNS managed zone with forwarding (D) is a zone-level forwarding configuration, not the hybrid bidirectional mechanism described, and DNS peering (E) only links Cloud DNS namespaces across GCP VPCs or projects, not to on-premises DNS.

Answer

Split-horizon DNS

Answer

DNS managed zone with forwarding

Answer

DNS peering

Question 7

You need to configure a health check for a backend service that uses HTTP2. Which THREE settings must be configured correctly for the health check to work? (Select three.)

Accepted Answer

Request path. Option A (Request path) is correct because an HTTP/HTTP2 health check must specify the URL path the load balancer probes (for example, /healthz), and an incorrect or missing path causes the probe to receive a 404 and mark the backend unhealthy. Option B (Protocol: HTTP2) is correct because the backend service speaks HTTP/2, so the health check must be configured with the HTTP2 protocol; if it is left as HTTP/1.1, the probe's request framing and headers will not match what the backend expects and the check will fail. Option E (Port) is correct because the health check must target the exact port on which the backend listens for HTTP/2 traffic; probing the wrong port results in connection refusal or timeout and the instance is removed from rotation. Option C (Proxy protocol) is not required, since proxy protocol is only needed when the backend must receive the client's original connection information (for example, for TCP load balancing), not for a basic HTTP/2 health probe. Option D (SSL certificate) is not required for the health check itself; certificates are relevant to TLS termination or backend encryption, but the health check configuration only needs the protocol, port, and path to succeed.

Answer

Proxy protocol

Answer

SSL certificate

Question 8

Which THREE components are required to set up a Cloud VPN with dynamic routing (BGP) between an on-premises network and Google Cloud?

Accepted Answer

Cloud VPN gateway. Option A (Cloud VPN gateway) is required because it is the Google Cloud side endpoint of the IPsec tunnel that terminates the VPN connection to the on-premises peer. Option B (Cloud Router) is required because it runs BGP on the Google Cloud side and dynamically exchanges routes with the on-premises router over the tunnel. Option D (BGP peer on the on-premises router) is required because dynamic routing needs a BGP speaker on the remote side to establish the BGP session and advertise on-premises prefixes. Option C (Cloud NAT) is not needed, as Cloud NAT provides outbound internet address translation for VMs and is unrelated to VPN/BGP peering. Option E (Static routes for the remote network) is not needed because dynamic routing via BGP automatically learns and installs remote routes, making static routes unnecessary.

Answer

Cloud NAT

Answer

Static routes for the remote network

Question 9

A company has a Hybrid Connectivity setup using Cloud VPN with BGP. They want to migrate to Dedicated Interconnect for better performance. During the migration, they need to avoid downtime. Which THREE steps should they take?

Accepted Answer

Provision the Dedicated Interconnect and VLAN attachments. Option C is correct because a Dedicated Interconnect migration must begin by provisioning the physical Interconnect connection and creating VLAN attachments (pairing keys) in the relevant Google Cloud regions, which establishes the layer-2/3 path before any traffic can be shifted. Option D is correct because configuring the Interconnect BGP session with a higher local preference than the existing Cloud VPN BGP session makes the Interconnect-learned routes preferred in the VPC route selection process, so new traffic begins flowing over the Interconnect while the VPN remains available as a fallback. Option E is correct because, after confirming traffic is actually traversing the Interconnect, you should gracefully withdraw the VPN-advertised routes (for example by lowering the VPN BGP local preference or disabling the VPN BGP sessions) so the cutover is controlled and no downtime occurs. Option A is wrong because setting a lower local preference on the Interconnect BGP session would keep the VPN preferred and prevent the migration from taking effect. Option B is wrong because removing the VPN tunnels immediately after the Interconnect comes up eliminates the fallback path before traffic has been verified, risking an outage if the Interconnect has issues.

Answer

Set a lower local preference on the Interconnect BGP session

Answer

Remove the VPN tunnels immediately after Interconnect is up

Question 10

A financial services company is deploying a multi-tier application in a custom VPC with three subnets: web (10.0.1.0/24), app (10.0.2.0/24), and db (10.0.3.0/24). They use a Cloud VPN with dynamic routing (BGP) to connect to their on-premises data center (10.1.0.0/16). The on-premises network administrator reports that traffic from the web tier (10.0.1.0/24) to on-premises is working, but traffic from the app tier (10.0.2.0/24) to on-premises is failing. The company uses an Identity-Aware Proxy (IAP) for SSH access. The following configurations are in place:
- Cloud Router advertises all VPC subnets via BGP.
- On-premises router advertises 10.1.0.0/16.
- Firewall rules allow all traffic from 10.0.0.0/16 to 10.1.0.0/16.
- The app tier instances have a network tag 'app-tier' and a service account 'app-sa@project.iam.gserviceaccount.com'.
- There is a firewall rule with priority 1000 that denies egress from tags 'app-tier' to 10.1.0.0/16.
What is the most likely cause of the failure?

Accepted Answer

A firewall egress rule with priority 1000 denies traffic from instances with tag 'app-tier' to 10.1.0.0/16.. The firewall egress rule with priority 1000 explicitly denies traffic from instances tagged 'app-tier' to the on-premises network (10.1.0.0/16). Since firewall rules are evaluated in order of priority (lower numbers are higher priority), and this rule has a relatively low priority number, it will override any higher-numbered (lower priority) allow rules. The fact that web tier traffic works confirms that routing and VPN are functional, isolating the issue to the egress deny rule targeting the app tier.

Answer

The service account 'app-sa' does not have permissions to send traffic through the VPN.

Answer

IAP is blocking traffic from the app tier because it is not configured for that subnet.

Answer

The Cloud Router is not advertising the 10.0.2.0/24 subnet to on-premises.

Question 11

A company is using Cloud DNS for private zone resolution within their VPC. They have a private zone for 'example.internal' and have attached it to the VPC. When they create a new Compute Engine VM and try to resolve 'myapp.example.internal', it fails. What is the most likely cause?

Accepted Answer

The record 'myapp.example.internal' does not exist in the zone. The most likely cause of a resolution failure for a specific record is that the record does not exist in the private zone. The question states the zone is attached to the VPC, so the zone itself is accessible; the failure is specific to the record name. Cloud DNS will return an NXDOMAIN response if the record is not defined, even if the zone is properly configured.

Answer

The private zone is not attached to the VPC

Answer

The VM's /etc/resolv.conf does not point to Cloud DNS

Answer

Firewall rule blocking DNS traffic (UDP 53) to the metadata server

Question 12

A company is using Partner Interconnect with a service provider that requires the use of VLAN attachments. Which type of VLAN attachment should they create in Google Cloud to use the partner's connection?

Accepted Answer

PARTNER. For Partner Interconnect, you create a VLAN attachment of type PARTNER. This attachment represents the logical connection to the partner's network. The partner can also use PARTNER_PROVIDER type if they manage the attachment, but from the customer side, it's PARTNER.

Answer

DEDICATED

Answer

PARTNER_PROVIDER

Answer

CUSTOMER

Question 13

A company is designing a hybrid network between their on-premises data center and Google Cloud. They need high availability for traffic between the two environments and want to use Cloud VPN with dynamic routing. Which configuration ensures that if one VPN tunnel fails, traffic automatically fails over to the other tunnel without manual intervention?

Accepted Answer

Create two VPN tunnels to two separate peer VPN gateways on-premises, and use Cloud Router with BGP to advertise routes from both tunnels.. It uses two VPN tunnels to separate on-premises peer gateways with Cloud Router and BGP. BGP automatically handles failover by withdrawing routes from the failed tunnel and advertising routes via the healthy tunnel, ensuring traffic fails over without manual intervention. This meets the high availability and dynamic routing requirements specified in the question.

Answer

Create one VPN tunnel and a static route with next hop set to the VPN gateway.

Answer

Use Cloud Interconnect instead of VPN, and configure two VLAN attachments.

Answer

Create two VPN tunnels to the same peer VPN gateway, and configure equal-cost multi-path (ECMP) routing with static routes.

Question 14

A company uses Identity-Aware Proxy (IAP) to secure access to Compute Engine VMs. Users report that they can SSH into some VMs but not others, even though they have the IAP-secured Tunnel User role. Both VMs are in the same project and have the same network tags. What is the most likely reason?

Accepted Answer

Firewall rules allow ingress from IAP's IP ranges only for some VMs.. IAP TCP forwarding relies on firewall rules that allow ingress from the IAP proxy's IP ranges (35.235.240.0/20) to the VM. If these rules are applied inconsistently across VMs (e.g., missing on some subnets or instances), users will be unable to SSH into those VMs. The fact that both VMs share the same network tags does not guarantee identical firewall configurations if rules are applied based on other criteria like target tags or service accounts. Options B and D are incorrect as DNS resolution and OS Login are not prerequisites for IAP TCP forwarding. Option C is wrong because IAP TCP forwarding works with internal IPs; external IPs are not required.

Answer

The VMs are in different zones with different DNS resolution.

Answer

The VMs that can be accessed have external IP addresses; the others only have internal IP addresses.

Answer

The VMs do not have OS Login enabled.

Question 15

Your company has a VPC with a single subnet in us-central1 (10.0.1.0/24). You have a managed instance group (MIG) of web servers (10.0.1.2-10.0.1.10) and a standalone database instance (10.0.1.100). The web servers need to communicate with the database on TCP port 3306. You have configured a firewall rule allowing ingress from 10.0.1.0/24 to 10.0.1.100 on tcp:3306. However, the web servers cannot connect to the database. You verified that the database is running and listening on port 3306, and that the web servers can ping the database. What should you do to resolve the issue?

Accepted Answer

Check the database instance's OS-level firewall (e.g., iptables) and ensure it allows traffic on port 3306 from the web servers.. The firewall rule is correctly configured at the VPC level to allow ingress from the web servers' subnet to the database on TCP port 3306. Since the web servers can ping the database, network connectivity exists, but the application-layer connection fails. This indicates the database instance's OS-level firewall (e.g., iptables on Linux) is blocking the port, as cloud VPC firewall rules and guest OS firewalls operate independently.

Answer

Create a custom route from the web servers to the database.

Answer

Add a network tag 'db' to the database instance and update the firewall rule to target 'db'.

Answer

Configure the firewall rule to use the database's service account as the target.