Google Practice Questions, Discussions & Exam Topics by our Authors

You recently deployed Compute Engine instances in regions us-west1 and us-east1 in a Virtual Private Cloud (VPC) with default routing configurations. Your company security policy mandates that virtual machines (VMs) must not have public IP addresses attached to them. You ...

Key Considerations: - Security Policy: The requirement is to prevent instances from having public IP addresses while allowing them to access the internet for updates. - VPC Design: The instances are already in a Virtual Private Cloud (VPC) and deployed in multiple regions (us-west1 and us-east1). - Connectivity to the Internet: Instances need to access the internet, so a solution that provides internet access without exposing instances to external traffic is required. - Routing and NAT: Network Address Translation (NAT) is often used for instances to access the internet while not exposing them to external access. Option Breakdown: - Option A: - Create a Cloud NAT gateway and Cloud Router in both us-west1 and us-east1: This option provides a NAT gateway in each region, allowing VMs without public IPs to access the internet. A Cloud Router would be needed to manage dynamic routes for outbound traffic. This option ensures that VMs in both regions can access the internet while adhering to the security policy. - Conclusion: This option works well but requires configuration in both regions, which could result in slightly higher complexity and cost due to the need for separate NAT gateways and Cloud Routers in each region. - Option B: - Create a single global Cloud NAT gateway and global Cloud Router in the VPC: A global Cloud NAT gateway would allow all instances in the VPC (across both us-west1 and us-east1) to access the internet without public IPs. It simplifies the architecture by using a single NAT gateway and router for the entire VPC. This is a cost...

Author: NightmareDragon2025 · Last updated Jul 26, 2026

You are designing a new global application using Compute Engine instances that will be exposed by a global HTTP(S) load balancer. You need to secure your application from distributed...

Key Considerations: - Security Requirements: The primary goal is to secure the application from distributed denial-of-service (DDoS) and application layer (Layer 7) attacks. DDoS attacks typically involve overwhelming a system with traffic, while Layer 7 attacks target the application itself (e.g., exploiting vulnerabilities in HTTP(S) requests). - Global HTTP(S) Load Balancer: Since the application is exposed through a global HTTP(S) load balancer, the solution should integrate with the load balancer and provide protections against both DDoS and application layer attacks. - Scope of Protection: The solution should be able to defend against both infrastructure-level attacks (e.g., DDoS) and application-level attacks (e.g., SQL injection, cross-site scripting). Option Breakdown: - Option A: - Configure VPC Service Controls and create a secure perimeter: VPC Service Controls provide data security by creating security perimeters around your services to protect against data exfiltration. While useful for securing access to Google Cloud services and data, this option does not directly address the need to protect against DDoS or Layer 7 attacks. It’s more suited to protecting sensitive data rather than mitigating network or application layer attacks. - Conclusion: This is not the best choice for securing your application from DDoS and Layer 7 attacks because it focuses on protecting data access, not application availability or security from external attacks. - Option B: - Configure a Google Cloud Armor security policy and attach it to the backend service: Google Cloud Armor is designed to protect applications from both DDoS and Layer 7 attacks. It can provide protection against high-volume attacks, as well as application-level attacks by applying security policies like rate limiting, geo-blocking, and custom rules. It integrates directly with Google Cloud’s HTTP(S) load balancer, making it the ideal ...

Author: Nia · Last updated Jul 26, 2026

Your organization's security policy requires that all internet-bound traffic return to your on-premises data center through HA VPN tunnels before egressing to the internet, while allowing virtual machines (VMs) to leverage private Google APIs using private virtual...

Let's break down each of the options with the requirements in mind: Requirements: - Internet-bound traffic must return to on-premises data center through HA VPN tunnels before egressing to the internet. - Virtual machines (VMs) need to access private Google APIs using private IPs (199.36.153.4/30). Option A: - Route 0.0.0.0/0 (internet traffic) with next hop as the default internet gateway and a priority of 500. - Route 199.36.153.4/30 with next hop as the VPN tunnel and a priority of 1000. This option routes all internet-bound traffic through the default internet gateway (which contradicts the requirement to go through the on-premises data center). The route for 199.36.153.4/30 is correct for accessing private Google APIs via the VPN tunnel, but internet traffic should first go through the on-premises data center, not the default internet gateway. This violates the primary requirement, so this option is rejected. Option B: - Route 0.0.0.0/0 (internet traffic) with next hop as the internet gateway and a priority of 1000. - Route 199.36.153.4/30 with next hop as the VPN tunnel and a priority of 500. This option places internet-bound traffic on the internet gateway, which is incorrect because we want it to go through the VPN tunnel to the on-premises data center. While the route for 199.36.153.4/30 is correct for accessing Google APIs via the VPN tunnel, this setup doesn’t properly...

Author: Aria · Last updated Jul 26, 2026

Your company has defined a resource hierarchy that includes a parent folder with subfolders for each department. Each department defines their respective project and VPC in the assigned folder and has the appropriate permissions to create Google Cloud firewall rules. The VPCs should not allow traffic to flow between them. You need to block a...

Let's break down each option and analyze its suitability for the requirements: Requirements: - Block traffic between VPCs to prevent communication between them. - Allow intra-VPC traffic within each department’s VPC, delegated to the respective departments. - Each department should have the appropriate permissions to manage its firewall rules. Option A: - Create a VPC firewall rule in each VPC to block traffic from any source, with priority 0. This option uses a priority 0 rule to block traffic from any source, which would block all traffic into and out of the VPC. However, priority 0 means this rule would have the highest priority, and thus it would block all traffic, including intra-VPC traffic, which is not desired. Since departments need to allow internal traffic within their own VPCs, this option is rejected because it would prevent intra-VPC traffic. Option B: - Create a VPC firewall rule in each VPC to block traffic from any source, with priority 1000. This option uses priority 1000, which is lower than the default priority of 1000 for other firewall rules. However, just like option A, this would block all traffic, including intra-VPC traffic, because the rule would be the first to evaluate (assuming no other rules are created for allowing intra-VPC traffic). This would also be a problem, as it prevents intra-VPC communication, violating the requirement for each department to have intra-VPC traffic. So, this option is also rejected. Option C: - Create two hierarchical firewall policies per department's folder with two rules in each: a high-priority rule that matches traffic from the private CIDRs assigned to the respective VPC and sets the action to allow, and another lower-priority rule that blocks traffic from any other source. This o...

Author: Sophia · Last updated Jul 26, 2026

You have two Google Cloud projects in a perimeter to prevent data exfiltration. You need to move a third project inside the perimeter; however, the move could negatively impact the existin...

To address this scenario, we need to validate the impact of moving the third project inside the Google Cloud perimeter while minimizing the potential risk of negative consequences on the existing environment. Let’s examine each option: Option A: Enable Firewall Rules Logging inside the third project. - Explanation: Firewall Rules Logging allows you to monitor the effect of firewall rules, providing insight into allowed and denied traffic within the project. - Why it's not selected: This option focuses on monitoring traffic flow rather than validating the overall impact of moving a project into a perimeter. Firewall logs may not provide enough information on broader impacts such as service interactions or cross-project access issues, which are central to the goal of validating the move. - Scenario: Useful if you're troubleshooting firewall rule effects but not for assessing the overall impact of moving a project into a perimeter. Option B: Modify the existing VPC Service Controls policy to include the new project in dry run mode. - Explanation: VPC Service Controls in "dry run" mode enables you to simulate the effect of adding a new project into the perimeter without actually implementing the changes. It helps you detect any violations, such as unauthorized access or potential service disruptions that may arise when the new project is added. - Why it’s selected: This is the best option because it directly addresses the need to validate the impact of moving the third project into the perimeter. The dry run mode allows you to safely test the configuration without any actual changes, which is essential for ensuring no negative impact on the existing environment. You can observe potential issues, such as access restrictions or service communication failures, before making any changes. - Scenario: Ideal for simulating the change in a controlled manner and ensuring it doesn't disrupt the existing setup. Option C: Monitor the Resource Manager audit logs inside the perimeter....

Author: Isabella · Last updated Jul 26, 2026

You are configuring an HA VPN connection between your Virtual Private Cloud (VPC) and on-premises network. The VPN gateway is named VPN_GATEWAY_1. You need to restrict VPN tunnels created in the project to o...

Let's evaluate each option for restricting VPN tunnels to only connect to your on-premises VPN public IP address: 203.0.113.1/32. Option A: Configure a firewall rule accepting 203.0.113.1/32, and set a target tag equal to VPN_GATEWAY_1. - Explanation: This option would create a firewall rule that allows inbound traffic from the IP address 203.0.113.1, and the firewall rule is applied specifically to the VPN gateway (identified by a target tag). While this might be useful for controlling traffic flow to the VPN gateway, it does not restrict the VPN tunnel connection itself based on the peer IP address at the tunnel configuration level. The firewall rule can be used to allow traffic, but it doesn't stop the creation of a tunnel with an incorrect peer IP address. - Why it’s not selected: This does not provide a restriction at the VPN tunnel level and is therefore not suitable for enforcing the peer IP address policy for the VPN connection. Firewall rules alone will not prevent the creation of tunnels to unwanted IP addresses. Option B: Configure the Resource Manager constraint constraints/compute.restrictVpnPeerIPs to use an allowList consisting of only the 203.0.113.1/32 address. - Explanation: This option uses a Resource Manager constraint (specifically `constraints/compute.restrictVpnPeerIPs`), which is a policy that restricts the allowed VPN peer IP addresses to a defined list. By setting the list to only include 203.0.113.1/32, this effectively enforces the restriction that VPN tunnels can only be established with the specified on-premises IP address. - Why it’s selected: This is the best solution because it directly addresses the requirement of restricting VPN tunnels to a specific peer IP address (203.0.113.1/32). This constraint operates at the level of the project or organization, ensuring that no unauthorized tunnels can be created. - Scenario: This is a policy-based solution, ideal for enforcing global, organization-wide restrictions on VPN peer IPs. I...

Author: Manish · Last updated Jul 26, 2026

Your company has recently installed a Cloud VPN tunnel between your on-premises data center and your Google Cloud Virtual Private Cloud (VPC). You need to configure access to the Cloud Functions API for your on-premises servers. The configuration must meet the following requirements: * Certain data must stay in the project where it is stored and not be exfiltrated to other projects. * Traffic from servers in your data center with RFC 1918 addresses do not use the in...

Let's break down the requirements and evaluate each option based on the given constraints: Requirements: 1. Certain data must stay in the project where it is stored and not be exfiltrated to other projects. 2. Traffic from servers with RFC 1918 addresses should not use the internet to access Google Cloud APIs. 3. All DNS resolution must be done on-premises. 4. The solution should only provide access to APIs compatible with VPC Service Controls. Option A: - Steps: 1. Create an A record for `private.googleapis.com` using the `199.36.153.8/30` address range. 2. Create a CNAME record for `.googleapis.com` that points to the A record. 3. Configure your on-premises routers to use the Cloud VPN tunnel as the next hop for the addresses used in the A record. 4. Remove the default internet gateway from the VPC where your Cloud VPN tunnel terminates. - Analysis: - The use of `private.googleapis.com` is correct because it is compatible with VPC Service Controls. - Removing the default internet gateway from the VPC ensures that traffic will be routed through the Cloud VPN tunnel and not over the internet, which meets the requirement of keeping the traffic within the VPC. - DNS resolution can still be done on-premises, as you're configuring your on-premises routers to route traffic to Google's private IP addresses. - Why it's selected: This option satisfies all the requirements: traffic stays within the VPC and uses the Cloud VPN tunnel for access to Google Cloud APIs, DNS resolution is on-premises, and the use of `private.googleapis.com` ensures data stays in the project and is not exfiltrated. Option B: - Steps: 1. Create an A record for `restricted.googleapis.com` using the `199.36.153.4/30` address range. 2. Create a CNAME record for `.googleapis.com` that points to the A record. 3. Configure your on-premises routers to use the Cloud VPN tunnel as the next hop for the addresses used in the A record. 4. Configure your on-premises firewalls to allow traffic to the `restricted.googleapis.com` addresses. - Analysis: - While using `restricted.googleapis.com` could work for VPC Service Controls, the key issue here is the on-premises firewalls. Configuring firewalls to allow traffic is an additional manual step, adding complexity to the configuration. - The on-premises firewall configuration might introduce operational overhead and complexity in ensuring access is restricted as required. Hence, the ...

Author: Charlotte · Last updated Jul 26, 2026

You need to configure a Google Kubernetes Engine (GKE) cluster. The initial deployment should have 5 nodes with the potential to scale to 10 nodes. The maximum number of Pods per node is 8. The number of services could grow...

To design the IP schema for your Google Kubernetes Engine (GKE) cluster, we need to ensure that the IP address space is large enough to support all nodes, pods, and services in the cluster, while keeping scalability in mind. Let's break down the key requirements and evaluate the options: Key Requirements: 1. Nodes: The initial deployment will have 5 nodes, with potential scaling up to 10 nodes. - A node requires a primary IP address. 2. Pods: Each node can have up to 8 pods. - The number of pods will grow as more nodes are added. 3. Services: The number of services will grow from 100 to up to 1024. - The number of services also needs a reasonable IP range. Breakdown of the IP Range Requirements: 1. Nodes: - If you have up to 10 nodes and need 1 IP per node, the IP range for nodes should be able to accommodate at least 10 IPs. - A /28 subnet gives you 16 IPs (14 usable IPs, excluding the network and broadcast IPs). This is more than sufficient for the 10 nodes. 2. Pods: - You will have 8 pods per node, and with 10 nodes, you would need a total of 80 pod IPs at full scale (10 nodes 8 pods). To account for growth, we need a subnet that can cover more IPs. - A /25 subnet provides 128 IPs (126 usable IPs), which is sufficient for up to 8 pods per node across 10 nodes (80 pods), with room for expansion. 3. Services: - Services in GKE are allocated IPs from a separate IP range. For 100 to 1024 services, you need a range that can support this growth. - A /22 subnet provides 1024 IPs (1022 usable IPs), which can easily handle 1024 services. Evaluation of Options: Option A: - /28 primary IP range for nodes: Provides 16 IPs, which is adequate for the 10 nodes. - /25 secondary IP range for Pods: Provides 128 IPs, which can accommodate up to 80 pods, with room for more as the cluster grows. - /22 secondary IP range for Services: Provides 1024 IP...

Author: Manish · Last updated Jul 26, 2026

You are migrating a three-tier application architecture from on-premises to Google Cloud. As a first step in the migration, you want to create a new Virtual Private Cloud (VPC) with an external HTTP(S) load balancer. This load balancer will forward traffic back to the on-premises compute resources that run the presentation tier. You need to stop malicious traffic from entering yo...

When migrating a three-tier application architecture to Google Cloud and setting up a new Virtual Private Cloud (VPC) with an external HTTP(S) load balancer, your objective is to stop malicious traffic from entering your VPC, filter IP addresses, and prevent cross-site scripting (XSS) attacks. Let's evaluate the options to find the best solution. Key Requirements: 1. Traffic Filtering: The primary goal is to filter malicious traffic and stop it from entering your VPC at the edge (via the load balancer). 2. Prevent XSS: Protect against cross-site scripting (XSS) attacks, typically through filtering or blocking malicious HTTP requests. 3. Use of Google Cloud Armor: Google Cloud Armor is a service designed to protect your applications from a wide range of threats, including DDoS attacks and malicious traffic filtering, such as filtering by IP address and preventing XSS attacks. Option Evaluation: Option A: Create a Google Cloud Armor policy and apply it to a backend service that uses an unmanaged instance group backend. - Google Cloud Armor is a highly suitable solution for protecting your HTTP(S) load balancer, as it can be configured to filter traffic based on IP addresses, block specific attack vectors (like XSS), and provide WAF (Web Application Firewall) functionality. - However, unmanaged instance groups are typically less dynamic compared to Google Cloud's network endpoint groups (NEGs), which are better suited for handling HTTP(S) traffic with the external load balancer. - Although this option could technically work, it is not the most optimal since Google Cloud Armor works more seamlessly with NEGs for HTTP(S) load balancing. Option B: Create a hierarchical firewall ruleset and apply it to the VPC's parent organization resource node. - Hierarchical firewall rules are a way to define firewall rules at a higher level within an organization, but this is not the most appropriate tool for filtering traffic at the ...

Author: Ryan · Last updated Jul 26, 2026

You just finished your company's migration to Google Cloud and configured an architecture with 3 Virtual Private Cloud (VPC) networks: one for Sales, one for Finance, and one for Engineering. Every VPC contains over 100 Compute Engine instances, and now developers using instances in the Sales VPC and the Finance VPC require private connectiv...

To allow private connectivity between the Sales VPC and the Fice VPC without compromising performance or security, let's analyze each option based on the requirements. Key Requirements: 1. Private Connectivity: Communication should be private, ensuring no exposure to the public internet. 2. Security: The solution should be secure and not expose sensitive internal resources. 3. Performance: The solution should not compromise network performance. Option Evaluation: Option A: Configure an HA VPN gateway between the Fice VPC and the Sales VPC. - HA VPN (High Availability VPN) provides a secure connection over the public internet between two networks, but this option is designed for connecting on-premises networks to Google Cloud, or Google Cloud VPCs to other Google Cloud VPCs over the public internet. - Although VPN connections are secure, using HA VPN between VPCs adds unnecessary complexity and could introduce latency or performance issues due to relying on the public internet. - This option is not ideal because it doesn’t prioritize private communication and could lead to performance degradation compared to other options designed for VPC-to-VPC communication. Option B: Configure the instances that require communication between each other with an external IP address. - Assigning external IP addresses to instances would expose them to the public internet, making them vulnerable to external threats. - This option compromises security because communication over public IP addresses means the traffic is not private, and it could potentially be intercepted or attacked. - This solution is not suitable because it does not meet the requirement for pr...

Author: RadiantJaguar56 · Last updated Jul 26, 2026

You have provisioned a Partner Interconnect connection to extend connectivity from your on-premises data center to Google Cloud. You need to configure a Cloud Router and create a VLAN attachment to connect to resources inside your VPC. You need to configure an Autonomou...

To connect your on-premises data center to Google Cloud using Partner Interconnect, you'll need to configure a Cloud Router and create a VLAN attachment. The configuration will also require you to choose an appropriate Autonomous System Number (ASN) for the Cloud Router to handle Border Gateway Protocol (BGP) routing. Key Considerations: 1. ASN Selection: The ASN represents a unique identifier for your network when using BGP for routing. There are two types of ASN: private and public. - Private ASNs are used for internal routing within your network or between your on-premises data center and Google Cloud. - Public ASNs are used when you're directly connecting to the global internet or a large-scale service provider. 2. Private ASN: Google Cloud supports using private ASNs for interconnections like Partner Interconnect and VPNs, and these are commonly used for private communication between Google Cloud and your on-premises network. 3. Public ASN: Public ASNs are generally assigned to internet-facing connections or large-scale interconnection services. Google Cloud assigns certain public ASNs for services like Dedicated Interconnect or to advertise routes to the internet. Option Evaluation: Option A: Use a 4-byte private ASN 4200000000-4294967294. - The 4-byte private ASN range (4200000000-4294967294) is allowed for private usage, and you can assign these ranges for internal purposes in your Cloud Router. - However, 4-byte ASNs are less common and typically used when you're dealing with large-scale organizations or require compatibility with other 4-byte ASN requirements. - This option is valid, ...

Author: IceDragon2023 · Last updated Jul 26, 2026

You are configuring a new application that will be exposed behind an external load balancer with both IPv4 and IPv6 addresses and support TCP pass-through on port 443. You will have backends in two regions: us-west1 and us-east1. You want to serve the content with...

To configure your new application exposed behind an external load balancer with IPv4 and IPv6 addresses, support for TCP pass-through on port 443, and backends in two regions (us-west1 and us-east1), there are several factors to consider: 1. Low Latency: You want to serve content with the lowest possible latency, which means selecting a load balancer that can direct traffic to the nearest backend. 2. High Availability: The solution should be highly available, ensuring minimal downtime. 3. Autoscaling: The load balancer should support autoscaling to dynamically adjust to changes in traffic. 4. TCP Pass-through: Since the application is configured for TCP pass-through on port 443, the load balancer must support TCP traffic. Option Evaluation: Option A: Use global SSL Proxy Load Balancing with backends in both regions. - SSL Proxy Load Balancing is designed to handle SSL traffic but operates at the application layer (Layer 7), terminating SSL connections and forwarding traffic to backend instances. However, SSL Proxy Load Balancing is not suitable for TCP pass-through traffic, as it handles the traffic at a higher layer (Layer 7) and requires SSL termination. - Since you need TCP pass-through, this option is not suitable for your use case. Option B: Use global TCP Proxy Load Balancing with backends in both regions. - TCP Proxy Load Balancing can handle TCP pass-through traffic and operates at Layer 4, which allows it to forward traffic to the backends without terminating the connection. This makes it an ideal choice for use cases where you want to pass TCP traffic (like your requirement for TCP pass-through on port 443). - It is global in nature, mean...

Author: Emma Brown · Last updated Jul 26, 2026

In your project my-project, you have two subnets in a Virtual Private Cloud (VPC): subnet-a with IP range 10.128.0.0/20 and subnet-b with IP range 172.16.0.0/24. You need to deploy database servers in subnet-a. You will also deploy the application servers and web servers in subnet-b. You want to co...

To solve the problem of configuring firewall rules that only allow database traffic from the application servers to the database servers, let's analyze each of the proposed options. Option A: - Description: You create a network tag `app-server` and a service account `sa-db@my-project.iam.gserviceaccount.com`. You add the tag to the application servers and associate the service account with the database servers. The firewall rule is created with `source-tags app-server` and `target-service-accounts sa-db@my-project.iam.gserviceaccount.com`. - Analysis: - The use of network tags in combination with service accounts provides a way to filter traffic based on the application server's tag and the database server's service account. - However, the firewall rule is using `source-tags app-server` and `target-service-accounts sa-db`, which could potentially cause confusion about which resources are being targeted. Also, service accounts should be targeted by service account, not tags. - Conclusion: This option is flawed because it mixes tags and service accounts incorrectly. Tags should be used with VM instances, not with service accounts directly in firewall rules. Option B: - Description: Create service accounts `sa-app@my-project.iam.gserviceaccount.com` and `sa-db@my-project.iam.gserviceaccount.com`. Associate these service accounts with the application servers and the database servers. The firewall rule is created with `source-service-accounts sa-app@my-project.iam.gserviceaccount.com` and `target-service-accounts sa-db@my-project.iam.gserviceaccount.com`. - Analysis: - This approach focuses on service accounts for controlling access, which is a solid method in scenarios where you need strict access control based on the identity of the services. - However, service accounts cannot directly control the traffic between different subnets using IP address ranges. Service accounts control what actions a VM can perform, not where it can send traffic to. - Service accounts are more suited for permissions related to API access or cloud resources, but this approach does not account for the subnet segmentation and network rules in this context. - Conclusion: This is not ideal for the case, because it relies only on service accounts for traffic filtering, whic...

Author: Elijah · Last updated Jul 26, 2026

You are planning a large application deployment in Google Cloud that includes on-premises connectivity. The application requires direct connectivity between workloads in all regions and on-premises locations without address transl...

Let's analyze each option carefully to determine the most suitable approach for your large application deployment in Google Cloud that requires direct connectivity between workloads in all regions and on-premises locations without address translation, while avoiding conflicts with already used RFC 1918 ranges. Option A: Use multiple VPC networks with a transit network using VPC Network Peering. - Description: This option suggests setting up multiple VPC networks and interconnecting them using VPC Network Peering. - Analysis: - VPC Peering allows you to connect VPCs in the same or different regions. However, VPC Peering doesn’t support overlapping IP ranges (i.e., the IP ranges must be disjointed). - Since the on-premises locations already use RFC 1918 IP ranges, using VPC Peering is not ideal because VPC Peering requires unique IP ranges between peered VPCs, which would conflict with the requirement to avoid address translation and with overlapping RFC 1918 ranges. - Conclusion: This option is not viable because VPC Peering cannot handle overlapping IP ranges, and your on-premises locations already use RFC 1918 IP ranges. Option B: Use overlapping RFC 1918 ranges with multiple isolated VPC networks. - Description: This option proposes using overlapping RFC 1918 ranges with multiple isolated VPCs. - Analysis: - Overlapping RFC 1918 ranges create problems because IP ranges must be unique for routing, especially in a multi-region and multi-network environment. Google Cloud requires disjoint IP addresses for VPC peering or shared VPCs. - Additionally, having isolated VPCs means you'd need complex routing setups, and connectivity with on-premises networks would require extra steps like VPN or Interconnect, and translating the overlapping addresses becomes complex. - Address translation (NAT) might still be needed here to ensure traffic routing works properly. - Conclusion: This option is not feasible because overlapping IP ranges lead to routing and address translation challenges. Option C: Use overlapping RFC 1918 ranges with multiple isolated VPC networks and Cloud NAT. - Description: This option suggests using overlapping RFC 1918 ranges with multiple isolated VPC networks and C...

Author: Rohan · Last updated Jul 26, 2026

Your company's security team wants to limit the type of inbound traffic that can reach your web servers to protect against security threats. You need to configure the firewall rules on the web servers within your Virt...

Let's analyze the different options for configuring the firewall rules to allow only HTTP (TCP port 80) and HTTPS (TCP port 443) traffic to your web servers within your Virtual Private Cloud (VPC). Option A: Create an allow on match ingress firewall rule with the target tag "web-server" to allow all IP addresses for TCP port 80. - Description: This rule allows ingress (incoming) traffic to your web servers for TCP port 80 (HTTP) from all IP addresses. - Analysis: - Ingress rules are used to control incoming traffic to your resources. This option only allows HTTP traffic (TCP port 80) but doesn't include HTTPS (TCP port 443). - This rule is limiting because it only opens port 80, missing the need to allow HTTPS (port 443), which is crucial for secure communication. - Conclusion: This option is not sufficient because it does not allow HTTPS traffic and doesn't meet the requirement for both HTTP and HTTPS traffic. Option B: Create an allow on match egress firewall rule with the target tag "web-server" to allow all IP addresses for TCP port 80. - Description: This rule allows egress (outgoing) traffic from your web servers for TCP port 80. - Analysis: - Egress rules control outgoing traffic, not incoming. However, the requirement here is to limit incoming traffic to the web servers for HTTP and HTTPS. - Allowing egress traffic on TCP port 80 would not address the security team's concern regarding restricting incoming traffic to the web servers. - Conclusion: This option is rejected because the rule is for outgoing traffic, not incoming, which doesn't satisfy the given requirement for limiting inbound traffic to the web servers. Option C: Create an allow on match ingress firewall ...

Author: Noah · Last updated Jul 26, 2026

You successfully provisioned a single Dedicated Interconnect. The physical connection is at a colocation facility closest to us-west2. Seventy-five percent of your workloads are in us-east4, and the remaining twenty-five percent of your workloads are in us-central1. All workloads have the...

Let's carefully examine the given options and reason through the best way to minimize data transfer costs in your scenario. Scenario Breakdown: - You have 75% of your workloads in us-east4 and 25% in us-central1. - You already have a single Dedicated Interconnect with a physical connection at a colocation facility closest to us-west2. - The goal is to minimize data transfer costs when deploying VLAN attachments. When minimizing data transfer costs, the key considerations are: 1. Proximity to workloads: The closer the interconnect or colocation facility is to the workloads, the cheaper the data transfer costs will be. 2. Inter-region data transfer: Data transfer across regions (e.g., from us-east4 to us-central1) is more expensive than within a single region. Option A: Keep the existing Dedicated Interconnect. Deploy a VLAN attachment to a Cloud Router in us-west2, and use VPC global routing to access workloads in us-east4 and us-central1. - Analysis: - Your interconnect is closest to us-west2, but this will cause traffic to travel across multiple regions (us-west2 to us-east4 and us-central1), which is likely to incur higher data transfer costs. - VPC global routing means that traffic could go through regions farther from your workloads, which adds to the cost. - Given that 75% of workloads are in us-east4, this approach would not be optimal, as it forces the majority of traffic to route through an interconnect that is far from the primary workload location (us-east4). - Conclusion: This option isn't ideal because of the longer path for the majority of your traffic (to us-east4) and the potential higher data transfer costs. Option B: Keep the existing Dedicated Interconnect. Deploy a VLAN attachment to a Cloud Router in us-east4, and deploy another VLAN attachment to a Cloud Router in us-central1. - Analysis: - This option keeps the existing Dedicated Interconnect but places VLAN attachments at the closest regions for the majority of your traffic (us-east4 for 75% of the workloads and us-central1 for the remaining 25%). - By deploying VLAN attachments in both us-east4 and us-central1, the traffic will stay within the regions where your workloads are located, minimizing cross-region traffic and reducing transfer costs. ...

Author: Layla · Last updated Jul 26, 2026

You are designing a hybrid cloud environment. Your Google Cloud environment is interconnected with your on-premises network using HA VPN and Cloud Router in a central transit hub VPC. The Cloud Router is configured with the default settings. Your on-premises DNS server is located at 192.168.20.88. You need to ensure that your Compute Engine resources in multiple spoke VPCs can resolve on-premi...

To resolve the private hostnames in your hybrid cloud environment, we need to configure DNS resolution between your on-premises network and Google Cloud, following the best practices. The solution needs to meet the following criteria: 1. Private DNS Resolution: Compute Engine resources in your spoke VPCs should be able to resolve both on-premises hostnames and Google Cloud hostnames. 2. Centralized Hub VPC: The DNS configuration should leverage the existing Cloud Router and HA VPN setup in the central transit hub VPC to allow resolution of on-premises hostnames. 3. Google Cloud Best Practices: We must follow Google’s recommended practices for DNS resolution and hybrid connectivity. Let's review each option to find the most suitable approach: Option A: 1. Create a private forwarding zone for `corp.altostrat.com` in Cloud DNS pointing to the on-premises DNS server (192.168.20.88) and associate it with the hub VPC. 2. Create a private peering zone in Cloud DNS for `corp.altostrat.com` associated with the spoke VPCs, with the hub VPC as the target. 3. Set a custom route advertisement on Cloud Router for the range `35.199.192.0/19`. 4. Configure VPC peering in the spoke VPCs to peer with the hub VPC. - Analysis: This option suggests peering VPCs, but VPC peering alone doesn't directly address the DNS resolution for on-premises resources. The DNS peering configuration across spoke VPCs will work for internal DNS resolution within Google Cloud. However, VPC Peering doesn't propagate DNS records or resolve on-premises private hostnames directly. - Conclusion: VPC Peering isn’t necessary for DNS resolution across regions and doesn’t fully support this use case for hybrid DNS setup. Option B: 1. Create a private forwarding zone for `corp.altostrat.com` in Cloud DNS pointing to 192.168.20.88 and associate it with the hub VPC. 2. Create a private peering zone in Cloud DNS for `corp.altostrat.com` associated with the spoke VPCs, with the hub VPC as the target. 3. Set a custom route advertisement on the Cloud Router for `35.199.192.0/19`. - Analysis: This configuration enables DNS resolution for on-premises hostnames through the central hub, which is correct. However, it misses the route advertisement and VPC peering configuration, which would be important for ensuring proper connectivity to the on-premises DNS server. - C...

Author: David · Last updated Jul 26, 2026

You have the following firewall ruleset applied to all instances in your Virtual Private Cloud (VPC): You need to update the firewall rule to add the following rule to the ruleset: You are using a new user account. You must assign the appropriate identity and Access Management (IAM) user roles to this new user ...

In order to determine the most appropriate option, we need to analyze the roles and their associated permissions in relation to the tasks the new user must perform (update the firewall rule and view logs), and consider the priority settings for the firewall rule. 1. IAM Roles Consideration: - compute.securityAdmin: This role allows the user to manage firewall rules, which is necessary to update the firewall rule. - logging.viewer: This role allows the user to view logs, which is required to view the firewall logs. - logging.bucketWriter: This role is for managing log export to Cloud Storage buckets and writing logs to a bucket. This role is not necessary for simply viewing firewall logs. - compute.orgSecurityPolicyAdmin: This role allows users to manage security policies at the organization level, which might be useful for high-level security configuration changes but isn't required for managing firewall rules on a project level. 2. Task Requirements: - The user needs the ability to apply the firewall update and view firewall logs. - The compute.securityAdmin and logging.viewer roles are the most appropriate for this requirement, as they direct...

Author: Leah Davis · Last updated Jul 26, 2026

Your organization has a single project that contains multiple Virtual Private Clouds (VPCs). You need to secure API access to your Cloud Storage buckets and BigQuery datasets by allowing API...

In this scenario, we need to secure API access to Cloud Storage and BigQuery datasets, restricting access only from your corporate public networks. Let's evaluate each option in detail. 1. Option A: Create an access context policy that allows your VPC and corporate public network IP ranges, and then attach the policy to Cloud Storage and BigQuery. - Access context policies define which resources or networks are allowed to access specific services based on various factors (like network or identity). This policy could effectively allow access from your VPC and corporate public networks, securing access to Cloud Storage and BigQuery. - However, access context policies alone aren't sufficient to secure APIs on their own without being part of a broader access control solution like VPC Service Controls. This would be useful in scenarios where you want a simple, direct restriction for APIs from particular networks, but on its own, it may not be the best solution for securing service access across multiple VPCs. 2. Option B: Create a VPC Service Controls perimeter for your project with an access context policy that allows your corporate public network IP ranges. - VPC Service Controls are designed to provide strong security for Google Cloud services (like BigQuery and Cloud Storage) by enforcing perimeters around data and limiting access from unauthorized networks. - This is a solid solution because VPC Service Controls help enforce access restrictions from specific networks (like your corporate network), and combining it with an access context policy ensures only the allowed networks (your VPC and corporate public IP ranges) can access sensitive services. - Best fit for securing API access to services like BigQuery and Cloud Storage by establishing strict perimeter-based controls for your project. 3. Option C: Create a firewall rule to block API access to Cloud Storage and BigQuery f...

Author: CrimsonViperX · Last updated Jul 26, 2026

Your company has provisioned 2000 virtual machines (VMs) in the private subnet of your Virtual Private Cloud (VPC) in the us-east1 region. You need to configure each VM to have a minimum of 128 TCP connections to a public repository so that users can download software updates and packages over the internet. You need to implement a Cloud NAT gateway so that the VMs are able to perform outbound NAT to the internet. You mu...

To ensure that all 2000 virtual machines (VMs) in the private subnet of your Virtual Private Cloud (VPC) can simultaneously connect to the public repository and download software updates with a minimum of 128 TCP connections per VM, while using a Cloud NAT gateway, let's analyze the available options: Key factors: 1. Cloud NAT gateway: A managed service that allows VMs in private subnets to access the internet for outbound traffic while keeping the VMs isolated from direct inbound internet access. 2. TCP Connections: Each VM needs at least 128 TCP connections to connect to a public repository, and Cloud NAT needs to scale to accommodate the required number of ports. 3. NAT IP addresses: Each Cloud NAT IP address has a finite number of ports it can allocate. By adjusting the number of NAT IP addresses and ports per VM, we can ensure that the number of concurrent outbound connections (128 TCP connections per VM) is met for all VMs. Option A: Configure the NAT gateway in manual allocation mode, allocate 2 NAT IP addresses, and update the minimum number of ports per VM to 256. - Reasoning: Allocating 2 NAT IP addresses with 256 ports per VM would provide enough capacity for 2000 VMs. However, this would be an over-provisioning scenario as it provides more ports per VM than needed (128 ports). While this approach works, it would be more efficient to scale the number of NAT IP addresses dynamically and set the ports to an optimal value. - Rejected: Over-allocating ports can lead to inefficiency and unnecessary costs. Option B: Create a second Cloud NAT gateway with the default minimum number of ports configured per VM to 64. - Reasoning: Creating a second Cloud NAT gateway doesn't seem to address the requirement for 128 TCP connections per VM. The default minimum of 64 ports per VM would not meet the requirement of 128 connections, so this configuration wouldn't work without additional adjustments. - Rejected: The default minimum of 64 ports per VM is insufficient for the requirement of 128 connections. O...

Author: Deepak · Last updated Jul 26, 2026

You have the following routing design. You discover that Compute Engine instances in Subnet-2 in the asia-southeast1 region cannot communi...

To resolve the issue of Compute Engine instances in Subnet-2 in the asia-southeast1 region being unable to communicate with compute resources on-premises, let's go through each option and analyze it based on the situation. Key Considerations: - The issue is related to communication with on-premises resources. - This likely involves Cloud Router and Border Gateway Protocol (BGP), as these are typically used for communication between Google Cloud VPCs and on-premises networks. - The VPC dynamic routing settings and the correct setup of BGP sessions are key factors that can influence the routing between VPCs and on-premises networks. Option A: Configure a custom route advertisement on the Cloud Router. - Reasoning: In this context, the Cloud Router handles the routing between your VPC and on-premises network using BGP. A custom route advertisement can be used to advertise specific routes between your VPC and on-premises, but this option presupposes that the issue lies with the existing route advertisement. - Rejected: This solution doesn't directly address the problem of the inability to communicate. It might be applicable if the routes are missing or incorrectly advertised, but it's more of an optimization rather than a direct fix. Option B: Enable IP forwarding in the asia-southeast1 region. - Reasoning: IP forwarding is necessary for Compute Engine instances that need to forward packets that are not intended for them (e.g., acting as routers). However, IP forwarding is usually required when an instance acts as a router or gateway. The issue mentioned is about communication to on-premises resources, so enabling IP forwarding wouldn't directly address the problem. - Rejected: This is more relevant when dealing with specific VM routing or gateway configurations, not for fixing routing to on-premises resources throug...

Author: Isabella · Last updated Jul 26, 2026

You are designing a hybrid cloud environment for your organization. Your Google Cloud environment is interconnected with your on-premises network using Cloud HA VPN and Cloud Router. The Cloud Router is configured with the default settings. Your on-premises DNS server is located at 192.168.20.88 and is protected by a firewall, and your Compute Engine resources are located at 10.204.0.0/24. Your Compute Engine resources need to re...

In this scenario, you need to allow Compute Engine resources in Google Cloud to resolve on-premises private hostnames (from your on-premises DNS server at 192.168.20.88) while still resolving Google Cloud hostnames. Let’s analyze each option carefully, keeping in mind Google-recommended practices and network security considerations. Key Factors: 1. Hybrid DNS resolution: Compute Engine instances in Google Cloud need to resolve both on-premises DNS names and Google Cloud DNS names. 2. Private DNS forwarding: You need a DNS forwarding solution that integrates with your on-premises DNS server while allowing for seamless access to Google Cloud DNS. 3. Firewall configuration: The on-premises DNS server is protected by a firewall, so you'll need to ensure that traffic from the Google Cloud VPC (specifically the `10.204.0.0/24` subnet) is allowed to reach the DNS server. 4. Cloud Router: Cloud Router manages dynamic route exchanges with your on-premises network. Proper route advertisements are required to ensure correct routing between Google Cloud and your on-premises network. Option A: 1. Create a private forwarding zone in Cloud DNS for ‘corp.altostrat.com’ called `corp-altostrat-com` that points to `192.168.20.88`. 2. Configure your on-premises firewall to accept traffic from `10.204.0.0/24` (your Google Cloud subnet). 3. Set a custom route advertisement on the Cloud Router for `10.204.0.0/24`. - Reasoning: This option is close to the correct approach. You create a private forwarding zone in Cloud DNS, which is a good practice for integrating with your on-premises DNS. Allowing the firewall to accept traffic from the correct subnet (`10.204.0.0/24`) ensures that your Compute Engine instances can communicate with the on-premises DNS server. The custom route advertisement for `10.204.0.0/24` is unnecessary, as this route is already internal to Google Cloud. - Rejected: The custom route advertisement for `10.204.0.0/24` is redundant since traffic to this subnet does not require any special routing advertisements. Option B: 1. Create a private forwarding zone in Cloud DNS for ‘corp.altostrat.com’ called `corp-altostrat-com` that points to `192.168.20.88`. 2. Configure your on-premises firewall to accept traffic from `35.199.192.0/19`. 3. Set a custom route advertisement on the Cloud Router for `35.199.192.0/19`. - Reasoning: The subnet `35.199.192.0/19` is not part of your Google Cloud VPC (`10.204.0.0/24`). The Google Cloud VPC's traffic should be routed to your on-premises network, but using `35.199....

Author: Olivia · Last updated Jul 26, 2026

Your company has a single Virtual Private Cloud (VPC) network deployed in Google Cloud with on-premises connectivity already in place. You are deploying a new application using Google Kubernetes Engine (GKE), which must be accessible only from the same VPC network and on-premises locations. You must ensure th...

Let's analyze the options based on your requirements: Requirements: 1. The GKE control plane must be accessible only from the same VPC network and on-premises locations. 2. The GKE control plane should be exposed to a predefined list of on-premises subnets through private connectivity only. Option A: Create a GKE private cluster with a private endpoint for the control plane. Configure VPC Networking Peering export/import routes and custom route advertisements on the Cloud Routers. Configure authorized networks to specify the desired on-premises subnets. - Explanation: A private GKE cluster with a private endpoint ensures that the control plane is only accessible via private IPs, meeting the requirement for private connectivity. VPC peering and custom route advertisements allow routing between your VPC and on-premises subnets. Authorized networks will ensure that only the specified on-premises subnets can reach the GKE control plane. - Why this option works: This option meets all of the requirements—private connectivity, access control, and the ability to use predefined on-premises subnets. It ensures that there is no exposure to the public internet. Option B: Create a GKE private cluster with a public endpoint for the control plane. Configure VPC Networking Peering export/import routes and custom route advertisements on the Cloud Routers. - Explanation: This setup creates a private GKE cluster but exposes the control plane endpoint to the public internet. Even though VPC peering and route advertisements help with on-premises access, the public endpoint introduces unnecessary exposure. - Why this option does not work: The control plane is publicly exposed, which violates the requirement for private connectivity only. The u...

Author: Joseph · Last updated Jul 26, 2026

You built a web application with several containerized microservices. You want to run those microservices on Cloud Run. You must also ensure that the services are h...

Requirements: - The web application must run containerized microservices on Cloud Run. - The services must be highly available and provide low latency to customers. Let's evaluate each option based on these factors: Option A: Deploy the Cloud Run services to multiple availability zones. Create a global TCP load balancer. Add the Cloud Run endpoints to its backend service. - Explanation: Cloud Run automatically provides scaling and high availability within a single region by deploying to multiple availability zones. However, a TCP load balancer is typically used for non-HTTP(S) traffic and would not be the best fit for HTTP-based services running on Cloud Run, especially because Cloud Run services are designed for HTTP(S) traffic. This option doesn’t leverage Cloud Run’s serverless architecture as efficiently as other options. - Why this option is rejected: Using a TCP load balancer for HTTP-based microservices is not optimal. Additionally, Cloud Run automatically scales across availability zones within a region without needing additional load balancing configurations. This option doesn't fully leverage the power of Cloud Run’s serverless capabilities or global distribution. Option B: Deploy the Cloud Run services to multiple regions. Create serverless network endpoint groups (NEGs) that point to the services. Create a global HTTPS load balancer, and attach the serverless NEGs as backend services of the load balancer. - Explanation: This is the best approach for Cloud Run services when high availability and low latency across different geographical locations are required. Deploying to multiple regions provides redundancy and ensures that the services are close to end users, reducing latency. Serverless NEGs allow integration between Cloud Run and Google Cloud’s global HTTPS load balancer, ensuring high availability and low-latency routing across regions. - Why this option works: The global HTTPS load balancer intelligently routes requests to the nearest Cloud Run service in the available region, ensuring low latency and high availability. It also scales automatically with demand and...

Author: Leo · Last updated Jul 26, 2026

You have an HA VPN connection with two tunnels running in active/passive mode between your Virtual Private Cloud (VPC) and on-premises network. Traffic over the connection has recently increased from 1 gigabit per second (Gbps) to 4 Gbps, and you notice that packets ...

Let's analyze the options for scaling your VPN connection to support 4 Gbps of traffic, ensuring there is no packet loss. Requirements: - Your existing VPN setup is using active/passive mode with two tunnels. - Traffic has increased to 4 Gbps, and packets are being dropped, which suggests the current configuration might not be handling the increased traffic load. - You need to scale the VPN connection to support 4 Gbps without packet loss. Option A: Configure the remote autonomous system number (ASN) to 4096. - Explanation: The autonomous system number (ASN) is used in Border Gateway Protocol (BGP) to identify the network that is advertising routes. Changing the ASN is typically related to BGP configuration for routing and does not directly affect the VPN tunnel bandwidth or performance. - Why this option is rejected: Changing the ASN does not solve the issue of bandwidth limitations. It is related to routing and does not affect the maximum throughput of the VPN tunnel. This option is not relevant for addressing packet drops due to increased traffic. Option B: Configure a second Cloud Router to scale bandwidth in and out of the VPC. - Explanation: Adding a second Cloud Router could provide redundancy and routing scalability for your VPN connection. However, it does not directly impact the bandwidth or help with scaling the VPN tunnels to support higher throughput. You would still be limited by the single VPN tunnel's capacity, even if you add another Cloud Router. - Why this option is rejected: This option could be useful for routing purposes or high-availability configurations, but it doesn't address the need to scale the VPN tunnel bandwidth. The limitation is the tunnel capacity itself, not the number of routers. Option C: Configure the maximum transmission unit (MTU) to its highest supported value. - Explanation: MTU defines the larges...

Author: RadiantJaguar56 · Last updated Jul 26, 2026

You recently deployed two network virtual appliances in us-central1. Your network appliances provide connectivity to your on-premises network, 10.0.0.0/8. You need to configure the routing for your Virtual Private Cloud (VPC). Your design must meet the following requirements: * All access to your on-premises network must go through the network virtual appliances. * Allow on-premises access in...

Requirements: - All access to the on-premises network (10.0.0.0/8) must go through the network virtual appliances. - Allow on-premises access in the event of a single network virtual appliance failure. - Both network virtual appliances must be used simultaneously for load balancing and redundancy. Let's evaluate each option: Option A: Configure two routes for 10.0.0.0/8 with different priorities, each pointing to separate network virtual appliances. - Explanation: This option involves configuring two routes for the same network (10.0.0.0/8) in the routing table, each pointing to a different network virtual appliance. By adjusting priorities, one route would be used as the primary, and the other would serve as a backup in case of failure. - Why this option is rejected: While this provides redundancy (with one route acting as a backup), it does not use both network virtual appliances simultaneously. Only one appliance would be active at any given time, which violates the requirement to utilize both appliances for load balancing. This option also doesn’t address the need for failure detection or traffic distribution. Option B: Configure an internal HTTP(S) load balancer with the two network virtual appliances as backends. Configure a route for 10.0.0.0/8 with the internal HTTP(S) load balancer as the next hop. - Explanation: An HTTP(S) load balancer is typically used for HTTP/S-based traffic, which is a layer 7 service. While it can provide load balancing and redundancy, it is not typically used for routing non-HTTP(S) traffic like VPN or other network protocols that your network virtual appliances would handle. Additionally, the internal HTTP(S) load balancer does not directly meet the routing requirements for a network appliance setup that needs to handle general network traffic. - Why this option is rejected: This option is not suitable for non-HTTP(S) traffic and does not align with the requirements for routing general network traffic through the network virtual appliances. It’s a layer 7 load balancer, not ideal for network-level appliances that require layer 3 or layer 4 routing. Option C: Configure a network load balancer for the two network virtual appliances. Configure a route for 10.0.0.0/8 with the net...

Author: Emma · Last updated Jul 26, 2026

You are responsible for enabling Private Google Access for the virtual machine (VM) instances in your Virtual Private Cloud (VPC) to access Google APIs. All VM instances have only a private IP address and need to access Cloud Storage. You need to ensure that all VM traffic is routed back to your on-premises data center for traff...

Requirements: 1. Private Google Access for VM instances to access Google APIs, but all traffic must route through your on-premises data center for traffic scrubbing via Cloud Interconnect. 2. VM instances have only a private IP address and must access Cloud Storage. 3. VM traffic to Google APIs must stay within the VPC, while other traffic must route to your on-premises data center. Let's break down the options: Option A: 1. Delete the default route in your VPC. 2. Create a private Cloud DNS zone for googleapis.com, create a CNAME for `.googleapis.com` to `restricted googleapis.com`, and create an A record for `restricted googleapis.com` that resolves to the addresses `199.36.153.4/30`. 3. Create a static route in your VPC for the range `199.36.153.4/30` with the default internet gateway as the next hop. - Explanation: This option suggests deleting the default route, which forces all traffic (including Google API traffic) to route back through your on-premises network via your Cloud Interconnect. However, Google APIs should stay within the VPC (Private Google Access), but this solution routes traffic destined for Google APIs out to the internet, which is not what you want. - Why this option is rejected: The DNS setup here routes API traffic to an external address (`restricted googleapis.com`), but you need Google APIs to stay within the VPC. Additionally, routing through the internet gateway for Google APIs doesn't meet your requirements. Option B: 1. Delete the default route in your VPC and configure your on-premises router to advertise 0.0.0.0/0 via BGP. 2. Create a public Cloud DNS zone with a CNAME for `.google.com` to `private googleapis.com`, create a CNAME for `.googleapis.com` to `private googleapis.com`, and create an A record for `private.googleapis.com` that resolves to the addresses `199.36.153.8/30`. 3. Create a static route in your VPC for the range `199.36.153.8/30` with the default internet gateway as the next hop. - Explanation: This option involves configuring DNS settings and routing that would potentially route Google API traffic through a non-VPC network (via `private googleapis.com` and external routing). While the DNS setup tries to guide traffic, the routing and the public Cloud DNS zone are not appropriate for ensuring Private Google Access stays within the VPC. - Why this option is rejected: The public DNS zone is unsuitable for this scenario because it exposes DNS records that should be private. Additionally, routing API traffic through external resources violates the requirement for keeping Google API traffic within the VPC. Option C: 1. Configure your on-premises router to advertise `0.0.0.0/0` via BGP with a lower priority (M...

Author: MoonlitPantherX · Last updated Jul 26, 2026

You are designing a hub-and-spoke network architecture for your company's cloud-based environment. You need to make sure that all spokes are peered with the hub. The spokes must use the hub's virtual appliance for internet access. The virtual appliance is configured in hi...

In a hub-and-spoke network architecture where spokes must use a hub's virtual appliance for internet access, the virtual appliance is configured in high-availability mode, and we aim to make sure all spokes are peered with the hub, the following considerations need to be made when evaluating the provided options: Key Considerations: 1. Routing of Internet Traffic: The goal is for all internet traffic from the spokes to pass through the hub's virtual appliance, which is set to handle internet traffic. 2. High Availability: Since the virtual appliance is in high-availability mode, it’s critical to ensure that traffic can be routed to the correct instance without disruption. 3. Route Propagation: Routes should be properly exported and imported between the hub and the spokes, ensuring that the traffic is directed through the virtual appliance at the hub. Breakdown of the Options: Option A: 1. Create a default route in the hub VPC that points to IP address 10.0.0.5: This will route the traffic destined for the internet to the virtual appliance's load balancer IP (10.0.0.5). 2. Delete the default internet gateway route and create a new route tagged only to the appliances with the next hop as the default internet gateway: This ensures that the appliances handle all outgoing internet traffic. 3. Export and import custom routes between hub and spokes: This step ensures that custom routes (like those pointing to the virtual appliance) are shared between the hub and spokes, maintaining consistent routing. - Why rejected: This is a valid option. However, there may be confusion regarding the handling of internet traffic in the spokes themselves. The custom routes are useful, but the spokes still need a more direct routing instruction for their internet-bound traffic. Option B: 1. Create a default route in the hub VPC pointing to 10.0.0.5. 2. Delete the default internet gateway route and create a new higher-priority route tagged only to the appl...

Author: Ella · Last updated Jul 26, 2026

You configured Cloud VPN with dynamic routing via Border Gateway Protocol (BGP). You added a custom route to advertise a network that is reachable over the VPN tunnel. However, the on-premises clients still cannot reach the network over the VPN tunnel. You need to examine the logs in Cloud Logging to confirm th...

To troubleshoot why on-premises clients cannot reach the network over the VPN tunnel, we need to focus on the logs that will show us the status of the VPN tunnel, the routing information, and the advertisements. The correct filter in Cloud Logging should help us identify the relevant logs to confirm whether the appropriate routes are being advertised over the VPN tunnel. Key Considerations: 1. VPN Tunnel Logs: We want to confirm if the VPN tunnel is advertising the custom route correctly. 2. BGP Routing Information: Since dynamic routing via BGP is being used, we need logs related to the VPN gateway or tunnel that would include the BGP advertisement details. 3. Resource Type: Each of the options points to different resource types in Cloud Logging, and we need to choose the one most relevant to the VPN and routing logs. Breakdown of the Options: Option A: `resource.type="gce_router"` - This filter is used to focus on logs related to the Google Cloud Router, which handles BGP and routing information. The Cloud Router manages the dynamic BGP sessions, advertisements, and route exchanges between Google Cloud and on-premises. - Why selected: Since the issue involves BGP dynamic routing, the Cloud Router logs will be the most appropriate place to verify if the appropriate routers are being advertised and if the routing information is correctly exchanged. Option B: `resource.type="g...

Author: Benjamin · Last updated Jul 26, 2026

Your company has a single Virtual Private Cloud (VPC) network deployed in Google Cloud with access from on-premises locations using Cloud Interconnect connections. Your company must be able to send traffic to Cloud Storage only through the Inter...

In this scenario, the goal is to ensure that all traffic to Cloud Storage flows over the Interconnect links while still allowing access to other Google APIs and services over the public internet. To achieve this, the solution must make use of private access for Cloud Storage while keeping other services accessible via the public internet. Key Considerations: 1. Cloud Storage via Interconnect: You want to ensure that traffic destined for Cloud Storage goes through the Interconnect connection, not the public internet. 2. Other Google APIs: Other Google services should be accessible through public internet routes to avoid unnecessary routing through the Interconnect links. 3. Private Access: Private access solutions such as Private Google Access or Private Service Connect can help route traffic privately to Google services like Cloud Storage. Breakdown of the Options: Option A: `Use the default public domains for all Google APIs and services.` - This option suggests using only public IP addresses for all Google services, which wouldn't achieve the goal of sending Cloud Storage traffic through the Interconnect link. - Why rejected: Since this option uses public domains for everything, it doesn't provide a mechanism to send traffic to Cloud Storage via Interconnect, so it doesn't meet the requirements. Option B: `Use Private Service Connect to access Cloud Storage, and use the default public domains for all other Google APIs and services.` - Private Service Connect enables private access to Google services, and in this case, it can be used to direct traffic to Cloud Storage. The public internet can still be used for other Google services. - Why selected: This option is ideal because...

Author: Grace · Last updated Jul 26, 2026

Your organization has a Google Cloud Virtual Private Cloud (VPC) with subnets in us-east1, us-west4, and europe-west4 that use the default VPC configuration. Employees in a branch office in Europe need to access the resources in the VPC using HA VPN. You configured the HA VPN associated with the Google Cloud VPC for your organization with a Cloud Router de...

Key Considerations: - VPC Configuration: The VPC spans multiple regions (us-east1, us-west4, and europe-west4), and you need to ensure that users in the branch office can access resources across all regions. - HA VPN Setup: You've configured HA VPN with a Cloud Router in the `europe-west4` region, which provides a high-availability VPN connection to your branch office. - Routing: The goal is to ensure that the routing allows seamless access to resources in all subnets from the branch office without any unnecessary complexity or delays. Breakdown of the Options: Option A: `Create custom advertised routes for each subnet.` - This option involves manually creating custom advertised routes for each subnet in the VPC. While this could work, it introduces unnecessary complexity and requires manual updates if new subnets are added to the VPC. - Why rejected: Custom routes would require more manual management and are less flexible when scaling. Additionally, in a multi-region VPC setup, this could lead to more configuration overhead, especially when new regions or subnets are introduced. Option B: `Configure each subnet's VPN connection to use Cloud VPN to connect to the branch office.` - This option would involve setting up a separate VPN connection for each subnet in the VPC. While this approach might work, it’s inefficient and unnecessarily complicated. You would end up with multiple VPN connections, which could be harder to maintain and would not leverage the HA VPN's full capabilities. - Why rejected: Setting up individual VPN connections for each subnet would create a fr...

Author: Michael · Last updated Jul 26, 2026

Your organization uses a Shared VPC architecture with a host project and three service projects. You have Compute Engine instances that reside in the service projects. You have critical workloads in your on-premises data center. You need to ensure that the Google Cloud instances can res...

To ensure that Compute Engine instances in your Google Cloud environment can resolve on-premises hostnames through the Dedicated Interconnect, you need to configure DNS forwarding correctly. Let's analyze the options provided: A) 1. Create a Cloud DNS private forwarding zone in the host project of the Shared VPC that forwards the private zone to the on-premises DNS servers. 2. In your Cloud Router, add a custom route advertisement for the IP 35.199.192.0/19 to the on-premises environment. - Why it doesn’t work: The IP range `35.199.192.0/19` is a public IP range, not a private one. DNS queries for on-premises hostnames should be forwarded over a private IP address range. Using public IP addresses could result in DNS resolution issues. Thus, this option doesn’t meet the requirement of routing DNS traffic to on-premises DNS servers securely. B) 1. Create a Cloud DNS private forwarding zone in the host project of the Shared VPC that forwards the private zone to the on-premises DNS servers. 2. In your Cloud Router, add a custom route advertisement for the IP 169.254.169.254 to the on-premises environment. - Why it doesn’t work: The IP `169.254.169.254` is typically used for Google Cloud's metadata server and is not intended for DNS resolution or as a DNS forwarder. Using this IP would not properly forward DNS queries between Google Cloud and the on-premises environment. So, this option doesn’t resolve the DNS forwarding issue either. C) 1. Configure...

Author: Henry · Last updated Jul 26, 2026

Your organization is implementing a new security policy to control how firewall rules are applied to control flows between virtual machines (VMs). Using Google-recommended practices, you need to set up a firewall rule to enforce strict control of traffic between VM A and VM B. You must ensure that communications flow only from VM A to VM B within the VPC, and no ot...

In this scenario, you need to create a firewall rule that enforces traffic only from VM A to VM B within the same VPC. No other communication paths should be allowed. Option Analysis: A) Firewall rule direction: ingressAction: allow - Target: VM B service account - Source ranges: VM A service account - Priority: 1000 - Explanation: This rule allows inbound traffic (ingress) to VM B from VM A, based on the service accounts. However, this rule does not specify what kind of traffic should be allowed from VM A to VM B beyond the service accounts. It could potentially allow traffic from VM A to VM B regardless of the tags or IP ranges, and there’s no specific restriction for VM A and VM B in terms of network address or virtual network configuration. - Rejection Reason: It doesn’t provide enough granularity to restrict traffic based only on the desired source and destination, and might allow unwanted traffic from other VM instances using similar service accounts. B) Firewall rule direction: ingressAction: allow - Target: specific VM B tag - Source ranges: VM A tag and VM A source IP address - Priority: 1000 - Explanation: This rule specifies that inbound traffic is allowed to VM B tagged as a specific VM, and only from the sources specified by VM A's tag or source IP address. This rule could work, but it's not the most optimal solution because it introduces complexity by requiring the correct tags to be set up and the proper source IP addresses to be specified. - Rejection Reason: Using tags and source IP addresses might work but isn’t as clear and easy to enforce as using service accounts, especially if you are aiming for simpler management based on identity (service accou...

Author: Stella · Last updated Jul 26, 2026

You have configured a service on Google Cloud that connects to an on-premises service via a Dedicated Interconnect. Users are reporting recent connectivity issues. You need to determine whether the traff...

To troubleshoot connectivity issues between a Google Cloud service and an on-premises service via a Dedicated Interconnect, you need to identify whether the issue is related to firewall rules or routing decisions. Here’s an analysis of the options: Option Analysis: A) Use the Network Intelligence Center Connectivity Tests to test the connectivity between the VPC and the on-premises network. - Explanation: The Connectivity Tests in the Network Intelligence Center are designed to help identify connectivity issues between Google Cloud and on-premises services. This tool simulates traffic flow between Google Cloud and external networks (like on-premises) and can check for issues related to firewall rules, routing configurations, and other networking issues. It is highly relevant in identifying whether the problem lies in routing or firewall misconfiguration. - Selection Reason: This option is ideal because it directly tests the connectivity between the VPC and the on-premises network, which can identify whether traffic is being dropped due to a firewall rule or routing decision. This tool is specifically designed to pinpoint networking issues like this. B) Use Network Intelligence Center Network Topology to check the traffic flow, and replay the traffic from the time period when the connectivity issue occurred. - Explanation: The Network Topology tool provides a visual representation of the VPC's network and the traffic flow within it, but it doesn’t specifically simulate or test connectivity between services. While useful for mapping out the network, it doesn't help diagnose if traffic is being blocked or misrouted at a specific time. - Rejection Reason: This option does not provide the specific testing needed to pinpoint whether the issue is related to firewall rules or routing, making it less appropriate for the issue described. C) Configure VPC Flow Logs. Review the logs by ...

Author: Henry · Last updated Jul 26, 2026

You are configuring a new HTTP application that will be exposed externally behind both IPv4 and IPv6 virtual IP addresses, using ports 80, 8080, and 443. You will have backends in two regions: us-west1 and us-east1. You want to serve the content with the lowest-possible latency while ensuring high availability and autoscaling, and create native content-based rules using the HTTP ...

In this scenario, the goal is to expose an HTTP application behind both IPv4 and IPv6 virtual IPs, ensuring high availability, low latency, autoscaling, content-based routing, and that client IP addresses are visible to the backends. Let's break down the options: Option Analysis: A) Use Network Load Balancing - Explanation: Network Load Balancing (NLB) operates at the transport layer (Layer 4) and is designed for TCP/UDP traffic. It distributes traffic across backends but doesn't provide advanced features such as content-based routing (based on HTTP headers or request paths) or visibility of client IP addresses in a user-friendly way for HTTP traffic. It also doesn't support URL-based routing (such as using request path or hostname). - Rejection Reason: Network Load Balancing is not suitable for HTTP(S) traffic that requires content-based routing (URL Maps) and client IP visibility, as it doesn't offer these higher-layer features. B) Use TCP Proxy Load Balancing with PROXY protocol enabled - Explanation: TCP Proxy Load Balancing allows you to handle TCP traffic and supports visibility of the client’s IP address through the PROXY protocol. However, it doesn’t provide native support for HTTP(S) traffic, content-based routing (like hostname or path-based routing), or advanced load balancing features like autoscaling with HTTP-specific rules. - Rejection Reason: Although the PROXY protocol allows for the passing of client IP addresses, this option doesn’t support the native content-based routing and autoscaling features ...

Author: Liam · Last updated Jul 26, 2026

You are reviewing and tuning Secure Web Proxy at your organization, Mount Kirk Games. Users have reported that they are unable to reach the documents they need on the Terram Earth website (https://www.terramearth.com/docs/*). The Secure Web Proxy ...

To resolve the issue of users being unable to access documents on the Terram Earth website, we need to analyze and tune the Secure Web Proxy rules and determine the best course of action to ensure access to the necessary documents. Let's break down the options and examine the key factors for each: Option Analysis: A) Delete the updates-limiter rule. - Explanation: The updates-limiter rule might be limiting access to certain websites or content by setting some form of restriction. However, deleting this rule could have unintended consequences, such as removing restrictions that might be necessary for security or proper access management. - Rejection Reason: Deleting the rule could break other controls in place and might not specifically address the problem if the issue lies elsewhere, such as with TLS inspection or NAT configuration. B) Modify the updates-1 rule to perform the TLS inspection. - Explanation: TLS inspection is often required for secure web traffic (HTTPS) so that proxies or firewalls can inspect the traffic and enforce security policies. If the updates-1 rule isn't performing TLS inspection, it may not be able to properly handle or allow access to HTTPS resources, such as those on the terramearth.com domain. - Selection Reason: Enabling TLS inspection on the updates-1 rule would allow the Secure Web Proxy to properly inspect and allow secure web traffic (HTTPS) to the desired website. If the problem is related to HTTPS inspection, this option would resolve it by ensuring the proxy can properly forward traffic to the Terram Earth website. C) Review Cloud Logging for errors wit...

Author: Krishna · Last updated Jul 26, 2026

You are responsible for designing a new connectivity solution for your organization's enterprise network to access and use Google Workspace. You have an existing Shared VPC with Compute Engine instances in us-west1. Currently, you access Google Workspace via your service p...

In this scenario, the goal is to establish a direct connection between your organization's network and Google in order to access Google Workspace, while also considering your existing Shared VPC in us-west1. Let's review each option in detail and select the most appropriate one. Option Analysis: A) Order a Dedicated Interconnect connection in the same metropolitan area. Create a VLAN attachment, a Cloud Router in us-west1, and a Border Gateway Protocol (BGP) session between your Cloud Router and your router. - Explanation: Dedicated Interconnect provides a private, high-bandwidth connection between your on-premises network and Google Cloud. This option involves creating a Cloud Router in us-west1, which is where your compute instances are located, and configuring BGP to handle routing. It is well-suited for large-scale, low-latency, high-availability requirements and can connect directly to Google services, including Google Workspace. - Selection Reason: This is the ideal choice because Dedicated Interconnect offers the highest level of performance and reliability for connecting to Google services privately. Additionally, it allows for more control over routing and can connect your on-premises network directly to Google Cloud, ensuring robust access to Google Workspace. B) Order a Direct Peering connection in the same metropolitan area. Configure a Border Gateway Protocol (BGP) session between Google and your router. - Explanation: Direct Peering is a form of direct connection between your on-premises network and Google Cloud through Google’s network. This option provides direct access to Google’s services, but it is generally more suitable for high-throughput, low-latency applications or content delivery. Direct Peering usually provides a connection to Google’s public IPs rather than private services, and is not the best option for accessing Google Workspace or private Google services. - Rejection Reason: Direct Peering would not be the optimal solution for accessing Google Workspace, as it is typically used for direct access to Google services such as YouTube or other content-based services, and does not provide the same level...

Author: Sofia · Last updated Jul 26, 2026

You suspect that one of the virtual machines (VMs) in your default Virtual Private Cloud (VPC) is under a denial-of-service attack. You need to analyze the incoming traffic fo...

To analyze the incoming traffic for the VM and identify the source of potential denial-of-service (DoS) attacks, the most appropriate approach is to look at the flow of network traffic directly. VPC Flow Logs are designed specifically to record this type of data and give insights into the source and destination of network traffic. Let’s break down the options: Option A: Enable Data Access audit logs of the VPC. Analyze the logs and get the source IP addresses from the subnetworks.get field. - Rejected: Data Access audit logs are used for logging administrative actions related to access control and permissions. These logs would not provide network traffic data, which is what you need to identify a DoS attack. This option doesn’t focus on traffic analysis, so it’s not suitable for your case. Option B: Enable VPC Flow Logs for the subnet. Analyze the logs and get the source IP addresses from the connection field. - Selected: VPC Flow Logs record network traffic information at the network interface level (source and destination IPs, ports, and protocols) within a subnet. The "connection" field contains useful data about the IP addresses involved in the traffic flow. This is exactly what you need to identify the sou...

Author: SilverBear · Last updated Jul 26, 2026

You are responsible for configuring firewall policies for your company in Google Cloud. Your security team has a strict set of requirements that must be met to configure firewall rules. * Always allow Secure Shell (SSH) from your corporate IP address. * Restrict SSH access from all other IP addresses. There are multiple projects and VPCs i...

To ensure that your security team's strict firewall requirements are met while preventing other VPC firewall rules from bypassing the configuration, we need to take a careful approach using hierarchical firewall policies. Let's break down the options: Option A: 1. Configure a hierarchical firewall policy to the organization node to allow TCP port 22 for your corporate IP address with priority 0. 2. Configure a hierarchical firewall policy to the organization node to deny TCP port 22 for all IP addresses with priority 1. - Selected: Hierarchical firewall policies allow you to apply rules to an entire organization or folder in Google Cloud, ensuring that they are enforced across all projects and VPCs under the organization. - Why it’s correct: This option applies at the organization level, meaning the rules are inherited by all VPCs, ensuring that no other VPC firewall rule can override it. The allow rule for your corporate IP address has a higher priority (0), meaning it will take precedence over any deny rules. The deny rule (priority 1) ensures that all other IP addresses are blocked from SSH access, as it applies to the rest of the world. Option B: 1. Configure a VPC firewall rule to allow TCP port 22 for your corporate IP address with priority 0. 2. Configure a VPC firewall rule to deny TCP port 22 for all IP addresses with priority 1. - Rejected: This option applies the rules at the VPC level, not the organization level. If you have multiple VPCs, each VPC would need to be configured separately, and other VPC firewall rules could still potentially conflict or bypass the intended restr...

Author: Evelyn · Last updated Jul 26, 2026

You are designing a new application that has backends internally exposed on port 800. The application will be exposed externally using both IPv4 and IPv6 via TCP on port 700. Yo...

To ensure high availability for your application that needs to be externally accessible via both IPv4 and IPv6 on TCP port 700, we need to carefully select the right load balancing configuration to handle traffic efficiently. Let's analyze each option in detail: Option A: - Create a network load balancer that uses backend services containing one instance group with two instances. - Selected: A Network Load Balancer (NLB) is ideal for high availability as it operates at the transport layer (Layer 4) and supports both IPv4 and IPv6. In this configuration, you use backend services with an instance group containing two instances. This ensures the application can handle failover if one instance fails. This setup is well-suited for distributing traffic to multiple instances and ensuring that your application remains highly available. Option B: - Create a network load balancer that uses a target pool backend with two instances. - Rejected: While a Network Load Balancer (NLB) with a target pool can handle traffic at Layer 4, it is an older configuration. Target pools are less flexible compared to backend services, particularly when you need to handle health checks and more complex routing. Additionally, target pools do not support IPv6, so this option is not suitable for your requirement to support both IPv4 and IPv6 traffic. Option C: - Create a TCP proxy that uses a zonal ne...

Author: Vivaan · Last updated Jul 26, 2026

You work for a university that is migrating to Google Cloud. These are the cloud requirements: * On-premises connectivity with 10 Gbps * Lowest latency access to the cloud * Centralized Networking Administration Team New departments are asking for on-premises connectivity to their projects. ...

To determine the most cost-efficient and scalable interconnect solution for connecting the university's campus to Google Cloud, we need to balance the requirements for high throughput (10 Gbps), low latency, and centralized networking administration. Let's break down each option: Option A: - Use Shared VPC, and deploy the VLAN attachments and Dedicated Interconnect in the host project. - Selected: Shared VPC allows you to centralize networking administration in a host project, while enabling service projects to leverage the networking resources in the host project. Deploying Dedicated Interconnect in the host project ensures that the on-premises connectivity (10 Gbps) is centralized and simplifies management. By placing the VLAN attachments in the host project, you avoid the overhead and complexity of managing multiple interconnects. This approach also minimizes costs as it reduces the need for interconnects per department or service project. Since the centralized network administration is a requirement, this solution meets that need well by allowing the networking team to manage the interconnects in one place. Option B: - Use Shared VPC, and deploy the VLAN attachments in the service projects. Connect the VLAN attachment to the Shared VPC's host project. - Rejected: This option also uses Shared VPC, but placing the VLAN attachments in the service projects and connecting them back to the host project creates unnecessary complexity. While this allows for some flexibility, it makes it harder to manage connectivity and increases administrative overhead. It may also lead to additional networking costs as the inter...

Author: Noah · Last updated Jul 26, 2026

You have several microservices running in a private subnet in an existing Virtual Private Cloud (VPC). You need to create additional serverless services that use Cloud Run and Cloud Functions to access the microservices. The network traffic volume between your serverless services and private microservices is low. However, each serverl...

To address the requirements of connecting Cloud Run and Cloud Functions (serverless services) with existing microservices running in a private subnet within a Virtual Private Cloud (VPC), while minimizing costs and ensuring communication between services, we need to consider the options carefully. Let’s analyze each option: Option A: - Deploy your serverless services to the serverless VPC. Peer the serverless service VPC to the existing VPC. Configure firewall rules to allow traffic between the serverless services and your existing microservices. - Rejected: This approach involves deploying serverless services to a separate serverless VPC, then peering that VPC with your existing VPC. While VPC peering does allow communication between VPCs, it introduces additional complexity, potential cost, and overhead. Peering also requires more configuration for routing and firewall rules between the VPCs. This setup could be more expensive compared to using a serverless VPC connector, especially since traffic volume is low and the goal is to minimize costs. Option B: - Create a serverless VPC access connector for each serverless service. Configure the connectors to allow traffic between the serverless services and your existing microservices. - Rejected: This option suggests creating a VPC Access connector for each serverless service (Cloud Run or Cloud Functions). While it provides the ability for serverless services to access resources in your VPC, it requires managing multiple connectors for each service. This could increase the complexity and management overhead. Additionally, having multiple connectors might lead to unnecessary costs, especially if the traffic volume between the services is low. Optio...

Author: Ethan · Last updated Jul 26, 2026

You have provisioned a Dedicated Interconnect connection of 20 Gbps with a VLAN attachment of 10 Gbps. You recently noticed a steady increase in ingress traffic on the Interconnect connection from the on-premises data center. You need to ensure that your end users can achie...

To ensure that end users can achieve the full 20 Gbps throughput as quickly as possible, we need to evaluate the options in terms of improving the traffic flow and utilization of the available bandwidth. Below are the key factors to consider: 1. VLAN Attachment Capacity: The VLAN attachment on a Dedicated Interconnect connection is limited to a maximum of 10 Gbps. If the current attachment is at this limit, there’s a bottleneck that prevents utilizing the full 20 Gbps of the interconnect. 2. Traffic Distribution and Load Balancing: In scenarios where there is increased ingress traffic, distributing this load across multiple VLAN attachments (whether in the same region or across regions) can help balance the traffic and avoid congestion on a single attachment. 3. Bandwidth Modifications: Modifying the bandwidth of the VLAN attachment can directly impact throughput, but the VLAN attachment bandwidth is usually constrained to specific values, so it is important to adjust the configuration carefully. Let’s evaluate each option: A) Configure an additional VLAN attachment of 10 Gbps in another region. Configure the on-premises router to advertise routes with the same multi-exit discriminator (MED). This option introduces a secondary VLAN attachment in another region to handle additional ingress traffic. Configuring the on-premises router with the same MED ensures that the traffic is balanced across the two VLAN attachments, making this a feasible method to distribute traffic efficiently. However, adding a new region might introduce some latency due to inter-region traffic, which could impact performance depending on your architecture and requirements. Still, this helps utilize the 20 Gbps link more effectively. B) Configure an additional VLAN attachment of 10 Gbps in the same region. Configure the on-premises router to advertise routes with the same multi-exit discriminator (MED). This option proposes adding another 10 Gbps VLAN attachment in the same region, which can also help distribute the load across both...

Author: Charlotte · Last updated Jul 26, 2026

Your company has a Virtual Private Cloud (VPC) with two Dedicated Interconnect connections in two different regions: us-west1 and us-east1. Each Dedicated Interconnect connection is attached to a Cloud Router in its respective region by a VLAN attachment. You need to configure a high availability failover path. By default, all ingress traffic from the on-premises environment should flow to the VPC using the us-west1 ...

To configure a high availability failover path for your Dedicated Interconnect connections, you need to use the multi-exit discriminator (MED) feature along with routing policies to control the path selection. The objective is to ensure that ingress traffic from your on-premises environment flows to the us-west1 region by default and, if the us-west1 connection becomes unavailable, traffic is rerouted to us-east1. Key Considerations: 1. Regional vs. Global Routing: - Regional routing means routing decisions are made based on the region where the traffic originates (i.e., from either the us-west1 or us-east1 region specifically). - Global routing allows for routing decisions to be made based on the entire global network, giving more control over routing preferences across regions. 2. Priority and MED: - A lower priority value (e.g., `1`) indicates a higher preference for routing through that Cloud Router. - MED values are used to influence the preference between multiple available routes. If two routes to the same destination exist (e.g., one from us-west1 and another from us-east1), the one with the lower MED value is preferred. - You need the us-west1 connection to have a lower MED value (higher priority) to be used by default, and the us-east1 connection to have a higher MED value to be used only when us-west1 is unavailable. Let's evaluate each option: A) Use regional routing. Set the us-east1 Cloud Router to a base priority of 100, and set the us-west1 Cloud Router to a base priority of 1. - Reasoning: This configuration sets the priority for us-west1 to `1`, which is the most preferred, and the priority for us-east1 to `100`, making it less preferred. However, this setup is incorrect because you are using regional routing. Regional routing doesn't allow you to configure failover effectively across regions; it is better suited for traffic that doesn't require cross-region failover. - Rejected: Regional routing is not ideal for cross-region failover. B) Use global r...

Author: Ava · Last updated Jul 26, 2026

You have the following private Google Kubernetes Engine (GKE) cluster deployment: You have a virtual machine (VM) deployed in the same VPC in the subnetwork kubernetes-management with internal IP address 192.168.40 2/24 and no external...

To communicate with the Google Kubernetes Engine (GKE) cluster master using kubectl from a virtual machine (VM) within the same VPC, the main challenge is to ensure the VM is authorized to access the Kubernetes master endpoint, which is secured using the masterAuthorizedNetworksConfig. Here's a breakdown of the options and considerations: Key Factors: 1. Internal IP Access: Since the VM has only an internal IP (no external IP) and resides in the same VPC, the communication to the GKE master must be via the internal IP. 2. Master Access: GKE clusters, especially in private mode, restrict access to the cluster master endpoint to authorized networks. The masterAuthorizedNetworksConfig allows you to define which IP ranges can access the master. 3. Network Ranges: The network range added to the masterAuthorizedNetworksConfig must match the VM's IP range to allow it to communicate with the master. This means the VM's network must be explicitly allowed. 4. kubectl Configuration: After configuring the network access, the kubectl command needs to be configured to point to the correct master endpoint, which might either be an internal or external IP, depending on your GKE cluster setup. Evaluating the Options: A) Add the network 192.168.40.0/24 to the masterAuthorizedNetworksConfig. Configure kubectl to communicate with the endpoint 192.168.38.2. - Reasoning: This option suggests adding the 192.168.40.0/24 network (which includes the VM's IP, 192.168.40.2) to the masterAuthorizedNetworksConfig, which is correct. However, the endpoint `192.168.38.2` is not mentioned as a valid internal endpoint. The correct internal endpoint should correspond to the cluster's internal IP address or name. - Rejected: Incorrect endpoint specified (`192.168.38.2`). B) Add ...

Author: Amira · Last updated Jul 26, 2026

Your company's logo is published as an image file across multiple websites that are hosted by your company. You have implemented Cloud CDN; however, you want to improve the performan...

To improve the performance of the cache hit ratio for an image file served by Cloud CDN, the goal is to ensure that Cloud CDN can serve the file from its cache as often as possible, minimizing cache misses and reducing load on the backend. Let’s evaluate each option based on this goal: Key Factors: - Cache Hit Ratio: This refers to the percentage of requests that are served directly from the cache instead of requiring a request to the origin. - TTL (Time to Live): The longer the TTL, the longer the cache remains valid before being refreshed, which can increase the cache hit ratio. - Cache Keys: The cache key determines what makes a unique cache entry. By customizing the cache key, you can control what is cached and how. - Origin Backend: The origin backend where the content is stored. If it's stored in Cloud Storage, which is highly optimized for serving static assets, the performance can be better than hosting it in some other backend. Evaluating the Options: A) Configure custom cache keys for the backend service that holds the image file, and clear the Host and Protocol checkboxes. - Reasoning: Custom cache keys allow you to fine-tune what variations of the content are cached. By clearing the Host and Protocol checkboxes, you can ensure that Cloud CDN doesn’t treat the same file as different based on the host or protocol (e.g., HTTP vs. HTTPS). This can improve cache hit ratio by avoiding unnecessary distinctions in cached versions of the same image. - Correct: This option optimizes caching by reducing unnecessary variations in the cache key, making it more likely that the image will be served from the cache. B) Configure the default time to live (TTL) as 0 for the image file. - Reasoning: Setting TTL to 0 would mean that Cloud CDN will never cache the file and always fetch it from the backend. This would reduce the cache hit ratio a...

Author: Oliver · Last updated Jul 26, 2026

Your company recently migrated to Google Cloud in a single region. You configured separate Virtual Private Cloud (VPC) networks for two departments: Department A and Department B. Department A has requested access to resources that are part of Department B's VPC. You need to configure the traffic from private IP addresses to flow between the VPCs using multi-NIC virtual machines (VMs) to meet security requirements. Your configuration also must:...

To meet the requirements of allowing traffic between the two VPCs in different departments with specific conditions—support for both TCP and UDP protocols, fully automated failover, health checks, and minimal manual intervention—we need to evaluate each approach carefully. Let's break down the options: Key Factors: 1. Multi-NIC VMs: The solution must utilize VMs with multiple network interfaces to facilitate traffic between the two VPCs. 2. Failover: The solution should automatically failover between VMs in case of a failure. 3. Health Checks: Health checks should be incorporated to ensure traffic only flows to healthy instances. 4. Minimal Manual Intervention: The solution should require little manual configuration or changes once set up. 5. TCP and UDP Protocols: The solution should support both protocols. Evaluating the Options: A) Create the VMs in the same zone, and configure static routes with IP addresses as next hops. - Reasoning: This option suggests creating VMs in the same zone and configuring static routes. However, static routes would not provide automated failover, as they are static and require manual intervention to reroute traffic in case of failure. Additionally, static routes do not support health checks natively, so this does not fully meet the requirements for failover and health checks. - Rejected: Lack of automated failover and health checks make this approach unsuitable for the requirements. B) Create the VMs in different zones, and configure static routes with instance names as next hops. - Reasoning: Similar to Option A, this option also uses static routes but with instance names as next hops instead of IP addresses. While this offers some flexibility, it still doesn't meet the requirements for automated failover or health checks. Static routes with instance names may offer easier management, but they still lack the automated failover and health check mechanisms that would be required in this case. - Rejected: This option also lacks automatic failover and health checks, which are crucial for high availability. C) Create an instance template and a managed instance group. Configure a single internal load balancer, and define a custom static route with ...

Author: Siddharth · Last updated Jul 26, 2026

You are designing an IP address scheme for new private Google Kubernetes Engine (GKE) clusters. Due to IP address exhaustion of the RFC 1918 address space in your enterprise, you plan to use privately used public IP space for the new cluste...

To design an IP address scheme for new private Google Kubernetes Engine (GKE) clusters using privately used public IP space, we need to align with Google-recommended practices, especially when dealing with address space exhaustion of the RFC 1918 address space in the enterprise. Analysis of Each Option: - Option A: Create the minimum usable RFC 1918 primary and secondary subnet IP ranges for the clusters. Re-use the secondary address range for the pods across multiple private GKE clusters. - Why it might not be ideal: The use of RFC 1918 space for primary and secondary subnets is typically suited for environments where private addressing is required. However, since you specifically want to use privately used public IP space due to address exhaustion of RFC 1918 space, this option does not align with the requirement to use public IP space. Furthermore, re-using the secondary address range for pods across clusters could lead to IP conflicts or insufficient addressing across multiple clusters. - Scenario: This could be used in environments where RFC 1918 space is sufficient and you do not need to use public IPs. But, it is not suitable given the premise of your need for public IP space. - Option B: Create the minimum usable RFC 1918 primary and secondary subnet IP ranges for the clusters. Re-use the secondary address range for the services across multiple private GKE clusters. - Why it might not be ideal: Again, this option uses RFC 1918 space, which you want to avoid due to exhaustion. Although it addresses the reuse of secondary address ranges for services (not pods), it does not solve the fundamental issue of using public IP space. It is more about internal GKE service networking and does not resolve the public IP address space issue. - Scenario: This could be used in cases where RFC 1918 space is still available, but it's not suitable for your needs as per the constraints you've mentioned. - Option C: Create privately used public IP primary and secondary subnet ranges for the clusters. Create a private GKE cluster with the fol...

Author: Nathan · Last updated Jul 26, 2026

You want Cloud CDN to serve the https://www.example.com/images/spacetime.png static image file that is hosted in a private Cloud Storage bucket. You are using the USE_ORIGIN_HEADERS cache mode. You receive an HTTP 403 error when opening the file in your browser, and...

To address the issue you're facing with Cloud CDN serving the static image file from the private Cloud Storage bucket, let's analyze the situation in detail. Here's the breakdown of each option: Issue Overview: - You're receiving an HTTP 403 error, which typically indicates a permission issue. - The HTTP response includes a `Cache-Control: private, max-age=0` header, which suggests that the file is being treated as private, meaning Cloud CDN cannot cache or serve it publicly. - The problem seems to be related to Cloud Storage permissions, and the file is not publicly accessible. Options Analysis: Option A: Enable negative caching for the backend bucket. - Why it’s not ideal: Negative caching is used to cache error responses (e.g., HTTP 404, 500) to avoid repeatedly fetching the same error from the origin server. However, in this case, the issue is an HTTP 403 error due to permission restrictions, not an error that needs to be cached. Enabling negative caching does not address the underlying issue of file permissions or caching behavior. - Scenario: Negative caching could be helpful in some error-handling scenarios, but it won’t solve the permission issue or the improper caching setup. Option B: Change the cache mode to Force cache all content. - Why it’s not ideal: Changing the cache mode to `Force cache all content` would force Cloud CDN to cache all content, including private content. However, this does not address the core issue, which is the permission problem causing the 403 error when accessing the file. Without granting public access to the Cloud Storage bucket or adjusting permissions, Cloud CDN cannot cache or serve the content. - Scenario: This could be considered in some cases if you are sure the file can be publicly cached, but it's...

Author: Aria · Last updated Jul 26, 2026

You are deploying an application that runs on Compute Engine instances. You need to determine how to expose your application to a new customer. You must ensure that your application meets the following requirements: * Maps multiple existing reserved external...

To address the requirements for exposing your application running on Compute Engine instances with specific needs like mapping multiple reserved external IP addresses to the instance and processing IP Encapsulating Security Payload (ESP) traffic, let’s evaluate each option carefully. Requirement Breakdown: 1. Maps multiple existing reserved external IP addresses to the instance: You need to ensure that multiple external IPs are mapped to the instance. 2. Processes IP Encapsulating Security Payload (ESP) traffic: ESP is used in IPsec VPNs, and it’s important to handle this kind of traffic properly, which can involve using specific network configurations or services. Options Analysis: Option A: Configure a target pool, and create protocol forwarding rules for each external IP address. - Why it might work: Target pools are used to configure groups of instances for load balancing. Protocol forwarding allows the forwarding of traffic for specific protocols (like ESP) to a target instance. - Why it’s not ideal: While target pools and protocol forwarding can help with mapping multiple external IPs, target pools are mainly used for health checking and load balancing. For ESP traffic specifically, protocol forwarding can work, but target pools don’t directly address the need for handling ESP traffic as part of the solution. - Scenario: This could be used in environments where load balancing is needed, but it’s not ideal for handling ESP traffic in a simple application deployment. Option B: Configure a backend service, and create an external network load balancer for each external IP address. - Why it might not work: Backend services and load balancers are used for distributing traffic across multiple instances in a scalable way. While this can handle HTTP(S), SSL, and other protocols, ESP traffic cannot be processed by a load balancer directly because load balancers don’t handle IPsec or non-HTTP traffic. This option doesn’t meet the requirement to process ESP traffic. - Why it’s not ideal: This is suited for applications needing high availability and traffic distribution but does not address the ESP traffic processing or mapping of multiple external IP addresses as needed. - Scenario: Ideal for stan...

Author: Lucas · Last updated Jul 26, 2026

What Our Friends Say

What Our Friends Say

Google Practice Questions, Discussions & Exam Topics by our Authors

You recently deployed Compute Engine instances in regions us-west1 and us-east1 in a Virtual Private Cloud (VPC) with default routing configurations. Your company security policy mandates that virtual machines (VMs) must not have public IP addresses attached to them. You ...

You are designing a new global application using Compute Engine instances that will be exposed by a global HTTP(S) load balancer. You need to secure your application from distributed...

Your organization's security policy requires that all internet-bound traffic return to your on-premises data center through HA VPN tunnels before egressing to the internet, while allowing virtual machines (VMs) to leverage private Google APIs using private virtual...

You have two Google Cloud projects in a perimeter to prevent data exfiltration. You need to move a third project inside the perimeter; however, the move could negatively impact the existin...

You are configuring an HA VPN connection between your Virtual Private Cloud (VPC) and on-premises network. The VPN gateway is named VPN_GATEWAY_1. You need to restrict VPN tunnels created in the project to o...

You need to configure a Google Kubernetes Engine (GKE) cluster. The initial deployment should have 5 nodes with the potential to scale to 10 nodes. The maximum number of Pods per node is 8. The number of services could grow...

You have provisioned a Partner Interconnect connection to extend connectivity from your on-premises data center to Google Cloud. You need to configure a Cloud Router and create a VLAN attachment to connect to resources inside your VPC. You need to configure an Autonomou...

You are configuring a new application that will be exposed behind an external load balancer with both IPv4 and IPv6 addresses and support TCP pass-through on port 443. You will have backends in two regions: us-west1 and us-east1. You want to serve the content with...

You are planning a large application deployment in Google Cloud that includes on-premises connectivity. The application requires direct connectivity between workloads in all regions and on-premises locations without address transl...

Your company's security team wants to limit the type of inbound traffic that can reach your web servers to protect against security threats. You need to configure the firewall rules on the web servers within your Virt...

You successfully provisioned a single Dedicated Interconnect. The physical connection is at a colocation facility closest to us-west2. Seventy-five percent of your workloads are in us-east4, and the remaining twenty-five percent of your workloads are in us-central1. All workloads have the...

Your organization has a single project that contains multiple Virtual Private Clouds (VPCs). You need to secure API access to your Cloud Storage buckets and BigQuery datasets by allowing API...

You have the following routing design. You discover that Compute Engine instances in Subnet-2 in the asia-southeast1 region cannot communi...

You built a web application with several containerized microservices. You want to run those microservices on Cloud Run. You must also ensure that the services are h...

You have an HA VPN connection with two tunnels running in active/passive mode between your Virtual Private Cloud (VPC) and on-premises network. Traffic over the connection has recently increased from 1 gigabit per second (Gbps) to 4 Gbps, and you notice that packets ...

You are designing a hub-and-spoke network architecture for your company's cloud-based environment. You need to make sure that all spokes are peered with the hub. The spokes must use the hub's virtual appliance for internet access. The virtual appliance is configured in hi...

Your company has a single Virtual Private Cloud (VPC) network deployed in Google Cloud with access from on-premises locations using Cloud Interconnect connections. Your company must be able to send traffic to Cloud Storage only through the Inter...

Your organization uses a Shared VPC architecture with a host project and three service projects. You have Compute Engine instances that reside in the service projects. You have critical workloads in your on-premises data center. You need to ensure that the Google Cloud instances can res...

You have configured a service on Google Cloud that connects to an on-premises service via a Dedicated Interconnect. Users are reporting recent connectivity issues. You need to determine whether the traff...

You are reviewing and tuning Secure Web Proxy at your organization, Mount Kirk Games. Users have reported that they are unable to reach the documents they need on the Terram Earth website (https://www.terramearth.com/docs/*). The Secure Web Proxy ...

You are responsible for designing a new connectivity solution for your organization's enterprise network to access and use Google Workspace. You have an existing Shared VPC with Compute Engine instances in us-west1. Currently, you access Google Workspace via your service p...

You suspect that one of the virtual machines (VMs) in your default Virtual Private Cloud (VPC) is under a denial-of-service attack. You need to analyze the incoming traffic fo...

You are designing a new application that has backends internally exposed on port 800. The application will be exposed externally using both IPv4 and IPv6 via TCP on port 700. Yo...

You work for a university that is migrating to Google Cloud. These are the cloud requirements: * On-premises connectivity with 10 Gbps * Lowest latency access to the cloud * Centralized Networking Administration Team New departments are asking for on-premises connectivity to their projects. ...

You have provisioned a Dedicated Interconnect connection of 20 Gbps with a VLAN attachment of 10 Gbps. You recently noticed a steady increase in ingress traffic on the Interconnect connection from the on-premises data center. You need to ensure that your end users can achie...

You have the following private Google Kubernetes Engine (GKE) cluster deployment: You have a virtual machine (VM) deployed in the same VPC in the subnetwork kubernetes-management with internal IP address 192.168.40 2/24 and no external...

Your company's logo is published as an image file across multiple websites that are hosted by your company. You have implemented Cloud CDN; however, you want to improve the performan...

You are designing an IP address scheme for new private Google Kubernetes Engine (GKE) clusters. Due to IP address exhaustion of the RFC 1918 address space in your enterprise, you plan to use privately used public IP space for the new cluste...

You want Cloud CDN to serve the https://www.example.com/images/spacetime.png static image file that is hosted in a private Cloud Storage bucket. You are using the USE_ORIGIN_HEADERS cache mode. You receive an HTTP 403 error when opening the file in your browser, and...

You are deploying an application that runs on Compute Engine instances. You need to determine how to expose your application to a new customer. You must ensure that your application meets the following requirements: * Maps multiple existing reserved external...