Google Practice Questions, Discussions & Exam Topics by our Authors
You need to enable Cloud CDN for all the objects inside a storage bucket. You want to ensure that all the object in the storage bucket can b...
To enable Cloud CDN for all objects inside a storage bucket, the most effective approach is to use an HTTP(S) Load Balancer in Google Cloud. Let's break down the options to understand why one option is the best:
1. Option A: Create a new cloud storage bucket, and then enable Cloud CDN on it.
Cloud Storage itself doesn't directly support Cloud CDN. Cloud CDN is enabled through a load balancer, not directly on the bucket. This option is not viable because enabling Cloud CDN cannot be done directly on a storage bucket itself. Therefore, this is not the correct choice.
2. Option B: Create a new TCP load balancer, select the storage bucket as a backend, and then enable Cloud CDN on the backend.
A TCP Load Balancer is used for layer 4 (transport layer) traffic and does not support Cloud CDN. Cloud CDN only works with HTTP(S) Load Balancers, which operate at the application layer (layer 7). Since TCP load balancers do not support CDN, this option is not the correct choice.
3. Option C: Create a new SSL proxy load balancer, select the storage bucket as a backend, and then enable Cloud CDN on the backend.
An SSL Proxy Load Balancer is used for non-HTTP(S) traffic that needs to be secured, but it is still a layer 4 load balancer. Like the TCP load balancer, it does not support Cloud CDN because CD...
Author: Alexander · Last updated Jul 26, 2026
Your company's Google Cloud-deployed, streaming application supports multiple languages. The application development team has asked you how they should support splitting audio and video traffic to different backend Google Cloud storage buckets. They want to use URL maps and minimize operational overhead. They are currently using the followin...
To split audio and video traffic to different backend Google Cloud storage buckets while minimizing operational overhead using URL maps, let’s analyze the options:
Option A: Rearrange the directory structure, create a URL map and leverage a path rule such as /video/ and /audio/
- Rearranging the directory structure is not necessary in this case because the existing structure already effectively separates the audio and video files into distinct paths (e.g., `/fr/video`, `/en/audio`). The main challenge is to set up the URL map to direct the traffic correctly based on the URL structure.
- Path rules like `/video/` and `/audio/` are straightforward and will work well in a URL map. This approach would route any request that has `/video/` to the video backend and `/audio/` to the audio backend.
- This option works, but it requires a directory structure change that might not be needed, as the existing directory structure is already suitable.
Option B: Rearrange the directory structure, create DNS hostname entries for video and audio and leverage a path rule such as /video/ and /audio/
- Rearranging the directory structure again isn’t required, as the current structure already separates video and audio in paths.
- Creating DNS hostname entries could be a potential solution, but it introduces unnecessary complexity. You would need to manage DNS records and configure multiple backend services based on hostnames, which adds operational overhead.
- The path rule `/video/` and `/audio/` works, but the DNS hostname approach adds complexity and isn’t needed if the directory structure and path rules are sufficient.
- This option is overcomplicated compared to other options.
Option C: Leave the directory structure as-is, create a URL map and leverage a path rule such as /[a-z]{2}/video and /[a-z]{2}/audio
- This option leverages a regular expression (`/[...
Author: James · Last updated Jul 26, 2026
You want to establish a dedicated connection to Google that can access Cloud SQL via a public IP address and that does not require a third-par...
To establish a dedicated connection to Google that can access Cloud SQL via a public IP address without using a third-party service provider, you need to choose a connection type that enables direct communication between your infrastructure and Google Cloud, while allowing access over a public IP address.
Let's go through each option:
1. Carrier Peering:
- What it is: Carrier Peering involves establishing a connection between a customer's on-premises network and Google Cloud via a telecommunications carrier's network. This is a third-party service, meaning you rely on a third-party service provider.
- Why it’s not selected: Since the question specifically asks for a solution that does not require a third-party service provider, Carrier Peering is not a suitable option.
- Possible scenario: Carrier Peering can be used when you want a dedicated connection over a carrier network, but it does involve a third-party.
2. Direct Peering:
- What it is: Direct Peering allows a customer to directly connect their on-premises network to Google Cloud via a private network link, bypassing the public internet.
- Why it’s not selected: Direct Peering is a good option for a private, dedicated connection, but it doesn't use a public IP address. Cloud SQL via public IP requires access over the public internet, so Direct Peering wouldn't fulfill that need.
- Possible scenario: This option is suitable for private, high-speed connections without using the internet, but it’s not ideal when public IP access is required for Cloud SQL.
3. Dedicated Interconnect:
- What it is: Dedicated Interconnect offers a direct, high-performance connection between your on-premises network and Google Cloud, bypassing the public internet, and can access services like ...
Author: Daniel · Last updated Jul 26, 2026
You are configuring a new instance of Cloud Router in your Organization's Google Cloud environment to allow connection across a new Dedicated Interconnect to your data center Sales, Marketing, and IT each have a service projec...
To properly configure a Cloud Router in Google Cloud, it must be placed in a VPC network that can facilitate routing between your organization's on-premises network and Google Cloud, specifically through the Dedicated Interconnect. The decision involves ensuring that the Cloud Router is positioned in a network that enables all required projects to use it for cross-project communication.
Let's review each option:
1. VPC network in all projects:
- What it is: This would imply creating separate Cloud Routers in each of the individual VPC networks in each project (Sales, Marketing, and IT) within the organization.
- Why it’s not selected: Creating Cloud Routers in all projects is inefficient and unnecessary because the goal is to centralize the routing functionality for connectivity across all projects. There is no need to create separate routers in each project when one central Cloud Router can serve the entire organization.
- Possible scenario: This could be used if there was a need for a highly isolated and project-specific routing configuration, but that is not needed here.
2. VPC network in the IT Project:
- What it is: Cloud Router is placed in the IT project's VPC network, which could be a central network for managing connectivity to the data center.
- Why it’s not selected: While the IT project is likely responsible for managing infrastructure, placing the Cloud Router solely in the IT project can limit the accessibility of the routing information to other projects, like Sales and Marketing. The IT project might need access to routes, but the other projects would be isolated from it.
- Possible scenario: This option is viable if the IT project alone is responsible for managing all external connectivity, but it does not meet the cross-project requirement efficiently.
3. VPC network in the Host Project:
- What it is: The Host Project is typically used to manage shared resources across different service projects in the organization. The Cloud Router in ...
Author: Carlos Garcia · Last updated Jul 26, 2026
You created a new VPC for your development team. You want to allow access to the resources in this VPC via SSH onl...
When configuring firewall rules to allow access to resources in a VPC, the goal is to define rules that provide the necessary access while blocking all other unwanted traffic. In this scenario, you want to allow SSH access to your VPC, which uses port 22 (the standard port for SSH) and block all other traffic.
Let's break down each option:
1. A) Create two firewall rules: one to block all traffic with priority 0, and another to allow port 22 with priority 1000:
- What it is: This option includes two rules: one to block all traffic at priority 0 (which is the highest priority) and another to allow SSH (port 22) at priority 1000.
- Why it’s not selected: While this approach would work, it introduces unnecessary complexity. The block-all rule with priority 0 would block all traffic, but the allow rule for port 22 (with a lower priority of 1000) would still permit SSH access. However, the simpler solution of just allowing SSH traffic directly is preferable.
- Possible scenario: This option can be used if you want to enforce a strict, layered firewall rule that includes both blocking and allowing traffic explicitly, but it adds complexity when a simpler solution exists.
2. B) Create two firewall rules: one to block all traffic with priority 65536, and another to allow port 3389 with priority 1000:
- What it is: This rule configuration would block all traffic with the lowest priority (65536) and allow RDP (Remote Desktop Protocol) access on port 3389 with priority 1000.
- Why it’s not selected: This option allows RDP, which uses port 3389, not SSH. Since you only need to allow SSH access (port 22), this rule is irrelevant.
- Possible scenario: This would be used if you were specifically configuring rem...
Author: Mia · Last updated Jul 26, 2026
Your on-premises data center has 2 routers connected to your GCP through a VPN on each router. All applications are working correctly; however, all of the traffic is passing across a single VPN instead of being load-balanced across the 2 connections as desired.
During troubleshooting you find:
* Each on-premises router is configured with the same ASN.
* Each on-premises router is configured with the same routes and priorities.
* Both on-premises routers are configured with a VPN connected to a single Clo...
In this scenario, you're trying to load-balance traffic across two VPN connections, but it's only passing through a single VPN connection. Given the troubleshooting findings, let's break down each option and see which one is most likely causing the issue:
Analysis of the findings:
- Each on-premises router has the same ASN: This suggests that both routers are part of the same Autonomous System Number (ASN), which should typically not prevent BGP from working, as long as there’s no conflict.
- Both routers have the same routes and priorities: This is not a problem in itself; both routers are configured to route the same traffic.
- The VPN is connected to a single Cloud Router: This indicates that you're using a single Cloud Router for both VPN connections, but the issue lies elsewhere.
- VPN logs show no-proposal-chosen lines: This suggests that the issue could be related to the negotiation of the VPN parameters, which might prevent the VPN from establishing correctly.
- BGP session is not established between one on-premises router and the Cloud Router: This is a critical clue. BGP is not established with one of the routers, which means that the Cloud Router is not aware of the routes from one of the on-premises routers. Without BGP, the traffic cannot be properly routed or load-balanced.
Let's go through the options:
1. A) One of the VPN sessions is configured incorrectly:
- What it is: This suggests that there is a misconfiguration on one of the VPN sessions between the on-premises routers and the Cloud Router.
- Why it’s not selected: The VPN logs indicate that no-proposal-chosen lines are appearing, which typically indicates a mismatch in configuration (like encryption settings or other negotiation parameters). However, the key issue here is the lack of BGP session establishment, not the VPN misconfiguration itself. If the VPN were misconfigured, the session wouldn't even establish, but in this case, one VPN session is working while the other is not. The root cause is more related to BGP, not the VPN configuration.
2. B) A firewall is blocking the traffic across the second VPN connection:
- What it is: This suggests that a firewall might be blocking traffic between the on-premises router and the Cloud Router, potentially preventing one of the VPNs from working correctly.
- Why it’s not selected: The issue described is specifically about the BGP session...
Author: Ryan · Last updated Jul 26, 2026
You need to define an address plan for a future new GKE cluster in your VPC. This will be a VPC native cluster, and the default Pod IP range allocation will be used. You must pre-provision all the needed VPC subnets and their respective IP address ranges before cluster creation. The cluster will initially have a single node, but it will be scaled to a maximu...
To determine the appropriate subnet mask for the Pod IP address range for your GKE cluster (Google Kubernetes Engine), we need to consider the following:
1. VPC native cluster: In a VPC native GKE cluster, Google Cloud assigns an IP range to the Pods from the VPC subnet. These IPs are allocated to the Pods and the nodes will use a different set of IP addresses.
2. Minimum number of Pod IP addresses: You want to allocate the minimum number of IP addresses for the Pods, based on the need for scaling from 1 to 3 nodes. Each node in the cluster needs an IP address for the node itself, but the Pods will also need IP addresses for each container running on those nodes.
3. Default Pod IP range allocation: Google Kubernetes Engine assigns a set number of IP addresses per node based on the subnet mask selected for the Pod IP range. Generally, the smaller the subnet mask, the more IP addresses are available.
Let's break down the options:
1. A) /21:
- What it is: A `/21` subnet mask provides 2,048 IP addresses (since 2^(32-21) = 2,048).
- Why it’s not selected: A `/21` subnet would give you a large number of IP addresses that you likely don’t need, especially since you’re only scaling the cluster to 3 nodes initially. This would waste a significant amount of IP address space for the Pods, which goes against the requirement of allocating the minimum number of Pod IP addresses.
- Possible scenario: This option would be more suitable for a much larger cluster with a significantly higher number of Pods, but not for a small cluster with just 3 nodes.
2. B) /22:
- What it is: A `/22` subnet mask provides 1,024 IP addresses (since 2^(32-22) = 1,024).
- Why it’s not selected: While this option provides fewer IP addresses than the `/21` subnet, it still gives more than enough for the current requirement. If the cluster will only need to scale to 3 nodes initial...
Author: Isabella · Last updated Jul 26, 2026
You have created a firewall with rules that only allow traffic over HTTP, HTTPS, and SSH ports. While testing, you specifically try to reach the server over multiple ports and protocols; however, you do not see any...
To resolve the issue of not seeing denied connections in the firewall logs, let's break down the options and consider the reasoning behind each one:
A) Enable logging on the default Deny Any Firewall Rule.
This option would be useful if you have a default "deny all" rule in place that catches traffic that doesn’t match any allow rule. By enabling logging on this rule, all traffic that does not match any allow rule will be logged as denied, which is what you're looking for. However, if there is no "deny all" rule explicitly defined or if the firewall rules don't have a default deny rule at the end, this may not work.
B) Enable logging on the VM Instances that receive traffic.
Enabling logging on the VM instances would capture logs related to the traffic at the instance level, not necessarily from the firewall perspective. Firewall logs are typically the appropriate place to capture details about denied traffic at the network layer. This option is not ideal because it won’t provide the insights needed from the firewall’s ruleset itself.
C) Create a logging sink forwarding all firewall logs with no filters.
A logging sink that forwards all firewall logs without any filtering can give you visibility into all firewall events, but this won’t specifically address the problem of not logging denied connections. It’s a broader approach and could overwhelm the log system with irrelevant information s...
Author: Chloe · Last updated Jul 26, 2026
In your company, two departments with separate GCP projects (code-dev and data-dev) in the same organization need to allow full cross-communication between all of their virtual machines in GCP. Each department has one VPC in its project and wants full control over their network. Neither department intends to recreat...
To allow full cross-communication between virtual machines (VMs) in two separate GCP projects (code-dev and data-dev) while minimizing costs and without re-creating existing computing resources, let’s review each of the available options.
A) Connect both projects using Cloud VPN
Cloud VPN allows you to connect on-premises networks or VPC networks across GCP projects, but it’s typically used for secure connections over the public internet. It creates encrypted tunnels, which can incur additional costs for data transfer and management overhead. Since both projects are in the same GCP organization and need internal communication, Cloud VPN is not the most cost-effective or efficient option in this case. It's usually used for hybrid cloud connectivity (e.g., connecting to on-premises environments) rather than between two internal GCP VPCs.
B) Connect the VPCs in project code-dev and data-dev using VPC Network Peering
VPC Peering is a cost-effective solution for enabling full communication between VPCs across GCP projects. Peering allows traffic to flow directly between the VPCs, and since the VPCs are in the same organization, there is no additional cost for data transfer between them (as long as they are in the same region). Peering also ensures that both departments maintain control over their individual VPCs without any interference or need to share resources directly. This approach is simple and avoids the overhead of managing external connectivity.
C) Enable Shared VPC in one project (e.g., code-dev), and make the second project (e.g., data-dev) a service project
Shared VPC is useful when you want a central project (the host project) to manage resources that other projects (service projects) can use. This is a good solution if you need central control over networking resources but can be overkill in this case since the goal is to allow full cross-communication without recreating existing resources. The Shared VPC model requires additional configuration (such as setting up IAM roles and enabling the appropriate service accounts) ...
Author: Joseph · Last updated Jul 26, 2026
You need to create a GKE cluster in an existing VPC that is accessible from on-premises. You must meet the following requirements:
* IP ranges for pods and services must be as small as possible.
* The nodes and the master must not be reachable from the internet.
* You mus...
To meet the requirements of creating a GKE cluster in an existing VPC that is accessible from on-premises while minimizing IP range sizes and ensuring that the nodes and master are not accessible from the internet, let's evaluate the given options.
Key Requirements:
1. Minimize IP ranges for pods and services: You need to ensure that the IP ranges for pods and services are as small as possible.
2. Nodes and the master must not be reachable from the internet: The GKE cluster must be private and not exposed to the internet.
3. On-premises access with kubectl: You need to manage the cluster from on-premises subnets using `kubectl`.
A) Create a private cluster that uses VPC advanced routes.
- Pod and service IP ranges set as /24: The /24 range is relatively small, which satisfies the requirement to minimize the IP ranges.
- Set up a network proxy to access the master: This is needed to ensure the master is not publicly accessible but still can be managed from on-premises.
- Private cluster: This option creates a private GKE cluster, meaning the nodes and master are not directly reachable from the internet, which meets the security requirement.
However, VPC advanced routes is not necessary in this case. The default networking setup for VPC-native clusters should suffice, and adding advanced routes might introduce unnecessary complexity. This option is not ideal because it adds unnecessary steps and complexity (advanced routing) when it could be avoided.
B) Create a VPC-native GKE cluster using GKE-managed IP ranges.
- Pod IP range as /21 and service IP range as /24: The /21 range for pods is much larger than necessary. The requirement is to minimize IP ranges, and a /21 range for pods is excessive in this case.
- Set up a network proxy to access the master: This is required to manage the master from on-premises securely.
- GKE-managed IP ranges: GKE-managed IP ranges provide a simplified approach for IP management but do not provide the flexibility of custom IP ranges that can be more tightly controlled, which is a better fit for the requirement to minimize the IP range size.
This option is rejected because the pod IP range of /21 is too large compared to the smaller /24 requirement and doesn’t offer enough control over IP range size.
C) Create a VPC-native GKE cluster using user-managed IP ranges.
- Set the pod and service ranges as /24: The /24 ranges meet the requirement to minimize I...
Author: Emily · Last updated Jul 26, 2026
You are creating an instance group and need to create a new health check for HTTP(s) load balancing.
Which two met...
To create a new health check for HTTP(s) load balancing in Google Cloud, let's evaluate each of the options and consider the reasoning behind the selected and rejected options:
A) Create a new health check using the gcloud command line tool.
- Correct: You can create a health check for HTTP(s) load balancing using the `gcloud` command line tool. This option allows you to configure health checks programmatically and is very effective for automation and managing infrastructure via scripts.
- Why it works: The `gcloud compute health-checks create http` or `gcloud compute health-checks create https` command can be used to create a new HTTP(s) health check. This approach is valid and widely used in both single instances and instance groups.
B) Create a new health check using the VPC Network section in the GCP Console.
- Rejected: The VPC Network section is primarily used for network-level configurations like subnets, routes, and firewall rules, not for creating health checks for load balancing. Health checks for HTTP(s) load balancing are managed under the "Health checks" section, not within VPC network settings.
- Why it doesn't work: This section doesn't provide the interface needed to create HTTP(s) health checks, as it focuses on networking configurations.
C) Create a new health check, or select an existing one, when you complete the load balancer's backend configuration in the GCP Console.
- Correct: You can create a new health check or select an existing one while configuring the backend service for HTTP(s) load balancing in the GCP Console. This approach is integrated into the load balancer's setup process, allowing you to define or select a health check as part of the backend configuration.
- Why it works: During the setup of a backend service for a HTTP(s) load balancer, the console prompts you to either choose an existing health check or create a new...
Author: Kunal · Last updated Jul 26, 2026
You are in the early stages of planning a migration to GCP. You want to test the functionality of your hybrid cloud design before you start to implement it in production. The design includes services running on a Compute Engine Virtual Machine instance that need to communicate to on-premises servers using private
IP addresses. The on-premises servers have connectivity to the internet, but you have not yet established any Cloud Interconnect connection...
To test the functionality of your hybrid cloud design with a low-cost method of enabling connectivity between your Compute Engine VM instance and on-premises servers in less than 24 hours, let’s evaluate each of the available options based on the following key factors:
Key Factors:
1. Cost: The goal is to choose the lowest-cost option.
2. Timeframe: The solution must be quick to set up, ideally within 24 hours.
3. Connectivity: The connection should allow private IP communication between the VM and on-premises servers.
A) Cloud VPN
- Correct: Cloud VPN is a low-cost and quick-to-deploy solution that enables secure communication between GCP resources (e.g., Compute Engine VM) and on-premises servers over the public internet using a VPN tunnel.
- Why it works: Cloud VPN allows for private IP communication by creating an encrypted tunnel between your GCP environment and your on-premises network, which fits the requirements of private IP communication and is relatively inexpensive to set up.
- Setup: You can create a Cloud VPN connection quickly (within 24 hours) and it is ideal for initial testing without requiring the full setup of physical infrastructure like Interconnect.
B) 50-Mbps Partner VLAN attachment
- Rejected: This option involves using a Partner Interconnect to create a connection via a partner service provider, which involves more cost than Cloud VPN and requires a partner VLAN attachment. It may take longer to set up compared to Cloud VPN because it requires coordination with the partner provider.
- Why it doesn't work: While this option can provide faster and more reliable connections than Cloud VPN, it involves higher costs, and setting up a partner VLAN attachment might take longer than the 24-hour testing window, especially if you don’t a...
Author: Lucas · Last updated Jul 26, 2026
You want to implement an IPSec tunnel between your on-premises network and a VPC via Cloud VPN. You need to restrict reachability over the tunnel to specific local subnets, and you do not have a device cap...
To implement an IPSec tunnel between your on-premises network and a VPC via Cloud VPN, while restricting reachability over the tunnel to specific local subnets and not using a device capable of speaking BGP, we need to focus on routing options that do not require dynamic protocols like BGP.
Let’s evaluate the options:
A) Dynamic routing using Cloud Router
- Explanation: This option uses BGP to dynamically exchange routing information between your on-premises network and the VPC. However, the question states that the device is not capable of speaking BGP, so this option is not viable because it relies on dynamic routing via Cloud Router and BGP.
B) Route-based routing using default traffic selectors
- Explanation: Route-based VPNs involve using traffic selectors to direct traffic over the VPN tunnel based on routes in the routing table. While this option might work in general, the use of default traffic selectors does not allow you to restrict reachability to specific subnets. It would route all traffic, and it doesn’t give you the flexibility to limit access to specific local subnets. Therefore, this option is not ideal for this specific need.
C) Policy-based routing using a custom local traffic selector
- Explanation: Policy-based routing (PBR) is typically used for directing traffic based on specific rules, such as...
Author: SolarFalcon11 · Last updated Jul 26, 2026
You have enabled HTTP(S) load balancing for your application, and your application developers have reported that HTTP(S) requests are not being distributed correctly to your Compute Engine Virtual Machine instances. You want to find da...
To determine how HTTP(S) requests are being distributed to your Compute Engine Virtual Machine instances, you'll need to analyze the behavior of the HTTP(S) load balancer and gain insights into metrics related to backend services and request distribution. Let's evaluate the options based on their relevance and utility in this scenario.
A) On the Load Balancer details page of the GCP Console, click on the Monitoring tab, select your backend service, and look at the graphs.
- Explanation: This option provides a graphical overview of how the load balancer is handling traffic. By selecting the backend service and examining the graphs, you can directly see metrics like request distribution, response time, and any issues related to the backend services. This approach gives a clear and direct visualization of how traffic is being routed to backend instances, making it a relevant and effective method for this scenario.
- Reasoning for rejection: There’s no rejection for this option as it directly answers the question and provides actionable insights.
B) In Stackdriver Error Reporting, look for any unacknowledged errors for the Cloud Load Balancers service.
- Explanation: Stackdriver Error Reporting provides details about errors and exceptions in the system, but it primarily focuses on error detection rather than detailed traffic distribution metrics. While errors related to load balancing might appear here, this is not a method for analyzing how requests are distributed to backend instances.
- Reasoning for rejection: This option doesn't give insights into how requests are being distributed, so it’s not suitable for answering the question.
C) In Stackdriver Monitoring, select Resources > Metrics Explorer and search for the https/request_bytes_count metric.
- Explanation: The `https/request_bytes_count` metric gives information about the number of HTTP(S) requests received, but it doesn't specifically provide information about how the requests are distributed among backend instances. It is more of a general traffic metric th...
Author: Charlotte · Last updated Jul 26, 2026
You want to use Partner Interconnect to connect your on-premises network with your VPC. You already have an...
To connect your on-premises network with your VPC using Partner Interconnect, you need to follow a series of steps to establish the connection, starting with the correct action to initiate the process.
Let's evaluate the options based on the correct steps:
A) Log in to your partner's portal and request the VLAN attachment there.
- Explanation: Partner Interconnect relies on an agreement with an Interconnect partner who provides the physical connection to Google’s network. Requesting the VLAN attachment from your partner would indeed be part of the process, but it is not the first step in establishing the connection from the Google Cloud side. The initial step involves setting up the connection in Google Cloud.
- Reasoning for rejection: While this is part of the process, it’s not the first action you should take, as the initial setup should be done in the Google Cloud Console before you go to the partner for the VLAN attachment.
B) Ask your Interconnect partner to provision a physical connection to Google.
- Explanation: This is an essential step, but it is not the first action you should take. The physical connection is typically provisioned by the Interconnect partner after you have configured the necessary settings on your Google Cloud project, such as creating the VLAN attachment.
- Reasoning for rejection: You need to first create the VLAN attachment in the Google Cloud Console before your partner can provision the physical connection. This step would occur after the Google Cloud-side configuration.
C) Create a Partner Interconnect type VLAN attachment in the GCP Console and retrieve the pairing key.
- Explanation: This is ...
Author: FlamePhoenix2025 · Last updated Jul 26, 2026
You need to centralize the Identity and Access Management permissions and email distribution for the WebServices Tea...
To centralize Identity and Access Management (IAM) permissions and email distribution for the WebServices Team efficiently, the goal is to provide a centralized and scalable way to manage both permissions and communications. Let's evaluate each option and determine the most suitable one.
A) Create a Google Group for the WebServices Team.
- Explanation: Creating a Google Group is an effective way to manage email distribution for a group of people. By setting up a Google Group, you can centralize communications and enable easy access control through group membership. However, Google Groups alone are not ideal for managing IAM permissions. While you can assign roles to a Google Group, they aren't as integrated or scalable as other solutions specifically designed for IAM at an enterprise level.
- Reasoning for rejection: Although useful for email distribution and managing access to shared resources, Google Groups doesn't centralize IAM permissions in the way that would allow for efficient, scalable permissions management across multiple Google Cloud services.
B) Create a G Suite Domain for the WebServices Team.
- Explanation: G Suite (now Google Workspace) is a productivity and collaboration suite that includes tools like Gmail, Google Drive, and Calendar. Creating a G Suite domain would enable centralized email management for the WebServices Team, but it does not address IAM permissions directly for Google Cloud resources. While Google Workspace provides admin controls for users and email, it is not primarily focused on IAM within Google Cloud.
- Reasoning for rejection: While G Suite allows centralized email and user management, it does not provide centralized IAM permissions for Google Cloud, which is key for the WebServices Team in this scenario.
C) Create a new Cloud Identity Domain for the WebServices Team.
- Explanation: Cloud Identity is a dedicated identity management service that help...
Author: Aditya · Last updated Jul 26, 2026
You are using the gcloud command line tool to create a new custom role in a project by coping a predefined role. You receive this error message:
INVALID_ARGUMENT: Pe...
When encountering the error "INVALID_ARGUMENT: Permission resourcemanager.projects.list is not valid" while attempting to create a custom role by copying a predefined role, it suggests that the permission `resourcemanager.projects.list` is either invalid or not appropriate for custom roles, and needs to be addressed properly.
Let's evaluate the options:
A) Add the resourcemanager.projects.get permission, and try again.
- Explanation: Adding `resourcemanager.projects.get` permission is unlikely to resolve the issue, because the problem is specifically related to the `resourcemanager.projects.list` permission being used inappropriately in the custom role. The `get` permission is different from `list`, and adding it does not address the root cause of the problem (invalid permission).
- Reasoning for rejection: This option does not solve the issue since it does not directly address the use of the invalid `resourcemanager.projects.list` permission in the custom role.
B) Try again with a different role with a new name but the same permissions.
- Explanation: This option suggests changing the name of the role and attempting the operation again. However, the error is about an invalid permission, not about the role's name. Changing the role’s name does not resolve the core issue of an invalid permission in the role.
- Reasoning for rejection: The error is due to the invalid permission in the predefined role, not the role's name. Changing the name will not address the underlying problem.
C) Remove the resourcemanager.projects.list permission, and try again.
- Explanation: This option is the cor...
Author: Sofia2021 · Last updated Jul 26, 2026
One instance in your VPC is configured to run with a private IP address only. You want to ensure that even if this instance is deleted, its current private IP address will not be automat...
In this case, the goal is to ensure that the instance’s current private IP address is not automatically reassigned to another instance if the instance is deleted. The proper solution here is to configure the private IP address to be "static," meaning it will persist even if the instance is terminated, thus preventing automatic reassignment.
Let's go through the options one by one:
A) Assign a public IP address to the instance:
- Rejection Reason: A public IP address would be used for communication over the internet, and this does not solve the issue of ensuring the private IP address is retained when the instance is deleted. In this scenario, the issue pertains to the private IP, not the public IP.
- Use case: Public IP addresses are used when instances need to be directly accessible over the internet, but this doesn't address the private IP reassignment scenario.
B) Assign a new reserved internal IP address to the instance:
- Rejection Reason: This would assign a different reserved internal IP to the instance but doesn't necessarily ensure that the current private IP is retained after instance deletion. While this does guarantee that an internal IP will persist, it's not what is being asked for—it's about keeping the existing IP.
- Use case: This could be used when you want to assign a different reserved internal IP address to an instance but doesn't specifically address ensuring the current IP is not...
Author: Scarlett · Last updated Jul 26, 2026
After a network change window one of your company's applications stops working. The application uses an on-premises database server that no longer receives any traffic from the application. The database server IP address is 10.2.1.25. You examine the change request, and the only change is that 3 additional VPC subnets were created. The new VPC subnets ...
To address the issue where the on-premises database server (10.2.1.25) no longer receives traffic after a network change, let's examine the situation and go over each option step by step:
Situation Breakdown:
- You added three new VPC subnets: `10.1.0.0/16`, `10.2.0.0/16`, and `10.3.1.0/24`.
- The on-premises router is advertising `10.0.0.0/8`, a broad range of IP addresses.
- The application’s traffic is supposed to reach the database server with IP `10.2.1.25`, but it’s no longer working.
- The issue is likely related to routing since the database server's IP is within the `10.2.0.0/16` subnet, which was affected by the change.
Let's go through each option:
---
A) The less specific VPC subnet route is taking priority.
- Rejection Reason: Routes in the VPC are matched based on specificity, with more specific routes (those with a longer prefix) taking precedence over less specific routes. The `10.2.0.0/16` subnet is more specific than `10.0.0.0/8`. In this case, the route to `10.2.1.25` (which falls within `10.2.0.0/16`) should be matched by the more specific route, not a less specific one.
- Use Case: This option would be valid if the more specific subnet (like `10.2.1.0/24`) were misconfigured, but that's not the case here. The more specific routes should be prioritized.
---
B) The more specific VPC subnet route is taking priority.
- Selection Reason: This is the correct option. The more specific route for `10.2.0.0/16` (created by the VPC) should be taking priority. However, the new subnets (`10.1.0.0/16`, `10.2.0.0/16`, and `10.3.1.0/24`) might cause a conflict in the routing table if the routing is misconfigured. The `10.0.0.0/8` advertisement from the on-premises router may have caused the new subnets to overlap or not be properly routed, affecting the traffic to `10.2.1.25`.
- ...
Author: Ethan · Last updated Jul 26, 2026
You need to create a new VPC network that allows instances to have IP addresses in both the 10.1.1.0/24 network an...
To allow instances in a new VPC network to have IP addresses from both the `10.1.1.0/24` and `172.16.45.0/24` networks, we need to configure the network so that instances can communicate using both IP address ranges within the same VPC or between VPCs. Let's go over the options and analyze each one in detail.
A) Configure global load balancing to point 172.16.45.0/24 to the correct instance.
- Rejection Reason: Global load balancing is typically used to distribute traffic across multiple instances or regions based on traffic rules. While it can manage traffic between instances, it does not directly help you assign multiple IP addresses (e.g., from `10.1.1.0/24` and `172.16.45.0/24`) to a single instance. This is not the right tool for enabling instances to have IPs from both subnets within a single VPC.
- Use Case: This could be used for high-availability routing or cross-region traffic management but is not related to the requirement of assigning IPs from two distinct subnets.
B) Create unique DNS records for each service that sends traffic to the desired IP address.
- Rejection Reason: DNS records are useful for resolving domain names to IP addresses, but they don't change how IP addresses are assigned to instances in your network. Creating DNS records won't allow instances to have IP addresses in both `10.1.1.0/24` and `172.16.45.0/24`. This approach addresses routing at the domain name level, not the IP assignment level.
- Use Case: This could be helpful for resolving specific domain names to specific services but won't help in assigning IPs to instances from different subnets.
C) Configure an alias-IP range of ...
Author: Mia · Last updated Jul 26, 2026
You are deploying a global external TCP load balancing solution and want to preserve the source IP address of the original layer...
To preserve the source IP address of the original layer 3 payload while deploying a global external TCP load balancing solution, you need a load balancer that forwards the traffic while retaining the client’s original IP address in the request.
Let's go over each option and analyze which one is the best for this use case:
---
A) HTTP(S) load balancer:
- Rejection Reason: The HTTP(S) load balancer operates at the Layer 7 (application layer) of the OSI model and is typically used for HTTP/HTTPS traffic. It doesn't preserve the original source IP address in the layer 3 (network layer) payload. Instead, it handles HTTP headers and uses a proxy model where the client’s IP is replaced with the IP of the load balancer. While it can forward the original IP address in the `X-Forwarded-For` header, it does not retain the client’s IP at Layer 3.
- Use Case: This load balancer is great for web traffic where the source IP can be forwarded in headers, but it’s not suitable for preserving Layer 3 information (such as the original source IP in the IP header).
---
B) Network load balancer:
- Selection Reason: The Network Load Balancer (NLB) is designed to operate at Layer 4 (transport layer) and is ideal for preserving the source IP address of the original traffic. It forwards traffic directly to the backend instances without modifying the original layer 3 payload, ensuring that the source IP address remains intact.
- Use Case: The NLB is perfect when you need to preserve the client’s original IP address in scenarios where TCP/UDP traffic is involved, and the goal is to forward the traffic witho...
Author: Vikram · Last updated Jul 26, 2026
Your company has a single Virtual Private Cloud (VPC) network deployed in Google Cloud with access from your on-premises network using Cloud Interconnect. You must configure access only to Google APIs and services that are supported by VPC Servi...
In your scenario, you need to configure access to Google APIs and services supported by VPC Service Controls over hybrid connectivity with a Service Level Agreement (SLA) in place. Here's an analysis of each option and why one should be selected:
---
A) Configure the existing Cloud Routers to advertise the Google API's public virtual IP addresses.
- Rejection Reason: Google APIs and services accessed through VPC Service Controls need to use private IP addresses, not public IPs. Advertising public IPs would not be the correct approach, as it doesn't align with the private connectivity required for VPC Service Controls.
- Use Case: Advertising public IP addresses is used when you need to access services that are publicly available, but it does not address the requirement for private connectivity to Google APIs via hybrid networking.
---
B) Use Private Google Access for on-premises hosts with restricted.googleapis.com virtual IP addresses.
- Selection Reason: This is the correct option. Private Google Access allows on-premises hosts (connected via Cloud Interconnect) to access Google APIs and services over private IP addresses, which is critical when using VPC Service Controls. This ensures that the traffic stays within the private network and does not traverse the public internet. By using restricted virtual IPs for the Google APIs, you are adhering to the SLA and requirements for private connectivity.
- Use Case: This option is ideal when you need secure, private access to Google services and APIs from an on-premises network connected to Google Cloud, without exposing traffic to the public internet. This configuration also supports hybrid connectivity with a service...
Author: Mia · Last updated Jul 26, 2026
Your company's security team tends to use managed services when possible. You need to build a dashboard to show the number of deny hits that occur against configured fi...
Let's evaluate each option carefully based on the goal of building a dashboard to show the number of deny hits against firewall rules, with minimal operational overhead.
A) Configure Firewall Rules Logging. Use Firewall Insights to display the number of hits.
- Pros:
- Firewall Rules Logging provides a native solution to track hits and denies.
- Firewall Insights is integrated with Google Cloud and designed to present metrics about firewall traffic.
- It directly integrates with Google's security infrastructure without additional overhead.
- Cons:
- May require some basic configuration for proper logging setup.
- Key Factor: Firewall Insights is specifically designed to help visualize traffic metrics (including deny hits) and can be configured with minimal setup.
B) Configure Firewall Rules Logging. View the logs in Cloud Logging, and create a custom dashboard in Cloud Monitoring to display the number of hits.
- Pros:
- Provides flexibility and customization for creating the dashboard.
- Cloud Logging and Monitoring are robust tools with extensive configuration options.
- Cons:
- Additional overhead is involved in creating custom dashboards.
- Requires more setup and management compared to Option A.
- Key Factor: While flexible, this option introduces extra complexity, such as creating custom dashboards and maintaining them.
C) Configure a firewall appliance from the Google Cloud Marketplace. Route all traffic through this appliance, and apply the firewall rules at this layer. Use the firewall appliance to display the number of hits.
- Pr...
Author: Rohan · Last updated Jul 26, 2026
You are configuring your Google Cloud environment to connect to your on-premises network. Your configuration must be able to reach Cloud Storage APIs and your Google Kubernetes Engine nodes across your private Cloud Interconnect network. You have already configured a Cloud Router with your Interconnect V...
To configure your Google Cloud environment to connect to your on-premises network and ensure connectivity to the Cloud Storage APIs and Google Kubernetes Engine (GKE) nodes over your private Cloud Interconnect network, the key focus is to ensure the proper advertisement of routes between your on-premises network and the Google Cloud network. Let's evaluate each option based on the context of your setup:
A) Configure the route advertisement to the default setting.
- Pros:
- Simple and quick setup.
- Default settings work for most cases where dynamic routing is sufficient.
- Cons:
- The default setting might not be sufficient for your specific needs (access to Cloud Storage APIs and GKE nodes). It may not advertise the necessary subnets for Cloud Storage or GKE nodes, as these typically require explicit routing.
- Key Factor: While the default route advertisement might work for general routing, it might not include all the necessary prefixes or specific Cloud Storage and GKE node IPs, leaving gaps in the connectivity.
B) On the on-premises router, configure a static route for the storage API virtual IP address, which points to the Cloud Router's link-local IP address.
- Pros:
- Allows direct static routing to the Cloud Storage API's IP address.
- Cons:
- It only addresses routing for the Cloud Storage API and doesn't cover all potential dynamic route needs, such as GKE node access. It also adds complexity in maintaining the static route manually, especially as the network grows or changes.
- This does not scale well or provide dynamic updates for new resources.
- Key Factor: This is too narrow a solution and only addresses Cloud Storage, which is not comprehensive enough for the full setup you need.
C) Configure the route advertisement to the custom setting, and manually add prefix 199.36.153.8/3...
Author: Sophia Clark · Last updated Jul 26, 2026
You are configuring load balancing for a standard three-tier (web, application, and database) application. You have configured an external HTTP(S) load balancer for the web servers. You need t...
To configure load balancing for the application tier of a standard three-tier application, we need to consider the following factors:
1. Traffic Type: Since the application tier is likely internal to the organization, it would need an internal load balancer (as external traffic to the application tier is typically not desired).
2. Separation of Tiers: The load balancing for the application tier should be independent of the web tier (which already has an external HTTP(S) load balancer).
3. Ease of Configuration and Scaling: The configuration should support scaling and not interfere with the existing infrastructure, ensuring that the application tier can be load balanced appropriately without requiring complex or invasive changes.
A) Configure a forwarding rule on the existing load balancer for the application tier.
- Pros:
- This option could potentially route traffic to the application tier via the same external HTTP(S) load balancer.
- Cons:
- Not recommended because it would expose the internal application tier to external traffic, which is a security risk and violates best practices for internal services. The application tier should not typically receive direct external traffic.
- Key Factor: This approach would compromise security and proper tier segregation, which is undesirable in a three-tier application.
B) Configure equal cost multi-path routing on the application servers.
- Pros:
- Equal cost multi-path routing (ECMP) could help with distributing traffic across multiple paths or servers.
- Cons:
- ECMP is not a load balancing solution in the traditional sense and would not manage or distribute traffic effectively between application servers.
- It lacks the scalability, health checks, and session persistence that a dedicated load balancer provides.
- Key Factor...
Author: Sophia · Last updated Jul 26, 2026
Your organization has a new security policy that requires you to monitor all egress traffic payloads from your virtual machines in region us-west2. You deployed an intrusion detection system (IDS) virtual appliance in the same region to meet the new policy. You now need...
To monitor all egress traffic payloads from your virtual machines in the `us-west2` region, the goal is to effectively capture and forward the traffic to the IDS for inspection. Let's evaluate the options based on the requirements and key factors:
A) Enable firewall logging, and forward all filtered egress firewall logs to the IDS.
- Pros:
- Firewall logging captures traffic that matches specific firewall rules.
- Cons:
- Firewall logs only capture metadata about the traffic (such as source, destination, and port), not the actual payloads. Since the policy requires monitoring payloads, firewall logs will not be sufficient as they don't provide full traffic inspection.
- Key Factor: This option is rejected because it only captures metadata, not the actual content of the egress traffic (the payload), which is necessary for the IDS.
B) Enable VPC Flow Logs. Create a sink in Cloud Logging to send filtered egress VPC Flow Logs to the IDS.
- Pros:
- VPC Flow Logs provide metadata on traffic flows, similar to firewall logs but at the VPC level.
- Cons:
- Like firewall logs, VPC Flow Logs only capture metadata about the traffic (such as source, destination, and ports), not the full payload. Therefore, this doesn't meet the requirement of monitoring payloads.
- Key Factor: This option is also rejected for the same reason as Option A; it doesn't provide the necessary payload data for the IDS.
C) Create an internal TCP/UDP load balancer for Packet Mirroring, and add a packet mirroring policy filter for egress traffic.
- Pros:
- Packet mirroring allows the capture of actual traffic payloads (not just metadata), which is necessary for the IDS to analyze the traffic.
- TCP/UDP load balancers are well-suited for this purpose, as th...
Author: Zara · Last updated Jul 26, 2026
You are developing an HTTP API hosted on a Compute Engine virtual machine instance that must be invoked only by multiple clients within the same Virtual Private Cloud (VPC). You wan...
To develop an HTTP API hosted on a Compute Engine virtual machine instance that is only invoked by clients within the same Virtual Private Cloud (VPC) and allow clients to get the IP address of the service, it's essential to choose a method that ensures internal-only access while also facilitating easy lookup of the IP address.
Let’s evaluate each option based on the goal of providing internal access and enabling clients to retrieve the IP address:
A) Reserve a static external IP address and assign it to an HTTP(S) load balancing service's forwarding rule. Clients should use this IP address to connect to the service.
- Pros:
- Reserving an external IP and using an HTTP(S) load balancer would allow clients to access the service externally.
- Cons:
- This does not meet the requirement of internal-only access. If the API is intended to be used only within the same VPC, exposing it to the internet through an external IP is a security risk and goes against the "internal-only" requirement.
- Key Factor: This option violates the requirement to keep the service accessible only within the VPC.
B) Ensure that clients use Compute Engine internal DNS by connecting to the instance name with the URL https://[INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal/.
- Pros:
- This solution would keep the service internal, utilizing Compute Engine’s internal DNS, which provides private DNS names for VM instances.
- The clients can resolve the VM’s IP address within the same VPC.
- Cons:
- The instance name-based URL may be cumbersome to manage across multiple instances, especially if there are frequent scaling operations or if there are multiple clients needing access to the service. It doesn’t provide a meaningful service name for clients to interact with.
- Key Factor: This is a valid internal-only solution, but it may be less flexible or s...
Author: Liam · Last updated Jul 26, 2026
You recently deployed Cloud VPN to connect your on-premises data canter to Google Cloud. You need to monitor the usage of this VPN and set up alerts in case traffic exceeds the maximum allowed. You need to be able to qui...
To monitor and set up alerts for VPN usage and ensure that you can quickly decide whether to add extra links or move to a Dedicated Interconnect, let’s break down the options:
A) In the Network Intelligence Center, check for the number of packet drops on the VPN.
- Reasoning: This option focuses on packet drops, which can be an important indicator of network issues or congestion. However, it doesn't directly monitor the bandwidth utilization, which is what you need for this scenario. The packet drop metric alone does not provide enough information to determine if you're exceeding bandwidth limits.
- Use case: You would use this option if you were troubleshooting specific network reliability issues like packet loss, but it does not provide the bandwidth monitoring needed for scaling decisions.
B) In the Google Cloud Console, use Monitoring Query Language to create a custom alert for bandwidth utilization.
- Reasoning: This option allows for precise monitoring of bandwidth utilization using Google Cloud's Monitoring Query Language (MQL). By setting up a custom alert, you can receive notifications if traffic exceeds the maximum allowed. This helps in scaling decisions, either by adding more VPN links or moving to a more robust solution like Dedicated Interconnect. MQL enables detailed custom alerts, making it the best option for proactive monitoring.
- Use case: This is ideal when you want full control over your monitoring and alerting setup, especially if you need to create custom alerts based on specific thresholds for bandwidth usage.
C) ...
Author: Sophia · Last updated Jul 26, 2026
You have applications running in the us-west1 and us-east1 regions. You want to build a highly available VPN that provides 99.99% availability to connect your applications from your project to the cloud services provided by your partner's project while minimizing the amount of infrastructure required. You...
To design a highly available VPN that offers 99.99% availability with minimal infrastructure, we need to carefully consider the most efficient solution to meet both availability and simplicity requirements. Let's analyze each option:
A) Create one Cloud Router and one HA VPN gateway in each region of your VPC and your partner's VPC. Connect your VPN gateways to the partner's gateways. Enable global dynamic routing in each VPC.
- Reasoning: This option uses HA VPN (High Availability VPN) to provide resilience and high availability, which is important for achieving 99.99% availability. By deploying one HA VPN gateway in each region of both your VPC and your partner’s VPC, you ensure that the VPN connection remains up even if one region or VPN gateway fails. Enabling global dynamic routing ensures that routing information is shared between both VPCs for efficient failover and load balancing.
- Use case: This option is ideal for achieving high availability with minimal infrastructure. It ensures redundancy in both regions and uses Cloud Router for efficient dynamic routing.
B) Create one Cloud Router and one HA VPN gateway in the us-west1 region of your VPC. Create one OpenVPN Access Server in each region of your partner's VPC. Connect your VPN gateway to your partner's servers.
- Reasoning: This option introduces OpenVPN Access Servers in your partner’s VPC, which adds unnecessary complexity. OpenVPN typically requires more management and doesn't scale as efficiently as the native Google Cloud solutions like HA VPN. Furthermore, this setup does not ensure high availability across both regions for your partner’s services, as it only sets up the VPN in one region (us-west1).
- Use case: This is not the most efficient option for high availability. It adds extra infrastructure (OpenVPN Access Servers) without significantly enhancing reliability or minimizing complexity.
C) Create one OpenVPN Access Server in each region of your VPC...
Author: Chloe · Last updated Jul 26, 2026
You need to create the network infrastructure to deploy a highly available web application in the us-east1 and us-west1 regions. The application runs on Compute Engine instances, and it does not require th...
To deploy a highly available web application in the us-east1 and us-west1 regions on Compute Engine instances, following Google-recommended best practices, we need to focus on redundancy, scalability, high availability, and global reach. Let’s break down the options:
A) Create one VPC with one subnet in each region. Create a regional network load balancer in each region with a static IP address. Enable Cloud CDN on the load balancers. Create an A record in Cloud DNS with both IP addresses for the load balancers.
- Reasoning: While creating a regional load balancer in each region provides redundancy, network load balancers are not global. They distribute traffic only within the region, meaning that if one region fails, the other won't automatically take over. This option does not fully ensure high availability across regions.
- Use case: This setup is more appropriate for non-global applications, where you want to use regional traffic management. However, for global high availability, a regional load balancer does not meet your requirements.
B) Create one VPC with one subnet in each region. Create a global load balancer with a static IP address. Enable Cloud CDN and Google Cloud Armor on the load balancer. Create an A record using the IP address of the load balancer in Cloud DNS.
- Reasoning: This option uses a global load balancer, which is the recommended approach for global applications as it distributes traffic across regions based on proximity, health checks, and traffic load. It also leverages Cloud CDN for faster content delivery and Google Cloud Armor for security. This setup aligns with Google Cloud's best practices for global high-availability deployments.
- Use case: This option is ideal for highly available web applications that require redundancy and failover between regions. It's optimal for applications serving global traffic.
C) Create one VPC in each region, and peer both VPCs. Create a global load balancer. Enable Cloud CDN on the load balancer. Create a CNAME for the load balancer in Cl...
Author: Carlos Garcia · Last updated Jul 26, 2026
You are the network administrator responsible for hybrid connectivity at your organization. Your developer team wants to use Cloud SQL in the us-west1 region in your Shared VPC. You configured a Dedicated Interconnect connection and a Cloud Router in us-west1, and the connectivity between your Shared VPC and on-premises data center is working as expected. You just created the private services access connection required for Cloud SQL ...
In this scenario, the developer team cannot access the Cloud SQL instance in us-west1 from your on-premises data center, even though you have set up the Dedicated Interconnect, Cloud Router, and Private Services Access connection for Cloud SQL. The issue likely involves the routing configuration required for access to Cloud SQL from on-premises.
Let’s break down the options and analyze them:
A) 1. Modify the VPC Network Peering connection used for Cloud SQL, and enable the import and export of routes. 2. Create a custom route advertisement in your Cloud Router to advertise the Cloud SQL IP address range.
- Reasoning: This option addresses the routing configuration by modifying the VPC Network Peering to enable route import/export. You also create a custom route advertisement for the Cloud SQL IP range. Custom route advertisements ensure that the IP range for Cloud SQL is advertised to your on-premises network, allowing access. This is a correct approach since the Cloud Router needs to advertise the Cloud SQL IP range to allow proper routing from on-premises.
- Use case: This option is valid because modifying the peering connection and adding route advertisements will ensure proper connectivity to the Cloud SQL instance.
B) 1. Change the VPC routing mode to global. 2. Create a custom route advertisement in your Cloud Router to advertise the Cloud SQL IP address range.
- Reasoning: Changing the VPC routing mode to global is not necessarily required here. The issue is likely due to missing route advertisements or misconfiguration with VPC Peering, not the routing mode. The global routing mode is typically used for cross-region routing, but this doesn’t directly solve the issue of making Cloud SQL accessible from on-premises.
- Use case: While creating a custom route advertisement is useful, changing the VPC routing mode to global isn't the right solution in ...
Author: John · Last updated Jul 26, 2026
Your company has separate Virtual Private Cloud (VPC) networks in a single region for two departments: Sales and Finance. The Sales department's VPC network already has connectivity to on-premises locations using HA VPN, and you have confirmed that the subnet ranges do not overlap. You plan to peer both VPC networks to use the same HA tunnels for on-premises connectivity, while providing internet connectivity for the Google Cloud workloads through Cloud NA...
In this scenario, the goal is to peer two VPC networks (Sales and Fice), propagate all routes between the Fice department and on-premises locations, and ensure that internet connectivity for the Google Cloud workloads is handled through Cloud NAT, while ensuring that internet access from the on-premises locations does not flow through Google Cloud. Additionally, route propagation between the two VPCs and on-premises must be set up correctly.
Let’s analyze the options:
A) Peer the two VPCs, and use the default configuration for the Cloud Routers.
- Reasoning: Using the default configuration for the Cloud Routers might not be sufficient in this case. The default configuration doesn’t address the need to propagate specific custom routes (such as the peered VPC network ranges) to on-premises locations. The default settings might not enable the level of control needed to propagate routes properly between the VPCs and the on-premises locations.
- Use case: This option is useful for simpler scenarios but doesn't meet the need for custom route advertisements or precise route control between the VPCs and on-premises locations.
B) Peer the two VPCs, and use Cloud Routers custom route advertisements to announce the peered VPC network ranges to the on-premises locations.
- Reasoning: This option sets up custom route advertisements, but it does not address the requirement to propagate all routes from the Fice VPC to on-premises locations. Additionally, it does not provide a clear mechanism to ensure internet traffic is properly routed through Cloud NAT rather than flowing through Google Cloud for on-premises locations.
- Use case: While custom route advertisements are necessary, this option doesn’t fully satisfy the routing and internet connectivity requirements, especially with respect to on-premises connectivity and internet traffic handling.
C) Peer the two VPCs. Configure VPC Network Peering to export custom routes from Sales and import custom routes on Fice's VPC network. Use Cloud Routers custom route advertisements to announce a default route to the on-premises locations.
- Reasoning: This option exports custom routes from the Sales VPC and imports custom routes into the ...
Author: Ella · Last updated Jul 26, 2026
You recently noticed a recurring daily spike in network usage in your Google Cloud project. You need to identify the virtual machine (VM) instances and type of traffic causing the spike in traffic util...
To identify the virtual machine (VM) instances and the type of traffic causing the spike in traffic utilization, while minimizing cost and management overhead, let’s assess the options provided:
Option A: Enable VPC Flow Logs and send the output to BigQuery for analysis.
- Explanation: VPC Flow Logs provide detailed information about the traffic flowing through your Google Cloud Virtual Private Cloud (VPC) network, such as which VM instances are involved in traffic, the source and destination IPs, and the amount of traffic. Sending the logs to BigQuery allows you to analyze and filter the data efficiently to identify patterns, such as the spikes in traffic and which VMs are generating them.
- Pros:
- Low cost: VPC Flow Logs are relatively inexpensive compared to other options like packet mirroring or third-party appliances.
- Scalable: This method allows for long-term monitoring and querying of traffic data.
- Low management overhead: Once configured, it is relatively hands-off. BigQuery allows for detailed analysis without needing to manage extra infrastructure.
- Cons: Does not capture detailed packet-level information. If the traffic pattern is more complex, additional analysis might be needed.
- When to use: Ideal for identifying traffic patterns, network bottlenecks, and overall traffic utilization per VM without high management overhead.
Option B: Enable Firewall Rules Logging for all allowed traffic and send the output to BigQuery for analysis.
- Explanation: Firewall Rules Logging captures data about the traffic that is being allowed by your firewall rules. This log will include the IP addresses of the source and destination, along with the allowed traffic.
- Pros:
- Helps in tracking allowed traffic patterns.
- Can be useful in identifying external sources or destinations that might be contributing to the spike.
- Cons:
- Firewall logs only show traffic that passes through your firewall and are limited to the traffic allowed by the firewall rules. It won’t show traffic that is blocked or internal traffic between VMs.
- Doesn’t give full visibility of traffic between VM instances or detailed traffic patterns.
- Higher complexity for data analysis compared to VPC Flow Logs.
- When to use: Best for analyzing traffic patterns related to the firewall's allowed traffic but not for identifyi...
Author: Elizabeth · Last updated Jul 26, 2026
You need to enable Private Google Access for use by some subnets within your Virtual Private Cloud (VPC). Your security team set up the VPC to send all internet-bound traffic back to the on- premises data center for inspection before egressing to the internet, and is also implementing VPC Service Controls in the environment for API-level security control. You have already enabled t...
To enable Private Google Access while adhering to the security team's requirements, let's go through each option:
Understanding the Requirements
- Private Google Access allows Google Cloud VMs without external IP addresses to access Google APIs and services privately (i.e., through internal IPs, not via the public internet).
- The VPC is already configured to send internet-bound traffic through the on-premises data center for inspection before egressing to the internet.
- VPC Service Controls are implemented to ensure API-level security.
- You’ve already enabled the subnets for Private Google Access.
The main goal is to ensure that traffic destined for Google APIs still adheres to the security team's inspection policies while allowing Private Google Access. The on-premises data center must inspect traffic to Google's services, and this should happen privately without direct exposure to the public internet.
Option A:
1. Create a private DNS zone with a CNAME record for `.googleapis.com` to `restricted.googleapis.com`, with an A record pointing to Google's restricted API address range.
2. Create a custom route that points Google's restricted API address range to the default internet gateway as the next hop.
- Explanation: This configuration routes traffic to `restricted.googleapis.com` (the restricted API address range) through the internet gateway. This doesn't work with Private Google Access because it directs traffic to a public internet gateway rather than leveraging Google's private infrastructure.
- Why rejected: Since the goal is to enable Private Google Access (which uses Google’s private network), routing via the internet gateway contradicts the need for private communication.
- When to use: This would be useful if you were configuring traffic to flow to external APIs rather than Google's private network.
Option B:
1. Create a private DNS zone with a CNAME record for `.googleapis.com` to `restricted.googleapis.com`, with an A record pointing to Google's restricted API address range.
2. Change the custom route that points the default route (`0.0.0.0/0`) to the default internet gateway as the next hop.
- Explanation: Similar to Option A, this points traffic destined for `restricted.googleapis.com` to an internet gateway, bypassing the private network for Google services. This is not aligned with the requirements for Private Google Access, which should use Google's internal network.
- Why rejected: This option still sends internet-bound traffic through the public internet gat...
Author: Nathan · Last updated Jul 26, 2026
You have deployed an HTTP(s) load balancer, but health checks to port 80 on the Compute Engine virtual machine instance are failing, and no traffic is sent to your in...
To resolve the issue where health checks on port 80 are failing for your HTTP(s) load balancer and no traffic is sent to your Compute Engine instances, let's go through the options one by one and explain the reasoning behind selecting the appropriate command.
Option A: `gcloud compute instances add-access-config instance-1`
- Explanation: This command adds an external IP address to a Compute Engine instance. It’s useful if the instance is missing an external IP or you need one to communicate with the internet or other services. However, the issue in this case is related to health checks and not the need for an external IP.
- Why rejected: This option won’t resolve the problem because the health check failures are not related to the instance lacking an external IP address. The issue is likely related to firewall rules or load balancer health check configurations.
- When to use: This option is used when you need to ensure a VM has an external IP address to access external resources or be publicly reachable, but this is not applicable to the current health check problem.
Option B: `gcloud compute firewall-rules create allow-lb --network load-balancer --allow tcp --destination-ranges 130.211.0.0/22,35.191.0.0/16 --direction EGRESS`
- Explanation: This command creates a firewall rule that allows egress (outbound) traffic to specific IP ranges associated with Google Cloud's external IPs used by load balancers. However, the problem here is related to incoming traffic to the VM for health checks, not outbound traffic.
- Why rejected: The issue is not with outgoing traffic; it’s with incoming health check traffic that the load balancer is trying to send to your VM on port 80. Therefore, an egress rule is not the solution.
- When to use: This would be useful in scenarios where you need to allow outgoing traffic to Google Cloud’s public IP ranges, but it’s irrelevant for health check failures or incoming traffic is...
Author: Kai · Last updated Jul 26, 2026
You deployed a hub-and-spoke architecture in your Google Cloud environment that uses VPC Network Peering to connect the spokes to the hub. For security reasons, you deployed a private Google Kubernetes Engine (GKE) cluster in one of the spoke projects with a private endpoint for the control plane. You configured authorized networks to be the subnet range where the GKE nodes are deployed. When you attempt to reac...
To allow access to the private Google Kubernetes Engine (GKE) control plane from other spoke projects in a hub-and-spoke architecture, let’s evaluate each of the options to determine which best addresses the situation.
Key Considerations:
- The GKE control plane has a private endpoint.
- You are using VPC Network Peering between the hub and the spoke projects.
- Authorized networks are configured as the subnet range where the GKE nodes are deployed.
- Access from other spoke projects to the GKE control plane is being blocked.
Option A: Add a firewall rule that allows port 443 from the other spoke projects.
- Explanation: This option proposes adding a firewall rule that allows inbound traffic on port 443, which is the default port for HTTPS traffic used to access the GKE control plane.
- Why rejected: While this might seem like a good idea, the issue lies in the fact that the GKE control plane is configured with a private endpoint. Access to the control plane is controlled by the authorized networks setting, not just by firewall rules. Even if you open port 443, the request will still be rejected if the source IP is not in the list of authorized networks.
- When to use: This would be useful for general access where there’s no private endpoint involved, but for a private GKE control plane, the authorized networks setting needs to be adjusted.
Option B: Enable Private Google Access on the subnet where the GKE nodes are deployed.
- Explanation: Private Google Access enables Google Cloud resources (such as VMs) in a subnet to access Google APIs and services (like GKE) over internal IPs, rather than needing an external IP for outbound traffic.
- Why rejected: While enabling Private Google Access is important for resources in the subnet where the GKE nodes are deployed to access Google services privately, it does not directly address the issue of cross-spoke communication for the private GKE control plane. The access is still controlled by the authorized networks setting, and enabling Private Google Access alone doesn’t resolve the cross-...
Author: Emily · Last updated Jul 26, 2026
You recently deployed your application in Google Cloud. You need to verify your Google Cloud network configuration before deploying your on-premises workloads. You want to confirm that your Google Cloud network configuration allows traffic to flow from your cloud resources to your on- premises network. This validation should also analyze ...
To verify your Google Cloud network configuration and confirm that traffic can flow from your cloud resources to your on-premises network, while also diagnosing potential failure points without sending any data plane test traffic, let's evaluate the available options:
Option A: Use Network Intelligence Center's Connectivity Tests.
- Explanation: Network Intelligence Center's Connectivity Tests is a tool that helps you analyze the connectivity between your Google Cloud resources and external destinations (like your on-premises network). This tool checks if the network configuration is correct and diagnoses any misconfigurations without sending actual data traffic. It can validate network configurations such as VPC peering, VPN tunnels, routes, and firewall rules, helping you identify potential failure points.
- Why selected: This option meets the requirement of verifying the network configuration without sending any test data traffic. It provides a non-intrusive way to ensure that the network allows traffic flow, while also diagnosing any issues in the network setup.
- When to use: This is the ideal choice when you want to validate network configurations between Google Cloud and your on-premises environment without triggering real data traffic. It helps you check connectivity, routes, and firewall configurations effectively.
Option B: Enable Packet Mirroring on your application and send test traffic.
- Explanation: Packet Mirroring allows you to capture and analyze network traffic for debugging and monitoring purposes. While it can be used to observe traffic and diagnose issues, it requires sending actual data plane traffic (test traffic) to mirror and analyze. This option contradicts the requirement to validate the network without sending any test traffic.
- Why rejected: This approach requires actual traffic to be sent and mirrored, which does not meet the goal of avoiding data plane test traffic.
- When to use: This opt...
Author: NebulaEagle11 · Last updated Jul 26, 2026
In your Google Cloud organization, you have two folders: Dev and Prod. You want a scalable and consistent way to enforce the following firewall rules for all virtual machines (VMs) with minimal cost:
* Port 8080 should always be open for VMs in the projects in the Dev folde...
To determine the best approach, let's evaluate each option based on scalability, consistency, ease of management, and cost-effectiveness.
Option A:
Create and associate a firewall policy with the Dev folder with a rule to open port 8080. Create and associate a firewall policy with the Prod folder with a rule to deny traffic to port 8080.
- Scalability and consistency: Firewall policies can be applied at the folder level, meaning this approach allows consistent enforcement across all projects within a folder, making it scalable and simple to manage.
- Cost-effectiveness: This method does not require creating additional infrastructure, such as Shared VPCs or separate services, so it is cost-effective.
- Why it works: Google Cloud firewall policies are an efficient way to manage security rules across a large number of projects within folders. The policy association at the folder level ensures that all resources within the folder are governed by the rule, making it ideal for your scenario.
Option B:
Create a Shared VPC for the Dev projects and a Shared VPC for the Prod projects. Create a VPC firewall rule to open port 8080 in the Shared VPC for Dev. Create a firewall rule to deny traffic to port 8080 in the Shared VPC for Prod. Deploy VMs to those Shared VPCs.
- Scalability and consistency: Shared VPCs can simplify network management across multiple projects, but this adds additional complexity, especially if you're managing multiple projects. You’d need to ensure the network setup is consistent, which can require more effort as the number of projects or resources increases.
- Cost-effectiveness: Shared VPCs introduce an additional level of complexity and potential cost, as you'd need to manage the shared network, especially if you're managing multiple projects and resources.
- Why it’s less ideal: While this could work, it introduces complexity with the Shared VPC and doesn’t fully align with the goal of simplicity and minimal cost. It would also require careful management of network resources.
Option C:
In all VPCs for the Dev projects, create a VPC f...
Author: Liam123 · Last updated Jul 26, 2026
You need to configure the Border Gateway Protocol (BGP) session for a VPN tunnel you just created between two Google Cloud VPCs, 10.1.0.0/16 and 172.16.0.0/16. You have a Cloud Router (router-1) in the 10.1.0.0/16 network and a second Cloud...
To properly configure a Border Gateway Protocol (BGP) session between two Google Cloud VPCs (with IP ranges of 10.1.0.0/16 and 172.16.0.0/16), each connected through its own Cloud Router, the configuration needs to be based on the following key factors:
1. Cloud Routers and BGP Peers: Each VPC will have a Cloud Router that manages the BGP session. The routers will need to communicate via BGP for exchanging routing information and advertise their respective IP ranges (subnets).
2. BGP Session: The two Cloud Routers need to be configured with BGP parameters, such as ASN (Autonomous System Number), the IP address of the peer router, and the IP ranges they will advertise.
Let's break down the configuration:
Key BGP Configuration Elements:
- Local and Remote ASN: Google Cloud uses default ASNs, but they can be customized for inter-region or multi-cloud communication.
- IP Address: Each Cloud Router will need an internal IP address in the respective VPC subnet, and BGP peers will communicate using these IP addresses. The BGP peer IP address of router-1 in VPC 10.1.0.0/16 should be configured to peer with router-2’s BGP IP in VPC 172.16.0.0/16.
Configuration Scenarios for the BGP session:
Scenario 1: Using Router-1 and Router-2 as BGP peers:
- Router-1 Configuration (10.1.0.0/16 network): This router will have an internal IP address, such as `10.1.0.1`.
- Router-2 Configuration (172.16.0.0/16 network): This router will have an internal IP address, such as `172.16.0.1`.
- BGP Peering: BGP will use the internal IP addresses (`10.1.0.1` on router-1 and `172.16.0...
Author: Harper · Last updated Jul 26, 2026
Your company's on-premises network is connected to a VPC using a Cloud VPN tunnel. You have a static route of 0.0.0.0/0 with the VPN tunnel as its next hop defined in the VPC. All internet bound traffic currently passes through the on-premises network. You configured Cloud NAT to translate the primary IP addresses of Compute Engine instances in one region. Traffic from those instances will now reach th...
To solve the issue where traffic from your VMs is not translating addresses as expected after configuring Cloud NAT, let's analyze the options and their relevance to your setup.
Key Considerations:
1. Cloud NAT: This service translates the internal IP addresses of Compute Engine instances to a public IP address to enable outbound internet access. However, Cloud NAT requires proper routing and firewall rules to ensure traffic flows as expected.
2. Traffic Flow: Initially, all internet-bound traffic was routed through the on-premises network via the VPN tunnel. However, now you want the traffic from Compute Engine instances to go directly to the internet via the Cloud NAT service, bypassing the on-premises network.
Options:
Option A: Lower the TCP Established Connection Idle Timeout for the NAT gateway.
- Reason for rejection: The TCP idle timeout controls the duration that a connection is kept open. Lowering this timeout could have performance implications but would not solve the issue of incorrect address translation. The issue is more likely related to routing or firewall configuration, not idle connection timeouts.
Option B: Add firewall rules that allow ingress and egress of the external NAT IP address, have a target tag that is on the Compute Engine instances, and have a priority value higher than the priority value of the default route to the VPN gateway.
- Reason for rejection: Firewall rules are crucial for controlling traffic flow, but adding firewall rules specifically for the Cloud NAT external IP isn't the key issue here. The problem is more about routing traffic through ...
Author: Sofia2021 · Last updated Jul 26, 2026
You are designing a Partner Interconnect hybrid cloud connectivity solution with geo-redundancy across two metropolitan areas. You want to follow Google-recommended practices to set up the following r...
In designing a Partner Interconnect hybrid cloud connectivity solution with geo-redundancy across two metropolitan areas, the goal is to ensure high availability and resiliency across the regions and metro pairs. Let’s analyze the options with a focus on Google-recommended practices for geo-redundancy and redundancy across two metro areas.
Key Considerations:
1. Cloud Router Setup: A Cloud Router in Google Cloud is required to exchange BGP routing information with on-premises equipment. To ensure geo-redundancy, we should use multiple VLAN attachments for each Cloud Router, each connecting to a different metro zone.
2. Redundancy Across Metro Zones: We need to ensure that the Cloud Routers in each region are connected to multiple availability zones within their respective metro regions. This allows for high availability and ensures that if one metro zone goes down, traffic can failover to the other metro zone.
3. Two Metro Zones: Since you want geo-redundancy across two metropolitan areas, each region should be set up with redundant VLAN attachments to ensure high availability between the two metro zones in each region.
Option Breakdown:
Option A:
Create a Cloud Router in region 1 with two VLAN attachments connected to metro1-zone1-x. Create a Cloud Router in region 2 with two VLAN attachments connected to metro1-zone2-x.
- Why this is rejected: This option only connects the Cloud Routers to zones within one metro (metro1) for both regions. To meet the geo-redundancy goal, we need to connect Cloud Routers in both regions to zones in two separate metros (i.e., metro1 and metro2). This setup does not provide redundancy across two metro areas, so it doesn't meet the requirements.
Option B:
Create a Cloud Router in region 1 with one VLAN attachment connected to metro1-zone1-x. Create a Cloud Router in region 2 with two VLAN attachments co...
Author: Noah · Last updated Jul 26, 2026
You are designing the network architecture for your organization. Your organization has three developer teams: Web, App, and Database. All of the developer teams require access to Compute Engine instances to perform their critical tasks. You are part of a small network and security team that needs to provide network access to the developers. You need to maintain centra...
To design a network architecture that allows centralized control over network resources (including subnets, routes, and firewalls) while minimizing operational overhead, we need to evaluate the different options carefully. The goal is to ensure that the network is easy to manage, scalable, and provides the necessary access for the Web, App, and Database teams, while maintaining centralized control.
Key Considerations:
- Centralized control: This is necessary for managing network resources (subnets, routes, firewalls) consistently and efficiently across all developer teams.
- Minimizing operational overhead: The design should avoid complex configurations that would require managing many separate VPCs or VPN connections.
- Access control: We need to ensure that the Web, App, and Database teams can access the required resources in a secure and manageable manner.
- Scalability and flexibility: The solution should allow for growth, enabling the addition of more teams or resources as needed without significantly increasing management complexity.
Option Breakdown:
Option A: Configure a host project with a Shared VPC. Create service projects for Web, App, and Database.
- Selected Option: This option uses a Shared VPC, which allows centralized control of network resources (subnets, routes, firewalls) in the host project. By creating separate service projects for each team (Web, App, and Database), each team can have its own isolated environment, but still share the same VPC network. This provides both centralized network control and flexibility for the teams.
- Why this works:
- Centralized control: The network configuration is managed in the host project, which reduces the operational overhead of managing individual VPCs for each team.
- Access control: The service projects can securely connect to the shared VPC, with network resources controlled centrally.
- Scalability: You can easily add more teams or resources by adding more service projects.
- Securit...
Author: Samuel · Last updated Jul 26, 2026
Your company has 10 separate Virtual Private Cloud (VPC) networks, with one VPC per project in a single region in Google Cloud. Your security team requires each VPC network to have private connectivity to the main on-premises location via a Partner Interconnect connection in the same region. To optimize cost and operations, the same connectivity must be shared with all projects. You must...
To ensure efficient connectivity, security, and cost optimization while adhering to the security team’s requirement of inspecting all traffic through third-party appliances, let's review each option:
A) Configure the third-party appliances with multiple interfaces and specific Partner Interconnect VLAN attachments per project. Create the relevant routes on the third-party appliances and VPC networks.
- Reasoning: This option involves setting up separate Partner Interconnect connections and VLANs per project. While this could meet the requirement of providing distinct paths per project, it introduces high complexity. Configuring multiple interfaces on the third-party appliances for each VLAN would result in increased operational overhead, and routing needs to be manually managed for each VPC network. This also likely increases costs due to the multiple VLANs.
- Rejected because: It creates more complexity and operational overhead without a centralized management approach for all VPCs.
B) Configure the third-party appliances with multiple interfaces, with each interface connected to a separate VPC network. Create separate VPC networks for on-premises and internet connectivity. Create the relevant routes on the third-party appliances and VPC networks.
- Reasoning: This option uses separate VPC networks and interfaces for each, effectively creating a segmented environment. However, managing these interfaces and VPC networks can be cumbersome. It also does not centralize the third-party appliances in a way that would make it easier to scale and manage for all projects.
- Rejected because: It doesn't optimize for centralization, and scaling the appliances for each VPC and interface individually would add significant complexity.
C) Consolidate all existing projects' subnetworks into a single VPC. Create separate VPC networks for on-premises and internet connectivity. Configure the third-party appliances with multiple int...
Author: VenomousSerpent42 · Last updated Jul 26, 2026
You have just deployed your infrastructure on Google Cloud. You now need to configure the DNS to meet the following requirements:
* Your on-premises resources should resolve your Google Cloud zones.
* Your Google Cloud resources should resolve your on-premise...
To meet the DNS requirements in Google Cloud, let's break down each option to see which one is most appropriate:
Key Requirements:
1. On-premises resources should resolve Google Cloud zones: On-premises DNS should be able to resolve domain names in Google Cloud's zones.
2. Google Cloud resources should resolve on-premises zones: Google Cloud resources need to resolve DNS queries for on-premises zones.
3. Ability to resolve “.internal” zones provisioned by Google Cloud: Resources within Google Cloud should be able to resolve the special internal DNS zones used by Google Cloud services.
Let's review the options:
A) Configure an outbound server policy, and set your alternative name server to be your on-premises DNS resolver. Configure your on-premises DNS resolver to forward Google Cloud zone queries to Google's public DNS 8.8.8.8.
- Reasoning: This option only configures the outbound policy for Google Cloud to forward DNS queries to the on-premises DNS resolver. However, it relies on using Google's public DNS (8.8.8.8) for resolving Google Cloud zones, which isn't ideal, especially for internal `.internal` domains used by Google Cloud.
- Rejected because: The requirement to resolve internal `.internal` Google Cloud zones is not addressed. Public DNS servers (8.8.8.8) don't handle `.internal` zones, so this wouldn't work for resolving Google Cloud internal domains.
B) Configure both an inbound server policy and outbound DNS forwarding zones with the target as the on-premises DNS resolver. Configure your on-premises DNS resolver to forward Google Cloud zone queries to Google Cloud's DNS resolver.
- Reasoning: This option provides a more complete setup, involving both inbound and outbound DNS forwarding, which allows resources in Google Cloud to resolve on-premises zones, and vice versa. It ensures that on-premises resources can resolve Google Cloud zones by forwarding Google Cloud queries to Google Cloud’s DNS resolver.
- Selecte...
Author: Sofia2021 · Last updated Jul 26, 2026
Your organization uses a hub-and-spoke architecture with critical Compute Engine instances in your Virtual Private Clouds (VPCs). You are responsible for the design of Cloud DNS in Google Cloud. You need to be able to resolve Cloud DNS private zones from your on-p...
To meet the DNS requirements for resolving Cloud DNS private zones from your on-premises data center and enabling on-premises name resolution in a hub-and-spoke VPC architecture, let’s break down each option.
Key Requirements:
1. Resolve Cloud DNS private zones from on-premises: On-premises DNS servers should be able to resolve names from Cloud DNS private zones.
2. Enable on-premises name resolution in hub-and-spoke architecture: The hub-and-spoke VPCs should be able to resolve names from the on-premises DNS server.
Options Review:
A) 1. Configure a private DNS zone in the hub VPC, and configure DNS forwarding to the on-premises server. 2. Configure DNS peering from the spoke VPCs to the hub VPC.
- Reasoning: This option configures DNS forwarding from the hub VPC to the on-premises DNS, which would allow on-premises resources to resolve Cloud DNS private zones in the hub VPC. DNS peering from the spoke VPCs to the hub VPC ensures that spoke VPCs can resolve the private DNS zones from the hub VPC. However, this setup doesn't address enabling on-premises name resolution directly.
- Rejected because: It doesn't ensure on-premises name resolution from the spoke VPCs directly, which is a critical part of the requirement.
B) 1. Configure a DNS policy in the hub VPC to allow inbound query forwarding from the spoke VPCs. 2. Configure the spoke VPCs with a private zone, and set up DNS peering to the hub VPC.
- Reasoning: Configuring a DNS policy in the hub VPC to allow inbound query forwarding from the spoke VPCs allows spoke VPCs to forward DNS queries to the hub VPC for resolution. Setting up DNS peering between the hub VPC and spoke VPCs allows for the sharing of private DNS zones. However, this option doesn’t address the need for on-premises DNS resolution.
- Rejected because: It only addresses DNS resolution within Google Cloud between the hub and spoke VPCs but do...
Author: Zara1234 · Last updated Jul 26, 2026
You have a Cloud Storage bucket in Google Cloud project XYZ. The bucket contains sensitive data. You need to design a solution to ensure that only instances belonging to VPCs under project...
To ensure that only instances belonging to VPCs in Google Cloud project XYZ can access the sensitive data in a Cloud Storage bucket, we need to focus on restricting access based on VPC-level policies and ensuring that traffic stays within the private Google Cloud network. Let’s analyze each option and determine which one is most appropriate:
Key Requirements:
- Only instances from VPCs under project XYZ should have access to the Cloud Storage bucket.
- We need a solution that restricts public or external access to the bucket, ensuring that only the internal VPC traffic can reach it.
Option Review:
A) Configure Private Google Access to privately access the Cloud Storage service using private IP addresses.
- Reasoning: Private Google Access allows instances in VPCs to access Google Cloud services like Cloud Storage via private IP addresses, avoiding the public internet. However, this option doesn't restrict the access specifically to only VPCs under project XYZ. Other VPCs that have private Google access enabled might still be able to access the data.
- Rejected because: It doesn't provide sufficient granularity for restricting access to only the VPCs in project XYZ.
B) Configure a VPC Service Controls perimeter around project XYZ, and include storage.googleapis.com as a restricted service in the service perimeter.
- Reasoning: VPC Service Controls provides a way to isolate Google Cloud services, such as Cloud Storage, within a specified security perimeter. By configuring a VPC Service Controls perimeter around project XYZ and restricting the access to `storage.googleapis.com`, you can ensure that only instances within the specified VPCs in project XYZ can access the Cloud Storage bucket. This solution gives a high level of security by enforci...
Author: Emma · Last updated Jul 26, 2026
You are maintaining a Shared VPC in a host project. Several departments within your company have infrastructure in different service projects attached to the Shared VPC and use Identity and Access Management (IAM) permissions to manage the cloud resources in those projects. VPC Network Peering is also set up between the Shared VPC and a common services VPC that is not in a service project. Several users are experiencing failed connectivity between certain instances in different Share...
To validate the network configuration and identify the root cause of connectivity issues between instances in different Shared VPC service projects, and between instances and the internet, we need a solution that helps troubleshoot network-related problems effectively.
Key Requirements:
- Identify connectivity issues between instances in different service projects.
- Verify if misconfigurations in the network are causing issues, especially with VPC Peering, Shared VPC, or internet access.
Option Review:
A) Review the VPC audit logs in Cloud Logging for the affected instances.
- Reasoning: VPC audit logs record actions taken on VPC resources, such as changes to firewall rules or network peering, but they won't provide direct information about current network traffic or connectivity status. Audit logs are useful for tracking configuration changes, but they are not ideal for troubleshooting connectivity issues in real-time.
- Rejected because: This approach does not directly address connectivity problems between the affected instances or connectivity to the internet. It focuses on configuration changes rather than current network performance or traffic.
B) Use Secure Shell (SSH) to connect to the affected Compute Engine instances, and run a series of PING tests to the other affected endpoints and the 8.8.8.8 IPv4 address.
- Reasoning: SSH and ping tests help verify if specific instances can communicate with other instances or the internet. However, while this method can help identify basic connectivity problems, it doesn’t provide a comprehensive view of the overall network configuration and issues across the entire VPC or Shared VPC setup. It is a more manual approach and doesn't scale well when troubleshooting larger environments.
- Rejected because: While useful for basic testing, this approach lacks the ability to diagnose broader network configuration issues or detect specific misconfigurations such as routing or VPC peering problems.
C) Run Connectivity Tests from Network Intelligence Center to check connectivi...
Author: Lucas Carter · Last updated Jul 26, 2026
Your organization has Compute Engine instances in us-east1, us-west2, and us-central1. Your organization also has an existing Cloud Interconnect physical connection in the East Coast of the United States with a single VLAN attachment and Cloud Router in us-east1. You need to provide a design with high availability and ensure that if a region goes down, you still h...
Let's analyze each option based on the requirements of achieving high availability and ensuring access to all VPC subnets in case of a region failure, while considering the most cost-effective approach.
Key Factors:
1. High Availability: The design should ensure that if a region goes down, there is still connectivity to other regions' VPC subnets.
2. VPC Routing Mode: Global mode provides better fault tolerance since the routing is done across regions, whereas regional mode is confined to a single region, which limits high availability across multiple regions.
3. Cloud Interconnect Attachments: Each attachment represents a connection to a specific region. Adding multiple attachments in different regions ensures that the connection remains functional even if one region experiences issues.
4. Cost-Effectiveness: Adding more Cloud Interconnect attachments and routers in multiple regions increases cost, so we should choose the least amount necessary to achieve high availability.
Option Breakdown:
- Option A:
- VPC Routing in Regional Mode: In this mode, each region has its own routing table. If one region goes down, VPC routing in that region would be lost, and there would be no access to other regions.
- Additional Cloud Interconnect in us-east1: This doesn't improve high availability because if us-east1 goes down, you still lose connectivity to all other regions.
- Conclusion: This option does not meet the high availability requirement because it doesn't cover regions outside us-east1.
- Option B:
- VPC Routing in Global Mode: This is a good option because routing across regions is possible, and if one region fails, traffic can be rerouted to other available regions. However, the routing still only happens within a single region for Cloud Interconnect.
- Additional Cloud Interconnect in u...
Author: Aditya · Last updated Jul 26, 2026
You recently configured Google Cloud Armor security policies to manage traffic to your application. You discover that Google Cloud Armor is incorrectly blocking some traffic to your application. You need to identity the...
To identify which web application firewall (WAF) rule in Google Cloud Armor is incorrectly blocking traffic, the correct approach is to focus on logs related to Google Cloud Armor and its behavior in blocking or allowing traffic.
Key Factors in Selection:
1. Relevance to Google Cloud Armor: Since the issue is related to traffic being blocked by Google Cloud Armor, the logs should specifically track the actions of Google Cloud Armor's security policies.
2. Firewall Logs: Logs related to firewalls in Google Cloud Armor will help identify which rule is blocking the traffic and why.
3. Log Analysis: The ability to quickly access logs and identify the specific rule and its actions is essential.
Option Breakdown:
- Option A:
- Enable firewall logs, and view the logs in Firewall Insights: This is a good option, but it focuses on network-level firewalls (VPC firewalls) rather than the application layer security provided by Google Cloud Armor. Firewall logs here are more focused on general network traffic filtering, not on WAF rules.
- Conclusion: This option is less relevant because it doesn’t provide insights into the specific WAF rules of Google Cloud Armor.
- Option B:
- Enable HTTP(S) Load Balancing logging with sampling rate equal to 1, and view the logs in Cloud Logging: HTTP(S) Load Balancing logs track load balancer-level traffic, which may include access logs, but it doesn’t give direct information about which Google Cloud Arm...
Author: William · Last updated Jul 26, 2026
You are the Organization Admin for your company. One of your engineers is responsible for setting up multiple host projects across multiple folders and sharing subnets with service projects. You need to enable the engineer's Identity and Access...
Key Considerations:
- Task Scope: The engineer needs to manage host projects and share subnets with service projects. This requires specific IAM roles, such as Compute Shared VPC Admin and Project IAM Admin, to be granted.
- IAM Role Scope: The IAM roles must be assigned in a way that allows the engineer to perform actions across multiple folders and projects.
- Granularity of Role Assignment: Assigning roles at the organization level provides broader access across all folders and projects, whereas assigning roles at the folder level restricts the access to just a specific folder and its projects.
Option Breakdown:
- Option A:
- Compute Shared VPC Admin IAM role at the folder level: This option provides the engineer with the ability to manage Shared VPCs within the folder. However, it doesn’t give sufficient access to set up IAM roles in the projects (e.g., service projects) and share subnets across multiple folders. It limits the engineer's ability to manage IAM roles for the service projects.
- Conclusion: This option does not provide full access for the engineer to complete all tasks across all projects in multiple folders.
- Option B:
- Compute Shared VPC Admin IAM role at the organization level: This option allows the engineer to manage Shared VPCs across all projects in the organization. However, this doesn't grant them the ability to manage IAM roles at the project level, which is necessary for sharing subnets with service projects and managing IAM configurations for projects.
- Conclusion: While this option provides broad access to Shared VPC, it ...
