75 of 97 questions · Page 1/2 · Network Services Config topic · Answers revealed
Drag and drop the steps to set up a Google Cloud Armor security policy for a backend service into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Security policy creation involves defining rules, setting default action, and attaching to a backend service. Testing ensures correct enforcement.
Drag and drop the steps to set up a Cloud Interconnect connection for dedicated on-premises connectivity into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
You are configuring an SSL Proxy load balancer for HTTPS traffic. The backend service points to an instance group with a self-managed certificate. The load balancer's frontend uses a Google-managed certificate. Clients receive SSL errors indicating certificate mismatch. What is the most likely cause?
Google-managed certificates require domain verification; if not verified, the certificate may not issue, causing mismatch.
Why this answer
When a Google-managed certificate is used on the frontend of an SSL proxy load balancer, the domain must be verified via DNS or a challenge file. If the domain is not verified, the certificate cannot be provisioned or validated, causing a mismatch between the certificate's Subject Alternative Names (SANs) and the domain clients are connecting to, resulting in SSL errors.
Exam trap
Google Cloud often tests the distinction between frontend and backend certificate validation, and candidates mistakenly think a backend certificate issue (like not being signed by a public CA) would cause frontend client errors, when in fact the frontend certificate mismatch is caused by domain verification failure for the Google-managed certificate.
How to eliminate wrong answers
Option A is wrong because requiring TLS 1.3 only does not cause a certificate mismatch; it would instead cause handshake failures for clients using older TLS versions. Option C is wrong because a backend self-managed certificate not signed by a public CA would cause backend SSL errors, not frontend client-side certificate mismatch errors. Option D is wrong because the backend service does not need to use a Google-managed certificate; it can use a self-managed certificate, and the frontend certificate mismatch is independent of the backend certificate type.
Why this answer
Port exhaustion occurs when the NAT gateway runs out of available source ports to map outbound connections. Increasing the number of NAT IP addresses assigned to the gateway multiplies the available port range (each IP provides 64,512 ports), directly alleviating port exhaustion during peak traffic. This is the standard mitigation for port exhaustion in Cloud NAT.
Exam trap
Google Cloud often tests the misconception that reducing NAT gateways or changing NAT type solves port exhaustion, when the actual solution is increasing the number of NAT IP addresses to expand the available port range.
How to eliminate wrong answers
Option A is wrong because changing the NAT type from standard to public is not a valid concept in Cloud NAT; Cloud NAT is always public-facing, and this option reflects a misunderstanding of NAT types. Option B is wrong because TCP keepalive helps maintain idle connections but does not increase the port pool or prevent port exhaustion; it may even delay port release. Option C is wrong because reducing the number of NAT gateways in the region would decrease the total available port capacity, worsening port exhaustion rather than mitigating it.
A company has deployed an HTTP load balancer with a backend service configured to use an unmanaged instance group. Users report that traffic is not reaching the backend instances. The backend instances are healthy and have proper firewall rules allowing traffic from the load balancer. What step should the network engineer take to resolve the issue?
Health check probes must be permitted by firewall rules to validate backend health.
Why this answer
The most likely issue is that firewall rules are not allowing health check probes from the load balancer's health check ranges. Option C is correct because health check probes must be allowed by a firewall rule for the load balancer to consider instances healthy. Option A is unnecessary because the load balancer VIP is not a destination route; Option B is not needed if health checks are already configured; Option D would give instances external IPs, defeating the purpose of internal load balancing.
A company is using Cloud NAT to allow private instances to access the internet. They notice that some instances are not able to reach certain external services. Which THREE steps should they take to troubleshoot?
Why this answer
Option A is correct because Cloud NAT uses a set of public IP addresses for outbound traffic. If the external service has firewall rules or access control lists that block these specific IP addresses, the instances will be unable to reach it. Checking for IP-based blocking is a standard first step in troubleshooting connectivity issues through a NAT gateway.
Your organization has an internal HTTP load balancer (ILB) in us-central1. The backend service is a managed instance group with a health check on port 8080. Recently, some instances are reported as unhealthy despite the application running fine. What is the most likely cause?
Health check probes come from Google's probe IPs, not from within the VPC.
Why this answer
Option A is correct because the firewall rule for health check sources must allow traffic from the GCP health check IP ranges (35.191.0.0/16, 130.211.0.0/22). If only allowing traffic from the VPC, health checks fail. Option B is wrong because the load balancer does not interfere with health check source IPs.
Option C is wrong because preemptible VMs are still healthy if app runs. Option D is wrong because the health check firewall rule must be separate from VPC internal traffic.
A company wants to protect their application behind an external HTTP(S) load balancer from SQL injection attacks. Which Cloud Armor feature should be used?
WAF rules include signatures for SQL injection and other common web attacks.
Why this answer
Pre-configured WAF rules in Cloud Armor include a SQL injection (SQLi) rule that inspects HTTP(S) request bodies, headers, and URIs for SQL injection patterns. This rule uses a set of signatures to detect and block malicious SQL queries, directly addressing the requirement to protect against SQL injection attacks on an external HTTP(S) load balancer.
Exam trap
Google Cloud often tests the misconception that IP-based controls (allowlist/denylist or named IP lists) can protect against application-layer attacks like SQL injection, but these features operate at Layer 3/4 and cannot inspect HTTP payloads.
How to eliminate wrong answers
Option A is wrong because IP allowlist/denylist only controls access based on source IP addresses and cannot inspect application-layer payloads for SQL injection patterns. Option C is wrong because Named IP address lists are simply a way to group IP addresses for use in firewall rules or allowlist/denylist policies, not a mechanism for content inspection. Option D is wrong because Rate limiting only restricts the number of requests from a client over a time window and does not analyze request content for SQL injection signatures.
Refer to the exhibit. A DNS managed zone is configured with private visibility and associated with a VPC network. A Compute Engine instance in a different VPC network tries to resolve 'test.example.com' but fails. What is the most likely reason?
The zone only resolves queries from vpc1; other VPCs are not authorized.
Why this answer
Private zones only respond to queries from authorized VPC networks. The instance is in a different VPC, so resolution fails.
Your company has a hybrid cloud architecture with two on-premises data centers: DC1 and DC2. Each DC is connected to Google Cloud via separate Cloud VPN tunnels (tunnel1 from DC1, tunnel2 from DC2) to a VPC in us-west1. The VPC has two subnets: subnet-a (10.0.1.0/24) and subnet-b (10.0.2.0/24). DC1 has a subnet 192.168.1.0/24 and DC2 has 192.168.2.0/24. You configure BGP on both tunnels with the VPC dynamic routing, and each on-premises router advertises its local subnet. The VPC automatically imports the learned routes. You notice that traffic from DC1 to an instance in subnet-a (10.0.1.5) works, but traffic from DC2 to the same instance fails intermittently. Additionally, traffic from DC2 to DC1 (192.168.1.0/24) fails completely. You check the route tables and see that both tunnels have learned the routes for the remote subnets. What is the most likely cause and solution?
Separate Cloud Routers allow fine-grained control over route priority, preventing asymmetric routing.
Why this answer
The issue is that both Cloud VPN tunnels are using the same Cloud Router, causing BGP to learn identical routes for the on-premises subnets from both tunnels. This leads to asymmetric routing and potential black-holing, especially when traffic from DC2 to DC1 or to subnet-a is routed via DC1's tunnel due to equal-cost multi-path (ECMP) or default BGP tie-breaking. By configuring separate Cloud Routers with different BGP priorities (MED or local preference), you can force traffic from each DC to use its own tunnel, ensuring symmetric routing and consistent connectivity.
How to eliminate wrong answers
Option A is wrong because creating a new VPN tunnel to a different VPC and using VPC peering adds unnecessary complexity and does not address the root cause of route conflict between the two tunnels; the problem is within the same VPC. Option B is wrong because increasing MTU addresses fragmentation issues, which would manifest as packet drops or performance degradation, not intermittent or complete connectivity failures for specific traffic flows. Option D is wrong because disabling dynamic routing and using static routes would remove the learned routes for remote subnets, breaking connectivity entirely, and would not resolve the asymmetric routing caused by BGP route propagation.
A service provider uses a Shared VPC with multiple service projects. The host project has a Cloud NAT configured for subnet 10.1.0.0/24 to provide outbound internet access to all service projects using that subnet. A new service project needs to use its own Cloud NAT for its VM instances in subnet 10.1.0.0/24 to meet compliance requirements. The network engineer attempts to create a Cloud NAT in the service project for that subnet but receives an error that the subnet already has a NAT gateway. What action should the engineer take to meet the compliance requirement?
This removes the conflict and allows the service project to manage its own NAT.
Why this answer
Option B is correct because a subnet can have only one NAT gateway associated. To use a different NAT for the service project, the host project's NAT must be removed from that subnet first, then the service project's NAT can be created. Option A is impossible due to the conflict.
Option C (VPC peering) would not allow the service project to have its own NAT on the same subnet. Option D (proxy instance) is not a native solution and introduces management overhead.
A company uses Private Service Connect (PSC) to access a managed SaaS application published by another company. The SaaS provider publishes a service attachment in their VPC. Which resource must the consumer create to connect to the service?
The consumer creates an endpoint to connect to the producer's service.
Why this answer
When a consumer wants to connect to a managed SaaS application published via Private Service Connect (PSC), they must create a Private Service Connect endpoint in their own VPC. This endpoint is a regional resource that uses an internal IP address from the consumer's VPC and establishes a connection to the service attachment published by the provider. The endpoint effectively makes the SaaS service accessible as if it were a resource inside the consumer's VPC, without requiring public IPs or VPNs.
Exam trap
Google Cloud often tests the distinction between who creates which resource — candidates mistakenly think the consumer creates the service attachment (Option A) because they confuse it with the endpoint, but the service attachment is always created by the provider.
How to eliminate wrong answers
Option A is wrong because a service attachment is created by the service provider (the SaaS company) to publish their service, not by the consumer. Option B is wrong because an internal forwarding rule is used within a VPC to route traffic to a backend service (e.g., a load balancer), but it does not directly connect to a PSC service attachment; the PSC endpoint itself handles the forwarding. Option C is wrong because a Cloud VPN tunnel is used for site-to-site or remote access connectivity between on-premises networks and Google Cloud, not for connecting to a published PSC service.
A company runs a private GKE cluster in us-central1. Pods need to access the internet for updates. Which configuration is required?
Cloud NAT provides outbound internet access for private instances.
Why this answer
In a private GKE cluster, nodes do not have external IPs, so pods cannot reach the internet directly. Cloud NAT provides outbound connectivity by translating private IPs to a public IP, allowing pods to fetch updates while keeping the cluster private. This is the standard solution for outbound-only internet access from private GKE clusters.
Exam trap
Google Cloud often tests the misconception that private clusters can reach the internet via default routes or firewall rules alone, but the trap here is that without Cloud NAT or a public IP, private instances have no path to the internet because the VPC's default route only covers internal ranges.
How to eliminate wrong answers
Option A is wrong because network tags control firewall rules for ingress/egress traffic within a VPC, but they do not provide internet connectivity; without a public IP or NAT, egress traffic to the internet is still blocked. Option B is wrong because Cloud Router with BGP peering is used for dynamic routing between on-premises and GCP, not for providing internet access to private instances. Option D is wrong because assigning external IPs to nodes would expose them to the internet, defeating the purpose of a private cluster and violating security best practices; Cloud NAT is the correct approach to avoid public IPs on nodes.
A company uses Cloud NAT to enable outbound internet access for private instances in a VPC. They notice that some instances are unable to connect to external services, while others can. The network team has verified that all instances have the same tags and are in the same subnet. Which TWO actions should the team take to troubleshoot the issue?
Port exhaustion can cause connection failures; Cloud NAT logs show when ports are depleted.
Why this answer
Option B is correct because Cloud NAT logs can reveal port exhaustion, which occurs when the NAT gateway runs out of available source ports for connections. Since all instances share the same NAT IP addresses, high connection counts from some instances can exhaust ports, preventing others from establishing new outbound connections. Checking these logs helps identify whether port exhaustion is the root cause of the connectivity issue.
VPC Flow Logs sample and log network flows with metadata.
Why this answer
VPC Flow Logs capture metadata about IP traffic flowing to and from network interfaces in a VPC, including source/destination IPs, protocols, and ports. This feature is designed specifically for analyzing traffic patterns and troubleshooting connectivity issues at the network layer, making it the correct choice for the described requirement.
Exam trap
Google Cloud often tests the distinction between metadata logging (VPC Flow Logs) and full packet capture (Packet Mirroring), leading candidates to choose Packet Mirroring when only summary traffic information is needed.
How to eliminate wrong answers
Option A is wrong because Packet Mirroring copies the actual packet payload (full packet capture) for deep inspection, not just metadata like IPs and ports, and is typically used for security appliances or intrusion detection, not for lightweight traffic pattern analysis. Option C is wrong because Cloud Audit Logs record administrative actions and API calls (e.g., who created a VM), not network packet-level details such as IPs, protocols, or ports. Option D is wrong because Firewall Rules Logging logs only traffic that is allowed or denied by firewall rules, and it does not capture all packets sent/received by a VM; it is rule-centric, not interface-centric.
A company wants to securely connect an on-premises data center to a VPC in us-central1. The on-premises network uses RFC 1918 addresses (10.0.0.0/8) that overlap with the VPC subnet (10.0.1.0/24). They need connectivity to specific workloads in the VPC without changing IP addresses on premises. What should they do?
Private Service Connect allows private connectivity without route overlap by using service attachments and endpoints.
Why this answer
Private Service Connect (PSC) allows on-premises clients to access specific VPC workloads via internal IP addresses (RFC 1918) without requiring VPC peering or VPN. PSC publishes the workloads as endpoints reachable through a Private Service Connect endpoint in the on-premises network, avoiding IP overlap by using a separate IP address range for the endpoint. This solution meets the requirement of not changing on-premises IPs while providing secure, targeted connectivity.
How to eliminate wrong answers
Option A is wrong because VPC Network Peering requires non-overlapping IP ranges between the two networks; overlapping RFC 1918 addresses (10.0.0.0/8 vs 10.0.1.0/24) cannot be resolved by custom route exchange, as peering does not support NAT or address translation. Option B is wrong because Dedicated Interconnect with BGP does not solve IP overlap; even with a more specific prefix, the on-premises router would still have a conflicting route for 10.0.0.0/8, causing asymmetric routing or unreachability. Option C is wrong because Cloud NAT is designed for outbound internet traffic from VMs, not for inbound connectivity from on-premises networks; firewall rules cannot translate overlapping IPs or provide direct access to VPC workloads.
Cloud DNS inbound server policy enables DNS queries from GCP to be forwarded to on-premises DNS servers via VPN or Interconnect.
Why this answer
Cloud DNS inbound server policy allows on-premises DNS servers to receive DNS queries from Compute Engine instances by creating a VPC-scoped policy that forwards queries to the IP addresses of on-premises DNS resolvers over Cloud VPN. This enables hybrid name resolution without custom scripts, as the policy automatically handles the forwarding of DNS requests from Google Cloud resources to the on-premises DNS infrastructure.
Exam trap
Google Cloud often tests the distinction between inbound and outbound DNS policies; the trap here is confusing the direction of DNS resolution, leading candidates to choose a forwarding zone (outbound) when the requirement is for Compute Engine to resolve on-premises hostnames (inbound).
How to eliminate wrong answers
Option B is wrong because a forwarding zone in Cloud DNS is used to forward queries from on-premises to Google Cloud, not the reverse; it resolves Google Cloud private DNS names from on-premises, not on-premises hostnames from Compute Engine. Option C is wrong because Private Google Access enables Compute Engine instances without external IPs to reach Google APIs and services, not to resolve on-premises hostnames. Option D is wrong because Cloud NAT is used for outbound internet connectivity from private instances, not for DNS query forwarding; it does not provide DNS resolution for on-premises hostnames.
Which THREE factors should be considered when choosing between a global external HTTP(S) load balancer and a regional external HTTP(S) load balancer? (Choose 3.)
Global terminates SSL at the edge; regional terminates at the backend.
Why this answer
Regional external HTTP(S) load balancers terminate SSL at the backend (the backend service or instance), meaning the encrypted traffic must travel to the backend before decryption. Global external HTTP(S) load balancers terminate SSL at the edge (Google Front End), decrypting traffic at the closest point of presence and forwarding plaintext HTTP to the backend. This architectural difference impacts security, latency, and backend processing requirements, making it a key factor in choosing between the two.
Exam trap
Google Cloud often tests the misconception that SSL termination location is the same for both load balancer types, but the key distinction is that global terminates at the edge (GFE) and regional terminates at the backend, which directly affects security and performance decisions.
An organization is deploying a Shared VPC with one host project and three service projects. Each service project has multiple VPC networks. They want to ensure that only the host project's network admin can create firewall rules affecting the shared VPC network. Which architecture satisfies this requirement?
Shared VPC firewall rules are managed in the host project, and IAM restricts who can modify them.
Why this answer
In a Shared VPC architecture, the host project owns the shared VPC network, and only IAM roles granted in the host project can manage that network's resources. By creating the shared VPC network in the host project and granting the network admin IAM role exclusively to host project users, you ensure that only those users can create firewall rules for the shared VPC. Service project users cannot modify the shared network's firewall rules because they lack the necessary IAM permissions on the host project.
Exam trap
The trap here is that candidates often confuse VPC Network Peering with Shared VPC, assuming peering provides centralized management, when in fact peering only enables connectivity without any cross-project IAM control over firewall rules.
How to eliminate wrong answers
Option B is wrong because VPC Network Peering does not centralize firewall rule management; each peered network's admin can create firewall rules for their own network, and peering does not allow one side to control the other's firewall rules, so service project admins could still manage their own rules, violating the requirement. Option C is wrong because assigning the network admin role to users in each service project for the shared VPC network would give those service project users the ability to create firewall rules affecting the shared VPC, directly contradicting the requirement that only the host project's network admin can do so. Option D is wrong because creating separate VPC networks in each service project and using VPC Network Peering to interconnect them does not create a shared VPC; each service project would have full control over its own firewall rules, and peering does not centralize rule management, so the requirement is not met.
A gaming company uses Cloud Armor with an external HTTP(S) load balancer to protect against DDoS attacks. They need to restrict access to the load balancer based on geographic region. What should they configure?
Cloud Armor rules can filter traffic based on geographic region (e.g., country or continent).
Why this answer
Cloud Armor supports geo-match custom rules that allow you to allow or deny traffic based on the geographic region of the client IP address. When attached to an external HTTP(S) load balancer, these rules are evaluated at the edge before traffic reaches the backend, providing effective geo-based access control against DDoS attacks.
Exam trap
Google Cloud often tests the distinction between Cloud Armor's security policies (which include geo-match rules) and backend service routing policies, leading candidates to confuse geo-based routing with geo-based access control.
How to eliminate wrong answers
Option A is wrong because geo-based routing policy on the backend service is used for directing traffic to different backends based on client location, not for blocking or allowing access at the edge. Option B is wrong because firewall rules operate at the VPC network level and cannot be applied directly to an external HTTP(S) load balancer; they would block traffic after it has already passed through the load balancer, which is ineffective for DDoS protection. Option D is wrong because Cloud CDN with geo filtering is a feature of Cloud CDN that restricts content delivery based on geography, but it does not provide the same granular access control or DDoS mitigation capabilities as Cloud Armor's geo-match rules.
An organization has a Dedicated Interconnect with Cloud Router configured for BGP. The on-premises network advertises a prefix that overlaps with an existing VPC subnet. How does Google Cloud handle the overlapping prefix?
Google Cloud rejects overlapping prefixes to maintain routing integrity.
Why this answer
When a Dedicated Interconnect with Cloud Router receives a BGP advertisement for a prefix that overlaps with an existing VPC subnet, Google Cloud rejects the prefix and does not install a dynamic route for it. This is because VPC subnet routes always take precedence over dynamically learned routes, and accepting an overlapping prefix would create ambiguity in forwarding decisions. The Cloud Router enforces this behavior to maintain the integrity of the VPC's internal addressing.
Exam trap
The trap here is that candidates often assume BGP routes can override VPC subnet routes due to the dynamic nature of BGP, but Google Cloud enforces a strict priority hierarchy where VPC subnet routes are always preferred over any dynamically learned or static route.
How to eliminate wrong answers
Option A is wrong because static routes do not have higher priority than VPC subnet routes; VPC subnet routes are implicitly created and have the highest priority (0), while static routes have a priority of 1000. Option B is wrong because Google Cloud never gives a dynamically learned BGP route higher priority than a VPC subnet route; the VPC subnet route is always preferred. Option D is wrong because Google Cloud does not load balance traffic between overlapping prefixes; it rejects the overlapping prefix entirely to prevent routing conflicts.
A large enterprise is migrating to Google Cloud and needs to establish connectivity between on-premises and VPCs in two different regions (us-east1 and europe-west1). They have a single Partner Interconnect connection at a co-location facility in New York. They want to use the same interconnect for both regions. Which configuration should they use?
VLAN attachments are regional; multiple can share same interconnect.
Why this answer
A is correct because a single Partner Interconnect connection can support multiple VLAN attachments, each associated with a different region. By creating two VLAN attachments over the same interconnect—one for us-east1 and one for europe-west1—the enterprise can route traffic from the on-premises network to both VPCs using the same physical link, leveraging Google Cloud's support for multiple VLAN attachments per interconnect.
Exam trap
Google Cloud often tests the misconception that a single VLAN attachment can serve multiple regions, but in Google Cloud, VLAN attachments are regional resources and cannot be shared across regions.
How to eliminate wrong answers
Option B is wrong because a VLAN attachment is a regional resource that can only be attached to a VPC in the same region; you cannot attach a single VLAN attachment to VPCs in two different regions. Option C is wrong because HA VPN over the interconnect is unnecessary and adds complexity; the interconnect already provides a dedicated, high-bandwidth connection, and using VPN over it would introduce encryption overhead and potential performance degradation without solving the multi-region requirement. Option D is wrong because Cloud VPN tunnels are typically used over the public internet or as a backup, not as a primary solution when a dedicated interconnect is available; moreover, using two VPN tunnels would bypass the interconnect's benefits of lower latency and higher reliability.
A company wants to connect two VPCs in the same project using VPC Network Peering. Each VPC has non-overlapping subnets. What is the minimum number of peering connections required to enable full bidirectional communication?
VPC peering is unidirectional, so two connections are needed for full mesh.
Why this answer
VPC Network Peering requires a peering connection to be established in each direction to enable full bidirectional communication. A single peering connection from VPC1 to VPC2 only allows VPC1 to initiate traffic to VPC2; for VPC2 to initiate traffic back to VPC1, a separate peering connection from VPC2 to VPC1 is needed. Therefore, two peering connections (one from each VPC to the other) are the minimum required.
Exam trap
The trap here is that candidates assume a single peering connection is sufficient because they think of it as a bidirectional link, but VPC Network Peering in Google Cloud requires explicit peering in each direction for full bidirectional traffic flow.
How to eliminate wrong answers
Option A is wrong because a single peering connection from VPC1 to VPC2 is unidirectional in terms of route propagation; without a reciprocal peering from VPC2 to VPC1, VPC2 cannot initiate traffic to VPC1. Option B is wrong because it suggests four connections, which is redundant; only two connections (one in each direction) are needed for full bidirectional communication. Option D is wrong because a Shared VPC is a different architecture that centralizes subnet management, not a method for peering two existing VPCs, and it does not replace the need for peering connections.
A company wants to serve global static content from a Cloud Storage bucket. They need low latency worldwide and SSL termination at the edge. Which solution should they choose?
This provides global anycast IP, SSL termination, and integrates with Cloud CDN.
Why this answer
A global external HTTP(S) load balancer with a backend bucket is the correct choice because it provides SSL termination at the edge (using Google Front Ends) and routes traffic over Google's global network to the nearest Cloud Storage bucket, ensuring low latency worldwide. The HTTP(S) load balancer supports global anycast IP addresses and integrates natively with Cloud Storage backends, making it ideal for serving static content globally.
Exam trap
Google Cloud often tests the misconception that Cloud CDN alone can provide SSL termination at the edge, but in reality, Cloud CDN requires a load balancer (HTTP(S) or external) to terminate SSL and route traffic, as the bucket's native HTTPS endpoint does not offer edge-based SSL termination or global anycast IP.
How to eliminate wrong answers
Option A is wrong because a TCP/UDP network load balancer does not support SSL termination at the edge (it operates at Layer 4) and cannot use a Cloud Storage bucket as a backend (buckets require HTTP(S)-based backends). Option C is wrong because an internal TCP/UDP load balancer is designed for private VPC traffic within a region, not for global public content delivery, and lacks SSL termination and bucket backend support. Option D is wrong because Cloud CDN directly on a bucket without a load balancer does not provide SSL termination at the edge (SSL is handled by the bucket's default HTTPS endpoint, which is not edge-terminated) and lacks the global anycast IP and advanced routing of a global HTTP(S) load balancer.
Your company runs a multi-tier web application on Google Cloud. The frontend is in us-central1 (3 instances behind an external HTTP(S) Load Balancer), the backend is in us-west1 (3 instances behind an internal TCP/UDP Load Balancer). The frontend instances are in a managed instance group (MIG) with autoscaling based on CPU utilization. Recently, you noticed that during traffic spikes, the frontend instances' CPU utilization remains low, but the backend instances' CPU utilization spikes to 90% and causes timeouts. The application uses a synchronous REST API; the frontend instances make requests to the internal load balancer's IP. What should you do to resolve the backend scaling issue?
Internal HTTP(S) load balancer supports autoscaling based on request rate, allowing the backend to scale with traffic.
Why this answer
Option C is correct because the internal TCP/UDP load balancer cannot provide request-level metrics (like requests per second) for autoscaling, as it operates at layer 4. Replacing it with an internal HTTP(S) load balancer (layer 7) allows the backend MIG to autoscale based on the load balancing serving capacity or request count, which directly correlates with the frontend's synchronous REST API calls. This resolves the backend CPU spike issue by scaling the backend instances before they become overloaded, rather than relying on CPU utilization which lags behind traffic spikes.
Exam trap
The trap here is that candidates assume CPU-based autoscaling is sufficient for all tiers, but Cisco tests the nuance that synchronous REST APIs require layer-7 load balancing to expose request-level metrics for proactive autoscaling, while layer-4 load balancers only provide connection-level metrics that lag behind traffic spikes.
How to eliminate wrong answers
Option A is wrong because connection draining only gracefully terminates existing connections during instance removal; it does not address the root cause of backend scaling during traffic spikes. Option B is wrong because the internal TCP/UDP load balancer's health check cannot monitor CPU utilization—health checks only verify instance responsiveness (e.g., TCP port check), and autoscaling metrics must be configured on the MIG itself, not on the load balancer. Option D is wrong because Cloud Armor rate-limiting on the external load balancer would throttle requests before they reach the frontend, but the issue is backend scaling; rate-limiting does not enable the backend to scale dynamically and could cause legitimate traffic to be dropped.
Which TWO actions should you take to configure Private Google Access for on-premises hosts connected via Cloud Interconnect?
These ranges are used for Private Google Access for on-premises.
Why this answer
Correct answers: B (Enable Private Google Access on the VPC subnet) and D (Configure custom route advertisement to include the 199.36.153.4/30 and 199.36.153.8/30 ranges for restricted.googleapis.com). Option A is wrong because Cloud NAT is for VMs without external IPs. Option C is wrong because Private Service Connect is for managed services, not for general Private Google Access.
Option E is wrong because DNS resolution is done via Private Google Access; forwarding is not required.
A large organization uses Shared VPC with multiple service projects. They have an on-premises network connected via Cloud Interconnect. They want the on-premises network to be able to reach instances in all service projects. What is the recommended configuration?
Cloud Router in the host project automatically includes subnets from all service projects in the Shared VPC.
Why this answer
Option C is correct because in a Shared VPC architecture, the host project owns the VPC network and subnets, and Cloud Router with BGP is used to advertise the subnets from the host project to the on-premises network over Cloud Interconnect. This allows the on-premises network to reach instances in all service projects, as those instances reside in the host project's subnets. Cloud Router dynamically advertises the host project's VPC subnets via BGP, enabling seamless Layer 3 connectivity without additional per-service-project configurations.
Exam trap
Google Cloud often tests the misconception that each service project needs its own interconnect or NAT configuration, but the key is that Shared VPC centralizes networking in the host project, so a single Cloud Router with BGP advertisement in the host project provides connectivity to all service project instances.
How to eliminate wrong answers
Option A is wrong because Cloud NAT provides outbound internet access for private instances, not inbound connectivity from on-premises networks; it does not establish routing between on-premises and VPC subnets. Option B is wrong because VPC peering is used for connectivity between separate VPC networks, but in Shared VPC, service projects do not have their own VPCs—they use the host project's VPC, so peering is unnecessary and would not provide the required routing. Option D is wrong because creating separate Interconnect VLAN attachments for each service project is unnecessary and does not solve the routing issue; the on-premises network needs a single BGP session to learn all subnets from the host project's VPC, not separate attachments per project.
Which TWO network services are required to enable private Google access for on-premises hosts using a Dedicated Interconnect connection? (Choose two.)
Cloud Router is needed to exchange routes and enable private access.
Why this answer
Cloud Router with BGP is required because Dedicated Interconnect uses BGP sessions between the on-premises router and Google's edge router to exchange routes. Without BGP, the on-premises network cannot advertise or receive the routes necessary for private Google access, such as the 199.36.153.4/30 or 199.36.153.8/30 ranges used for Private Google Access for on-premises.
Which TWO of the following are required when setting up an internal TCP/UDP load balancer (ILB) in a shared VPC environment?
Health checks are required to determine instance health.
Why this answer
Correct answers: A (The load balancer must be in the same region as the backend instances) and C (The backend service must reference a health check). Option B is wrong because ILB does not require an internal IP address from the host project; it can use an IP from the service project's subnet. Option D is wrong because ILB does not require global routing; it works within a region.
Option E is wrong because the firewall rule for health checks must allow traffic from the health check ranges, not from the proxy subnet (ILB does not use proxy subnets like in HTTP LB).
Which THREE considerations are important when designing a Cloud CDN configuration for a global web application that serves both static and dynamic content?
Ignoring session parameters allows multiple users to share cache.
Why this answer
Correct answers: A (Cache keys should exclude session-specific parameters), C (Use separate cache modes for static vs dynamic content), and E (Enable origin shield to reduce load on the backend). Option B is wrong because signed URLs are for content protection, not caching. Option D is wrong because negative caching is not recommended for dynamic content.
This rule only allows traffic from VMs with the specified service account to the tagged database VMs.
Why this answer
Option D is correct because it defines an ingress firewall rule that allows TCP traffic on port 3306 (MySQL) from VMs using the service account 'web-sa@project.iam.gserviceaccount.com' as the source, targeting VMs with the network tag 'db'. In GCP VPC firewall rules, source service accounts can be used to filter traffic based on the identity of the source VM, while target tags apply the rule to destination VMs that have the specified tag, enabling identity-based access control without relying on IP addresses.
Exam trap
Google Cloud often tests the distinction between ingress and egress rules in the context of service account filtering, and the trap here is that candidates may confuse the direction of traffic (thinking an egress rule on the web VMs is needed) or incorrectly mix source/target tags with service accounts, leading them to pick options that use IP ranges or mismatched attributes.
How to eliminate wrong answers
Option A is wrong because it uses a broad source IP range (10.0.0.0/8) instead of the specific service account, which would allow traffic from any VM in that IP range, not just those with the 'web-sa' service account, violating the principle of least privilege. Option B is wrong because it incorrectly uses source tags 'web' (which filter by network tag, not service account) and target service account 'db-sa' (which would apply the rule to VMs with that service account, not the database VM with tag 'db'), and it also specifies an ingress rule but the direction is correct; the main issue is the mismatch in filtering attributes. Option C is wrong because it defines an egress rule, but the requirement is to allow traffic from the web VMs to the database VM, which is an inbound connection to the database; egress rules control outbound traffic from the source, not inbound access to the target.
A financial services company needs to audit all VPC firewall rule changes in real time. They want to receive notifications whenever a rule is created, modified, or deleted. What is the most efficient way to achieve this?
Cloud Logging captures Admin Activity audit logs for firewall changes; a logs-based metric with alert policy provides real-time notification.
Why this answer
Option D is correct because VPC Firewall Rules Logging with a sink to Pub/Sub can filter change events. Option A is wrong because export to BigQuery is for batch analysis. Option B is wrong because Stackdriver (Cloud Logging) by itself doesn't create alerts easily; Option C is wrong because Cloud Audit Logs track changes but require additional setup to send alerts.
A company has deployed an external HTTPS load balancer with a Cloud CDN backend. The load balancer uses a managed SSL certificate. Recently, the company updated their DNS record to point to a different IP address of a new load balancer. After the change, some users are still being served from the old load balancer's cache. The network engineer has confirmed that the DNS TTL has expired. What is the most likely cause of this issue?
Cloud CDN caches content at edge locations; if the cache TTL has not expired, users may receive the old content even after DNS changes.
Why this answer
Cloud CDN caches content at Google's edge caches based on the cache-control headers or default cache TTL. When the DNS record is updated to point to a new load balancer, the old load balancer's cached responses may still be served from edge caches until their cache TTL expires, even after the DNS TTL has expired. This is because Cloud CDN caches are independent of DNS resolution and are governed by HTTP caching rules.
Exam trap
Google Cloud often tests the distinction between DNS TTL (which controls how long DNS records are cached by resolvers) and HTTP cache TTL (which controls how long content is cached by CDN edge nodes), leading candidates to incorrectly attribute the issue to DNS propagation rather than CDN cache expiration.
How to eliminate wrong answers
Option B is wrong because SSL certificates are not cached by clients in a way that would cause them to be served content from the old load balancer; certificate caching affects TLS handshake validation, not content delivery. Option C is wrong because the question explicitly states that the DNS TTL has expired, meaning the DNS change has propagated globally; the issue is not DNS propagation. Option D is wrong because Google's edge network uses anycast to route traffic to the nearest healthy load balancer IP, but the old load balancer's IP is no longer advertised once the DNS points to a new IP; anycast does not serve stale IPs.
If the subnet is not advertised, on-premises traffic may not be routed correctly.
Why this answer
Since the VPN tunnel is up and BGP sessions are established, the issue is not with the tunnel or BGP peering itself. Intermittent connectivity to a specific subnet (10.1.0.0/16) while other subnets remain reachable strongly indicates a route advertisement problem. The Cloud Router must be configured to advertise the correct subnet range to the on-premises router via BGP; if it is not, the on-premises router will lack a route for that subnet, causing intermittent or no connectivity.
How to eliminate wrong answers
Option A is wrong because a misconfigured shared secret would prevent the VPN tunnel from establishing or cause it to fail authentication, but the tunnel is up and BGP sessions are established. Option B is wrong because tunnel flapping due to packet loss would cause the entire tunnel to go up and down, affecting all traffic, not just a specific subnet, and BGP sessions would also flap. Option C is wrong because a firewall rule blocking traffic from on-premises would cause consistent failure for all traffic from that source, not intermittent connectivity to a single subnet, and the tunnel and BGP being up suggests no such block at the network layer.
A company has a VPC with multiple subnets and uses Cloud VPN tunnels to connect to on-premises. They want to ensure that only traffic destined for on-premises is sent through the VPN tunnels; all other traffic should use the internet. Which route configuration should they implement?
BGP-learned specific routes will override the default route for those destinations.
Why this answer
Option B is correct because using Cloud Router with BGP allows the VPC to dynamically learn specific routes from the on-premises network via the VPN tunnels. The default route (0.0.0.0/0) remains pointing to the internet gateway, so only traffic destined for the learned on-premises prefixes is sent through the VPN, while all other traffic uses the internet. This provides precise control without overriding the default route.
Exam trap
Google Cloud often tests the misconception that a default route (0.0.0.0/0) must be manipulated to direct traffic to on-premises, when in fact the correct approach is to use more specific routes learned via BGP to selectively direct only on-premises-destined traffic through the VPN.
How to eliminate wrong answers
Option A is wrong because adding a static route for 0.0.0.0/0 with next hop VPN gateway would send all traffic (including internet-bound) through the VPN, contradicting the requirement; setting a lower priority does not help because the VPN route would still be more specific than the default internet route only if it has a higher priority, but the question states 'lower priority' which would make it less preferred, but the real issue is that a 0.0.0.0/0 route to VPN would capture all traffic. Option C is wrong because configuring the Cloud VPN to advertise a default route to on-premises would cause on-premises to send all its traffic to the cloud, not the other way around, and does not control which cloud traffic uses the VPN. Option D is wrong because VPC Network Peering is used for connecting VPCs within Google Cloud, not for connecting to on-premises networks; it does not support VPN tunnels or on-premises connectivity.
A company has deployed a Global External Application Load Balancer with Premium Tier and enables Cloud CDN. Users in Europe report high latency, while users in the US have good performance. The backend is a regional NEG in us-west1. What is the most likely cause?
Cloud CDN respects origin cache headers; private or no-store headers prevent caching, so all requests hit the backend.
Why this answer
Option D is correct because Cloud CDN cannot cache responses that include a 'Cache-Control: private' header. This header instructs intermediate caches (including CDN nodes) not to store the response, forcing all requests to go to the origin server in us-west1. Users in Europe experience high latency because their requests must traverse the long distance to the US origin, while US users benefit from shorter paths.
Enabling Cloud CDN alone does not guarantee caching; the origin must also allow caching by omitting 'private' or setting appropriate 'Cache-Control: public' and 'max-age' directives.
Exam trap
Google Cloud often tests the misconception that enabling Cloud CDN automatically caches all content, when in reality the origin's cache-control headers dictate cacheability, and 'Cache-Control: private' is a common reason for CDN bypass.
How to eliminate wrong answers
Option A is wrong because Premium Tier uses Google's global anycast network to route traffic to the nearest frontend IP address, not to the nearest backend; the backend location does not affect routing to the load balancer's global IP. Option B is wrong because the question states Cloud CDN is enabled on the load balancer, so the issue is not that CDN is disabled. Option C is wrong because the question explicitly states Premium Tier is used, not Standard Tier; Standard Tier would route traffic regionally and could cause high latency for European users, but that is not the case here.
An engineer creates a Cloud NAT configuration as shown in the exhibit. The test-instance is created without an external IP address. However, the instance cannot reach the internet. What is the most likely cause?
Cloud NAT covers only subnets in the same region as the NAT router. If subnet-a is in another region, it is not covered.
Why this answer
Option A is correct because Cloud NAT is a regional resource that applies to all instances within a given region. The exhibit shows subnet-a is in a different region than us-central1, so the NAT gateway cannot route traffic from instances in that subnet. Even though the instance is in us-central1, the subnet's region mismatch means the NAT configuration does not apply, leaving the instance without internet access.
Exam trap
Google Cloud often tests the misconception that Cloud NAT is zonal or that Cloud Router must be in the same zone as the instance, but the key trap here is that candidates overlook the regional scope of Cloud NAT and assume subnet location is irrelevant.
How to eliminate wrong answers
Option B is wrong because Cloud Router is a regional resource, not zonal, and does not need to be in the same zone as the instance; it only needs to be in the same region. Option C is wrong because the question states the instance cannot reach the internet, but no firewall rule is mentioned or implied; by default, VPC firewall rules allow outbound traffic, and the issue is specifically about NAT configuration. Option D is wrong because enabling logging is optional and does not affect the ability to reach the internet; it only controls whether NAT connection logs are sent to Cloud Logging.
A multinational company has a Shared VPC environment with multiple service projects. They need to allow a specific service project to use its own Cloud DNS private zone that resolves to internal IPs in the Shared VPC. Which configuration ensures this without exposing the zone to other projects?
Response policies enable selective DNS resolution for specific VPC networks.
Why this answer
Option A is correct: DNS response policies allow controlling DNS resolution per VPC. By creating a response policy in the host project and associating it with the service project's VPC, only that project can use the private zone. Option B places the zone in the service project but inbound server policy is for on-premises resolution; Option C would expose the zone to all projects; Option D adds unnecessary complexity.
Match each network pricing model to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Data leaving Google Cloud to the internet
Data entering Google Cloud (typically free)
Data transferred between regions within Google Cloud
Global network with consistent performance, higher cost
Lower cost, uses ISP networks for some hops
Why these pairings
Understanding pricing helps optimize network costs.
Which TWO of the following load balancer types can distribute traffic to backends in multiple regions?
This global LB can route traffic to backends in various regions based on location.
Why this answer
The External HTTP(S) Load Balancer is a global load balancer that can distribute traffic to backends in multiple regions using anycast IP addresses and Google's global network. It supports cross-regional backend services, making it suitable for global applications.
Exam trap
Google Cloud often tests the misconception that all external load balancers are global, but the External TCP/UDP Load Balancer is regional unless explicitly configured as a global proxy load balancer, which is a separate type (SSL Proxy or TCP Proxy).
If the external service restricts access by IP, only VMs using that NAT IP can connect.
Why this answer
Cloud NAT uses a source IP address (either a static IP you assign or an ephemeral IP from the NAT gateway's IP range) when translating outbound traffic from private VMs. If the external service's firewall only allows traffic from specific IP addresses, and the Cloud NAT gateway is using a static IP that is not on that allowlist, the affected VMs' traffic will be blocked. Other VMs might reach the service if they use a different NAT gateway or if the service's firewall permits their translated IP.
How to eliminate wrong answers
Option A is wrong because the default route (0.0.0.0/0) is required for internet-bound traffic to be sent to the Cloud NAT gateway; if it were missing, no VM could reach the internet, not just a specific set of external IPs. Option B is wrong because the question states firewall rules are correctly configured, and a deny rule for the source IP range of the affected VMs would block all outbound traffic from those VMs, not just to a specific set of external IPs. Option D is wrong because VM tags do not override Cloud NAT routing; tags are used for firewall rule targeting or network tags, but Cloud NAT routing is determined by the VPC network and the NAT gateway's configuration, not by VM tags.
A company has Compute Engine instances in a VPC that only have internal IP addresses. They need to access Google Cloud services like Cloud Storage and BigQuery. They also have on-premises servers that need to access the same instances via a Cloud VPN tunnel. What must be enabled for the instances to access Google APIs without public IPs?
Private Google Access enables access to Google APIs from internal IPs without public IPs.
Why this answer
Private Google Access enables Compute Engine instances that have only internal IP addresses (no external IPs) to reach Google APIs and services such as Cloud Storage and BigQuery. It works by routing traffic destined for Google API IP ranges through the default internet gateway, using the VPC's internal DNS resolution to map the API hostnames to Google's internal IP addresses, without requiring a public IP on the instance.
How to eliminate wrong answers
Option B is wrong because Cloud Router is used for dynamic routing (BGP) between a VPC and an on-premises network over Cloud VPN or Dedicated Interconnect, not for enabling internal-only instances to reach Google APIs. Option C is wrong because VPC peering connects two VPC networks to exchange traffic, but it does not provide access to Google APIs for instances without public IPs; that requires Private Google Access on the subnet. Option D is wrong because Cloud NAT provides outbound internet connectivity for instances without public IPs, but it is designed for general internet access, not specifically for reaching Google APIs and services; Private Google Access is the correct feature for that purpose.
You have a Cloud Router with the configuration shown. The on-premises network (ASN 65002) is not receiving any routes from Google Cloud. What is the most likely cause?
Custom mode overrides default; must explicitly advertise VPC subnets.
Why this answer
When a Cloud Router is configured in custom advertise mode, it only advertises the routes explicitly specified in the custom advertisement list. If the VPC subnets are not included in that list, the on-premises network will not receive any routes from Google Cloud, even if the BGP session is established. This is the most likely cause because the question states the on-premises network is not receiving any routes, which aligns with a missing custom advertisement rather than a session or timer issue.
Exam trap
Google Cloud often tests the misconception that a BGP session being 'Established' guarantees route exchange, but in Google Cloud's custom advertise mode, the session can be up while no routes are advertised due to missing custom advertisement configuration.
How to eliminate wrong answers
Option A is wrong because a low BGP keepalive interval (e.g., 10 seconds) would cause the session to flap or reset, not silently prevent route advertisement; the session would still exchange routes when up. Option B is wrong because if the BGP session were not established, the Cloud Router would show a state other than 'Established' (e.g., Idle, Active), and the question implies the session is up but no routes are received. Option D is wrong because the on-premises subnet 10.0.1.0/24 is a route that the on-premises router advertises to Google Cloud, not a route that Google Cloud advertises to on-premises; the issue is about routes from Google Cloud not being received, not about missing on-premises advertisements.
Inbound server policy allows on-premises to resolve private zones; forwarding zone allows GCP to resolve on-premises.
Why this answer
Option A is correct because Cloud DNS supports inbound server policies that allow on-premises DNS resolvers to forward queries for private zone names (e.g., `gcp.internal`) to Cloud DNS via the Cloud VPN. A forwarding zone in the VPC directs queries for on-premises hostnames (e.g., `corp.example.com`) to the on-premises DNS servers. This bidirectional resolution is achieved without exposing DNS to the internet, leveraging BGP for routing.
Exam trap
Google Cloud often tests the distinction between DNS peering (VPC-to-VPC) and DNS forwarding/inbound policies (VPC-to-on-premises), causing candidates to mistakenly choose peering for hybrid scenarios.
How to eliminate wrong answers
Option B is wrong because split-horizon DNS is a design pattern, not a Google Cloud architecture component; it does not provide the required integration between Cloud DNS and on-premises DNS over VPN. Option C is wrong because Cloud DNS peering zones only allow DNS resolution between VPCs within Google Cloud, not between a VPC and an on-premises network. Option D is wrong because DNS over HTTPS to Google Public DNS would only resolve public internet names, not private zone names or on-premises hostnames, and bypasses the VPN.
A company is running workloads on Compute Engine instances without public IP addresses. They need to allow these instances to securely access the internet for software updates. Which Google Cloud service should be configured?
Why this answer
Cloud NAT (Network Address Translation) allows Compute Engine instances without public IP addresses to initiate outbound connections to the internet for tasks like software updates. It translates the private IP addresses of the instances to a public IP address managed by Google Cloud, enabling secure outbound internet access without exposing the instances to inbound traffic.
Exam trap
Google Cloud often tests the distinction between Private Google Access (which only reaches Google APIs) and Cloud NAT (which provides full internet access), causing candidates to confuse the two when the requirement is for general internet connectivity like software updates.
How to eliminate wrong answers
Option A is wrong because Cloud VPN creates an encrypted tunnel to an on-premises network, not to the general internet; it does not provide outbound internet access for instances without public IPs. Option B is wrong because Private Google Access allows instances to reach Google APIs and services using private IPs, but it does not provide access to the broader internet for software updates. Option D is wrong because VPC Peering connects two VPC networks privately, but it does not provide internet access; it only enables communication between the peered networks.
A company has a Dedicated Interconnect connection from their on-premises data center to GCP. They have set up BGP sessions over VLAN attachments to peer with their VPC. Traffic from on-premises to GCP works, but return traffic from GCP to on-premises is dropped at the on-premises firewall. What is the most likely cause?
If the on-premises prefix is not advertised, GCP routes return traffic through the internet, causing asymmetric routing and firewall drops.
Why this answer
The most likely cause is that the on-premises router is not advertising the on-premises prefix to GCP via BGP. For return traffic from GCP to be routed correctly, GCP must learn the on-premises network prefix through a BGP advertisement from the on-premises router. Without this advertisement, GCP has no route to send traffic back, causing the firewall to drop the packets as they have no valid path.
How to eliminate wrong answers
Option A is wrong because the VLAN attachment can be in a different region than the GCP resources; traffic is routed through the VPC's global routing, and region mismatch does not cause return traffic to be dropped at the on-premises firewall. Option B is wrong because GCP firewall rules control traffic entering or leaving VM instances, not traffic that is already routed through the Dedicated Interconnect; the issue is at the on-premises side, not in GCP. Option C is wrong because MTU inconsistency would typically cause fragmentation issues or packet loss, not a complete drop of return traffic at the firewall; the firewall drop indicates a routing or prefix advertisement problem.
A company is deploying a global application on Google Cloud using Cloud Load Balancing. They want to serve traffic from multiple regions and require the lowest possible latency for users worldwide. The application serves HTTP traffic and uses a static IP address. Which load balancing solution should they use?
External HTTP(S) Load Balancer with Premium Tier uses Google's global network and anycast IP to direct users to the nearest backend, minimizing latency.
Why this answer
The External HTTP(S) Load Balancer with Premium Tier is correct because it uses Google's global anycast IP address to route user traffic to the nearest frontend, minimizing latency worldwide. Premium Tier leverages Google's global network backbone, ensuring traffic enters and exits at the closest Google edge point of presence (PoP) for HTTP(S) traffic, which is essential for a global application requiring low latency and a static IP.
Exam trap
Google Cloud often tests the misconception that any load balancer with 'HTTP(S)' in its name is automatically global, but the trap here is that only the External HTTP(S) Load Balancer with Premium Tier provides global anycast routing; the Internal and SSL Proxy variants are regional, and the Network Load Balancer is Layer 4 only.
How to eliminate wrong answers
Option A is wrong because a Network Load Balancer is a regional, passthrough load balancer that operates at Layer 4 (TCP/UDP) and does not support HTTP(S) traffic or global anycast IPs, making it unsuitable for global low-latency HTTP traffic. Option B is wrong because an Internal HTTP(S) Load Balancer is designed for internal VPC traffic within a single region and cannot serve traffic from the internet or use a public static IP. Option C is wrong because an SSL Proxy Load Balancer terminates SSL/TLS connections but is regional (not global) and does not provide the lowest possible latency for worldwide users compared to the Premium Tier's global anycast routing.
Which TWO of the following are benefits of using Cloud NAT?
This is the primary purpose of Cloud NAT.
Why this answer
Cloud NAT enables outbound connectivity from private instances that lack public IP addresses. It translates private source IPs to a single or a pool of external IPs, allowing instances to reach the internet while remaining unreachable from outside. This is essential for security and compliance in VPC networks.
Which THREE actions should you take to secure a VPC that hosts public-facing web applications?
Provides outbound connectivity without exposing VMs.
Why this answer
Cloud NAT enables outbound internet access for private VMs without assigning them public IP addresses, which reduces the attack surface. This is a secure alternative to direct internet access because it allows outbound connections initiated by the VMs while blocking unsolicited inbound traffic from the internet. It works by translating private IP addresses to a set of ephemeral public IPs managed by Google Cloud.
Exam trap
Google Cloud often tests the misconception that VPC Flow Logs are a security control that can block traffic, when in reality they are only a logging and monitoring feature, not an enforcement mechanism.
A media streaming company uses Cloud CDN with signed URLs to protect content. They want to invalidate cached content for a specific file after a security incident. The file is stored in a Cloud Storage bucket and the CDN cache key includes the URL. They run: gcloud compute url-maps invalidate-cdn-cache URL_MAP --path "/videos/incident.mp4". The invalidation succeeds but the old content is still served. What is the most likely reason?
With signed URLs, each request has unique query strings, so the cache key varies.
Why this answer
Option C is correct because Cloud CDN's cache key for signed URLs includes the query parameters (e.g., `?Expires=...&Signature=...`). The invalidation command specifies only the path `/videos/incident.mp4`, which does not match the full cache key that includes the query string. As a result, the invalidation does not purge the cached entry for the signed URL, and the old content continues to be served.
Exam trap
Google Cloud often tests the misconception that cache invalidation by path alone will work for all cached objects, ignoring that signed URLs or query parameters can create distinct cache entries that require matching the full cache key.
How to eliminate wrong answers
Option A is wrong because the cache key does include query parameters when signed URLs are used, so the invalidation path must match the full cache key. Option B is wrong because a long `max-age` only affects how long the object is cached by the browser or intermediate caches, not Cloud CDN's ability to invalidate its own cache; invalidation overrides any cache-control directives. Option D is wrong because object versioning is not required for CDN cache invalidation; Cloud CDN invalidates based on the cache key, not on object versions.
A company uses Cloud Armor with an external HTTPS load balancer to protect their web application. They have a security policy 'my-policy' attached to the backend service. The policy includes an allow rule (priority 1000) for their corporate IP range (203.0.113.0/24) and a deny rule (priority 2000) for all other IPs. The company has an office at a remote location that uses a different IP range (198.51.100.0/24). Employees from the remote office report they cannot access the application. Meanwhile, employees from the corporate office (203.0.113.0/24) can access. The engineer checks the Cloud Armor policy and sees the rule configuration as shown. What is the most likely cause?
Only the corporate IP range is allowed; all others are denied by the default deny rule.
Why this answer
The remote office IP range (198.51.100.0/24) is not explicitly allowed by any rule in the security policy. The only allow rule (priority 1000) permits traffic from the corporate IP range (203.0.113.0/24), and the deny rule (priority 2000) blocks all other IPs. Since the remote office IPs are not covered by the allow rule, they are denied by default, which explains their inability to access the application.
Exam trap
Google Cloud often tests the misconception that a deny rule with a higher priority number (e.g., 2000) will override an allow rule with a lower priority number (e.g., 1000), but in reality, Cloud Armor evaluates rules in ascending priority order, so the allow rule is evaluated first and permits matching traffic before the deny rule is considered.
How to eliminate wrong answers
Option A is wrong because the rule evaluation order is correct: Cloud Armor evaluates rules from lowest priority number to highest, so the allow rule (priority 1000) is evaluated before the deny rule (priority 2000). Option C is wrong because 'SRC_IPS_V2' is a valid expression type in Cloud Armor for specifying IP ranges using CIDR notation, and its use does not cause the issue. Option D is wrong because the load balancer's frontend IP does not block traffic based on geographic regions; geographic blocking would require a separate Cloud Armor rule or a different configuration, and the problem statement does not indicate any such rule.
Refer to the exhibit. A VM in 'subnet-a' can access Google APIs via private IP, but a VM in 'subnet-b' cannot. What change should be made to fix this?
Enabling Private Google Access allows VMs to reach Google APIs via internal IP.
Why this answer
Private Google Access enables a VM that has only an internal IP address (no external IP) to reach Google APIs and services through the default internet gateway using Google's private network. Since subnet-b lacks this setting, VMs there cannot reach Google APIs via private IP. Enabling Private Google Access on subnet-b resolves this by allowing the VM's traffic to be routed to Google APIs without needing an external IP.
Exam trap
Google Cloud often tests the distinction between enabling outbound internet access (Cloud NAT) and enabling private access to Google services (Private Google Access), leading candidates to mistakenly choose Cloud NAT when the requirement is specifically for private IP access to Google APIs.
How to eliminate wrong answers
Option A is wrong because changing the stack type to IPV4_IPV6 adds IPv6 support but does not enable private access to Google APIs; Private Google Access is independent of IP stack type. Option B is wrong because Cloud NAT provides outbound internet access for private VMs but does not route traffic to Google APIs via private IP; Cloud NAT uses external IPs for translation, not the private Google network path. Option C is wrong because a firewall rule allowing egress to 0.0.0.0/0 on port 443 would permit HTTPS traffic but does not enable the underlying routing needed for private Google API access; without Private Google Access, the traffic would still be dropped or sent via external IP.
The allow-http rule allows tcp:80 from 0.0.0.0/0 to tagged instances; the instance has http-server tag.
Why this answer
The instance has the network tag 'http-server', which is used by the default VPC firewall rule 'default-allow-http' to permit inbound TCP traffic on port 80 from any source (0.0.0.0/0). Since the instance also has a public IP address, HTTP traffic from the internet can reach it. The other tags and the public IP do not override this allow rule.
Exam trap
Google Cloud often tests the misconception that having a public IP address automatically opens all ports, or that a network tag alone (without a corresponding firewall rule) permits traffic on that port.
How to eliminate wrong answers
Option A is wrong because the implied deny-all rule only applies to traffic that is not explicitly allowed; the 'default-allow-http' rule explicitly permits HTTP traffic, so it is not denied. Option B is wrong because although the instance has the tag 'ssh-server', there is no default firewall rule that allows SSH traffic from the internet; the default-allow-ssh rule exists only if explicitly created, and the tag alone does not create a rule. Option D is wrong because HTTPS (port 443) is not allowed by any default rule associated with the 'http-server' tag; the default-allow-https rule would require a separate tag like 'https-server' or a custom rule.
Refer to the exhibit. A network team has created this load balancer. Clients inside the VPC are unable to connect to the load balancer's IP address from a Compute Engine instance in the same VPC. What is the most likely cause?
Internal load balancers must use Premium Tier. Standard tier is for external load balancers only.
Why this answer
Option B is correct because a load balancer configured with network tier STANDARD uses the Premium Tier's external IP addressing, which does not support internal traffic routing within the same VPC. Clients inside the VPC attempting to connect to the load balancer's IP address from a Compute Engine instance in the same VPC will fail because STANDARD tier IPs are designed for external internet-facing traffic and cannot be reached from within the VPC without a public IP and appropriate routing. The load balancer must use the Premium Tier (network tier PREMIUM) to support internal client traffic within the same VPC.
Exam trap
Google Cloud often tests the distinction between network tier STANDARD and PREMIUM, trapping candidates who assume all load balancer IPs are reachable from within the VPC regardless of tier, when in fact STANDARD tier IPs are external-only and require public internet routing.
How to eliminate wrong answers
Option A is wrong because the target HTTPS proxy configuration is unrelated to the client's inability to connect from within the same VPC; a misconfigured proxy would cause backend failures, not a connectivity failure from clients to the load balancer IP. Option C is wrong because INTERNAL_MANAGED scheme is specifically designed for internal load balancing within the same VPC and region, and clients in the same region can connect; the issue here is the network tier, not the scheme or region. Option D is wrong because the absence of a backend service would cause health check failures or 502 errors, not a complete inability for clients to reach the load balancer's IP address from within the VPC.
A company uses an internal TCP/UDP load balancer to distribute traffic to a backend service. The backend instances are in an unmanaged instance group. Some instances fail health checks and are removed. What happens to existing connections to failed instances?
Why this answer
When an instance in an unmanaged instance group fails a health check, the internal TCP/UDP load balancer immediately terminates all existing connections to that instance. This is because the load balancer does not support connection draining for unmanaged instance groups; it simply stops forwarding new traffic and drops existing flows to the failed instance. The abrupt termination occurs because the load balancer operates at Layer 4 and has no mechanism to gracefully close TCP connections or wait for application-level cleanup.
Exam trap
The trap here is that candidates often assume connection draining is always available for load balancers, but Cisco tests the distinction between managed and unmanaged instance groups, where unmanaged groups lack graceful connection termination features.
How to eliminate wrong answers
Option A is wrong because connection draining is a feature of managed instance groups (e.g., with Google Cloud's managed instance groups), not unmanaged instance groups; the load balancer does not drain connections for unmanaged groups. Option B is wrong because existing connections are not seamlessly redirected; TCP/UDP sessions are stateful and cannot be transparently moved to another instance without breaking the connection. Option D is wrong because the load balancer does not wait for connections to close; it removes the instance immediately upon health check failure, terminating all active connections.
Private Google Access allows on-premises to access Google APIs and services, but for internal IP access, the VPN provides routing.
Why this answer
Option B is correct because Private Google Access for on-premises (via VPN/Interconnect) requires setting up a Private Service Connect endpoint or simply enabling Private Google Access on the subnet and ensuring routes are advertised. However, the simplest method is to enable Private Google Access on the VPC subnet (or the whole VPC) and ensure the on-premises network can reach the internal IP directly via VPN routes. Option A is wrong because Cloud NAT is for outbound only.
Option C is wrong because a global IP is not needed. Option D is wrong because Cloud DNS is not directly required.
Refer to the exhibit. The Cloud Router is configured with custom BGP advertisements. The on-premises router receives only the two advertised ranges (10.1.0.0/24 and 10.2.0.0/24) but not the VPC subnets (e.g., 10.3.0.0/24). What is the most likely reason?
On-premises routers often have ingress filters that can drop routes.
Why this answer
Option D is correct because Cloud Router custom advertisements can include BGP communities or AS-path attributes that the on-premises router may be filtering. If the on-premises router is configured to reject routes based on these attributes (e.g., only accepting routes with a specific community or AS-path length), it would drop the VPC subnet routes even if they are advertised. The scenario states that only the two explicitly advertised ranges are received, indicating a filtering mechanism on the on-premises side rather than a Cloud Router misconfiguration.
Exam trap
Google Cloud often tests the misconception that Cloud Router's custom advertisement configuration automatically overrides on-premises filtering, when in reality BGP attributes like communities and AS-path are the primary mechanisms for route filtering on the receiving side.
How to eliminate wrong answers
Option A is wrong because the on-premises router receiving /24 prefixes does not imply it filters longer prefixes; the VPC subnets (e.g., 10.3.0.0/24) are also /24, so prefix length filtering would not explain why they are missing. Option B is wrong because BGP route priority (MED or local preference) influences route selection among multiple paths, not whether a route is accepted or rejected; a priority of 100 is a default value and does not cause routes to be ignored. Option C is wrong because if the Cloud Router's custom advertisement includes both the ALL_SUBNETS group and explicit ranges, all VPC subnets should be advertised; the fact that only the explicit ranges are received points to a filtering issue on the on-premises side, not a Cloud Router configuration problem.
Why this answer
Option C is correct because a Cloud VPN requires both a VPN gateway (the GCP-side endpoint for encrypted traffic) and a VPN tunnel (the actual IPSec tunnel configuration that defines the remote peer IP, shared secret, and IKE parameters). Option E is correct because dynamic routing with BGP mandates a Cloud Router in the same region as the VPN gateway to exchange BGP routes with the on-premises router; the Cloud Router advertises the VPC subnets and learns remote prefixes via BGP sessions over the tunnel.
Exam trap
Google Cloud often tests the misconception that firewall rules are part of the VPN setup process, but they are a separate security control applied after the VPN infrastructure is created; the trap here is confusing prerequisite security policies with the actual configuration steps for the VPN gateway, tunnel, and BGP routing.
An organization is migrating a legacy application to GCP. The application requires a static internal IP address for a Compute Engine VM that must persist even if the VM is stopped or deleted. Which IP address type should they assign?
Static internal IPs are reserved and persist until released.
Why this answer
A static internal IP address is reserved within a specific region and subnetwork, ensuring the IP persists even after the VM is stopped or deleted. This meets the requirement for a fixed internal address that remains available for reassignment to the same or a different VM in the same subnet. Ephemeral IPs are released on VM stop/delete, and external IPs are not relevant for internal-only communication.
How to eliminate wrong answers
Option A is wrong because an alias IP range is used to assign multiple IP addresses to a single network interface for container or multi-service workloads, but it does not provide a persistent static IP that survives VM deletion. Option B is wrong because an ephemeral external IP is a public, temporary address that is released when the VM is stopped or deleted, and a firewall rule does not affect IP persistence. Option D is wrong because there is no 'auto-delete' property for internal IP addresses; the correct mechanism to make an internal IP persistent is to reserve a static internal IP address, and the term 'regional internal IP address' is ambiguous without the reservation step.
Your company uses Network Connectivity Center (NCC) to manage multiple on-premises sites connected via Cloud VPN and Partner Interconnect. You create a NCC hub and attach spokes (VPN tunnels and VLAN attachments). Traffic between two on-premises sites (Site A and Site B) should flow through Google Cloud. However, traffic is not passing between the sites. What is the most likely cause?
NCC requires route exchange to be enabled on spokes to propagate routes.
Why this answer
Option A is correct because NCC routes will only propagate if the spokes are configured with the proper route exchange options. By default, custom dynamic route exchange is not enabled for VPN tunnels; you need to configure advertisement of routes. Option B is wrong because NCC supports VPN and Interconnect.
Option C is wrong because NCC uses dynamic routing; static routes are not required. Option D is wrong because VPC networks are not directly involved if using NCC hub-and-spoke.
Private zone is authoritative; records must be added explicitly.
Why this answer
Option D is correct because 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.
How to eliminate wrong answers
Option A is wrong because the question explicitly states the private zone is attached to the VPC, so this is not the cause. Option B is wrong because Compute Engine VMs automatically have their /etc/resolv.conf configured to use the metadata server (169.254.169.254) which proxies DNS queries to Cloud DNS; manual configuration is not required. Option C is wrong because DNS traffic to the metadata server uses a special internal path that does not traverse standard firewall rules; UDP 53 to 169.254.169.254 is allowed by default and not blocked by VPC firewall rules.
A global e-commerce company has deployed a web application across multiple GCP regions using an external HTTPS load balancer. Traffic is expected to originate from users worldwide. They want to minimize latency and improve user experience, while also ensuring that traffic is served from the nearest healthy backend. Which load balancing configuration should they use?
Global load balancer uses anycast to route users to the nearest healthy backend automatically.
Why this answer
A global external HTTP(S) load balancer uses a single anycast IP address, which directs each user to the closest healthy backend based on the user's geographic location and backend health. Enabling Cloud CDN further reduces latency by caching content at Google's global edge locations, ensuring that static and dynamic content is served from the nearest point of presence.
Exam trap
Google Cloud often tests the distinction between global anycast-based load balancers and regional load balancers with DNS routing, where candidates mistakenly think that regional load balancers with Cloud CDN can achieve the same latency optimization as a global anycast load balancer.
How to eliminate wrong answers
Option A is wrong because regional external HTTP(S) load balancers do not provide a single anycast IP; they require separate IPs per region and rely on DNS-based routing, which cannot guarantee that traffic is always served from the nearest healthy backend without additional complexity and potential latency from DNS caching. Option C is wrong because internal TCP/UDP load balancers are designed for private VPC traffic within a region, not for global external user traffic, and DNS-based geolocation routing introduces latency and does not provide the same anycast-based proximity as a global load balancer. Option D is wrong because a global external TCP proxy load balancer operates at Layer 4 and does not support HTTP/HTTPS features like Cloud CDN, URL-based routing, or content caching, making it unsuitable for optimizing user experience for a web application.
You are using Serverless VPC Access to connect Cloud Run services to a VPC network. The connector is in us-central1 with a /28 subnet. You have a Cloud SQL instance (private IP) in the same region but in a different VPC network (peered). The Cloud Run service cannot reach the Cloud SQL instance. What is the most likely cause?
VPC peering does not automatically propagate routes; you must configure custom route exchange or create routes.
Why this answer
Option A is correct because Serverless VPC Access routes traffic through the connector's VPC, but if the Cloud SQL instance is in a different VPC (even peered), the connector does not automatically route to the peered VPC. You need to ensure the route for the Cloud SQL private IP range is present in the connector's VPC. Option B is wrong because Cloud SQL private IP is accessible within the same VPC.
Option C is wrong because the Cloud SQL proxy is not required if direct access is configured. Option D is wrong because the connector does not use Private Google Access for Cloud SQL.
Your security team wants to block specific SQL injection attacks using Cloud Armor. You have configured a security policy with a preconfigured WAF rule for SQL injection (evaluatePreconfiguredExpr('sqli-stable')). The rule is set to DENY. However, legitimate traffic is being blocked intermittently. What should you adjust?
Reducing sensitivity reduces false positives.
Why this answer
The preconfigured WAF rule for SQL injection (sqli-stable) uses a default sensitivity level that may be too aggressive, causing false positives on legitimate traffic. By lowering the sensitivity level or excluding specific request attributes (e.g., headers, cookies, or URI paths), you can reduce false positives while still blocking actual SQL injection attempts. Cloud Armor allows fine-tuning of preconfigured rules via the `sensitivity` parameter and `exclude` lists, which is the correct approach here.
Exam trap
Google Cloud often tests the misconception that false positives from WAF rules are best handled by adding allow rules or rate limiting, rather than tuning the rule's sensitivity or exclusions, which is the proper Cloud Armor mechanism.
How to eliminate wrong answers
Option A is wrong because rate-based rules limit request frequency to mitigate DDoS or brute-force attacks, not to address false positives from a WAF rule that incorrectly flags legitimate SQL-like patterns. Option B is wrong because creating a higher-priority allow rule would bypass the WAF rule entirely for that traffic, defeating the purpose of SQL injection protection and potentially allowing actual attacks through. Option D is wrong because TLS inspection (e.g., using Cloud Armor with HTTPS load balancers) is already performed by default for encrypted traffic; the issue is not about decryption but about the WAF rule's sensitivity to benign SQL-like patterns.
A company has a VPC with subnet 10.1.0.0/24 in us-central1. They created a Cloud NAT gateway named 'nat-us-central1' attached to that subnet. During peak hours, many VM instances in the subnet cannot connect to the internet. The NAT configuration shows only one NAT IP. Firewall rules allow egress traffic, and health checks confirm the NAT gateway is functioning. What is the most likely cause of the failure?
One NAT IP provides limited source ports, easily exhausted by many concurrent connections.
Why this answer
With only one NAT IP address and many VM instances sharing it, the available source ports (65,535 per IP) are quickly exhausted during peak hours. Each concurrent outbound connection consumes a unique source port; once all ports are in use, new connections fail. This is a classic port exhaustion scenario, not a configuration or firewall issue.
How to eliminate wrong answers
Option A is wrong because Cloud NAT requires a Cloud Router for dynamic routing, but the question states the NAT gateway is functioning and health checks pass, indicating the router is present and correctly configured. Option B is wrong because the NAT gateway is explicitly attached to subnet 10.1.0.0/24, and health checks confirm it is working, so the attachment is correct. Option C is wrong because the firewall rules allow egress traffic, and ICMP is not required for general internet connectivity; the failure affects all protocols, not just ICMP.
Refer to the exhibit. A Cloud Router has two BGP sessions. The first session is UP, the second is DOWN. What is the most likely cause for the second session being down?
If the peer is also PASSIVE, the session cannot establish. One side must be ACTIVE.
Why this answer
The second session has sessionInitializationMode set to PASSIVE. If the peer router is also configured as PASSIVE, the BGP session will never establish. The first session is ACTIVE, so it came up.
This is a common misconfiguration.
A company is designing a hybrid network using Dedicated Interconnect. They want to configure BGP for load balancing across multiple VLAN attachments. Which TWO statements are correct?
Advertising the same prefixes over multiple VLANs enables load balancing.
Why this answer
Option B is correct because a Cloud Router can advertise the same IP prefixes over multiple VLAN attachments to enable load balancing. This allows Google Cloud to use ECMP (Equal-Cost Multi-Path) routing to distribute outbound traffic across the two VLAN attachments, as long as the BGP attributes (e.g., AS path length, MED) are equal.
Exam trap
Google Cloud often tests the misconception that BGP MED controls outbound traffic, but in reality, MED is a hint for inbound path selection, while outbound load balancing relies on equal BGP attributes and ECMP.
Your company has deployed a hybrid cloud environment with a Cloud VPN tunnel between Google Cloud VPC and an on-premises data center. The VPC has a custom mode with subnet 10.0.1.0/24 in us-east1. On-premises uses subnet 192.168.1.0/24. The VPN tunnel is established using dynamic routing (BGP). Both sides advertise the correct prefixes. A Compute Engine VM in the VPC (10.0.1.10) can ping the on-premises gateway (192.168.1.1), but cannot ping a server on-premises (192.168.1.100). The on-premises network team confirms that 192.168.1.100 is reachable from the on-premises gateway. Firewall rules in GCP allow ingress from 192.168.1.0/24 to all VMs. What is the most likely cause?
Without a return route, the on-premises server sends replies through the default route (likely internet), causing asymmetric routing and packet drop.
Why this answer
The correct answer is A. Since the VM can ping the on-premises gateway (192.168.1.1) but not the server (192.168.1.100), the VPN tunnel and BGP session are working, and GCP has the correct route. The issue is that the on-premises router is not advertising or does not have a route for the GCP subnet 10.0.1.0/24 pointing back to the VPN tunnel, so return traffic from the server to the VM is dropped.
Without this route, the on-premises router cannot forward packets destined for 10.0.1.10 back through the VPN.
Exam trap
Google Cloud often tests the misconception that a successful ping to the remote gateway proves full bidirectional connectivity, but the trap here is that the gateway responds from its own IP stack, not from behind it, so a missing return route for the GCP subnet on the on-premises router breaks traffic to hosts beyond the gateway.
How to eliminate wrong answers
Option B is wrong because if the on-premises server lacked a default gateway pointing to the on-premises gateway, the server would not be able to reach any off-subnet destination, including the gateway itself, but the problem states the server is reachable from the gateway. Option C is wrong because an IKE version mismatch would prevent the VPN tunnel from establishing at all, yet the VM can ping the on-premises gateway, proving the tunnel is up and BGP is exchanging routes. Option D is wrong because the GCP firewall rule explicitly allows ingress from 192.168.1.0/24 to all VMs, and the VM can receive ICMP from the gateway (192.168.1.1), so a firewall block on 192.168.1.100 specifically is inconsistent with the rule and the successful ping from the gateway.
A higher priority deny rule can override the allow rule.
Why this answer
The most likely cause is that a firewall rule with priority 500 explicitly denies ingress traffic to the specific VM's tag or IP range, overriding the allow-ssh rule (which has a lower priority, i.e., a higher numerical value). In Google Cloud Platform (GCP), firewall rules are evaluated from lowest to highest priority number, and a deny rule with a lower priority number (e.g., 500) takes precedence over an allow rule with a higher priority number (e.g., 1000). This explains why other VMs with the same 'ssh-allowed' tag remain reachable, as they are not affected by the specific deny rule.
Exam trap
Google Cloud often tests the misconception that a higher priority number means higher priority, when in fact a lower priority number (e.g., 500) takes precedence over a higher one (e.g., 1000), causing candidates to overlook the effect of a deny rule with a lower priority number.
How to eliminate wrong answers
Option B is wrong because the source range 0.0.0.0/0 does allow all internet IPs, but the issue is that a higher-priority deny rule (priority 500) is blocking the traffic, not that the allow rule is misconfigured. Option C is wrong because if the VM were in a different VPC without the allow-ssh rule, no VM in that VPC would be reachable via SSH, but the question states that other VMs with the same tag work, implying they are in the same VPC. Option D is wrong because while the allow-ssh rule with priority 1000 is higher than the implicit deny (65535), a deny rule with a lower priority number (500) takes precedence over the allow rule, blocking the traffic.
Through VPC peering, VMs can use the NAT of the peered network for outbound traffic.
Why this answer
Cloud NAT (Option A) provides source network address translation for VMs in a subnet. VPC peering to a network with Cloud NAT (Option C) allows VMs to use the NAT of the peered network. Option B only provides access to Google APIs, not the full internet.
Option D is for on-premises connectivity. Option E is possible but not a native Google Cloud service.
Which TWO are best practices for securing a VPC network? (Choose 2.)
This minimizes attack surface.
Why this answer
Option D is correct because firewall rules are the primary mechanism for controlling ingress traffic in a VPC. By restricting traffic to only necessary ports and source IPs, you minimize the attack surface and enforce the principle of least privilege. This is a fundamental security best practice for network segmentation and access control.
Exam trap
Google Cloud often tests the misconception that default firewall rules are secure or that enabling features like Private Google Access or VPC Peering directly improve VPC security, when in fact they serve different purposes and can introduce risks if not configured correctly.
Which THREE of the following are requirements for VPC Network Peering?
Overlapping IP ranges cannot be peered due to routing conflicts.
Why this answer
VPC Network Peering requires non-overlapping subnet IP ranges to prevent routing conflicts and ensure that traffic is correctly directed between the peered VPCs. Overlapping CIDR blocks would cause ambiguous routing, as the same IP address could exist in both VPCs, making it impossible for the VPC routers to determine the correct destination.
Exam trap
Google Cloud often tests the misconception that VPC Network Peering supports transitive routing, but the correct behavior is that peering is non-transitive and each pair must be explicitly configured.
An e-commerce website uses Cloud CDN to cache static content. The origin is an external HTTP load balancer. What is the benefit of enabling Cloud CDN in this scenario?
Content is cached at edges closer to users, reducing round-trip time.
Why this answer
Cloud CDN caches content at Google's global edge locations, which are geographically closer to end users. By serving static content from these edge caches instead of the origin HTTP load balancer, the request latency is significantly reduced because the data travels a shorter distance over the network.
Exam trap
Google Cloud often tests the misconception that CDN replaces security features like SSL or DDoS protection, but the trap here is that candidates confuse caching benefits with infrastructure scaling or security capabilities.
How to eliminate wrong answers
Option A is wrong because Cloud CDN does not eliminate the need for SSL certificates; the origin load balancer still requires an SSL certificate to terminate HTTPS, and the CDN can use Google-managed certificates for edge termination. Option B is wrong because while Cloud CDN can absorb some volumetric attacks through caching, it is not a dedicated DDoS protection service; Google Cloud Armor is the primary DDoS protection solution. Option C is wrong because Cloud CDN does not increase compute instance capacity; it offloads requests from the origin, reducing the load on backend instances, but does not add compute resources.
A company has deployed a web application on Compute Engine instances in a VPC with subnet 10.1.0.0/20. The instances need to access an external API that whitelists IP addresses. The company uses Cloud NAT to provide outbound connectivity. The API integration tests are failing, and the operations team suspects that the source IP addresses seen by the API are not consistent. What is the most likely cause and solution?
If the subnet is not in a NAT rule, instances may not use NAT or use different NAT IPs, causing inconsistent source IPs. Adding the subnet ensures consistent NAT IP usage.
Why this answer
Option D is correct because if Cloud NAT's default rule does not include the subnet 10.1.0.0/20, instances in that subnet will not have their outbound traffic translated through the NAT gateway, causing them to use their ephemeral public IPs (if any) or fail to reach the external API. Adding a custom NAT rule that explicitly includes the subnet ensures all outbound traffic from those instances uses the consistent NAT IP address that the API whitelist expects.
Exam trap
The trap here is that candidates assume Cloud NAT automatically applies to all subnets in the VPC, but in reality, the default rule must explicitly include the subnet, and if it is removed or not configured, traffic from that subnet will not be NATed.
How to eliminate wrong answers
Option A is wrong because endpoint-independent mapping (which preserves the same source IP and port for all sessions to a given destination) actually provides consistency; endpoint-dependent mapping would change the source IP per destination, causing inconsistency. Option B is wrong because dynamic port allocation is the default and does not affect source IP consistency; static port allocation is used for specific port forwarding rules, not for ensuring a consistent source IP. Option C is wrong because a manual NAT IP address is assigned to the Cloud NAT gateway, not to the instances; assigning it as an alias IP range to instances would bypass Cloud NAT and use the instance's own IP, defeating the purpose of NAT.
A company uses Cloud CDN with an external HTTP(S) load balancer. They have two origin server groups: a primary in us-central1 and a backup in europe-west1. They want traffic directed to the primary unless it is unhealthy, in which case traffic should fail over to the backup. Which configuration is required?
This is the correct architecture for failover across origins.
Why this answer
Option D is correct because Cloud CDN with an external HTTP(S) load balancer uses a backend service that can contain multiple backends (e.g., instance groups or NEGs) with a failover policy. When the primary backend is marked as unhealthy by the health check, the load balancer automatically routes traffic to the failover backend. This configuration meets the requirement without manual intervention.
Exam trap
The trap here is that candidates confuse Cloud CDN's origin settings with backend service failover policies, assuming CDN itself handles failover, when in fact failover is a property of the backend service used by the external HTTP(S) load balancer.
How to eliminate wrong answers
Option A is wrong because Cloud CDN does not have a built-in failover setting for origins; failover is configured at the backend service level, not within CDN settings. Option B is wrong because a TCP/UDP network load balancer uses target pools and does not support HTTP(S) traffic or failover policies between backends in different regions. Option C is wrong because weighted round-robin requires manual weight changes to fail over, which does not provide automatic failover based on health checks.
Ready to test yourself?
Try a timed practice session using only Network Services Config questions.