Google Practice Questions, Discussions & Exam Topics by our Authors
Your company is designing its data lake on Google Cloud and wants to develop different ingestion pipelines to collect unstructured data from different sources.
After the data is stored in Google Cloud, it will be processed in several data pipelines to build a recommendation engine for end users on the website. The structure of the data retrieved from the source systems can change at any time. The data must be stored exactly as it was retrieved for reprocessin...
For designing a data lake architecture that supports ingesting unstructured data with a potential for changing data structures, it’s essential to focus on flexibility, reprocessing capability, and storage. Let's evaluate each option:
A) Send the data through the processing pipeline, and then store the processed data in a BigQuery table for reprocessing.
- Reasoning: BigQuery is an excellent tool for querying structured data, but it’s not ideal for storing raw unstructured data. BigQuery also requires a predefined schema, which is problematic if the data structure changes over time. If the structure of the data changes, storing it directly in BigQuery could result in data incompatibility with existing pipelines.
- Rejected: This option is not ideal because BigQuery is more suited for structured data, and changes in data structure could complicate reprocessing. Additionally, BigQuery doesn't store raw unstructured data in its native format.
B) Store the data in a BigQuery table. Design the processing pipelines to retrieve the data from the table.
- Reasoning: Similar to option A, storing unstructured data directly in BigQuery presents challenges, especially when the data structure is unpredictable. BigQuery tables require a fixed schema, and changing data structures could lead to data integrity issues, making it unsuitable for a use case with dynamic unstructured data.
- Rejected: This option is inappropriate for raw, unstructured data with evolving schemas. The nature of the data makes BigQuery a less ideal option for storing it in its original form for reprocessing.
C) Send the data through the processing pipeline, and then store the processed data in a Cloud Storage bucket for reprocessing.
- Reasoning: While Cloud Storage is ideal for storing raw, unstructured data, it doe...
Author: Emma · Last updated May 10, 2026
You are responsible for the Google Cloud environment in your company. Multiple departments need access to their own projects, and the members within each department will have the same project responsibilities. You want to structure your Google Cloud environment for minimal maintenance and maximum overview o...
In order to provide a scalable and maintainable IAM structure for managing access across multiple departments while ensuring good overview and minimal operational overhead, let's break down the available options:
A) Grant all department members the required IAM permissions for their respective projects.
- Reasoning: This approach means assigning IAM permissions directly to individual members for each project. While this might seem straightforward, it leads to poor scalability and lack of overview as the number of members and projects grows. Managing individual permissions can quickly become unwieldy, especially as projects start and end, or when people transition between departments.
- Rejected: This approach is not ideal because it lacks flexibility and doesn’t provide a centralized, high-level view of IAM permissions for entire departments. Managing permissions for each individual across projects would be cumbersome and prone to errors.
B) Create a Google Group per department and add all department members to their respective groups. Create a folder per department and grant the respective group the required IAM permissions at the folder level. Add the projects under the respective folders.
- Reasoning: This option involves grouping department members into Google Groups, granting IAM permissions at the folder level, and structuring the projects under department-specific folders. This setup is scalable, offers centralized management, and ensures that permissions apply uniformly to all members within a department. As new projects are added to the department, you only need to add them to the appropriate folder without changing permissions for individual users.
- Selected: This is the best option because it follows Google-recommended best practices for IAM, ensuring minimal maintenance while providing a clean structure for managing access. By using folders and groups, it allows a clear overview of access rights for each department and reduces the risk of misconfiguration as projects are added or removed.
C) Create a folder per d...
Author: Nia · Last updated May 10, 2026
Your company has an application running as a Deployment in a Google Kubernetes Engine (GKE) cluster. You have separate clusters for development, staging, and production. You have discovered that the team is able to deploy a Docker image to the production cluster without first testing the deployment in development and then staging. You want to allow the team to hav...
To prevent your team from deploying Docker images to production without testing them in earlier environments (development and staging), the solution should ensure that only approved images can be deployed in production. Let’s evaluate each option:
A) Configure a Kubernetes lifecycle hook to prevent the container from starting if it is not approved for usage in the given environment.
- Reasoning: Kubernetes lifecycle hooks allow you to run certain actions at different stages of a pod’s lifecycle (e.g., `postStart` or `preStop`). However, lifecycle hooks are generally not suitable for controlling whether a container should start based on the image’s approval status. They are better for managing the state or behavior of a running container, not for enforcing security or deployment policies.
- Rejected: Lifecycle hooks are not intended for enforcing approval or access policies. This method would not effectively prevent unauthorized Docker images from being deployed to production.
B) Implement a corporate policy to prevent teams from deploying Docker images to an environment unless the Docker image was tested in an earlier environment.
- Reasoning: Implementing a corporate policy could be an effective manual solution in some cases, but it relies heavily on human enforcement and would not be automated. This would introduce a higher risk of policy violations due to lack of automation, especially in an environment where continuous integration and deployment (CI/CD) practices are prevalent.
- Rejected: While a policy can help set expectations, it lacks automation and doesn’t prevent the issue directly. It relies on manual oversight, making it difficult to enforce at scale.
C) Configure binary authorization policies for the development, staging, and production clusters. Create attestations as part of the continuous integration pipeline.
- Reasoning: Binary Authorization is a Google Cloud service that allows you to enforce s...
Author: RadiantPhoenixX · Last updated May 10, 2026
Your company wants to migrate their 10-TB on-premises database export into Cloud Storage. You want to minimize the time it takes to complete this activity, the overall cost, and database load. The bandwidth between the on-premises enviro...
To choose the best approach for migrating the 10-TB on-premises database export into Google Cloud Storage, it's essential to evaluate the key factors such as migration speed, overall cost, database load, bandwidth constraints, and ease of implementation. Let's look at each option:
A) Develop a Dataflow job to read data directly from the database and write it into Cloud Storage.
- Pros: This approach would use a cloud-native service designed for processing and transforming data. Dataflow can handle large datasets, providing robust data processing features. However, it might introduce a high level of load on the on-premises database while it’s being accessed.
- Cons: Writing directly from the database could cause performance degradation on the database due to the heavy load of reading and writing large amounts of data. It also requires development effort to build and configure the Dataflow job and monitor it.
- Why Rejected: While scalable, this approach could negatively impact database performance due to the high volume of data being transferred, and it would incur high costs in terms of both time and resources to implement.
B) Use the Data Transfer appliance to perform an offline migration.
- Pros: The Data Transfer Appliance is designed for transferring large amounts of data without using bandwidth from the internet. The appliance allows for offline data transfer by copying the data locally to a physical device and then shipping it to Google Cloud.
- Cons: It requires shipping the physical appliance, which could add additional time, and handling the logistics of shipping can be cumbersome. Also, the device's availability may depend on geographic location, which could result in delays.
- Why Rejected: While it provides a solution for large datasets, it may be slow and logistically complex due to the shipping process. For a scenario with constant ...
Author: FlamePhoenix2025 · Last updated May 10, 2026
Your company has an enterprise application running on Compute Engine that requires high availability and high performance. The application has been deployed on two instances in two zones in the same region in active-passive mode. The application writes data to a persistent disk. In the case of a single zone outage, that data should be immediately ...
In this scenario, the primary goal is to ensure high availability and high performance, while minimizing downtime and data loss during a zone outage. Let's evaluate each option based on the requirements:
A) 1. Attach a persistent SSD disk to the first instance. 2. Create a snapshot every hour. 3. In case of a zone outage, recreate a persistent SSD disk in the second instance where data is coming from the created snapshot.
- Pros: This approach ensures that a snapshot of the data is regularly created, meaning that in case of a zone failure, you can recreate the persistent SSD disk from the snapshot on the second instance.
- Cons: The major drawback is the time required to recreate the disk from the snapshot. While the snapshot protects against data loss, it doesn't allow for immediate access to the data during an outage, resulting in significant downtime until the disk is recreated and mounted on the second instance.
- Why Rejected: This approach has significant downtime due to the need to recreate the disk from the snapshot, which goes against the goal of minimizing downtime.
B) 1. Create a Cloud Storage bucket. 2. Mount the bucket into the first instance with gcs-fuse. 3. In case of a zone outage, mount the Cloud Storage bucket to the second instance with gcs-fuse.
- Pros: Cloud Storage provides a highly available and durable solution, and `gcs-fuse` allows the application to interact with the storage as if it were a regular disk.
- Cons: Cloud Storage is not designed for high-performance, low-latency workloads like a persistent SSD disk. Using it via `gcs-fuse` introduces additional latency and could severely degrade the performance of the application.
- Why Rejected: While this provides high availability, it doesn't meet the performance requirements. Cloud Storage is not suitable for high-performance, I/O-intensive applications compared to other options like persistent disks.
C) 1. Attach a regional SSD persistent disk to the first instance. 2. In case of a zone outage, force-attach the disk to the other instance.
...
Author: John · Last updated May 10, 2026
You are designing a Data Warehouse on Google Cloud and want to store sensitive data in BigQuery. Your company requires you to generate the encryption keys outside ...
To meet the requirement of storing sensitive data in BigQuery while managing encryption keys outside of Google Cloud, we need to find an option that allows for the use of customer-managed encryption keys (CMEK), where the keys are generated outside Google Cloud. Let's evaluate the available options:
A) Generate a new key in Cloud Key Management Service (Cloud KMS). Store all data in Cloud Storage using the customer-managed key option and select the created key. Set up a Dataflow pipeline to decrypt the data and store it in a new BigQuery dataset.
- Pros: This option involves generating the encryption key using Cloud KMS, but the storage would initially happen in Cloud Storage before it is transferred to BigQuery using Dataflow. It aligns with the customer-managed key approach for Cloud Storage.
- Cons: This option requires an extra step, as the data first needs to be stored in Cloud Storage, decrypted using Dataflow, and then transferred to BigQuery. This adds complexity and performance overhead, which is not ideal for directly storing sensitive data in BigQuery.
- Why Rejected: This approach introduces an unnecessary step (using Cloud Storage and Dataflow) for a scenario where you can directly store the data in BigQuery, making it more complex than necessary.
B) Generate a new key in Cloud KMS. Create a dataset in BigQuery using the customer-managed key option and select the created key.
- Pros: This option allows you to use a customer-managed encryption key (CMEK) directly within BigQuery. The key is generated and managed within Cloud KMS, but the sensitive data is stored securely in BigQuery with the encryption key you control.
- Cons: There are no significant drawbacks for this scenario. The solution is straightforward and utilizes BigQuery's ability to directly integrate with Cloud KMS for encryption.
- Why Selected: This is the simplest and most effective solution that fulfills the requirements. BigQuery supports customer-managed encryption keys (CMEK), and Cloud KMS allows you to generate the key externally and control its lifecycle. This is the mo...
Author: Ishaan · Last updated May 10, 2026
Your organization has stored sensitive data in a Cloud Storage bucket. For regulatory reasons, your company must be able to rotate the encryption key used to encrypt the data in the bucket. The data will be processed ...
To meet the requirement of being able to rotate encryption keys while processing sensitive data in Cloud Storage and ensuring compliance with regulatory practices, let's evaluate the available options based on Google-recommended practices for security:
A) Create a key with Cloud Key Management Service (KMS). Encrypt the data using the encrypt method of Cloud KMS.
- Pros: Cloud KMS is a Google-recommended solution for managing encryption keys. It provides centralized control and allows for encryption and decryption operations with strong security practices. KMS also supports key rotation, so you can rotate encryption keys when needed.
- Cons: This approach encrypts the data directly using Cloud KMS but does not address the ongoing need to manage or store the encryption key for the Cloud Storage bucket itself. Additionally, this method doesn't specify how the encryption is tied to the Cloud Storage bucket for future access.
- Why Rejected: While Cloud KMS can encrypt data, it doesn't solve the key management or automatic key rotation problem for the Cloud Storage bucket. This option would require manual effort and does not integrate with the Cloud Storage bucket in the way required.
B) Create a key with Cloud Key Management Service (KMS). Set the encryption key on the bucket to the Cloud KMS key.
- Pros: Using Cloud KMS to set a customer-managed encryption key (CMEK) on the Cloud Storage bucket is the best Google-recommended approach. Cloud KMS allows for easy key rotation, key management, and auditing. By using CMEK, you can ensure that the data in Cloud Storage is encrypted using your specified key, and key rotation is simplified via Cloud KMS.
- Cons: There are minimal downsides as this approach directly aligns with Google’s security best practices. The only minor consideration is that the process of managing the keys requires proper configuration and access control.
- Why Selected: This option meets the requirement for key rotation while adhering to security best practices. Cloud KMS provides built-in key management, and rotating the keys for encrypted data is simple and well-integrated with Cloud Storage.
C) Gene...
Author: Olivia Johnson · Last updated May 10, 2026
Your team needs to create a Google Kubernetes Engine (GKE) cluster to host a newly built application that requires access to third-party services on the internet.
Your company does not allow any Compute Engine instance to have a public IP address on ...
To meet the requirement of creating a Google Kubernetes Engine (GKE) cluster that can access third-party services on the internet while ensuring that no Compute Engine instance has a public IP, let's evaluate the options based on the need for private connectivity and the overall best practices:
A) Configure the GKE cluster as a private cluster, and configure Cloud NAT Gateway for the cluster subnet.
- Pros: This approach ensures that the GKE cluster is private, meaning the nodes do not have public IP addresses. Cloud NAT (Network Address Translation) is a fully managed service that provides internet access to resources in a private VPC without exposing those resources to the public internet. This is the most straightforward and recommended solution for accessing external services while keeping the cluster private.
- Cons: Minimal downsides, as Cloud NAT is a managed service, and there could be slight overhead in the configuration of Cloud NAT, but it is well-supported and scalable.
- Why Selected: This is the optimal solution for ensuring internet access to the private GKE cluster without violating the company's policy of not allowing public IP addresses on Compute Engine instances. Cloud NAT allows outbound internet access while maintaining strict security for the private cluster.
B) Configure the GKE cluster as a private cluster. Configure Private Google Access on the Virtual Private Cloud (VPC).
- Pros: This solution configures the cluster as a private cluster and uses Private Google Access, which allows instances in the VPC (without public IP addresses) to access Google APIs and services. However, it doesn't provide general internet access (e.g., third-party services on the public internet).
- Cons: Private Google Access is specific to Google Cloud services, not third-party services. This option will not allow access to services outside of Google Cloud.
- Why Rejected: While this works for accessing Google Cloud services, it does not fulfill the requirement to access third-party se...
Author: Sofia · Last updated May 10, 2026
Your company has a support ticketing solution that uses App Engine Standard. The project that contains the App Engine application already has a Virtual Private
Cloud (VPC) network fully connected to the company's on-premises environment through a Cloud VPN tunnel. You want to enable the App E...
To enable an App Engine application to communicate with a database running in an on-premises environment over a VPN, the solution must support serverless compute (App Engine) while ensuring private communication with resources outside of Google Cloud (the on-premises database). Let's analyze the options in detail:
A) Configure private Google access for on-premises hosts only:
- Explanation: This option enables on-premises hosts to access Google services via private IP addresses. However, it does not apply to App Engine. The App Engine application itself would not be able to reach the on-premises database, as this solution is more geared toward enabling on-premises systems to access Google Cloud services.
- Reason for rejection: This does not address the need for App Engine to communicate with on-premises resources.
B) Configure private Google access:
- Explanation: This option is used to allow Google Cloud resources like Compute Engine, Cloud Functions, or Cloud Run, to access Google APIs and services over private IPs (not public IPs). However, it does not help establish communication between App Engine and an on-premises database.
- Reason for rejection: It only facilitates communication from Google Cloud resources to Google service...
Author: Ishaan · Last updated May 10, 2026
Your company is planning to upload several important files to Cloud Storage. After the upload is completed, they want to verify that the uploaded content is identical to what they have on-premises. ...
Let's evaluate each option based on the goal of verifying that the uploaded content is identical to the on-premises files, while also minimizing cost and effort.
A) Use Linux shasum to compute a digest of files you want to upload.
- Explanation: This option involves manually computing file hashes before and after the upload (using `shasum`), then comparing them.
- Reason for rejection: While this method works, it requires downloading the files back to the on-premises environment, which could result in higher costs and effort, especially for large files. Additionally, `shasum` would use SHA hashes, which are not optimized for use with Cloud Storage in terms of performance or cost.
B) Use gsutil -m to upload the files to Cloud Storage.
- Explanation: This option uses the `gsutil` command-line tool to upload files and then uses custom Java development to compute CRC32C hashes.
- Reason for rejection: Developing a custom Java application adds unnecessary complexity and cost. Cloud Storage already offers built-in support for CRC32C hashes, which eliminates the need for writing custom code.
C) Use gsutil -m to upload all the files to Cloud Storage.
- Explanation: This option uses `gsutil` for uploading and then use...
Author: Kai99 · Last updated May 10, 2026
You have deployed an application on Anthos clusters (formerly Anthos GKE). According to the SRE practices at your company, you need to be alerted if request latency is abo...
Let's break down each option to determine the best choice for alerting on request latency in an Anthos cluster.
A) Install Anthos Service Mesh on your cluster. Use the Google Cloud Console to define a Service Level Objective (SLO), and create an alerting policy based on this SLO.
- Explanation: Anthos Service Mesh (ASM) provides observability and monitoring features for microservices, including the ability to define SLOs based on service latency, traffic, and other metrics. By defining an SLO in the Google Cloud Console and setting an alerting policy, you can be notified if request latency exceeds a threshold for a given period.
- Reason for selection: This option aligns perfectly with SRE practices for monitoring request latency. ASM is specifically designed for managing traffic between microservices and provides built-in observability features like request latency, which can be used to set up SLOs and alerts easily.
B) Enable the Cloud Trace API on your project, and use Cloud Monitoring Alerts to send an alert based on the Cloud Trace metrics.
- Explanation: Cloud Trace is useful for tracing individual requests and identifying performance bottlenecks in your application. You can use Cloud Monitoring to set alerts based on these metrics.
- Reason for rejection: While Cloud Trace is useful for tracing requests and latencies, it's more focused on individual request analysis rather than a continuous alerting system based on an aggregate SLO. This approach does not integrate directly with the SLO-based alerting system, which is preferred for sustained latency m...
Author: FlamePhoenix2025 · Last updated May 10, 2026
Your company has a stateless web API that performs scientific calculations. The web API runs on a single Google Kubernetes Engine (GKE) cluster. The cluster is currently deployed in us-central1. Your company has expanded to offer y...
Let's analyze each option to determine the best approach for reducing latency for users in Asia:
A) Create a second GKE cluster in asia-southeast1, and expose both APIs using a Service of type LoadBalancer. Add the public IPs to the Cloud DNS zone.
- Explanation: This option involves creating a second GKE cluster in Asia and exposing the APIs via LoadBalancer services, then using Cloud DNS to distribute traffic between the clusters.
- Reason for rejection: While this setup might work, managing multiple GKE clusters and handling DNS routing across multiple regions can introduce complexity. It does not scale well in terms of traffic management, especially if you have many regions or need to ensure the most efficient route for each user. A global load balancing solution would be more appropriate for automatic routing and better latency optimization.
B) Use a global HTTP(s) load balancer with Cloud CDN enabled.
- Explanation: The global HTTP(s) load balancer is designed for distributing HTTP(s) traffic across multiple regions. Cloud CDN (Content Delivery Network) can cache responses, which helps with reducing latency for static content but is less beneficial for dynamic content or scientific calculations that require real-time computation.
- Reason for rejection: While this solution is excellent for static content, Cloud CDN is not suitable for dynamic workloads like scientific calculations, as the content would need to be computed on-demand. Therefore, this option is not ideal for a stateless web API that...
Author: Liam · Last updated May 10, 2026
You are migrating third-party applications from optimized on-premises virtual machines to Google Cloud. You are unsure about the optimum CPU and memory options. The applications have a consistent usage pattern across...
Let's evaluate each option to determine the best approach for optimizing resource usage for the lowest cost when migrating third-party applications to Google Cloud.
A) Create an instance template with the smallest available machine type, and use an image of the third-party application taken from a current on-premises virtual machine. Create a managed instance group that uses average CPU utilization to autoscale the number of instances in the group. Modify the average CPU utilization threshold to optimize the number of instances running.
- Explanation: This option involves using a managed instance group with autoscaling based on CPU utilization, adjusting the instance count according to CPU usage.
- Reason for rejection: While autoscaling based on CPU utilization can help optimize instance count, this solution may not be fully optimized for memory or consistent workloads. Autoscaling based solely on CPU utilization could lead to inefficient resource usage or unnecessary scaling up/down, especially if the application has a consistent usage pattern. Additionally, CPU-based autoscaling may not directly map to real-world usage patterns for applications with predictable memory or storage needs.
B) Create an App Engine flexible environment, and deploy the third-party application using a Dockerfile and a custom runtime. Set CPU and memory options similar to your application's current on-premises virtual machine in the app.yaml file.
- Explanation: App Engine flexible environments can automatically handle scaling and resource allocation, but this approach involves running third-party applications within a containerized environment, which may not be necessary for all cases.
- Reason for rejection: App Engine is typically best suited for applications built to leverage its platform and automatic scaling. For third-party applications that may not be optimized for a fully managed environment or that require specific virtual machine configurations, this solution introduces complexity without significant cost optimization benefits. Additionally, the cost might not be as optimized as with Compute Engine instances because App Engine charges based on instance usage, potentially resulting in higher operational costs for third-party applications with consistent usage patterns.
C) Create multiple Compute Engine instances with varying CPU and memory options. Install the ...
Author: Henry · Last updated May 10, 2026
Your company has a Google Cloud project that uses BigQuery for data warehousing. They have a VPN tunnel between the on-premises environment and Google
Cloud that is configured with Cloud VPN. The security team wants to avoid data ex...
To address the security concerns of data exfiltration by malicious insiders, compromised code, and accidental oversharing, it’s essential to focus on securing the data traffic, limiting unnecessary access, and ensuring proper access controls.
Option A: Configure Private Google Access for on-premises only
This option limits the ability of on-premises systems to access Google Cloud services through internal IP addresses, thus preventing data from being routed over the public internet. However, this does not address the broader security concerns in the context of a malicious insider or compromised code within Google Cloud itself, nor does it help with controlling how the data is accessed once inside the Google Cloud environment. It provides a basic layer of security but doesn’t fully prevent exfiltration or oversharing.
Option B: Perform the following tasks:
1. Create a service account.
2. Give the BigQuery JobUser role and Storage Reader role to the service account.
3. Remove all other IAM access from the project.
This option involves controlling access to Google Cloud services by managing IAM roles. By creating a dedicated service account with specific roles and stripping other unnecessary access, this approach can reduce the potential for accidental oversharing or unauthorized access. However, it does not address the potential threat of insiders or compromised code trying to exfiltrate data. Additionally, removing IAM access from other users might cause operational difficulties and requires strict monitoring to avoid over-restriction.
Option C: Configure VPC Service Controls and configure Private Google Access
VPC Service Controls enhance security by defining service peri...
Author: Mia · Last updated May 10, 2026
You are working at an institution that processes medical data. You are migrating several workloads onto Google Cloud. Company policies require all workloads to run on physically separated hardware, and workloads from different clients must also be separated. You created a sole-tenant ...
To ensure that workloads from different clients are properly separated on dedicated hardware while respecting the company’s policies, it’s important to assign each workload to specific nodes or groups of nodes that are physically separated. Here's the reasoning for each option:
Option A: Add the node group name as a network tag when creating Compute Engine instances in order to host each workload on the correct node group
This option is not effective because network tags are used for networking purposes, like applying firewall rules or routing, rather than to schedule workloads on specific nodes or node groups. Network tags will not guarantee that workloads are placed on the right physical hardware.
Option B: Add the node name as a network tag when creating Compute Engine instances in order to host each workload on the correct node
This option is also not effective for the same reasons as Option A. Network tags don’t control the placement of instances on specific nodes; they are used for networking configuration. Adding node names as network tags won't ensure that workloads are placed on the correct hardware.
Option C: Use node affinity labels based on the node group name when creating Compute Engine instances in order to host each workload on the correct node group
This option is partially correct, but it doesn’t guarantee placement on physically separated hardwa...
Author: Charlotte · Last updated May 10, 2026
Your company's test suite is a custom C++ application that runs tests throughout each day on Linux virtual machines. The full test suite takes several hours to complete, running on a limited number of on-premises servers reserved for testing. Your company wants to move the testing infrastructure to the cloud, to reduce the amount of tim...
To reduce the time it takes to run the test suite while moving the infrastructure to the cloud, it is essential to select a solution that allows parallel execution of tests with minimal changes to the existing system. Let’s assess each option:
Option A: Google Compute Engine unmanaged instance groups and Network Load Balancer
This option uses unmanaged instance groups, which means you will have to manually manage the instances. While it provides flexibility, you would have to manually handle the scaling and management of the instances, which could become cumbersome. Additionally, using a Network Load Balancer does not directly address the need for distributing workloads across the instances, and it’s not well-suited for running tests in parallel. Therefore, this option adds complexity without offering the necessary automation for scaling and management of the testing infrastructure.
Option B: Google Compute Engine managed instance groups with auto-scaling
This is a strong candidate because managed instance groups provide automated scaling, which would allow the test suite to run in parallel across many instances. By scaling the infrastructure based on demand, the cloud environment can automatically add more instances to run tests faster, greatly reducing the overall testing time. The setup is straightforward, as it allows you to easily spin up additional instances, and the cloud platform manages load balancing and distribution of tasks. You can use C++ applications with minimal modification and deploy them on the instances, providing a highly scalable solution.
Option C: Google Cloud Dataproc to run Apache Hadoop jobs to process each test
While Google Cloud Dataproc is a ma...
Author: Mia · Last updated May 10, 2026
A lead software engineer tells you that his new application design uses websockets and HTTP sessions that are not distributed across the web servers. You want to help him ensure hi...
When ensuring that an application using websockets and HTTP sessions runs properly on Google Cloud Platform (GCP), the key concern is the application’s ability to scale across multiple web servers while maintaining session state and websocket connections. Given that websockets and HTTP sessions are not distributed across the web servers in the application design, the solution must address scalability and session management to ensure smooth operation in a cloud environment.
Option A: Help the engineer to convert his websocket code to use HTTP streaming
This option is not ideal because converting websockets to HTTP streaming would essentially eliminate the persistent, bidirectional connection that websockets offer. Websockets are designed for continuous, real-time communication between the client and server, which is crucial for many modern applications (like chat or live updates). HTTP streaming does not offer the same low-latency, bi-directional capabilities and may cause performance issues for applications that rely on real-time data flow. Additionally, it does not solve the issue of session persistence and scaling across multiple servers.
Option B: Review the encryption requirements for websocket connections with the security team
While encryption is important for securing websockets (typically using wss:// for secure connections), this option does not address the scalability issue that is the primary concern here. Ensuring websockets are secure is a good practice but does not solve the challenge of distributing websocket connections and sessions across multiple web servers in a cloud environment.
Option C: Meet with the cloud operations team and the engineer to discuss load balancer options
This is a highly relevant and practical approach. In a cloud environment like GCP, scaling applications...
Author: James · Last updated May 10, 2026
The application reliability team at your company this added a debug feature to their backend service to send all server events to Google Cloud Storage for eventual analysis. The event records are at least 50 KB and at most 15 MB and are expecte...
To determine the optimal process for handling server events in Google Cloud Storage, we need to consider factors like data size, frequency, data loss minimization, efficiency, and scalability. Let's break down each option:
Option A:
- Append metadata to file body: This approach adds metadata directly to the file. While this is feasible, it can make file retrieval inefficient, as you need to extract metadata every time.
- Compress individual files: This is a good idea for reducing storage usage and optimizing I/O operations, especially with varying file sizes.
- Name files with serverName "Timestamp": This naming scheme provides clarity on the origin (serverName) and when the event was logged, which makes sense for tracking events over time.
- Create a new bucket if the bucket is older than 1 hour and save individual files to the new bucket. Otherwise, save files to the existing bucket: While this provides a dynamic way to handle storage, creating too many buckets in a short amount of time could cause overhead in managing bucket metadata and might result in inefficiencies, especially when the frequency of events is high.
Option B:
- Batch every 10,000 events with a single manifest file for metadata: This option creates a batch of events, which would reduce the overhead of individual file uploads. The manifest file is used to store metadata and simplifies analysis by grouping events.
- Compress event files and manifest file into a single archive file: Compressing the batch into a single archive is effective for storage efficiency, reducing the number of objects, and simplifying the retrieval process.
- Name files using serverName "EventSequence": Naming files with event sequences is useful for tracking the order of events for each server.
- Create a new bucket if the bucket is older than 1 day and save the single archive file to the new bucket. Otherwise, save the single archive file to the existing bucket: Creating new buckets based on time intervals (daily in this case) seems like an unnecessary complexity. Over time, this can result in too many buckets...
Author: Aria · Last updated May 10, 2026
A recent audit revealed that a new network was created in your GCP project. In this network, a GCE instance has an SSH port open to the world. Y...
In order to discover the origin of the newly created network in your GCP project, let's evaluate the options:
- A) Search for Create VM entry in the Stackdriver alerting console
Stackdriver (now called Cloud Operations) provides monitoring and alerting features, but it doesn't offer a direct way to trace the creation of the network or VM instance. This would focus more on monitoring and alerting rather than auditing who created the network. So, this option doesn't directly help trace the origin of the network.
- B) Navigate to the Activity page in the Home section. Set category to Data Access and search for Create VM entry
The Activity page in the GCP Console provides an audit trail of user actions, such as the creation of resources. The category "Data Access" typically focuses on changes to data (e.g., access to storage), rather than creation of infrastructure resources like VM instances or networks. Therefore, this option is not likely to help track the creation of a new network or VM.
- C) In the Logging section of the console, specify GCE Network as the logging section. Search for the Create Insert entry
This option utilizes Cloud Lo...
Author: Rahul · Last updated May 10, 2026
You want to make a copy of a production Linux virtual machine in the US-Central region. You want to manage and replace the copy easily if there are changes on the production virtual machine. You will deploy the cop...
Let’s analyze each option based on the goal of copying and managing a production Linux virtual machine (VM) and deploying it as a new instance in a different region (US-East).
A) Use the Linux dd and netcat commands to copy and stream the root disk contents to a new virtual machine instance in the US-East region.
- Explanation: The `dd` and `netcat` commands allow for copying the raw disk contents and streaming them over the network. However, this method is cumbersome and error-prone. It requires manual configuration and isn't ideal for managing VM images across regions, especially when changes need to be tracked and managed efficiently. Additionally, this approach doesn't leverage GCP's infrastructure, meaning it lacks the robustness of built-in solutions.
- Why Rejected: This method involves more manual effort and isn't as seamless or scalable for your scenario, especially when handling changes to the original production VM or easily managing the copied instances.
B) Create a snapshot of the root disk and select the snapshot as the root disk when you create a new virtual machine instance in the US-East region.
- Explanation: Snapshots are a good way to capture the state of a disk at a specific point in time. You can create a snapshot of the root disk and then use it as the root disk for the new VM in the US-East region. This method leverages GCP's built-in features, providing a simpler and more reliable solution.
- Why Rejected: While this option works well for creating a new VM, it doesn’t provide an easy way to manage updates or changes to the source VM. You'd need to take new snapshots each time there are changes to keep the copy up-to-date, which isn’t as efficient as using an image.
C) Create an image file from the root disk with Linux dd command, create a new virtual machine instance in the US-East regi...
Author: Ming · Last updated May 10, 2026
Your company runs several databases on a single MySQL instance. They need to take backups of a specific database at regular intervals. The backup activity needs to complete as quickly as possible an...
Let's evaluate each option based on the goal of taking regular backups of a MySQL database with minimal impact on disk performance and fast completion:
A) Configure a cron job to use the gcloud tool to take regular backups using persistent disk snapshots.
- Explanation: This option uses `gcloud` to create persistent disk snapshots, which capture the state of the disk at a given moment. Persistent disk snapshots are efficient for backup purposes, as they don't require downtime for the MySQL instance, and the snapshots are incremental, saving only the changes since the last snapshot. This minimizes the impact on the disk performance.
- Why Rejected: While snapshots are efficient and require minimal impact on performance, this method doesn’t ensure that only the specific database is backed up, and it doesn’t guarantee the consistency of the database at the backup point. Additionally, using snapshots of the entire persistent disk might not be as granular or focused on just the specific database.
B) Mount a Local SSD volume as the backup location. After the backup is complete, use gsutil to move the backup to Google Cloud Storage.
- Explanation: Local SSDs provide high-speed storage, but they are ephemeral, meaning the data is lost if the VM is terminated or stopped. However, this option involves mounting a Local SSD for the backup operation and then moving the backup to Google Cloud Storage using `gsutil`. The idea here is to use the Local SSD for temporary storage, and `gsutil` moves the backup data to Cloud Storage after the backup completes.
- Why Rejected: The Local SSD option has the limitation of being volatile (data is lost on VM termination), which is not ideal for a backup solution. Additionally, using Local SSDs could still impact the disk performance, especially when the backup process is running in parallel with other MySQL operations.
C) Use gcsfuse to mount a Google Cloud Storage bucket as...
Author: Leah Davis · Last updated May 10, 2026
You are helping the QA team to roll out a new load-testing tool to test the scalability of your primary cloud services that run on Google Compute Engine with Cloud
...
Let's evaluate each option based on the goal of rolling out a new load-testing tool for scalability testing in a cloud environment that includes Google Compute Engine and Cloud Bigtable.
A) Ensure that the load tests validate the performance of Cloud Bigtable.
- Explanation: This option is crucial because Cloud Bigtable is a key component of your architecture. The load tests should include scenarios that stress test Cloud Bigtable's performance, especially under varying load conditions, to ensure that the system can handle the expected scale.
- Why Selected: It is essential to validate the performance of your database (Cloud Bigtable) as it can become a bottleneck if not properly tested. Without testing the Bigtable component specifically, you might miss performance issues or scalability problems that could arise from database limitations under load.
B) Create a separate Google Cloud project to use for the load-testing environment.
- Explanation: Using a separate project for load testing is a good practice as it isolates the load-testing environment from production. This minimizes the risk of load tests inadvertently affecting the production environment or other critical services.
- Why Selected: Keeping the load-testing activities in a separate project ensures that any issues caused by the tests (e.g., resource consumption or misconfigurations) don't impact the production environment. This provides a safe environment for testing without jeopardizing live services.
C) Schedule the load-testing tool to regularly run against the production environment.
- Explanation: Running load tests directly against production can risk degrading service availability, causing downtime, or even affecting end users. This is generally not a best practice, especially if the tests are resource-intensive.
- Why Rejected: Load testing against production should be done with extreme caution or avoided. In most cases, it's better to perform load testing in a controlled environment that mimics production rather than directly on the live systems. Frequent load testing on production can negatively impact user experience and service reliability.
D) Ensure all third-party systems your services use are capable of handling high load.
- Explanation: This is important becau...
Author: Amelia · Last updated May 10, 2026
Your customer is moving their corporate applications to Google Cloud Platform. The security team wants detailed visibility of all projects in the organization. You provision the Google Cloud Resource Manager and set up yourself as the org admin....
Let's evaluate the best roles for providing detailed visibility of all projects in the organization for the security team.
A) Org viewer, project owner
- Explanation:
- Org viewer: This role allows users to view all aspects of the organization, including projects, folders, and resources. It gives read-only access at the organization level.
- Project owner: This role provides full control over a project, allowing users to manage resources, including the ability to add or remove users, modify settings, and manage permissions.
- Why Rejected: While the Org viewer role provides visibility into all projects, the project owner role is too permissive for the security team. It grants the ability to make changes to the project (create, modify, delete resources), which is unnecessary and could pose a security risk, especially if they only need visibility, not management capabilities.
B) Org viewer, project viewer
- Explanation:
- Org viewer: As mentioned above, this role grants view-only access to all resources in the organization.
- Project viewer: This role grants read-only access at the project level. It allows the user to view the configuration of a project, including resources, but not modify them.
- Why Selected: This option is the most appropriate for the security team. It allows them to view all the projects and resources within the organization without the ability to modify or interfere with the projects. This role combination ensures they can monitor and assess the organization's setup, which aligns with their need for detailed visibility and audit capabilities, while maintaining...
Author: Lucas · Last updated May 10, 2026
Your company places a high value on being responsive and meeting customer needs quickly. Their primary business objectives are release speed and agility. You want to reduce the chance of security ...
To reduce the chance of security errors being introduced while maintaining a focus on release speed and agility, we should focus on automating security checks and integrating them directly into the CI/CD pipeline. Let’s analyze the options:
A) Ensure every code check-in is peer-reviewed by a security SME
- Pros: Peer reviews by a security Subject Matter Expert (SME) could catch security issues early.
- Cons: This can significantly slow down the development process, as it requires manual review for every check-in. Given the emphasis on release speed and agility, this would not scale well and could delay releases.
- Conclusion: This is not ideal because it could hinder agility and speed.
B) Use source code security analyzers as part of the CI/CD pipeline
- Pros: Automated source code security analyzers can be integrated into the CI/CD pipeline to automatically detect vulnerabilities and security issues early. This would allow issues to be addressed quickly without requiring manual review, fitting the goal of speed and agility.
- Cons: It may not catch all possible security vulnerabilities (depending on the tool's coverage), but this is generally an effective approach for reducing security risks in a timely manner.
- Conclusion: This is ideal, as it integrates security checks directly into the CI/CD pipeline, maintaining speed while reducing errors.
C) Ensure you have stubs to unit test all interfaces between components
- Pros: Unit tests are important for ensuring the correctness of individual components. However, this approach mainly addresses functional issues, not security concerns.
- Cons: While it may help identify issues in components’ in...
Author: Ryan · Last updated May 10, 2026
You want to enable your running Google Kubernetes Engine cluster to scale as demand for your applica...
To enable your Google Kubernetes Engine (GKE) cluster to scale as demand changes, you need to implement autoscaling. Let’s analyze the options:
A) Add additional nodes to your Kubernetes Engine cluster using the following command:
`gcloud container clusters resize CLUSTER_Name --size 10`
- Pros: This command increases the number of nodes in the cluster.
- Cons: While it scales the cluster by adding nodes, it is not automatic and doesn’t provide autoscaling based on workload demand. This approach requires manual intervention every time scaling is needed.
- Conclusion: This is not ideal for automatic scaling based on application demand. It's useful in a fixed-resource scenario, but it doesn’t meet the requirement for scaling as demand changes dynamically.
B) Add a tag to the instances in the cluster with the following command:
`gcloud compute instances add-tags INSTANCE --tags enable-autoscaling max-nodes-10`
- Pros: Adding a tag may configure certain features or settings, but it doesn't specifically enable autoscaling in GKE.
- Cons: The command is more related to adding metadata or organizing resources. Tags themselves don’t enable autoscaling in the cluster or set node scaling parameters. Autoscaling needs to be configured specifically for the cluster, not just through tags.
- Conclusion: This is not correct because tags alone do not enable the autoscaling feature on the cluster. It may be useful for organizational purposes, but it doesn't solve the autoscaling problem.
C) Update the ...
Author: Abigail · Last updated May 10, 2026
Your marketing department wants to send out a promotional email campaign. The development team wants to minimize direct operation management. They project a wide range of possible customer responses, from 100 to 500,000 click-through per day. The link leads to a simple website that expl...
When recommending infrastructure for a scalable and easy-to-manage solution, we need to consider both the expected scale (which could range from 100 to 500,000 click-throughs per day) and the minimization of direct operation management (since the development team doesn’t want to manage operations directly). Let’s analyze the options:
A) Use Google App Engine to serve the website and Google Cloud Datastore to store user data.
- Pros:
- App Engine is a fully managed service, which means it abstracts away most of the operational overhead, such as server management, scaling, and patching. This directly aligns with the desire to minimize direct operations management.
- Google Cloud Datastore is a scalable, NoSQL database that can handle large amounts of data efficiently, with built-in scaling and high availability. It is well-suited for handling the potential range of customer responses.
- Auto-scaling: App Engine can automatically scale based on traffic, which is important given the potential for wide fluctuations in click-through volume.
- Cons:
- Datastore may not be the best choice if relational queries are needed, as it’s a NoSQL database, but it is fine for user data storage if it's mostly key-value or document-style data.
- Conclusion: This option is ideal because it minimizes management complexity and scales seamlessly with the demand.
B) Use a Google Container Engine cluster to serve the website and store data to persistent disk.
- Pros:
- Google Kubernetes Engine (GKE) offers container orchestration and scaling, which can handle a wide range of traffic. You can scale the cluster to match the demand.
- Persistent disk is reliable storage, suitable for some types of data.
- Cons:
- GKE requires more operational overhead compared to fully managed services like App Engine. You would need to manage the containerized applications, monitor scaling, and handle updates.
- This option introduces more complexity and requires ongoing management of Kubernetes infrastructure.
- Persistent disk isn’t optimized for scalable, high-performance querying like a NoSQL database or a managed database.
- ...
Author: Grace · Last updated May 10, 2026
Your company just finished a rapid lift and shift to Google Compute Engine for your compute needs. You have another 9 months to design and deploy a more cloud-native solution. Specifically, you want a system th...
To design a more cloud-native solution that is no-ops (no operations management) and auto-scaling, the key requirements are automation, scaling, and minimized management overhead. Let’s analyze the options:
A) Compute Engine with containers
- Pros:
- Using containers in Compute Engine gives you control over your environment and allows for flexibility in configuration.
- Cons:
- Compute Engine still requires manual management and scaling of the virtual machines (VMs), meaning it's not "no-ops" as it involves managing the infrastructure itself, including scaling, patching, and load balancing.
- Auto-scaling is possible but requires significant configuration and management, which doesn't meet the goal of a "no-ops" solution.
- Conclusion: This is not ideal because it still requires manual intervention for scaling and management, making it less suited for the no-ops requirement.
B) Google Kubernetes Engine with containers
- Pros:
- Google Kubernetes Engine (GKE) is a managed container orchestration service, providing an easy, scalable, and no-ops solution. Kubernetes manages scaling, deployment, and high availability automatically.
- It offers auto-scaling and integrates seamlessly with other Google Cloud services.
- Fully managed, reducing the need for hands-on infrastructure management.
- Cons:
- Kubernetes requires some initial setup and may involve some complexity in understanding container orchestration, but once set up, it operates largely as a no-ops solution with auto-scaling.
- Conclusion: This is ideal for a cloud-native, no-ops, and auto-scaling solution. It is a fully managed service that abstracts away most operational concerns.
C) Google App Engine Standard Environment
- Pros:
- App Engine is a fully managed, no-ops platform that automatically scales your application based on traffic.
- It abstracts away all infrastructure concerns, including scaling, patching, and provisioning, making i...
Author: Victoria · Last updated May 10, 2026
One of your primary business objectives is being able to trust the data stored in your application. You want to log all changes to the application data.
How ca...
To design a logging system that ensures the authenticity of logs, you need a mechanism that ensures the logs cannot be tampered with and that the data can be verified at any time. Let’s analyze the options:
A) Write the log concurrently in the cloud and on-premises
- Pros: Writing logs in multiple locations (cloud and on-premises) could help provide redundancy and availability.
- Cons: While this increases availability, it doesn’t solve the problem of verifying the authenticity of the logs. If someone can modify the logs on either side (cloud or on-prem), you still don’t have a guarantee that the logs are untampered with. The distributed nature of the system may also make it more complex to verify the authenticity of the logs across both environments.
- Conclusion: This option does not provide a secure way to verify authenticity and is rejected for this requirement.
B) Use a SQL database and limit who can modify the log table
- Pros: Limiting who can modify the log table helps reduce unauthorized changes. Using a SQL database is common for logging structured data.
- Cons: This solution still doesn’t ensure the integrity of the logs. If someone gains access to the database, they could potentially tamper with the logs. There’s no inherent mechanism to verify whether the log entries have been altered after they were written.
- Conclusion: While it’s important to limit access to logs, this solution doesn’t guarantee authenticity. It’s rejected because it lacks verification of the data’s integrity after it's written.
C) Digital...
Author: Madison · Last updated May 10, 2026
Your company has a Google Workspace account and Google Cloud Organization. Some developers in the company have created Google Cloud projects outside of the Google Cloud Organization.
You want to create an Organization structure that allows developers to create projects, but prevents them from modifying production projects. You want to manage policies for all projects centrally and be able to set more restrictive policies for production projects.
Y...
When designing an Organization structure in Google Cloud, it’s important to focus on central management, policy enforcement, and flexibility, as well as minimizing disruption to users and developers. Let's evaluate each option based on these factors.
Option A:
- Creating a second Google Workspace account and Organization: This would create a completely separate environment, which adds complexity and administrative overhead. It also introduces difficulty in central policy management, as you'd need to manage policies across two Organizations. Moving projects between organizations could lead to disruption, and developers would need to work across two different accounts.
- Granting Project Creator IAM role on a new Organization: This works for giving developers the ability to create new projects, but it's unnecessary to have a second Organization, as you can manage different environments within a single Organization structure using folders.
- Conclusion: This option introduces unnecessary complexity, makes it harder to manage policies centrally, and could lead to disruption when moving projects. It's not optimal.
Option B:
- Creating a folder for production projects: Creating a "Production" folder under the main Organization allows you to separate production and development projects clearly. This approach is in line with best practices and allows for central management while enforcing stricter policies on the "Production" folder.
- Granting Project Creator IAM role on the Organization: Developers will have the ability to create projects, but they won't be able to create projects directly under the "Production" folder unless granted specific permissions.
- Policy management: This option allows for applying common policies at the Organization level and setting more restrictive policies at the folder level for production projects. However, moving the developer projects to the new Organization (outside the Google Cloud Organ...
Author: Layla · Last updated May 10, 2026
Your company has an application running on Compute Engine that allows users to play their favorite music. There are a fixed number of instances. Files are stored in Cloud Storage, and data is streamed directly to users. Users are reporting that they sometimes need to attempt to play popular...
To improve the performance of your application and address the issue of users having to attempt playing popular songs multiple times, the solution should focus on optimizing the delivery of music files to users. Let's break down each option:
Option A: Mount the Cloud Storage bucket using `gcsfuse` on all backend Compute Engine instances
- gcsfuse is a tool that allows you to mount Cloud Storage buckets as file systems on Compute Engine instances.
- Serving music files directly from the backend Compute Engine instance: While this might seem like a solution, using `gcsfuse` introduces performance issues. Cloud Storage is not designed to be accessed as a local file system, and using `gcsfuse` can lead to latency, inconsistent performance, and potential overloading of the Compute Engine instances.
- Conclusion: This option is not ideal because it is not optimized for high-performance access and can lead to slower performance.
Option B: Create a Cloud Filestore NFS volume and attach it to the backend Compute Engine instances
- Cloud Filestore provides a managed NFS file share, which can be used for high-performance storage with low-latency access. However, downloading popular songs into Cloud Filestore would require managing synchronization between Cloud Storage and Cloud Filestore, adding complexity and potential delays. It also doesn’t scale as efficiently as a CDN, especially for globally distributed users.
- Serving music files directly from the backend Compute Engine instance: This would still require Compute Engine to handle all the traffic, which could lead to scalability issues if demand increases.
- Conclusion: While this option can improve performance compared to Cloud Storage, it introduces additional complexity and might not scale well for large numbers of users.
Option C: Copy popular songs into CloudSQL a...
Author: StarlightBear · Last updated May 10, 2026
The operations team in your company wants to save Cloud VPN log events for one year. You need to configure the cloud i...
To configure your cloud infrastructure to save Cloud VPN log events for one year, you need to ensure that logs are collected, stored, and accessible for the required time period. Let's analyze each option:
Option A: Set up a filter in Cloud Logging and a Cloud Storage bucket as an export target for the logs you want to save.
- Cloud Logging allows you to configure filters to capture specific logs, such as Cloud VPN events.
- Exporting to Cloud Storage is an ideal solution for long-term log retention. Cloud Storage can store large amounts of data, and you can configure the bucket's retention policy to keep logs for one year.
- Advantages: This is a scalable, reliable, and low-cost way to retain logs for extended periods. Cloud Storage provides flexible storage options, and it ensures that logs are easily accessible for compliance, auditing, or analysis.
- Conclusion: This is the most appropriate and efficient solution to save logs for the required time frame.
Option B: Enable the Compute Engine API, and then enable logging on the firewall rules that match the traffic you want to save.
- Compute Engine API and firewall rules logging are unrelated to Cloud VPN logs. Enabling firewall logs only tracks traffic that passes through the firewall, which is not...
Author: William · Last updated May 10, 2026
You are working with a data warehousing team that performs data analysis. The team needs to process data from external partners, but the data contains personally identifiable information (PII). You need ...
When processing and storing data that contains personally identifiable information (PII), it's crucial to ensure the PII is either anonymized, removed, or handled in compliance with privacy regulations. Let's review each option carefully:
Option A: Create a Dataflow pipeline to retrieve the data from the external sources. As part of the pipeline, use the Cloud Data Loss Prevention (Cloud DLP) API to remove any PII data. Store the result in BigQuery.
- Cloud Data Loss Prevention (DLP) is a tool specifically designed to detect and redact PII in data. It is capable of identifying sensitive information such as names, email addresses, and credit card numbers, and it can either mask or remove this information from the data.
- Dataflow is a fully managed stream and batch processing service, ideal for processing data at scale.
- BigQuery is a robust analytics data warehouse capable of storing large datasets efficiently.
- Advantages: This approach ensures that any PII data is detected and removed during the processing stage before storing it in BigQuery, minimizing the risk of storing sensitive data. It is an end-to-end solution that uses the DLP API for privacy compliance.
- Conclusion: This is the best option, as it allows you to handle PII securely while leveraging both the scalability of Dataflow and the analytical power of BigQuery.
Option B: Create a Dataflow pipeline to retrieve the data from the external sources. As part of the pipeline, store all non-PII data in BigQuery and store all PII data in a Cloud Storage bucket that has a retention policy set.
- Storing PII data in Cloud Storage: Storing PII data, even with a retention policy, can be risky. If the PII data is not properly anonymized or deleted, it could lead to privacy violations or non-compliance with regulations like GDPR.
- Retention policy: While it might seem like a good approach to control the lifespan of PII data, simply storing the PII without processing it first does not fully mitigate risks associated with privacy and data leakage.
- Conclusion: This option is not ideal because it still involves storing PII data, e...
Author: Amira99 · Last updated May 10, 2026
You want to allow your operations team to store logs from all the production projects in your Organization, without including logs from other projects. All of the production projects are contained in a folder. You want to ensure th...
To allow the operations team to store logs from all production projects in your organization without including logs from other projects, you should focus on a solution that ensures automatic capturing of logs for both existing and new production projects, while also centralizing log storage. Let's review each option based on this goal:
Option A: Create an aggregated export on the Production folder. Set the log sink to be a Cloud Storage bucket in an operations project.
- Aggregated export on the folder: This option is well-suited for aggregating logs from all projects within a specific folder, in this case, the production projects folder. It ensures that all logs from production projects, including both existing and new projects, are captured automatically.
- Log sink to Cloud Storage: Cloud Storage is an excellent option for long-term, cost-effective storage of logs. It allows easy access and is suitable for handling large volumes of log data.
- Advantages: This solution provides centralized logging for all production projects with minimal configuration. It automatically handles new production projects added to the folder.
- Conclusion: This is the best option, as it meets the requirement of automatically capturing logs from all production projects and storing them in a centralized location (Cloud Storage), without including logs from other projects.
Option B: Create an aggregated export on the Organization resource. Set the log sink to be a Cloud Storage bucket in an operations project.
- Aggregated export on the Organization resource: While this would aggregate logs from all projects within the entire Organization, it does not filter for only production projects. This means that logs from non-production projects would also be included, which is not desirable based on the requirements.
- Cloud Storage bucket: Using Cloud Storage is a good choice for log storage, but the...
Author: Lucas · Last updated May 10, 2026
Your company has an application that is running on multiple instances of Compute Engine. It generates 1 TB per day of logs. For compliance reasons, the logs need to be kept for at least two years. The logs need to be available for active query for 30 days. After that, they just need to be retained for audit purposes. ...
To determine the best solution, let's break down each option, consider the key factors (cost, compliance, queryability, and long-term storage), and explain why some are more suitable than others for your use case.
Key Requirements:
1. Retention for at least two years for compliance.
2. Active queryability for 30 days.
3. Audit purposes after 30 days.
4. Minimizing costs.
5. Following Google-recommended practices.
Option A:
1. Install a Cloud Logging agent on all instances.
2. Create a sink to export logs into a regional Cloud Storage bucket.
3. Create an Object Lifecycle rule to move files into a Coldline Cloud Storage bucket after one month.
4. Configure a retention policy at the bucket level using bucket lock.
Pros:
- Cloud Storage is cost-effective for long-term storage, and Coldline is a low-cost option for infrequent access.
- Using Object Lifecycle rules helps automate the transition of data to Coldline after one month.
- Retention policy via bucket lock ensures compliance by preventing accidental deletion of logs.
Cons:
- Active querying is not easily done with Cloud Storage; you would need a separate solution (like BigQuery or other querying services).
- While Cloud Storage is good for archival, it is not optimal for real-time queryability for logs in the first 30 days.
Option B:
1. Write a daily cron job, running on all instances, that uploads logs into a Cloud Storage bucket.
2. Create a sink to export logs into a regional Cloud Storage bucket.
3. Create an Object Lifecycle rule to move files into a Coldline Cloud Storage bucket after one month.
Pros:
- Similar to option A, using Cloud Storage for long-term storage and Coldline for low-cost archival.
- Cron job can be flexible for pushing logs from instances.
Cons:
- The cron job introduces more manual management and complexity in the system.
- Similar to option A, Cloud Storage does not allow for efficient querying, which is needed for the first 30 days.
- The sink approach for logs is redundant here since the cron job is already handling log exportation.
Option C:
1. Install a Cloud Logging agent on all instances.
2. Create a sink to export logs into a partitioned BigQuery table.
3. Set a time_partitioning_expiration of 30 days.
Pros:
- BigQuery is de...
Author: William · Last updated May 10, 2026
Your company has just recently activated Cloud Identity to manage users. The Google Cloud Organization has been configured as well. The security team needs to secure projects that will be part of the Organization. They want to...
Let's break down the options and evaluate them based on the key factors: security, ease of implementation, compliance, and automation.
Key Requirements:
1. Prohibit IAM users outside the domain from gaining permissions.
2. Implement a security control across the Organization.
3. Minimize complexity and ensure ongoing compliance.
---
Option A:
Configure an organization policy to restrict identities by domain.
Pros:
- Organization policy is a native, scalable, and highly secure solution.
- It can enforce a domain-based restriction across all projects within the Organization.
- Directly blocks external IAM users from gaining permissions from the start, ensuring security compliance in a straightforward manner.
- This solution is Google-recommended for managing access at an Organization level and is well-integrated with the Google Cloud Platform.
Cons:
- It might require some initial configuration and testing to ensure it’s properly enforced across all resources.
Scenario where it is used:
- This is the best solution for any situation where a company wants a consistent, automated security control across all projects without complex manual intervention.
---
Option B:
Configure an organization policy to block creation of service accounts.
Pros:
- This is a simple security measure that could help prevent new service accounts from being created outside the domain.
Cons:
- Service accounts are often used for automated workflows and application access, so blocking their creation might cause disruptions to legitimate workflows.
- Blocking service account creation does not address the main concern of restricting IAM users outside the domain from gaining permissions. This is not directly related to the problem of prohibiting external IAM users from gaining access.
Scenario where it is used:
- This could be used if the primary concern is to restrict service accounts, but it doesn’t fit well with the broader goal of managing IAM access for users. Not applicable to this scenario.
---
Option C:
Configure Cloud Scheduler to trigger a Cloud Function every hour that removes all users that don't belong to the Cloud Identity domain from all projects.
Pros:
- This solution can automate the removal of external users periodically.
- Ensures that external users are removed from existing IAM roles over time.
Cons:
-...
Author: SolarFalcon11 · Last updated May 10, 2026
Your company has an application running on Google Cloud that is collecting data from thousands of physical devices that are globally distributed. Data is published to Pub/Sub and streamed in real time into an SSD Cloud Bigtable cluster via a Dataflow pipeline. The operations team informs you that your Cloud
Bigtable cluster has a hotsp...
Let's evaluate each option based on the scenario where Cloud Bigtable is experiencing hotspots (regions with disproportionately high access, leading to performance degradation). The goal is to improve query performance by distributing data more evenly across the nodes in the cluster.
Key Requirements:
- Resolve hotspots and improve query performance.
- Ensure that the solution is scalable and prevents future issues.
- Minimize costs and complexity while maintaining system reliability.
---
Option A:
Advise your clients to use HBase APIs instead of NodeJS APIs.
Pros:
- HBase APIs could potentially offer performance improvements if there are issues related to API-level operations.
Cons:
- Not a root cause of the hotspot issue. The problem lies in how data is distributed in the Cloud Bigtable cluster, not in the choice of API.
- Switching to HBase APIs doesn't change the fundamental data distribution problem in Bigtable that is causing hotspots.
- NodeJS APIs work fine with Cloud Bigtable, and the problem is not related to API usage but how the data is accessed and queried.
Scenario where it could be used:
- This might be useful if there are specific performance optimizations or limitations in the NodeJS API, but it is not related to the hotspot problem in the cluster.
---
Option B:
Delete records older than 30 days.
Pros:
- Deleting older records can reduce the overall data volume, which might reduce the load on the cluster.
Cons:
- Does not address the hotspot issue directly. Hotspots are caused by uneven data distribution in the row key design, not necessarily by the total amount of data.
- Deleting data may reduce storage requirements, but if the data distribution is still skewed, hotspots will likely persist even with fewer records.
- Data deletion should be a secondary action, not the primary solution to addressing hotspots.
Scenario where it might be used:
- Deleting older records can help in terms of reducing the size of the dataset or for compliance reasons, but it is not an effective long-term solution to prevent hotspots in Bigtable.
---
Option C:
Review your RowKey strategy and ensure that keys are evenly spread acr...
Author: Ryan · Last updated May 10, 2026
Your company has a Google Cloud project that uses BigQuery for data warehousing. There are some tables that contain personally identifiable information (PII).
Only the compliance team may access the PII. The other information in the tables must be available to the data scienc...
To address the need to provide appropriate access to tables containing personally identifiable information (PII) while minimizing costs and the time it takes to assign access, let's break down the key requirements and evaluate each option:
Key Requirements:
1. PII should be restricted to the compliance team.
2. Non-PII information should be accessible to the data science team.
3. Minimize cost and effort in setting up access.
4. Data access should be granular and secure, with proper authorization.
Key Concepts:
- Views: Allow controlled access to specific columns or rows from tables, which can help avoid exposing sensitive data.
- Materialized Views: Precomputed results of queries, which offer faster query performance but incur storage costs and maintenance overhead.
- Dataset-level IAM roles: Controls access at the dataset level, which can be used to allow or restrict access to specific resources.
- Access Control Lists (ACLs): Set access at the granular level (i.e., on the individual view or dataset).
---
Option A:
1. Create views of tables that exclude PII data from the source dataset.
2. Assign an appropriate project-level IAM role to the data science team.
3. Assign access controls to the dataset that contains the view.
Pros:
- Views are lightweight, don’t incur additional storage costs, and allow for more flexible and granular data access control.
- Reduces the need for copying large volumes of data and is generally cost-effective.
- Easy to set up and manage as it allows fine-grained control over what data the data science team can see.
Cons:
- This option is missing the explicit authorization of the view to access the source dataset. This step is crucial because, without it, the view won't have the necessary permissions to pull data from the source dataset.
- Views are not materialized, meaning performance can be slower when querying large datasets, but since we aren't dealing with materialized views, this doesn't incur extra storage costs.
Scenario where it is used:
- This is a solid solution if there is no heavy reliance on performance and the data science team needs quick, flexible access to non-sensitive data.
---
Option B:
1. Create materialized views of tables that exclude PII.
2. Assign an appropriate project-level IAM role to the data science team.
3. Assign access controls to the dataset that contains the view.
Pros:
- Materialized views provide faster query performance since the data is precomputed.
Cons:
- Materialized views incur extra costs for storage, as they store the precomputed data.
- This could be more costly than simple views, especially when the underlying tables are large and constantly changing.
- Similar to Option A, it is missing the crucial step of authorizing the view to access the source dataset.
Scenario where it is used:
- If performance is critical and queries over large datasets need to be sped up, materi...
Author: David · Last updated May 10, 2026
Your operations team currently stores 10 TB of data in an object storage service from a third-party provider. They want to move this data to a Cloud Storage bucket as quickly as possible, following Google-recommended pr...
To determine the best approach for migrating 10 TB of data to Google Cloud Storage efficiently, we need to consider the key factors: speed, cost, simplicity, and Google-recommended practices.
---
Option A: Use the gsutil mv command to move the data.
Pros:
- The `gsutil mv` command can be used to transfer data directly between cloud storage providers if the data is already available in a cloud environment.
- Simplicity: This is a simple command-line tool that can be effective for small-scale data transfers.
Cons:
- Not applicable for migrating data from a third-party object storage service to Google Cloud Storage. The `gsutil mv` command is primarily used for moving data within Google Cloud or from one Google Cloud storage location to another.
- It does not directly support migrations from third-party services.
Scenario where it might be used:
- It would work if the data was already in another Google Cloud bucket, but it's not applicable for third-party data sources.
---
Option B: Use the Storage Transfer Service to move the data.
Pros:
- Google-recommended tool for migrating data from third-party cloud storage services to Google Cloud Storage.
- It supports large-scale data transfers and can handle migrations from a variety of sources (e.g., AWS S3, Microsoft Azure, and other third-party providers).
- Minimizes cost by efficiently moving large datasets in parallel, reducing overall transfer time and associated costs compared to manual methods.
- This service is specifically designed for cloud-to-cloud transfers, and it can handle both scheduled and on-demand transfers.
- The data is transferred directly, avoiding any intermediate steps like downloading and re-uploading data.
Cons:
- It requires setting up and configuring the service, though this is typically straightforward.
Scenario where it is used:
- This is the ideal solution for migrating large amounts of data (such as your 10 TB) from third-party providers to Google Cloud Storage efficiently and cost-effectively.
---
Option C: Download the data to a Transfer Appliance, and ship it to Google.
Pros...
Author: Michael · Last updated May 10, 2026
You have a Compute Engine managed instance group that adds and removes Compute Engine instances from the group in response to the load on your application. The instances have a shutdown script that removes REDIS database entries associated with the instance. You see that many database entries have not been removed, and you suspect that the shutdown script is the problem. You need to ensure that th...
To address this problem effectively, the solution should ensure that the Cloud Function is triggered reliably and efficiently each time an instance is shut down.
Let's analyze the options:
A) Modify the shutdown script to wait for 30 seconds before triggering the Cloud Function.
- Reasoning: This option introduces a hard delay, which is unreliable as it assumes the shutdown script will run for the entire 30 seconds. There's no guarantee that the shutdown script will complete in time, especially under varying conditions, like network latency or CPU load. This could result in incomplete operations or missed database entry deletions.
- Rejected because: A fixed wait time can be unreliable and introduces unnecessary latency in the process.
B) Do not use the Cloud Function. Modify the shutdown script to restart if it has not completed in 30 seconds.
- Reasoning: This approach tries to ensure that the shutdown script completes, but introducing restarts could cause unnecessary complexity and lead to unpredictable behavior. Restarting the shutdown process might make the overall instance shutdown more complicated and increase load unnecessarily, especially if the system tries to restart multiple times.
- Rejected because: Restarting the shutdown script may introduce complexity, delays, and possibly cause other issues with the instance lifecycle.
C) Set up a Cloud Monitoring sink that triggers the Cloud Function after an instance removal log message arrives in Cloud Logging.
- Reasoning: This approach uses Cloud Logging and Cloud Monitorin...
Author: Kai · Last updated May 10, 2026
You are managing several projects on Google Cloud and need to interact on a daily basis with BigQuery, Bigtable, and Kubernetes Engine using the gcloud CL tool. You are travelling a lot and work on different workstations ...
To address the need to interact with Google Cloud services (BigQuery, Bigtable, Kubernetes Engine) using the `gcloud` CLI without manually managing installations on different workstations, let's review each option:
A) Use Google Cloud Shell in the Google Cloud Console to interact with Google Cloud.
- Reasoning: Google Cloud Shell provides an integrated environment that comes with the `gcloud` CLI pre-installed and is available directly in the Google Cloud Console. It's a browser-based solution, so you can access it from any device with internet access without worrying about installing or maintaining the `gcloud` tool. Cloud Shell is ideal for frequent travelers, as it provides a consistent environment across all devices without needing to manage installations or configurations.
- Selected because: This option provides a hassle-free, always-available, and consistent environment for interacting with Google Cloud without needing to install or manage the `gcloud` CLI on various workstations. It fits the use case of working across different locations and workstations while avoiding manual setup.
B) Create a Compute Engine instance and install gcloud on the instance. Connect to this instance via SSH to always use the same gcloud installation when interacting with Google Cloud.
- Reasoning: This option provides a central location where `gcloud` is pre-configured, but it introduces additional management overhead. You would need to maintain the Compute Engine instance, ensure SSH access, and potentially deal with instances being terminated or unavailable. It's also less flexible since you would have to connect to the Compute Engine instance whenever you need to use the `gcloud` tool.
- Rejected because: While this solution provides a consistent environment, it adds unnecessary complexity with instance management and SSH access. Additionally, it’s not as convenient or accessible as Cloud Shell, especially wh...
Author: Nathan · Last updated May 10, 2026
Your company recently acquired a company that has infrastructure in Google Cloud. Each company has its own Google Cloud organization. Each company is using a Shared Virtual Private Cloud (VPC) to provide network connectivity for its applications. Some of the subnets used by both companies overlap. In order for both businesses to integrate, the applications need to have p...
To ensure that the applications in both organizations can communicate with each other over private network connectivity without significant re-engineering, we need a solution that allows seamless integration without requiring extensive changes to the existing infrastructure. Let's analyze each option:
A) Set up VPC peering and peer each Shared VPC together.
- Reasoning: VPC peering allows two Virtual Private Clouds (VPCs) to communicate with each other using private IP addresses. Even if subnets overlap in each organization’s Shared VPC, VPC peering can still allow non-overlapping subnets to communicate, provided the subnets are correctly configured and do not overlap. This is a low-latency, cost-effective solution and is commonly used when both networks need to communicate privately without the need for a full re-architecture.
- Selected because: VPC peering is the most appropriate solution when both organizations need private network connectivity and the subnets do not overlap. It provides a secure, scalable, and efficient method for network connectivity, especially when minimal re-engineering is desired.
B) Migrate the projects from the acquired company into your company's Google Cloud organization. Re-launch the instances in your company's Shared VPC.
- Reasoning: Migrating projects and re-launching instances in your company's Shared VPC could work, but it requires significant re-engineering. The process would involve moving resources, re-configuring the network setup, and possibly changing how applications interact with one another. This introduces unnecessary complexity and downtime for applications, making it a less ideal choice compared to a solution like VPC peering.
- Rejected because: Migrating projects and re-launching instances introduces substantial changes and downtime, which is unnecessary for simply providing private connectivity between the two organizations.
C) Set up a Cloud VPN gateway in each Shared VPC and...
Author: John · Last updated May 10, 2026
You are managing several internal applications that are deployed on Compute Engine. Business users inform you that an application has become very slow over the past few days. You want to f...
To identify the underlying cause of the performance degradation in the application deployed on Compute Engine, it's important to start with diagnosing the root cause using the available monitoring tools before making significant changes to the infrastructure. Let’s analyze the options:
A) Inspect the logs and metrics from the instances in Cloud Logging and Cloud Monitoring.
- Reasoning: This is the most appropriate first step. Cloud Logging and Cloud Monitoring provide insights into the behavior and performance of your instances, including metrics like CPU usage, memory usage, network traffic, and application logs. By reviewing these logs and metrics, you can identify if there are resource bottlenecks (e.g., CPU spikes, memory leaks, slow disk IO) or application-level errors that could be causing the slowdown.
- Selected because: This approach directly helps identify the root cause of the issue by reviewing key performance indicators and logs. It provides a clear view of resource utilization and application health, which is crucial for diagnosing issues before making any infrastructure changes.
B) Change the Compute Engine Instances behind the application to a machine type with more CPU and memory.
- Reasoning: While increasing the resources (CPU, memory) of the instances might provide a temporary performance boost, it does not address the root cause of the slowdown. If the underlying issue is related to application design, network latency, or external dependencies (e.g., database performance), simply upgrading the machine type won’t resolve the issue and could lead to unnecessary cost increases.
- Rejected because: Scaling up without identifying the cause can lead to wasted resources and does not guarantee solving the problem. It's better to first diagnose the issue before deciding on infrastructure adjustments.
C) Restore a backup of ...
Author: Emma · Last updated May 10, 2026
Your company has an application running as a Deployment in a Google Kubernetes Engine (GKE) cluster. When releasing new versions of the application via a rolling deployment, the team has been causing outages. The root cause of the outages is misconfigurations with parameters that are on...
To prevent outages caused by misconfigurations during rolling deployments in Google Kubernetes Engine (GKE), the most effective approach is to implement preventive measures during deployment and avoid manual errors that affect the production environment. Let’s analyze each option:
A) Configure liveness and readiness probes in the Pod specification.
- Reasoning: Liveness and readiness probes are essential in Kubernetes to ensure that pods are functioning correctly. The readiness probe checks if the application is ready to receive traffic, while the liveness probe checks if the application is still healthy and needs to be restarted. By configuring these probes, Kubernetes can ensure that only healthy pods are allowed to handle traffic during a rolling deployment, preventing misconfigurations from affecting live traffic and reducing the chance of outages.
- Selected because: This is the most effective and preventive measure. It directly addresses the root cause of the issue by ensuring that misconfigurations, such as those causing the application to become unresponsive or unhealthy, do not result in application downtime during deployments. Kubernetes will only route traffic to pods that pass the readiness check, making it highly suited for avoiding outages during deployments.
B) Configure health checks on the managed instance group.
- Reasoning: Health checks in managed instance groups help monitor the health of Compute Engine instances, but they are not specifically tied to Kubernetes Pods, which is where the issue is occurring in this scenario. Health checks on instance groups are generally used for VM-level health checks, not for individual containers running in Kubernetes.
- Rejected because: While health checks are valuable for monitoring VM health, they do not directly apply to Kubernetes ...
Author: Arjun · Last updated May 10, 2026
Your company uses Google Kubernetes Engine (GKE) as a platform for all workloads. Your company has a single large GKE cluster that contains batch, stateful, and stateless workloads. The GKE cluster is configured with a single node pool with 200 nodes. Your co...
To reduce the cost of the Google Kubernetes Engine (GKE) cluster while maintaining availability, it's essential to consider the impact on different types of workloads (batch, stateful, stateless) and ensure that the solution aligns with the organization's needs.
Let's analyze the given options:
A) Create a second GKE cluster for the batch workloads only. Allocate the 200 original nodes across both clusters.
- Reasoning: Splitting the workload into two clusters might introduce additional overhead and complexity, such as managing multiple clusters and maintaining cross-cluster communication. Also, it could lead to inefficient resource allocation, as the batch workloads may not need the full capacity of the second cluster all the time. Additionally, while this approach can segregate workloads, it doesn't effectively address cost reduction in terms of underutilization of resources.
- Rejected: This option introduces complexity and doesn't efficiently address the need for cost savings. The extra cluster could increase operational overhead.
B) Configure CPU and memory limits on the namespaces in the cluster. Configure all Pods to have a CPU and memory limits.
- Reasoning: Setting CPU and memory limits is useful to prevent resource contention, but it doesn't directly reduce costs. While it ensures that workloads won't exceed resource usage, it doesn't make the cluster more cost-effective by itself. This approach can also limit the ability of certain workloads to scale optimally, as the limits are fixed.
- Rejected: This is more of a resource management strategy than a cost-saving one. It ensures stable resource consumption but does not reduce the overall cost of running the cluster.
C) Configure a HorizontalPodAutoscaler for all stateless workloads and for all compatible stateful workloads. Configure the cluster to...
Author: Emma · Last updated May 10, 2026
Your company has a Google Cloud project that uses BigQuery for data warehousing on a pay-per-use basis. You want to monitor queries in real time to discover the m...
Let's analyze each option carefully to determine the most suitable approach for monitoring costly queries and user activity in real-time:
A) 1. In the BigQuery dataset that contains all the tables to be queried, add a label for each user that can launch a query. 2. Open the Billing page of the project. 3. Select Reports. 4. Select BigQuery as the product and filter by the user you want to check.
- Reasoning: This option involves manually adding labels for users in BigQuery datasets, but it won't provide real-time monitoring of query costs. While the Billing page can show costs by users, it doesn't provide detailed, real-time query-level information like which specific queries are costly.
- Rejected: Adding labels and using the Billing page is too manual and does not offer a way to track the real-time costs of individual queries. It is not an effective way to monitor cost at the query level or track usage as it happens.
B) 1. Create a Cloud Logging sink to export BigQuery data access logs to BigQuery. 2. Perform a BigQuery query on the generated table to extract the information you need.
- Reasoning: Cloud Logging exports BigQuery data access logs, which include useful information about queries, such as execution time and resources used. By exporting these logs into BigQuery, you can write queries to analyze query performance, cost, and usage per user. This is a powerful and flexible solution for real-time monitoring, as BigQuery itself can be used to analyze the logs.
- Selected: This is a good solution because it allows you to monitor queries in real-time by analyzing data access logs in BigQuery. It also provides flexibility for customization, filtering, and grouping based on user, cost, and query characteristics.
C) 1. Create a Cloud Logging sink to export BigQuery data access logs to Cloud Storage. 2. Develop a Dataflow pipeline ...
Author: SilverBear · Last updated May 10, 2026
Your company and one of its partners each have a Google Cloud project in separate organizations. Your company's project (prj-a) runs in Virtual Private Cloud
(vpc-a). The partner's project (prj-b) runs in vpc-b. There are two instances running on vpc-a and one instance running on vpc-b. Subnets defined in both VPCs are not overlapping. Yo...
Let's carefully analyze each option to determine the best approach for ensuring communication between the instances in `vpc-a` and `vpc-b` while minimizing latency and maximizing throughput:
A) Set up a network peering between vpc-a and vpc-b.
- Reasoning: VPC peering is a direct connection between two VPCs that allows instances in both VPCs to communicate using internal IPs. It’s highly efficient as it doesn't require any tunneling or VPN infrastructure and avoids the overhead of encryption and decryption that might occur with a VPN. Peering offers low-latency, high-throughput communication, and no data transfer costs for the inter-VPC communication (aside from egress and ingress charges). This solution is straightforward and designed for precisely the scenario where you want two VPCs to communicate efficiently and securely using internal IPs.
- Selected: This is the best option because it ensures low-latency, high-throughput communication between instances in separate VPCs, leveraging Google Cloud’s native peering capability.
B) Set up a VPN between vpc-a and vpc-b using Cloud VPN.
- Reasoning: Cloud VPN creates an encrypted tunnel between two networks over the internet, providing secure communication between VPCs. While this option ensures secure communication, it introduces overhead from encryption and decryption, increasing latency. Additionally, VPNs are not as efficient as VPC peering in terms of throughput since they rely on internet-based tunnels, which are subject to congestion, packet loss, and limited bandwidth compared to the direct internal communication VPC peering offers.
- Rejected: Although it provides secure communication, a VPN introduces unnecessary complexity and overhead, impacting latency and throughput. VPC peering is a more efficient solution in this case.
C) Configure IAP TCP forwarding on the instance in vpc-b, and then launch the following gcloud command from one of the instances in vpc-a:
```bash
gcloud compute start-iap-tunnel INSTANCE_NAME_IN_VPC_B 22 --local-host-port=localhost:22
```
- Reasoning: Identity-Aware Proxy (IAP) TCP forwarding allows you to forward traffic over the Google Cloud infrast...
Author: Zara · Last updated May 10, 2026
You want to store critical business information in Cloud Storage buckets. The information is regularly changed, but previous versions need to be referenced on a regular basis. You want to ensure that there is a record of all changes to any information in these buckets...
Let's evaluate the different features in Google Cloud Storage and their suitability for the given scenario:
A) Bucket Lock
- Reasoning: Bucket Lock is a feature that helps enforce retention policies and prevents the deletion of objects within the bucket for a specified retention period. This ensures that data cannot be deleted or modified until the retention period has expired. While this is a useful feature for compliance purposes (e.g., ensuring data retention for a minimum period), it does not help in tracking versions or easily rolling back changes. It also focuses on preventing deletion rather than enabling versioning of the data.
- Rejected: While it is useful for compliance and preventing accidental deletions, it does not address the need for versioning or tracking all changes. It's not the best fit for this scenario where the goal is to reference previous versions of data and recover from accidental edits or deletions.
B) Object Versioning
- Reasoning: Object Versioning is the best feature for the scenario described. When enabled, Cloud Storage automatically keeps previous versions of objects in the bucket whenever changes are made to them. This allows you to reference any previous version of a file and easily roll back to it if needed. It provides a full history of changes made to the object, which is essential for tracking and recovering from accidental edits or deletions.
- Selected: This is the ideal feature for ensuring a record of all changes, allowing previous versions to be referenced regularly, and enabling easy rollback of accidental edits or deletions. It directly meets the needs for version tracking and rollback.
C) Object Change Notification
- Reasoning: Object Change Notification sends notifications when an object in Cloud Storage is changed (such as being uploaded, updated, or delet...
Author: Daniel · Last updated May 10, 2026
You have a Compute Engine application that you want to autoscale when total memory usage exceeds 80%. You have installed the Cloud Monitoring agent and configured the autoscaling policy as follows:
* Metric identifier: agent.googleapis.com/memory/percent_used
* Filter: metric.label.state =3D 'used'
* Target utilization le...
Let's carefully evaluate each option based on the scenario described:
Current Configuration:
- Metric identifier: `agent.googleapis.com/memory/percent_used`
- Filter: `metric.label.state = 'used'`
- Target utilization level: 80%
- Target type: GAUGE
The goal is to autoscale the application when memory usage exceeds 80%.
A) Change the Target type to DELTA_PER_MINUTE.
- Reasoning: The DELTA_PER_MINUTE target type would calculate the change in the metric over time, which can be useful for metrics like CPU usage or requests over time. However, in this case, memory usage is being tracked with GAUGE, which measures the current value of memory usage rather than its change over time. Memory usage doesn't need to be measured as a delta; rather, it needs to be compared to a threshold (80%). Changing the target type to DELTA_PER_MINUTE would not be appropriate for this use case and could cause scaling to behave unpredictably.
- Rejected: Changing the target type to DELTA_PER_MINUTE is not suitable because memory usage is a static metric (not a rate of change), so it should be compared directly to a threshold.
B) Change the Metric identifier to agent.googleapis.com/memory/bytes_used.
- Reasoning: The current metric identifier (`agent.googleapis.com/memory/percent_used`) tracks the percentage of memory used. This is a perfectly valid metric for scaling purposes, as it's intuitive to scale when memory usage exceeds a certain percentage (80%). Changing the metric to `bytes_used` would give the raw number of bytes used, but the percentage of memory used is more useful for scaling decisions. The existing metric (`percent_used`) is already a good choice for autoscaling based on memory usage.
- Rejected: Changing the metric identifier to `bytes_used` would complicate the scaling decision, as it would require converting the raw byte usage into a percentage. The current metric is more appropriate for this scenario.
C) Change the filter to `metric.label.state = 'used' AND metric.label.state = 'buffered' AND metric.label.state = 'cached' AND metric.label.state = 'slab'`.
- Reasoning: The...
Author: Ella · Last updated May 10, 2026
You are deploying an application to Google Cloud. The application is part of a system. The application in Google Cloud must communicate over a private network with applications in a non-Google Cloud environment. The expected average throughput is 200 kbps. The business requires:
* as close to 100% system availability as possible...
Let's go through the options in detail and analyze which one is most suitable for your requirements based on factors like availability, cost optimization, and throughput.
Key Requirements:
- Availability: The solution should ensure high availability with as close to 100% uptime as possible.
- Cost Optimization: The solution should be cost-effective and avoid unnecessary complexity or over-provisioning for a 200 kbps throughput.
Option A: An HA Cloud VPN gateway connected with two tunnels to an on-premises VPN gateway
- High Availability: The HA (High Availability) Cloud VPN gateway ensures that there is automatic failover between two tunnels, providing high availability. This option is designed for scenarios where both high availability and failover are critical, which aligns well with the requirement for "as close to 100% availability as possible."
- Cost: While more expensive than a single VPN, it provides a more robust solution with redundancy and failover. The cost is justified by the business's need for high availability.
- Throughput: With 200 kbps throughput, this option is more than capable of handling the traffic, as it's designed for larger, more critical deployments. The cost might be slightly higher than single tunnel options, but the value added by high availability justifies the cost.
Option B: Two Classic Cloud VPN gateways connected to two on-premises VPN gateways (each with two tunnels)
- High Availability: This option involves Classic VPNs, which are considered outdated and don't provide the same level of reliability as HA Cloud VPNs. Classic VPN doesn't have the same built-in features for automated failover or redundancy as HA Cloud VPN does.
- Cost: Classic Cloud VPN gateways are typically cheaper than HA VPN gateways, but this comes at the cost of lesser reliability and features. Two VPN gateways with multiple tunnels create additional complexity, which may not be worth the reduced cost for a critical system.
- Throughput: Though capable of handling 200 kbps, this setup would unn...
Author: Daniel · Last updated May 10, 2026
Your company has an application running on App Engine that allows users to upload music files and share them with other people. You want to allow users to upload files directly into Cloud Storage from their ...
Let's evaluate the different options based on the scenario provided: allowing users to upload files directly into Cloud Storage from their browser, without the backend application (App Engine) handling the payload.
Key Considerations:
1. Direct Browser Upload: The goal is to let users upload files to Cloud Storage without passing the file through the backend, which reduces latency and avoids unnecessary load on your App Engine instance.
2. Security: Only authorized users should be able to upload files to Cloud Storage. This involves using a secure method for uploading directly from the browser.
3. Ease of Use: The solution should minimize complexity and work seamlessly with the front-end (browser) interaction.
Option A: 1. Set a CORS configuration in the target Cloud Storage bucket where the base URL of the App Engine application is an allowed origin. 2. Use the Cloud Storage Signed URL feature to generate a POST URL.
- Direct Upload: This option allows for direct upload from the browser to Cloud Storage. By generating a signed URL, the application provides a secure endpoint for users to upload files directly to the Cloud Storage bucket.
- Security: The signed URL feature ensures that only users with the correct signed URL can upload files, which is crucial for security.
- CORS Configuration: Configuring CORS (Cross-Origin Resource Sharing) on the Cloud Storage bucket is necessary to allow uploads from the user's browser (which is typically a different origin) to Cloud Storage. This is a standard requirement for browser-based file uploads to a cloud service.
- Appropriateness: This option meets all the requirements of direct uploads, security, and reducing backend involvement. This is the correct choice.
Option B: 1. Set a CORS configuration in the target Cloud Storage bucket where the base URL of the App Engine application is an allowed origin. 2. Assign the Cloud Storage WRITER role to users who upload files.
- Direct Upload: This option would allow direct uploads via a CORS configuration, but giving users the Cloud Storage WRITER role directly can be risky. This would mean users would have write access to the entire Cloud Storage bucket, which could introduce potential security risks (unrestricted access to the bucket).
- Security: The approach of assigning the WRITER role to users is overly permissive and not ideal for limiting access to on...
