75 of 222 questions · Page 2/3 · Pcne Designing Network topic · Answers revealed
A company is setting up HA VPN to connect an on-premises network to a single GCP region. They want to achieve 99.99% SLA. Which three steps are required? (Choose THREE.)
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?
Enables GCP to on-premises DNS resolution.
Why this answer
Inbound DNS server policy allows on-premises to forward queries to Cloud DNS. Outbound DNS server policy allows GCP to forward queries to on-premises DNS.
Which TWO of the following are valid methods to reduce latency between users in Europe and a GCP-hosted application?
Brings content closer to users.
Why this answer
Cloud CDN uses Google's globally distributed edge caches to serve content from locations closer to users, reducing round-trip time and latency. For users in Europe, cached static or dynamic content is delivered from a nearby edge PoP, bypassing the need to fetch from the origin server in a potentially distant region.
Exam trap
Google Cloud often tests the misconception that Premium Tier networking alone reduces latency for end users, but the real latency reduction comes from deploying resources in the same continent as the users (Option E) or using CDN edge caching (Option B), not just the network tier.
A company uses Shared VPC with a host project and several service projects. They want to allow only a specific team to create subnets in the host project, and another team to use those subnets in their service projects. Which IAM roles should be assigned?
Network Admin allows creating subnets; Network User allows using them.
Why this answer
To create subnets, a user needs the Compute Network Admin role on the host project. To use subnets, a user needs the Compute Network User role on the host project or specific subnets.
A company has a GKE cluster with pods and services that need IP addresses. They want to plan IP address space to avoid overlapping with on-premises networks. Which GCP feature allows reserving separate IP ranges for GKE pods and services?
GKE uses secondary ranges for pods and services.
Why this answer
Secondary IP ranges on a subnet can be designated for GKE pods and services. These ranges are separate from the primary subnet range.
A company needs to connect multiple on-premises sites and multiple GCP VPCs in a hub-and-spoke topology using Google Cloud. Which service provides a centralized hub for managing such connectivity?
NCC provides a hub-and-spoke model for connecting on-premises and VPC networks.
Why this answer
Network Connectivity Center (NCC) is the correct choice because it provides a centralized hub-and-spoke topology for connecting multiple on-premises sites (via VPN, Interconnect, or third-party SD-WAN appliances) and multiple GCP VPCs. It manages routing and policy distribution across spokes, eliminating the need for individual peering or complex route tables, and supports both intra- and cross-region connectivity.
Exam trap
The trap here is that candidates confuse VPC Peering or Shared VPC as a hub-and-spoke solution, but neither provides centralized management or transitive routing across multiple VPCs and on-premises sites, which is the key requirement of the question.
How to eliminate wrong answers
Option B is wrong because VPC Peering creates direct, point-to-point connections between two VPCs and does not support a hub-and-spoke model with centralized management; each peering must be configured individually and transitive routing is not supported. Option C is wrong because Shared VPC allows multiple projects to use a common VPC host network but does not connect on-premises sites or provide a hub for multiple separate VPCs; it is a project-level resource sharing mechanism, not a connectivity hub. Option D is wrong because Cloud Router is a dynamic routing component used for BGP sessions with on-premises networks via VPN or Interconnect, but it does not serve as a centralized hub for managing multiple VPCs and sites; it is a per-connection router, not a topology manager.
GKE uses secondary pod range for pod IPs and service range for ClusterIPs. Pods use pod range as source.
Why this answer
In GKE, pods are assigned IP addresses from the secondary pod range, and services (of type ClusterIP) are assigned IPs from the secondary service range. For on-premises resources to allow traffic from pods via a VPN, the firewall must see the pod IPs (not node IPs), so the secondary pod range must be configured on the VPC subnet. The secondary service range is also required for service discovery and proper routing, but the source IP seen by on-premises will be the pod IP from the secondary pod range.
Exam trap
The trap here is that candidates often confuse the primary IP range (used for nodes) with the pod IP range, or assume that only the pod range is needed, forgetting that the secondary service range is mandatory for GKE cluster creation and service IP allocation.
How to eliminate wrong answers
Option A is wrong because the primary IP range is used for nodes, not pods; configuring only the primary range and secondary pod range would omit the secondary service range, which is needed for Kubernetes services to function correctly (e.g., kube-dns, service IP allocation). Option B is wrong because configuring only the secondary service range would provide IPs for services but not for pods; the on-premises firewall expects pod source IPs, which come from the secondary pod range, not the service range. Option D is wrong because the primary IP range is for nodes, not pods, and the secondary service range alone does not provide pod IPs; the on-premises firewall would see node IPs (from the primary range) instead of pod IPs, breaking the required source IP restriction.
A company is deploying a global HTTP load balancer with a backend service that spans multiple regions. The backend instances are in a managed instance group. They want to use Cloud CDN to cache content. What is the minimal set of configurations required on the backend bucket or instance group to enable Cloud CDN?
Cloud CDN is enabled at the backend service level; protocol must be HTTP(S).
Why this answer
Cloud CDN must be enabled on the backend service of the HTTP(S) load balancer, and the frontend must use HTTP or HTTPS because Cloud CDN only supports HTTP(S) protocols. This is the minimal configuration; no changes to the backend bucket or instance group are required beyond ensuring the backend service is correctly associated with the load balancer.
Exam trap
Google Cloud often tests the misconception that Cloud CDN requires a Cloud Storage bucket or that it can be enabled on the load balancer itself rather than on the backend service, leading candidates to select options that involve bucket creation or incorrect command syntax.
How to eliminate wrong answers
Option A is wrong because Identity-Aware Proxy (IAP) is an authentication and authorization layer that does not affect caching; enabling IAP does not allow or enable Cloud CDN. Option B is wrong because the --enable-cdn flag is applied to the backend service, not directly to the load balancer itself; the command syntax is gcloud compute backend-services update BACKEND_SERVICE_NAME --enable-cdn. Option D is wrong because creating a Cloud Storage bucket with public access is not required; Cloud CDN can be enabled on a backend service that uses a managed instance group as its backend, and the bucket is only one possible backend type.
A network engineer needs to create a private Google Kubernetes Engine (GKE) cluster with a secondary IP range for pods and another for services. They must ensure the pod CIDR does not conflict with any VPC subnets or on-premises ranges. Which step is essential during cluster creation?
Explicitly specifying ranges ensures they are from a non-conflicting CIDR block.
Why this answer
GKE clusters can specify secondary IP ranges for pods and services during creation. To avoid conflicts, the engineer must explicitly define these ranges using the --cluster-secondary-range-name and --service-secondary-range-name flags.
A company wants to connect two VPCs in different GCP projects so that they can communicate using internal IP addresses. The VPCs have overlapping IP ranges. Which approach allows connectivity without changing existing IP addresses?
GCP does not support direct connectivity between VPCs with overlapping IP ranges. You would need to re-IP one VPC or use NAT/translation.
An organization has Compute Engine instances in a VPC without external IP addresses. They need to allow these instances to access Google Cloud Storage buckets but not the internet. What should they configure?
Allows instances to reach Google APIs and services using internal IPs.
Why this answer
Private Google Access allows Compute Engine instances without external IP addresses to reach Google APIs and services, including Cloud Storage, through the VPC network's default route to the internet gateway, but only to Google's published IP ranges. This is the correct solution because it provides the required access without exposing the instances to the general internet.
How to eliminate wrong answers
Option B is wrong because Cloud NAT would provide outbound connectivity to the internet, which is explicitly not allowed, and it would also require a default route to the internet gateway, defeating the restriction. Option C is wrong because Google Cloud Storage does not expose a VPC that can be peered; it is a global service accessed via API endpoints, not through VPC peering. Option D is wrong because allowing traffic to 0.0.0.0/0 with a route to the default internet gateway would grant full internet access, which violates the requirement to block internet access.
A company is migrating its on-premises data center to Google Cloud. They currently have a Cloud VPN tunnel with dynamic routing (BGP) connecting their on-premises router (ASN 65001) to a Cloud Router in us-central1 (ASN 64512). The on-premises network uses IP range 10.0.0.0/8, and the Google Cloud VPC uses 172.16.0.0/12. After migration, they notice intermittent connectivity issues: traffic from on-premises to a new VM (172.16.1.2) is sometimes dropped, while other VMs in the same subnet work fine. The VM 172.16.1.2 is fine when accessed from other Google Cloud VMs. The team suspects asymmetric routing. Investigation shows that the on-premises router receives two routes for 172.16.1.2/32: one with next-hop as the Cloud VPN tunnel and another with next-hop as the internet (default route). No custom route advertisements are configured on the Cloud Router. The VPC has a default route (0.0.0.0/0) pointing to the internet gateway. What should the network engineer do to resolve the issue without breaking other connectivity?
This prevents the on-premises router from injecting a default route, eliminating the asymmetric routing issue.
Why this answer
The intermittent connectivity to 172.16.1.2 is caused by asymmetric routing: on-premises traffic uses the BGP-learned /32 route (via VPN) to reach the VM, but return traffic from the VM follows the VPC's default route (0.0.0.0/0) to the internet gateway, which drops the packet because the source IP is from the on-premises range. By configuring an inbound route filter on the Cloud Router to reject the BGP route 0.0.0.0/0 from the on-premises router, the on-premises router will no longer have a default route pointing to the VPN tunnel, forcing it to use the more specific /32 route for 172.16.1.2 and eliminating the asymmetric path.
Exam trap
The trap here is that candidates focus on the on-premises router's routing table (the /32 route) and assume the issue is on-premises, but the real problem is the VPC's default route causing asymmetric return traffic, which is resolved by filtering the BGP advertisement of 0.0.0.0/0 from the Cloud Router to the on-premises router.
How to eliminate wrong answers
Option B is wrong because enabling global routing does not affect route selection for a single VM, and creating a static route for 172.16.1.2/32 with next-hop as the VPN tunnel would not fix the root cause—the on-premises router already has a more specific /32 route via BGP, and the issue is the default route on the VPC side causing asymmetric return traffic. Option C is wrong because adding a second VPN tunnel from a different region does not address the asymmetric routing problem; it would only provide additional paths without resolving the conflicting default route. Option D is wrong because changing the Cloud Router's advertise-mode to 'custom' and advertising only subnets would not prevent the on-premises router from receiving the default route (0.0.0.0/0) from the VPC, which is the source of the asymmetric routing; the issue is inbound filtering on the Cloud Router, not outbound advertisement.
A company has a Shared VPC setup with a host project and several service projects. They want to grant a service project's network admin the ability to create VM instances using a specific subnet from the host project. Which IAM role should they assign at the subnet level?
This role grants permission to use the subnet for creating resources, which is the recommended approach.
Why this answer
Shared VPC allows granting IAM roles on individual subnets. The Compute Network User role (roles/compute.networkUser) allows a principal to use a subnet to create resources, without giving them broader network management permissions.
A company uses VPC Network Peering between VPC-A (project X) and VPC-B (project Y). They want resources in VPC-A to reach resources in VPC-B, but also need VPC-A to reach an on-premises network connected to VPC-B via Dedicated Interconnect. Which two steps must be configured?
Importing custom routes from VPC-B allows VPC-A to use those routes to reach on-premises.
Why this answer
By default, VPC peering is non-transitive, so VPC-A cannot reach on-premises through VPC-B. To enable this, VPC-B must export custom routes to VPC-A, and the on-premises network's routes must be learned via BGP on Cloud Router in VPC-B.
A financial company requires encrypted traffic between on-premise and GCP. They have strict compliance requiring that encryption keys are managed on-premise and rotated every 30 days. Which connectivity solution should they use?
MACsec provides encryption with customer-managed keys, easily rotated.
Why this answer
B is correct because MACsec (IEEE 802.1AE) provides encryption at Layer 2, which is required for Cloud Interconnect to secure traffic between on-premise and GCP. Unlike VPN solutions, MACsec allows the customer to manage encryption keys on-premise and rotate them every 30 days, meeting strict compliance requirements. Cloud Interconnect with MACsec ensures low-latency, high-bandwidth connectivity while keeping key management under the customer's control.
Exam trap
Google Cloud often tests the distinction between Layer 2 encryption (MACsec) and Layer 3 encryption (IPsec), and the trap here is that candidates assume Cloud VPN with IKEv2 or certificate-based authentication can satisfy on-premise key management, but GCP manages the IPsec keys, not the customer.
How to eliminate wrong answers
Option A is wrong because Cloud VPN with certificate-based authentication uses TLS/IPsec encryption, which is managed by GCP and does not allow the customer to control key rotation on-premise. Option C is wrong because Cloud VPN with IKEv2 and pre-shared keys uses IPsec encryption where keys are managed by GCP, not on-premise, and pre-shared keys are not rotated every 30 days by default. Option D is wrong because Cloud Interconnect with VLAN attachments provides Layer 2 connectivity but does not include encryption; it relies on the customer to implement encryption separately, which does not meet the requirement for encrypted traffic.
Option E is wrong because Partner Interconnect with a service provider that supports MACsec still requires the service provider to manage the MACsec keys, violating the compliance requirement that keys be managed on-premise.
A company wants to connect on-premise to GCP via Cloud VPN with dynamic routing. They have two on-prem routers for redundancy. Which configuration ensures automatic failover?
This allows BGP to automatically fail over traffic if one peer goes down.
Why this answer
Creating two VPN tunnels with Cloud Router using BGP and the same ASN on both on-prem routers enables dynamic routing and automatic failover. Cloud Router establishes BGP sessions with each on-prem router, and when both tunnels advertise the same routes with the same ASN, Cloud Router can detect a BGP session failure and automatically route traffic through the remaining healthy tunnel. This setup ensures seamless failover without manual intervention.
Exam trap
The trap here is that candidates often think different ASNs provide better redundancy, but in GCP Cloud Router, the same ASN is required for proper ECMP and automatic failover, as different ASNs can cause routing loops or incomplete failover.
How to eliminate wrong answers
Option A is wrong because static routes do not support dynamic failover; if one tunnel goes down, traffic continues to be sent to the failed tunnel until the static route is manually updated or a separate health-check mechanism is implemented. Option B is wrong because a single VPN tunnel with two interfaces does not provide redundancy; if the tunnel itself fails, both interfaces become unavailable, offering no failover. Option D is wrong because using different ASNs on each tunnel would cause the on-prem routers to be treated as separate BGP peers, preventing proper route advertisement and failover; Cloud Router expects the same ASN for redundant paths to correctly handle route selection and failover.
A company needs to resolve DNS queries for a private zone (e.g., corp.example.com) from multiple GCP projects that are not in the same organization. Which Cloud DNS feature should they use?
DNS peering enables cross-project DNS resolution.
Why this answer
DNS peering allows you to resolve DNS queries across different GCP projects, even if they are not in the same organization, by establishing a peering relationship between two VPC networks. This enables the private zone (corp.example.com) in one project to be queried from instances in another project without exposing the zone to the internet or requiring shared VPC.
Exam trap
A common misconception is that Shared VPC is required for cross-project DNS resolution, but the trap here is that DNS peering works across organizations without the organizational hierarchy constraint of Shared VPC.
How to eliminate wrong answers
Option A is wrong because Private DNS zones are scoped to a single VPC network within a project and cannot be directly accessed from projects outside the same organization without additional configuration like peering. Option B is wrong because DNS forwarding is used to send queries to an external DNS server (e.g., on-premises) from a VPC, not to resolve private zones across different projects. Option C is wrong because Shared VPC requires projects to be in the same organization and ties networking to a host project, which does not apply when projects are in different organizations.
A company is designing a hybrid network with Cloud VPN. Which TWO best practices should they follow? (Choose TWO.)
Pre-shared keys are the default authentication method for Cloud VPN.
Why this answer
Exam trap
The trap here is that candidates often assume static routes are simpler and therefore better for hybrid networks, but the PCNE exam emphasizes dynamic routing (BGP) for reliability and scalability, and they may also overlook the need for multiple tunnels for redundancy.
Correct. The public zone handles external queries.
Why this answer
Split-horizon DNS is achieved by having a public zone for external resolution and a private zone for internal resolution within the same domain.
A company plans to connect an on-premises network to Google Cloud using HA VPN with dynamic routing (BGP). The on-premises side supports BGP and has two independent routers for redundancy. The company wants to ensure failover within seconds if one tunnel goes down. Which configuration meets this requirement?
Regional redundancy plus independent BGP sessions enable fast failover via BGP route withdrawals and advertisements.
Why this answer
Deploying two Cloud VPN gateways in different regions with separate Cloud Routers ensures true regional redundancy. If one gateway or its tunnel fails, BGP sessions on the other gateway remain active, and Google Cloud's network can immediately route traffic via the surviving path. This architecture meets the sub-second failover requirement by avoiding a single point of failure at the gateway level and leveraging BGP's fast convergence.
Exam trap
The trap here is that candidates assume multiple tunnels from a single gateway provide sufficient redundancy, overlooking that the gateway itself is a single point of failure; Google Cloud's HA VPN gateway is regional, not zonal, so a regional outage can bring down all tunnels on that gateway.
How to eliminate wrong answers
Option B is wrong because using a single Cloud VPN gateway creates a single point of failure; if the gateway fails, both tunnels fail, violating the failover requirement. Option C is wrong because static routing with route metrics does not provide dynamic failover within seconds; BGP is required for fast convergence, and static routes rely on manual intervention or slow timer-based failover. Option D is wrong because a single Cloud Router with two tunnels to the same gateway still has a single point of failure at the gateway; if the gateway goes down, both tunnels are lost, and BGP sessions cannot failover.
Which TWO statements are true about VPC Network Peering? (Choose 2)
Custom route export is supported.
Why this answer
VPC Network Peering allows you to export custom routes (including static and dynamically learned routes) to a peered VPC by enabling the 'Export custom routes' option on the peering connection. Option B is correct because peering is non-transitive: traffic cannot flow through an intermediate VPC to reach a third VPC; each peering connection is direct and isolated. Options C, D, and E are incorrect: global routing mode is a VPC-level setting, not a peering property; peering is never transitive by default; and peered VPCs must have non-overlapping IP ranges to avoid conflicts.
Exam trap
The trap here is that candidates often assume VPC Network Peering is transitive (like in traditional networking) or that overlapping IP ranges are allowed, but GCP enforces non-transitivity and requires unique IP ranges to prevent routing conflicts.
An organization wants to implement a hub-and-spoke network topology in Google Cloud using VPC Network Peering. The hub VPC hosts shared services and the spoke VPCs host application workloads. They need to ensure that spokes can communicate with each other through the hub. Which additional configuration is required?
Using a managed VPN with dynamic routing (e.g., Cloud Router with BGP) allows the hub to advertise routes between spokes.
Why this answer
VPC Network Peering does not support transitive routing by default. To enable spoke-to-spoke communication through the hub, you must configure a managed VPN (Cloud VPN) between the hub and each spoke with dynamic routing (BGP). This creates a routed overlay that allows the hub to forward traffic between spokes, effectively achieving transitive routing.
Exam trap
The trap here is that candidates assume exporting/importing custom routes (Option B) can enable transitive routing, but VPC Network Peering explicitly forbids transitive routing regardless of route propagation settings.
How to eliminate wrong answers
Option B is wrong because exporting and importing custom routes only propagates static or dynamically learned routes between directly peered VPCs; it does not enable transitive routing through the hub because VPC Network Peering explicitly prohibits forwarding traffic from one peering connection to another. Option C is wrong because Shared VPC does not solve the transitive routing requirement; it centralizes subnet management but still uses VPC peering for cross-project connectivity, which lacks transitive routing. Option D is wrong because creating a peering connection between each pair of spokes creates a full mesh, not a hub-and-spoke topology, and does not satisfy the requirement of routing through the hub; it also increases management complexity and does not leverage the hub for centralized inspection or policy enforcement.
A company is designing a VPC network to support multiple projects that require isolation but also need to communicate with a shared services project. Which approach should the company use to minimize administrative overhead while ensuring isolation?
Centralizes network management and enforces isolation through subnets and firewall rules.
Why this answer
A Shared VPC (XPN) allows an organization to connect resources from multiple service projects to a common host project's VPC network, enabling isolated projects to communicate with shared services while centralizing network administration. This minimizes administrative overhead because network policies, firewall rules, and routing are managed in one place, and service projects do not need to manage their own VPC infrastructure.
Exam trap
The trap here is that candidates often confuse VPC peering with Shared VPC, assuming that peering provides the same centralized management, but peering requires per-connection configuration and does not allow a single host project to centrally administer subnets and firewall rules across all projects.
How to eliminate wrong answers
Option A is wrong because using a single VPC with separate subnets does not provide true project-level isolation; all projects would share the same VPC and IAM boundaries are blurred, increasing the risk of unintended access and complicating resource management. Option C is wrong because using dedicated VPCs connected via Cloud VPN tunnels introduces significant administrative overhead for tunnel configuration, routing, and maintenance, and does not scale efficiently for multiple projects. Option D is wrong because peering each project's VPC with a shared services VPC requires managing multiple peering connections, each with its own routing and firewall rules, which increases complexity and administrative burden compared to a single Shared VPC.
A company is planning to migrate to Google Cloud and needs to design a VPC network for a multi-tier application (web, app, database). Which THREE best practices should they follow? (Choose THREE.)
Segmentation improves security and manageability.
Why this answer
Separating each application tier into its own subnet allows you to apply VPC firewall rules to control ingress and egress traffic between tiers based on source and destination CIDR ranges or service accounts. This follows the principle of least privilege, ensuring that only necessary traffic (e.g., web-to-app on TCP port 8080, app-to-database on TCP port 3306) is permitted, while all other traffic is denied by default.
Exam trap
Google Cloud often tests the misconception that instance-level firewalls are a best practice for multi-tier security in GCP, but the correct approach is to use VPC firewall rules with subnet segmentation and service account or tag-based controls for centralized, scalable traffic management.
Drag and drop the steps to set up a Private Service Connect for accessing Google APIs privately into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Private Service Connect involves creating an endpoint, assigning IP, setting DNS, and testing.
A team is deploying a new service in a Compute Engine instance without an external IP in subnet-b. The service needs to access Google Cloud Storage using internal IPs. What must the team do to enable this?
Enables instances without external IP to reach Google APIs via internal IPs.
Why this answer
Private Google Access enables a Compute Engine instance without an external IP address to reach Google APIs and services (including Cloud Storage) over the internal VPC network using RFC 1918 addresses. By enabling this feature on subnet-b, the instance can access Cloud Storage via internal IPs without needing an external IP or NAT gateway. This is the correct and minimal configuration for the requirement.
How to eliminate wrong answers
Option A is wrong because assigning an external IP address would expose the instance to the internet, violating the requirement to use only internal IPs and introducing unnecessary security risk. Option B is wrong because moving the instance to subnet-a is not required; Private Google Access can be enabled on any subnet, including subnet-b, without moving resources. Option D is wrong because Cloud NAT is used for outbound internet access to non-Google services or for dynamic source IP translation, but Private Google Access directly provides internal IP access to Google APIs without NAT.
An organization is migrating on-premises workloads to GCP. They need a dedicated, high-bandwidth connection with a 99.99% SLA. They have a co-location facility near a Google Cloud region. Which connectivity option should they choose?
Dedicated Interconnect provides direct, dedicated connections with a 99.99% SLA when using redundant links.
Why this answer
Dedicated Interconnect provides direct physical connections (10G or 100G links) between on-premises and Google's network, offering a 99.99% SLA when using redundant connections.
You run the command shown in the exhibit. Your on-premises network is connected to your VPC via a Cloud Router with two BGP sessions. You notice that your on-premises network receives routes for only the two custom IP ranges (10.0.1.0/24 and 10.0.2.0/24) but not for other subnets in the VPC. What is the most likely cause?
With advertiseMode CUSTOM, the router only advertises the explicitly listed ranges, ignoring ALL_SUBNETS unless it is the only group. The advertisedGroups includes ALL_SUBNETS but since mode is CUSTOM, only custom ranges are advertised.
Why this answer
The Cloud Router's custom route advertisement configuration explicitly controls which routes are advertised to on-premises via BGP. If only the two custom IP ranges (10.0.1.0/24 and 10.0.2.0/24) are included in the custom advertisement, other VPC subnets will not be advertised, even if they exist. The exhibit shows that the on-premises network receives only those two ranges, which directly matches a custom advertisement setup rather than the default ALL_SUBNETS behavior.
Exam trap
The trap here is that candidates often assume BGP session establishment implies all routes are automatically exchanged, but Cloud Router's custom advertisement feature allows granular control over which prefixes are advertised, and the default ALL_SUBNETS behavior is not active when custom ranges are explicitly listed.
How to eliminate wrong answers
Option A is wrong because if the BGP interface IP addresses 169.254.x.x were unreachable, the BGP sessions would not establish at all, and no routes would be received—not just a subset. Option B is wrong because the BGP peer ASN 65001 is a private ASN commonly used in GCP Cloud Router configurations; if the on-premises router did not recognize it, the BGP session would fail to establish, again resulting in zero routes. Option C is wrong because if advertisedGroups included ALL_SUBNETS, the Cloud Router would advertise all VPC subnets by default; the router does not 'ignore' this setting due to misconfiguration—either it is set or it is not, and the observed behavior (only two ranges) indicates custom advertisement is in use.
An enterprise uses Shared VPC with a host project and multiple service projects. A service project team wants to create a Cloud VPN tunnel to their on-premises network. What must the network team configure in the host project to allow this?
Correct configuration; the networking resources are in the host project.
Why this answer
In a Shared VPC setup, the VPN gateway and Cloud Router must reside in the host project's VPC because the host project owns the underlying network infrastructure. The service project can then use the VPN tunnel by being granted the `compute.networkUser` role on the host project, which allows it to create forwarding rules and use the VPN resources. This ensures that the VPN termination point is within the shared VPC network, enabling connectivity to on-premises networks.
How to eliminate wrong answers
Option A is wrong because the service project cannot create a VPN gateway directly in its own project using a VPC peered with the host project; VPC peering does not support Cloud VPN termination, and the VPN gateway must reside in the host project's VPC. Option C is wrong because Cloud VPN is fully supported with Shared VPC; Dedicated Interconnect is a separate, higher-bandwidth option, not a requirement. Option D is wrong because both the Cloud Router and the VPN gateway must be created in the host project, not split between projects; the service project cannot host the Cloud Router for a VPN tunnel terminating in the host project.
A company is designing a hybrid network using Dedicated Interconnect. They want to achieve a 99.99% SLA for availability. Which THREE configurations are required to meet this SLA?
Each VLAN attachment provides a logical path.
A startup is setting up a new GCP project and needs to create a VPC that will have predictable IP ranges for future peering with other VPCs. They do not anticipate needing to grow the network beyond the initial IP range. Which VPC type should they choose?
Custom mode VPC provides full control over subnet IP ranges, avoiding overlap for peering.
Why this answer
Custom mode VPCs allow you to define your own subnets with specific IP ranges. Auto mode VPCs automatically create subnets in every region, which can cause IP overlap when peering. For controlled, predictable IP ranges, custom mode is appropriate.
Which IP address type in Google Cloud can communicate with the internet but is not reachable from the internet?
Internal IP addresses are private and not directly reachable from the internet.
An organization has a hybrid network with multiple BGP sessions between on-premises and GCP. They want to influence outbound traffic from GCP to prefer a specific path. Which BGP attribute should they adjust on the Cloud Router?
Local Preference influences outbound traffic from GCP by setting a preference for paths within the AS. A higher Local Preference on a Cloud Router session makes GCP prefer that path for outbound traffic. This is the correct attribute.
Why this answer
To influence outbound traffic from GCP (i.e., which path GCP uses to send traffic to on-premises), the correct BGP attribute is Local Preference. Local Preference is an attribute that influences the outbound path selection within the local AS. On Cloud Router, setting a higher Local Preference for a specific BGP session makes GCP prefer that path for outbound traffic.
MED, on the other hand, is used to influence inbound traffic to GCP by telling neighboring ASes which path to prefer.
Exam trap
A common mistake is confusing MED with Local Preference. MED influences how neighboring ASes choose paths for inbound traffic to GCP, while Local Preference influences outbound path selection from GCP. For controlling outbound traffic, adjust Local Preference on the Cloud Router.
How to eliminate wrong answers
Option B (Local Preference) is wrong because Local Preference is used to influence outbound traffic from the local AS (i.e., which path GCP uses to send traffic out), not to influence how other ASes route traffic into GCP; it is an attribute exchanged only within an AS, not advertised to neighbors. Option C (Next hop) is wrong because the Next hop attribute simply indicates the IP address of the next router to reach a destination; modifying it does not influence path selection preference for outbound traffic from GCP. Option D (AS Path prepend) is wrong because AS Path prepend makes a path less preferred by artificially lengthening the AS_PATH, which is used to influence inbound traffic from other ASes, but it is not the primary attribute for influencing outbound traffic from GCP; MED is more granular and directly controls path selection at the multi-exit point.
A company needs a dedicated, low-latency connection from their on-premises data center to GCP with a 10 Gbps capacity. They require the highest availability and service level agreement (SLA). Which connectivity option should they choose?
Dedicated Interconnect provides dedicated, low-latency connection with high SLA.
Why this answer
Dedicated Interconnect provides a direct, private connection between the on-premises data center and GCP with 10 Gbps capacity. By using two connections to different meet-me rooms, the company achieves the highest availability and meets the 99.99% SLA, as this eliminates single points of failure at the physical layer and within a single facility.
Exam trap
Google Cloud often tests the misconception that Partner Interconnect can match the SLA of Dedicated Interconnect, but the key trap is that Partner Interconnect's SLA is limited to the partner's network and does not cover the entire path from on-premises to GCP.
How to eliminate wrong answers
Option A is wrong because Carrier Peering uses a shared connection over the public internet, does not offer a 10 Gbps dedicated capacity, and provides no SLA for availability or latency. Option C is wrong because Partner Interconnect relies on a third-party provider's network, which introduces additional latency and does not offer the same 99.99% SLA as Dedicated Interconnect; two VLAN attachments from different providers still depend on the partner's infrastructure. Option D is wrong because Cloud VPN uses encrypted tunnels over the public internet, cannot guarantee 10 Gbps throughput (typically limited to ~3 Gbps per tunnel), and provides no SLA for latency or availability.
A company wants to resolve DNS queries from their on-premises network for Google Cloud private zones (e.g., example.internal) without duplicating DNS data. Which Cloud DNS feature should they use?
Inbound server policy enables on-premises resolvers to forward queries to Cloud DNS.
Why this answer
Cloud DNS inbound server policy allows on-premises DNS resolvers to forward queries to Cloud DNS for resolution of private zones. This avoids the need to replicate zone data on-premises.
Which THREE are valid considerations when planning IP address ranges for VPCs that will be connected via VPC Peering and Cloud VPN? (Choose 3)
Leaving space avoids renumbering later.
Why this answer
Avoid overlapping ranges, use RFC 1918 addresses, and ensure unique ranges for each subnet.
Which TWO of the following are true regarding VPC Network Peering? (Choose TWO.)
Overlapping IP ranges are not allowed in VPC peering.
Why this answer
VPC Network Peering requires that the subnet IP ranges of the peered VPCs do not overlap. Overlapping ranges would cause routing conflicts and ambiguous destination addresses, as GCP uses the subnet CIDR blocks to determine the next hop for traffic. If two VPCs have overlapping ranges, packets cannot be reliably forwarded to the correct destination, breaking the peering connection.
Exam trap
Google Cloud often tests the misconception that VPC Network Peering supports transitive routing or dynamic route exchange, leading candidates to select options B or C, when in fact peering is strictly non-transitive and only exchanges subnet and static routes.
A company is planning to connect their on-premises data center to Google Cloud using a Dedicated Interconnect. They require 20 Gbps of total bandwidth and want to achieve the highest SLA. What is the minimum number of 10 Gbps connections needed?
Two 10 Gbps links provide 20 Gbps total and meet the 99.99% SLA with redundancy.
Why this answer
Dedicated Interconnect offers 10 Gbps or 100 Gbps per link. To achieve 20 Gbps, at least two 10 Gbps links are needed. For the highest SLA (99.99%), two connections are required (one must be redundant).
A company uses Shared VPC with multiple service projects. They want to ensure that only specific service projects can use the Cloud NAT configured in the host project. What should they do?
This is the standard method to restrict Cloud NAT usage.
Why this answer
Cloud NAT can be restricted to specific VMs using network tags. By configuring the Cloud NAT gateway in the host project with a specific network tag, and then assigning that tag only to the VM instances in authorized service projects, only those tagged VMs can use the NAT gateway. This ensures that only specific service projects (via their tagged VMs) can leverage the Cloud NAT, while all other VMs in the shared VPC are excluded.
Exam trap
The trap here is that candidates often assume IAM is the correct way to restrict access to a Cloud NAT resource, but Cloud NAT does not have an IAM resource—it is a regional service that is controlled via network tags or subnet-level configuration, not IAM permissions.
How to eliminate wrong answers
Option B is wrong because firewall rules control traffic flow (allow/deny) based on IP addresses, ports, and protocols, but they cannot restrict which VMs can use a Cloud NAT gateway; Cloud NAT operates at the network address translation layer, not at the firewall rule level. Option C is wrong because VPC Service Controls are designed to protect data exfiltration by controlling access to Google Cloud APIs and services, not to manage which VMs can use a Cloud NAT gateway within a shared VPC. Option D is wrong because Cloud NAT does not have its own IAM resource; IAM roles on the Cloud NAT resource do not exist—Cloud NAT is a regional resource that is automatically used by VMs in the VPC, and access is controlled via network tags or subnet-level configuration, not IAM.
A company needs to connect multiple branch offices to GCP using Partner Interconnect. They need at least 99.9% availability and bandwidth between 50 Mbps and 10 Gbps. Which type of Partner Interconnect should they choose?
99.9% SLA meets the requirement and is typically sufficient for branch offices.
Why this answer
Partner Interconnect offers two SLA tiers: 99.9% for a single connection and 99.99% for dual connections. Since the requirement is at least 99.9% availability and bandwidth between 50 Mbps and 10 Gbps, a single connection with 99.9% SLA meets both criteria without the cost and complexity of dual connections.
Exam trap
The PCNE exam often tests the misconception that higher SLA numbers are always better, but the trap here is that the 99.99% SLA requires dual connections, which is overkill for a 99.9% requirement, and candidates may overlook the specific SLA tiers tied to connection redundancy.
How to eliminate wrong answers
Option A is wrong because a single connection with 99.99% SLA does not exist; the 99.99% SLA requires dual connections for redundancy. Option C is wrong because Classic VPN does not provide an SLA and typically offers lower bandwidth and reliability than Partner Interconnect, failing the 99.9% availability requirement. Option D is wrong because dual connections with 99.99% SLA exceed the minimum 99.9% requirement and add unnecessary cost and complexity; the question asks for the type that meets the requirement, not the highest SLA.
Refer to the exhibit. A company has enabled Private Google Access on the subnet. What effect does this have on VMs in the subnet?
Private Google Access enables access to Google APIs over internal IPs.
Why this answer
Private Google Access enables VMs in a subnet that have only internal IP addresses (RFC 1918) to reach Google APIs and services (e.g., Cloud Storage, BigQuery) through Google's internal network. The traffic is routed via the default internet gateway (which does not require an external IP on the VM) and uses a special 0.0.0.0/0 route with next hop 'default internet gateway' to reach Google's external IPs, but the VM itself never needs a public IP. This is why D is correct: VMs can access Google services using only internal IPs.
How to eliminate wrong answers
Option A is wrong because Private Google Access specifically allows VMs without external IPs to reach Google services; if a VM already has an external IP, it can reach Google services directly without needing Private Google Access. Option B is wrong because Cloud NAT is used to enable outbound internet connectivity for VMs without external IPs, but Private Google Access is a separate feature that only covers Google APIs and services, not general internet access. Option C is wrong because VM-to-VM communication within a subnet is governed by VPC firewall rules (ingress/egress), and Private Google Access has no effect on internal traffic between VMs.
A company is designing a VPC for a multi-tier web application. They need to ensure that the web servers can be reached from the internet, but the database servers should only be accessible from the web servers. Which three components should they use to achieve this? (Choose THREE.)
External IPs allow inbound internet traffic to web servers.
A company is setting up VPC peering between two VPCs. They need the peered VPC to be able to reach the entire subnets of their VPC, including those that may be added in the future. Which configuration is required?
Exporting custom routes advertises all custom routes (including future subnets) to the peered VPC.
Why this answer
Exporting custom routes from the VPC ensures that any future subnets (which create custom routes) are advertised to the peer.
Enables on-premises to query Cloud DNS for private zones.
Why this answer
The on-premises servers need to resolve DNS names of GCP VM instances using RFC 1918 addresses over a Cloud VPN connection. Configuring a Cloud DNS inbound server policy creates a VPC-wide inbound DNS endpoint (using an internal IP address) that on-premises DNS servers can forward queries to. This allows the on-premises DNS to send DNS requests for GCP private zone records (e.g., `vm-instance.c.example.internal`) directly to the Cloud DNS inbound endpoint, which then resolves the private RFC 1918 addresses of the VM instances.
Exam trap
The trap here is that candidates confuse inbound and outbound server policies, often selecting Option B (outbound) because they think 'forwarding to on-premises' is needed, but the requirement is for on-premises to query GCP, which requires an inbound endpoint.
How to eliminate wrong answers
Option A is wrong because using a public zone and the instance's external IP would expose the DNS records to the internet and require public IP addresses, contradicting the requirement to use RFC 1918 addresses. Option B is wrong because Cloud DNS outbound server policy is used to forward DNS queries from GCP VPCs to on-premises DNS servers, not the reverse direction needed here. Option C is wrong because DNS peering is used to allow DNS resolution between two GCP VPCs or between a GCP VPC and a service producer network; it does not support forwarding from an on-premises DNS server to Cloud DNS.
A request comes from IP 192.0.2.5, with origin region code 'US', and path '/admin/dashboard'. What will be the final action?
The request path starts with '/admin', matching rule 2000.
Why this answer
The request matches a rule with priority 2000 that denies traffic from IP 192.0.2.5 to path '/admin/dashboard' with origin region 'US'. Since Cloud Armor security policies evaluate rules in ascending priority order, rule 2000 is evaluated before rule 3000 and after rule 1000. Rule 1000 does not match (likely a different condition), so rule 2000 applies and denies the request.
Exam trap
Google Cloud often tests the misconception that rules are evaluated in descending priority order (e.g., 3000 before 2000) or that the default rule overrides explicit deny rules, when in fact the lowest numeric priority wins and evaluation stops at the first match.
How to eliminate wrong answers
Option A is wrong because priority 1000 is evaluated first but does not match the request (e.g., it might allow all traffic or match a different path/region), so it does not deny. Option C is wrong because priority 3000 is evaluated after priority 2000; once a match occurs at priority 2000, evaluation stops and rule 3000 is never reached. Option D is wrong because the default rule (allow) only applies if no higher-priority rule matches; here, rule 2000 matches and denies the request.
A company has two VPCs in the same project, VPC-A and VPC-B. They have set up VPC peering between them. In VPC-A, there is a subnet 10.0.1.0/24. In VPC-B, there are subnets 10.0.2.0/24 and 10.0.3.0/24. A compute instance in VPC-A can ping an instance in VPC-B with IP 10.0.2.10, but fails to ping an instance in VPC-B with IP 10.0.3.10. All subnets are in the same region. Firewall rules allow all traffic between VPC-A and VPC-B. What is the most likely cause?
Static routes have higher priority than peering routes, causing traffic to go elsewhere.
Why this answer
VPC peering routes are automatically added to the route tables of both VPCs when the peering is established. However, if a more specific static route (e.g., to 10.0.3.0/24) exists in VPC-A, it will take precedence over the peering route due to longest prefix match routing. Since the instance in VPC-A can reach 10.0.2.10 but not 10.0.3.10, the most likely cause is that VPC-A has a static route that preempts the peering route for the 10.0.3.0/24 subnet.
Exam trap
The trap here is that candidates often assume VPC peering automatically works for all subnets in the peered VPC, forgetting that static routes with more specific prefixes can override peering routes, even when firewall rules are permissive.
How to eliminate wrong answers
Option B is wrong because VPC peering is bidirectional by default; both VPCs export and import routes unless explicitly configured otherwise, and the question does not indicate any custom export/import settings. Option C is wrong because the question explicitly states that firewall rules allow all traffic between VPC-A and VPC-B, so ICMP is not blocked. Option D is wrong because VPC peering routes are dynamically updated when subnets are added or removed; there is no need to recreate the peering, as route propagation is automatic.
A company uses a Shared VPC with a host project and multiple service projects. They have deployed Cloud NAT in the host project's network to provide internet access for service project instances. The Cloud NAT is configured to use a network tag 'nat'. Instances in service projects that have the tag 'nat' can reach the internet. A new service project is added and its instances are created with the same tag 'nat' in a subnet in europe-west1. However, these instances cannot reach the internet. Other service project instances with the tag 'nat' in us-central1 work fine. The Cloud NAT is deployed in us-central1. What is the most likely cause?
Cloud NAT only works for instances in its region.
Why this answer
Cloud NAT is a regional resource; it only provides outbound internet access to instances within the same region. Since the Cloud NAT is deployed in us-central1, instances in europe-west1 cannot use it, regardless of their network tag. The instances in the new service project must have a Cloud NAT deployed in europe-west1 to reach the internet.
Exam trap
The trap here is that candidates assume Cloud NAT is a global resource or that network tags alone ensure connectivity, overlooking the critical regional scope of Cloud NAT and the fact that it must be deployed in the same region as the instances it serves.
How to eliminate wrong answers
Option A is wrong because UDP timeout settings affect the duration of NAT connections, not the ability to establish them across regions; a short timeout would cause dropped idle connections, not a complete lack of internet access. Option B is wrong because firewall rules in the host project control traffic at the network level, but Cloud NAT operates at the regional level and does not require explicit firewall rules for NAT traffic; the issue is regional mismatch, not firewall blocking. Option D is wrong because the question explicitly states the new instances are created with the same tag 'nat', so the tag is present; the problem is regional, not tag-related.
A company has Compute Engine instances without external IPs that need to access the internet for updates. They do not want any inbound traffic. What is the best design?
Meets both outbound access and inbound blocking requirements.
Why this answer
Cloud NAT provides outbound internet connectivity for instances without external IPs, and the explicit firewall rules ensure only necessary egress traffic is allowed while denying all ingress, meeting the requirement of no inbound traffic. Default firewall rules allow some ingress (e.g., ICMP), so they must be overridden with a deny-all-ingress rule to fully block inbound traffic.
How to eliminate wrong answers
Option A is wrong because default firewall rules allow certain ingress traffic (e.g., ICMP from RFC 1918 ranges), which violates the 'no inbound traffic' requirement. Option C is wrong because allowing all egress traffic is overly permissive and does not follow the principle of least privilege; the question implies only necessary egress (e.g., updates) should be allowed. Option D is wrong because denying all egress traffic would block the outbound updates the instances need, defeating the purpose of Cloud NAT.
Which TWO statements are true about VPC Network Peering?
Default limit is 25 peerings per VPC.
Why this answer
The default limit for VPC Network Peering per VPC is 25, as documented in Google Cloud's quotas and limits. This is a soft limit that can be increased by requesting a quota adjustment, but by default, each VPC can have up to 25 peerings. Option B is correct because VPC Network Peering allows direct communication between VPCs using RFC 1918 private IP addresses without requiring VPN tunnels or Cloud Interconnect, as the peering connection uses Google's internal network infrastructure.
Exam trap
The trap here is that candidates often assume firewall rules or custom routes are automatically shared across peered VPCs, but Google Cloud explicitly requires separate firewall rule management and manual route exchange configuration for custom routes.
HA VPN uses two gateways for redundancy.
Why this answer
Cloud VPN (D) is the correct service because it securely extends an on-premises network to a Google Cloud VPC over the public internet using IPsec VPN tunnels. It provides encrypted connectivity that matches the existing IPsec-based architecture, ensuring data confidentiality and integrity between the two sites.
How to eliminate wrong answers
Option A is wrong because Cloud Router is a BGP-based dynamic routing component that exchanges routes between a Cloud VPN tunnel and a VPC, not a connectivity service itself. Option B is wrong because Cloud Interconnect provides dedicated, high-bandwidth physical connections between on-premises and Google Cloud, but it does not inherently include IPsec encryption; encryption would require an additional overlay. Option C is wrong because VPC Network is the virtual network container within Google Cloud that defines subnets, routes, and firewall rules, not a service that establishes encrypted tunnels to on-premises networks.
Refer to the exhibit. A network engineer reviews the firewall rules in a VPC. What is the most significant security concern?
0.0.0.0/0 includes all public IPs, which is insecure.
Why this answer
Exam trap
Google Cloud often tests the misconception that a missing explicit deny rule is a security risk, but in GCP VPC, the implicit deny at the end of the rule evaluation makes an explicit deny unnecessary unless you need to override a higher-priority allow rule.
How to eliminate wrong answers
Option A is wrong because VPC firewall rules are implicitly deny-all at the end; a missing explicit deny rule is not a security concern as long as allow rules are properly scoped. Option B is wrong because RDP from 10.0.0.0/8 is a private RFC 1918 range, which is acceptable for internal administrative access and does not represent a significant security concern. Option D is wrong because VPC firewall rules are evaluated based on priority numbers, not order of creation; the lowest priority number wins, and there is no requirement for rules to be in a specific sequence.
A company is using a Classic VPN with static routing to connect to GCP. They need to add a new subnet in GCP and make it reachable from on-premises without manual configuration changes on-premises. What is the limitation of Classic VPN in this scenario?
Since Classic VPN uses static routing, new GCP subnets require adding static routes on-premises.
A network engineer is troubleshooting connectivity from a Compute Engine instance in subnet-a to a Google Cloud Storage bucket. The instance has no external IP address. Based on the exhibit, what is the most likely cause of the connectivity issue?
Private Google Access must be enabled for instances without external IPs to access Google APIs.
Why this answer
The instance has no external IP address, so it must use Private Google Access to reach Google APIs and services like Cloud Storage. Private Google Access is enabled at the subnet level; if it is disabled, the instance cannot route traffic to the Google API VIPs through the default route (0.0.0.0/0) without a NAT gateway or external IP. Option B correctly identifies this as the most likely cause.
Exam trap
The trap here is that candidates may assume a private subnet inherently blocks all external traffic, but Private Google Access is a separate, optional subnet setting that must be explicitly enabled for instances without external IPs to reach Google APIs.
How to eliminate wrong answers
Option A is wrong because the subnet purpose PRIVATE does not block Google APIs; it simply means the subnet is used for internal VPC traffic, and Private Google Access can still be enabled on it. Option C is wrong because the CIDR range size does not affect connectivity to Google APIs; it only limits the number of IP addresses available for instances. Option D is wrong because flow logs are a monitoring feature that capture metadata about traffic, but disabling them does not prevent connectivity; they are not required for traffic to flow.
Which THREE factors should be considered when designing a Cloud VPN for high availability? (Choose 3.)
BGP allows automatic route advertisement and failover.
Why this answer
Enabling BGP (Border Gateway Protocol) for dynamic routing is correct because it allows the Cloud VPN to automatically detect and route around failures. BGP exchanges route information between the on-premises router and the Cloud Router, enabling dynamic failover and load balancing across multiple tunnels. Without BGP, you would rely on static routes, which cannot adapt to network changes and require manual intervention during a failure.
Exam trap
The trap here is that candidates often think static routes with a higher metric can provide failover, but they fail to realize that static routes cannot dynamically detect a tunnel failure unless combined with a health check mechanism, which is not as reliable or fast as BGP's built-in path selection and withdrawal.
A company is planning a hybrid connectivity solution with 200 Gbps total bandwidth between their data center and Google Cloud. They need the highest SLA and lowest latency. Which combination of services would meet these requirements?
Two 100 Gbps connections provide 200 Gbps bandwidth and meet the highest SLA (99.99%) and lowest latency.
Why this answer
Dedicated Interconnect provides up to 100 Gbps per link. To achieve 200 Gbps, they need two 100 Gbps connections. Two connections provide redundancy and the 99.99% SLA.
Which TWO of the following are benefits of using Shared VPC?
Service project VMs automatically communicate using host project's routes.
Why this answer
Shared VPC allows an organization to connect resources from multiple projects to a common VPC network, enabling automatic cross-project routing. This is because all subnets in the host project are directly reachable from any service project attached to that host, without needing additional VPC peering or VPN tunnels. Option B is correct because this inherent routing simplifies network connectivity and reduces administrative overhead.
Exam trap
Google Cloud often tests the misconception that Shared VPC inherently provides security features like VPC Service Perimeters, when in fact those are separate controls; the trap here is confusing the administrative separation of network and application teams as a direct benefit of Shared VPC, rather than recognizing that the core technical benefit is automatic cross-project routing and centralized firewall rule management.
A startup is migrating a two-tier application to GCP. The web tier must be accessible from the internet, and the database tier must only be accessible from the web tier. Which network design should be used?
This design provides proper segmentation and security.
Why this answer
It places the web servers in a public subnet with external IPs, allowing direct internet access, while the database resides in a private subnet with no external IP, enforcing isolation. A firewall rule (ingress on the database subnet) explicitly permits traffic from the web subnet’s CIDR range, typically on the database port (e.g., TCP 3306 for MySQL), ensuring the database is reachable only from the web tier. This design follows GCP’s best practice of using VPC firewall rules to control east-west traffic between subnets.
Exam trap
Google Cloud often tests the misconception that placing resources in the same subnet automatically allows isolation via firewall rules, but in GCP, firewall rules are applied at the instance level (via tags or service accounts) and cannot restrict traffic between instances in the same subnet without additional tagging, leading candidates to incorrectly choose Option C.
How to eliminate wrong answers
Option B is wrong because placing both tiers in separate VPCs with VPC peering and no firewall rules would allow unrestricted traffic between the VPCs (peering does not impose default deny), violating the requirement that the database be accessible only from the web tier. Option C is wrong because placing both tiers in the same subnet would give the database the same network access as the web servers, making it impossible to restrict database access to only the web tier using subnet-level firewall rules (firewall rules in GCP are applied at the subnet or instance level, but same-subnet traffic is not easily isolated without complex per-instance tags). Option D is wrong because placing web servers in a private subnet with Cloud NAT only provides outbound internet access, not inbound; the web tier would not be accessible from the internet, failing the requirement that the web tier must be internet-accessible.
A company has multiple projects that each need their own administrative control but must share a common VPC network. Which networking solution should they use?
Provides centralized network management with per-project resource control.
Why this answer
Shared VPC allows an organization to connect resources from multiple projects to a common VPC network, enabling centralized control of the network while maintaining administrative isolation for each project. The host project owns the VPC and firewall rules, and service projects can use subnets within that VPC, meeting the requirement for separate administrative control with a shared network.
Exam trap
The trap here is that candidates often confuse VPC peering (Option D) with Shared VPC, not realizing that peering does not allow a single common VPC network and lacks centralized administrative control, while Shared VPC is designed exactly for this use case.
How to eliminate wrong answers
Option A is wrong because granting all users access to a single project eliminates administrative isolation, as all users would have project-level permissions, not per-project control. Option B is wrong because creating separate VPCs and connecting via Cloud VPN introduces complexity, latency, and bandwidth limitations, and does not provide a single common VPC network; it creates multiple networks that are bridged. Option D is wrong because VPC peering does not support transitive routing and requires non-overlapping CIDR ranges, making it unsuitable for a shared network with multiple projects that need to communicate through a common VPC; it also does not allow centralized firewall or subnet management.
Handles external queries.
Why this answer
Split-horizon DNS is achieved by having a private zone for internal resolution and a public zone for external resolution, both authoritative for the same domain.
A company has two VPCs (Prod and Dev) that are peered. Both VPCs have routes to an on-premises network via separate Cloud VPN tunnels. The on-prem network has routes to both VPCs. The Dev VPC recently added a subnet that overlaps with an on-prem subnet. What is the likely impact on the Prod VPC?
Overlapping subnets cause routing issues for Dev VPC to on-prem.
Why this answer
When the Dev VPC adds a subnet that overlaps with an on-premises subnet, Cloud VPN routes for that overlapping prefix become ambiguous. GCP Cloud Router uses dynamic routing (BGP) and will prefer the more specific route, but if the prefixes are identical, the route to the on-premises network via the Dev VPN tunnel may be withdrawn or become unreachable due to the conflict. This directly impacts the Dev VPC's ability to communicate with the on-premises network over the VPN, while the Prod VPC, with its non-overlapping subnet, remains unaffected.
Exam trap
The trap here is that candidates might think that an overlapping subnet in one VPC will break VPN connectivity for all peered VPCs. However, in Google Cloud, each VPC has its own Cloud VPN tunnel and Cloud Router, so only the VPC with the overlapping subnet loses connectivity to the on-premises network. The Prod VPC remains unaffected.
How to eliminate wrong answers
Option A is wrong because overlapping subnets between a VPC and an on-premises network cause routing conflicts that disrupt connectivity for the VPC with the overlap, so there is an impact. Option B is wrong because the Prod VPC has its own separate Cloud VPN tunnel and routes to the on-premises network, and the overlap in the Dev VPC does not affect Prod's routes or connectivity. Option C is wrong because VPC peering already enables direct communication between Prod and Dev VPCs; routing traffic via on-premises would be unnecessary and is not automatically enabled by the overlap—in fact, overlapping subnets would break such a path.
A company wants to resolve DNS queries from their on-premises DNS servers for a private zone hosted in Cloud DNS. They also need GCP resources to resolve on-premises hostnames. Which combination of Cloud DNS features should they configure?
Inbound allows on-premises to query Cloud DNS; outbound allows GCP to query on-premises DNS.
Why this answer
Inbound DNS server policy allows on-premises to forward queries to Cloud DNS private zones. Outbound DNS server policy allows GCP to forward queries to on-premises DNS servers.
A company uses a Shared VPC host project with three service projects: Prod, Staging, and Dev. All service projects have similar network requirements except that Prod requires Private Google Access to access Google APIs from VM instances without external IP addresses. The network team creates a single subnet in the Shared VPC with Private Google Access enabled. However, Staging and Dev teams report that their VMs cannot reach external IP addresses on the internet because the subnet's route has a next hop of default internet gateway. What is the most cost-effective solution that meets all requirements?
Cloud NAT provides internet access to VMs without external IPs; Private Google Access remains enabled for Prod. This is cost-effective because Cloud NAT shares IPs across multiple VMs.
Why this answer
Cloud NAT provides outbound internet connectivity for VM instances without external IP addresses, which is exactly what Staging and Dev need. Since Private Google Access is already enabled on the shared subnet, Prod VMs can reach Google APIs without external IPs, while Cloud NAT handles the general internet access for the other projects. This is the most cost-effective solution because Cloud NAT incurs only egress data processing charges and does not require additional subnets or complex routing changes.
Exam trap
The trap here is that candidates confuse Private Google Access with general internet access, assuming that enabling it on a subnet automatically allows VMs to reach any external IP, when in fact Private Google Access only covers Google API and service endpoints, not arbitrary internet destinations.
How to eliminate wrong answers
Option A is wrong because creating separate subnets for each service project increases IP address consumption and management overhead, and it does not solve the outbound internet access issue for Staging and Dev VMs without external IPs—they still lack a route to the internet. Option B is wrong because enabling Private Google Access on all subnets does not provide outbound internet access; Cloud Router with BGP advertising a default route would require a VPN or Dedicated Interconnect to an on-premises router, which is not cost-effective and is unnecessary for simple internet access. Option D is wrong because disabling Private Google Access on the shared subnet would break Prod's requirement to access Google APIs from VMs without external IPs, and creating a separate Prod subnet with Private Google Access enabled does not address the outbound internet need for Staging and Dev.
A company is planning a hybrid connectivity strategy between their on-premises data center and GCP. They require at least 99.9% availability and are open to using a third-party service provider. Which TWO options meet these requirements? (Choose TWO.)
Dedicated Interconnect offers 99.9% SLA for a single connection, but it does not use a third-party provider. However, the scenario says 'open to using' but not required. So it still meets the SLA requirement.
Why this answer
Partner Interconnect with two connections offers 99.99% SLA, but a single connection offers 99.9%. HA VPN with two tunnels offers 99.99% SLA, but the scenario requires at least 99.9%, so any option meeting that is acceptable. Dedicated Interconnect with one connection offers 99.9% SLA, but it's not via a third-party provider.
Classic VPN does not have a 99.9% SLA.
A company has a VPC with several subnets and wants to force traffic between two specific subnets (A and B) to be inspected by a third-party firewall appliance in a separate subnet (C). The firewall has source/destination check disabled. What is the best way to route traffic from A to B through C?
Policy-based routes can match source and destination and redirect to a next hop.
Why this answer
Policy-based routes allow you to define a forwarding rule that matches traffic based on source and destination IP ranges, then sends it to a next-hop instance (the firewall). Since the firewall has source/destination check disabled, it can forward the inspected traffic to the final destination. This is the only option that directly forces traffic between subnets A and B through the firewall in subnet C.
Exam trap
Google Cloud often tests the distinction between policy-based routes (which match on source and destination) and static routes (which match only on destination), leading candidates to incorrectly choose a custom static route (Option B) when a policy-based route is required.
How to eliminate wrong answers
Option A is wrong because Cloud NAT is used for outbound internet access from private instances, not for routing traffic between subnets within a VPC. Option B is wrong because a custom route with lower priority would only affect traffic destined for the subnet's IP range if no more specific route exists; it does not force traffic through a specific next-hop instance for inter-subnet communication. Option C is wrong because VPC flow logs only capture metadata about network flows for monitoring and analysis; they do not influence routing decisions.
An organization is deploying a global application and wants to use an Internal Load Balancer (ILB) across multiple regions. What is the correct configuration?
Regional ILBs combined with DNS provide global internal load balancing.
Why this answer
Google Cloud does not support a native cross-region Internal Load Balancer (ILB). To distribute traffic across multiple regions, you must deploy a separate Internal TCP/UDP Load Balancer in each region and use DNS-based routing (e.g., Cloud DNS with geo-routing or weighted record sets) to direct clients to the appropriate regional ILB. This approach provides regional high availability and global reach without exposing internal IPs externally.
Exam trap
Google Cloud often tests the misconception that 'global access' can make an Internal Load Balancer cross-region, but in Google Cloud, global access only allows clients from any region within the same VPC to reach a regional ILB, not to load balance across regions.
How to eliminate wrong answers
Option A is wrong because there is no 'cross-region ILB' in Google Cloud; Internal Load Balancers are regional resources and cannot be made global by enabling 'global access' (that feature applies only to external load balancers). Option B is wrong because routing traffic via Cloud VPN from a single-region ILB to other regions adds latency, complexity, and defeats the purpose of a global application; it does not provide native multi-region load balancing. Option D is wrong because a global External Load Balancer with internal backends is not supported; external load balancers require backends with external connectivity or specific hybrid connectivity, and using them for internal-only traffic violates the requirement for an internal load balancer.
Drag and drop the steps to create a VPC with custom subnet mode in Google Cloud into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Custom subnet mode requires manual subnet creation. The steps include naming the VPC, selecting custom mode, and defining subnets.
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.)
DNS peering allows a source project to resolve queries from a target project's private zone.
Why this answer
DNS peering allows a zone to be shared from one project to another. Shared VPC can also enable DNS resolution if the private zone is attached to the shared VPC host project and service projects use that VPC. However, DNS peering is more direct.
Outbound forwarding is for on-premises resolution, not cross-project. Inbound forwarding is for on-premises to Cloud DNS. Private zones are per-project and don't automatically resolve cross-project.
A company is planning to use Partner Interconnect to connect their on-premises network to GCP. Which TWO of the following are characteristics of Partner Interconnect?
Correct. Like Dedicated Interconnect, Partner Interconnect uses VLAN attachments.
Why this answer
Partner Interconnect supports bandwidth from 50 Mbps to 10 Gbps and provides a 99.9% or 99.99% SLA depending on configuration. It does not require colocation facility presence; the partner handles that.
A company has a VPC with three subnets and multiple firewall rules. They want to ensure that the most specific firewall rule takes precedence when there is a conflict. What is the default evaluation order of firewall rules?
Lower priority number = higher priority; rules are evaluated from high to low priority.
Why this answer
In Google Cloud Platform (GCP) VPC firewall rules, the default evaluation order is based on priority. Each rule is assigned a priority number from 0 to 65535 (lower number = higher priority), and rules are evaluated from highest priority (lowest number) to lowest priority. When multiple rules match traffic, the rule with the highest priority (lowest priority number) is applied first, and its action (allow/deny) is definitive; lower-priority rules are not evaluated for that traffic.
Exam trap
Google Cloud often tests the misconception that firewall rules are evaluated based on specificity (most restrictive wins) or creation order, but GCP explicitly uses a numeric priority system where lower numbers take precedence, not the breadth of the rule's match criteria.
How to eliminate wrong answers
Option A is wrong because GCP firewall rules do not have a default evaluation order based on direction (ingress vs. egress); both ingress and egress rules are evaluated independently using their priority numbers, and there is no inherent precedence of one direction over the other. Option C is wrong because GCP does not use rule restrictiveness (e.g., smaller IP range) as the default tiebreaker; instead, the priority number explicitly determines evaluation order, and if two rules have the same priority, the behavior is undefined (conflict resolution is not based on range size). Option D is wrong because GCP firewall rules are not evaluated in the order they were created; creation order has no effect on evaluation—only the priority field dictates the sequence.
A company is planning to connect multiple VPCs in different projects to a common on-premises network using a hub-and-spoke topology. They want to use Network Connectivity Center (NCC). Which TWO components are required to set up this topology?
The hub is the central routing entity in NCC.
Why this answer
NCC uses a hub (NCC hub) and spokes (VPC spokes). Spokes are VPCs that connect to the hub. The hub acts as a central point for routing.
An organization wants to design IP addresses for their GCP VPC that will be peered with an on-premises network using 10.0.0.0/8. Which subnet IP range should they avoid to prevent overlap?
10.1.0.0/16 is a subset of 10.0.0.0/8, so it overlaps with the on-premises network and must be avoided.
Why this answer
Both option A (10.1.0.0/16) and option C (10.0.0.0/8) overlap with the on-premises network using 10.0.0.0/8. Option A is a subset, and option C is the exact same range. Peering requires non-overlapping CIDR blocks, so both must be avoided.
Exam trap
The trap is that candidates often think only an exact match (10.0.0.0/8) would cause overlap, but any subnet within that range (like 10.1.0.0/16) also overlaps and must be avoided.
How to eliminate wrong answers
Option B (192.168.0.0/16) is wrong because it is a private IPv4 range (RFC 1918) that does not overlap with 10.0.0.0/8, so it is safe to use for the VPC. Option C (10.0.0.0/8) is wrong because it is the exact same range as the on-premises network, causing a complete overlap and making peering impossible. Option D (172.16.0.0/12) is wrong because it is another RFC 1918 private range (172.16.0.0 to 172.31.255.255) that does not intersect with 10.0.0.0/8, so it is also safe.
Ready to test yourself?
Try a timed practice session using only Pcne Designing Network questions.