Google Practice Questions, Discussions & Exam Topics by our Authors

A governmental regulation was recently passed that affects your application. For compliance purposes, you are now required to send a duplicate of specific application logs from your application...

In this scenario, the goal is to comply with a regulatory requirement that mandates sending a duplicate of specific application logs to a project restricted to the security team. We need to ensure the logs are routed securely and reliably to the appropriate location. Let's evaluate the options: Option A: Create user-defined log buckets in the security team's project. Configure a Cloud Logging sink to route your application's logs to log buckets in the security team's project. - Analysis: Cloud Logging sinks allow you to route logs to different destinations. By creating a user-defined log bucket in the security team's project and configuring a sink to route logs from the application project to that bucket, you ensure that the logs are securely transferred and stored in the security team's project. This setup provides a clean and compliant way to replicate logs while maintaining control over where they are stored. - Selected Option: This is the most appropriate choice. It allows you to specify exactly which logs should be routed to the security team's project, ensuring compliance with the regulation. It also follows the principle of least privilege, as you can configure the sink to only allow the necessary logs to be forwarded to the security team’s project. Option B: Create a job that copies the logs from the _Required log bucket into the security team's log bucket in their project. - Analysis: This approach would require manually creating and managing a job that continuously copies logs from one location to another. While it could work, it introduces extra complexity and overhead. This method is also prone to errors and may not be as reliable as using Cloud Logging sinks, which are natively integrated into Google Cloud's logging system. - Rejection Reason: The jo...

Author: Manish · Last updated Jul 4, 2026

You plan to deploy a new Go application to Cloud Run. The source code is stored in Cloud Source Repositories. You need to configure a fully managed, automated, continuous deployment pipeline that runs when a sourc...

To set up a fully managed, automated, continuous deployment pipeline for your Go application on Cloud Run with the simplest configuration, let's evaluate each option: Option A: Configure a cron job on your workstations to periodically run `gcloud run deploy --source` in the working directory. - Analysis: This approach requires setting up a cron job on your local workstation or on a server. It would periodically run the `gcloud run deploy` command to deploy the latest code to Cloud Run. While this might work, it requires manual configuration, maintenance, and doesn’t fully automate the process, especially in terms of handling code commits automatically. - Rejection Reason: This is not a suitable approach for continuous deployment because it introduces unnecessary complexity (managing cron jobs) and lacks the automation that cloud-native solutions provide. It’s not scalable, and it relies on a local or external machine to run the deployment process. Option B: Configure a Jenkins trigger to run the container build and deploy process for each source code commit to Cloud Source Repositories. - Analysis: Jenkins is a popular CI/CD tool that can handle this process, but it introduces complexity. You would need to set up and maintain a Jenkins server, configure build pipelines, and handle integrations. While Jenkins is powerful, it may be overkill for a simple deployment process, especially if you are looking for a fully managed solution. - Rejection Reason: This approach is more complex and involves managing an external Jenkins server. It’s a good option for organizations that already use Jenkins or have custom requirements, but it’s more effort than necessary for a straightforward deployment pipeline, especially when fully managed services are available. Option C: Configure continuous deployment of new revisions from a source repository for Cloud Run using buildpacks. - Analysis: Buildpacks provide a way...

Author: Aditya · Last updated Jul 4, 2026

Your team has created an application that is hosted on a Google Kubernetes Engine (GKE) cluster. You need to connect the application to a legacy REST service that is deployed in two GKE clusters in two different regions. You want to connect your application to the target service in a way that is resilient. You ...

To connect your application to the legacy REST service deployed in two different GKE clusters in separate regions, we need to ensure resiliency, robust health checking, and smooth service connectivity across clusters. Let's go through each option and reason through the selection. Option A: Use Traffic Director with a sidecar proxy to connect the application to the service. - Explanation: Traffic Director is a fully managed traffic control plane that supports service mesh functionality. Using Traffic Director with a sidecar proxy (such as Envoy) allows the application to manage traffic between services across clusters with built-in load balancing and resiliency features. The sidecar proxy handles communication with the legacy service and also provides monitoring capabilities for health checks. - Why it's selected: This setup ensures that traffic to the legacy service is highly available and resilient, as Traffic Director can manage failover between the two GKE clusters. The sidecar proxy can also be configured to send health check requests to the legacy service on a separate port. Option B: Use a proxyless Traffic Director configuration to connect the application to the service. - Explanation: A proxyless Traffic Director configuration means you rely on native Kubernetes services to route traffic directly to your backend service without a sidecar proxy. This reduces overhead since there's no proxy component, but it doesn't provide as many traffic management capabilities (like fine-grained control over retries, timeouts, and observability). - Why it's rejected: While this option is simpler and can work, it lacks the advanced resiliency features provided by a sidecar proxy in a service mesh configuration, such as automatic traffic failover, retries, and advanced health check capabilities. Option C: Configure the legacy service's firewall to allow health checks originating from the proxy...

Author: Ella · Last updated Jul 4, 2026

You have an application running in a production Google Kubernetes Engine (GKE) cluster. You use Cloud Deploy to automatically deploy your application to your production GKE cluster. As part of your development process, you are planning to make frequent changes to the application's source code and need to select the tools to test the changes before pushing them to your remote source code repository. Your toolset must meet the following requirements: * Test f...

To meet the requirements of testing frequent local changes, automatically building, and running containers with minimal resources while emulating production deployment, let's evaluate each option in detail: Option A: Docker Compose and dockerd - Explanation: Docker Compose is a tool for defining and running multi-container Docker applications, while `dockerd` is the Docker daemon that runs Docker containers. Docker Compose is often used for local development to spin up multiple containers with simple configurations. - Why it's rejected: While Docker Compose allows you to run containers locally, it does not emulate a production Kubernetes environment like GKE. The setup is more suited for local application testing in Docker, but it lacks features for Kubernetes-style orchestration and is not designed to integrate with Cloud Deploy or Kubernetes clusters. It does not automate testing as seamlessly in the way Kubernetes and associated tools do, which is crucial for the production-like emulation. Option B: Terraform and kubeadm - Explanation: Terraform is an infrastructure as code (IaC) tool that can be used to provision resources, including GKE clusters, and `kubeadm` is a tool to set up Kubernetes clusters. While these tools are powerful for managing infrastructure and clusters, they are not specifically suited for local application testing. - Why it's rejected: Terraform and `kubeadm` are heavy infrastructure management tools that don’t focus on local development and testing of application code. `kubeadm` requires significant resources to set up a Kubernetes cluster on your local machine, which could be overkill for the minimal resource requirement. These tools are better suited for setting up or managing infrastructure, not...

Author: Aria · Last updated Jul 4, 2026

You are deploying a Python application to Cloud Run using Cloud Source Repositories and Cloud Build. The Cloud Build pipeline is shown below: You want to opt...

To optimize deployment times and avoid unnecessary steps, let's evaluate each option and determine which one is the best fit for your use case: Option A: Remove the step that pushes the container to Artifact Registry. - Explanation: The step that pushes the container image to Artifact Registry is essential for making the built image available for deployment. If you remove this step, the application will not have a proper image stored in a registry, and Cloud Run will not be able to access it for deployment. - Why it's rejected: This option would eliminate the necessary step of storing the container image for deployment, which is critical in the deployment pipeline. Without storing the image in Artifact Registry (or another container registry), Cloud Run won't be able to deploy your Python application. Option B: Deploy a new Docker registry in a VPC, and use Cloud Build worker pools inside the VPC to run the build pipeline. - Explanation: Setting up a Docker registry inside a VPC and using Cloud Build worker pools in the VPC can be beneficial for security and network isolation but does not directly address optimizing deployment times or unnecessary steps in the pipeline. - Why it's rejected: While this may enhance security, it doesn’t directly contribute to optimizing deployment times. In fact, using VPC worker pools could introduce additional complexity and overhead for managing networking and access between services. It's a useful solution in specific security-focused scenarios but does not directly impact build time efficiency. Optio...

Author: Lucas · Last updated Jul 4, 2026

You are developing an event-driven application. You have created a topic to receive messages sent to Pub/Sub. You want those messages to be processed in real time. You need the application to be independent from any other ...

To design an event-driven application that processes messages in real-time, remains independent of other systems, and incurs costs only when messages arrive, we need to carefully evaluate each option. Let's look at the options and reason through the best one: Option A: Deploy the application on Compute Engine. Use a Pub/Sub push subscription to process new messages in the topic. - Explanation: This option would involve using Compute Engine VMs to process messages pushed from Pub/Sub. A Pub/Sub push subscription would send messages directly to an endpoint of your application running on Compute Engine. - Why it's rejected: While Compute Engine can be used, it incurs costs even when no messages are being processed, as the VMs would need to be running continuously to listen for messages. This is not cost-efficient for event-driven workloads, as Compute Engine is not serverless and requires you to manage infrastructure even when no events are being triggered. Option B: Deploy your code on Cloud Functions. Use a Pub/Sub trigger to invoke the Cloud Function. Use the Pub/Sub API to create a pull subscription to the Pub/Sub topic and read messages from it. - Explanation: In this scenario, you would use a Cloud Function to process Pub/Sub messages. The Cloud Function is triggered by Pub/Sub, and you would manually set up a pull subscription using the Pub/Sub API to read messages. - Why it's rejected: While Cloud Functions are serverless, the combination of pull subscription and manual API management in this setup adds unnecessary complexity. Cloud Functions can directly process messages via triggers without needing to manually create and manage a pull subscr...

Author: Leo · Last updated Jul 4, 2026

You have an application running on Google Kubernetes Engine (GKE). The application is currently using a logging library and is outputting to standard output. You need to export the logs to Cloud Logging, and you need the logs to include m...

To export logs from an application running on Google Kubernetes Engine (GKE) to Cloud Logging and include metadata about each request, let's evaluate the options: Option A: Change your application's logging library to the Cloud Logging library, and configure your application to export logs to Cloud Logging. - Explanation: This option suggests changing your application's logging library to the Cloud Logging library, which is designed to send logs directly to Cloud Logging in an optimized format. It would automatically include relevant metadata, such as request information, without much additional configuration. - Why it's selected: This is the simplest and most direct approach. The Cloud Logging library is fully integrated with Cloud Logging, so it takes care of the heavy lifting of exporting logs in the correct format and including the required metadata. It provides native support for GKE and simplifies the overall setup process. This approach doesn’t require you to handle log formatting manually or install additional agents, making it an optimal solution. Option B: Update your application to output logs in JSON format, and add the necessary metadata to the JSON. - Explanation: This option involves manually configuring your application to output logs in JSON format and including the necessary metadata in the log entries. - Why it's rejected: While this can work, it requires manual effort to format the logs correctly and ensure the metadata is included in each log entry. Additionally, this approach doesn't offer the out-of-the-box integration with Cloud Logging that the Cloud ...

Author: FrostFalcon88 · Last updated Jul 4, 2026

You are working on a new application that is deployed on Cloud Run and uses Cloud Functions. Each time new features are added, new Cloud Functions and Cloud Run services are deployed. You use ENV variables to keep track of the services and enable interservice communication, but the maintena...

To solve the problem of managing dynamic discovery of services deployed on Cloud Run and Cloud Functions, let's evaluate each option based on scalability, maintenance, and ease of integration with the cloud-native environment. Option A: Configure your microservices to use the Cloud Run Admin and Cloud Functions APIs to query for deployed Cloud Run services and Cloud Functions in the Google Cloud project. - Pros: - Uses Google Cloud's native APIs, so no extra infrastructure is required. - Scalable as it is fully integrated with Google Cloud. - Cons: - This approach requires making API calls to discover services dynamically, which may incur additional overhead and complexity. - Might result in slower service discovery because of API call latency. - Requires keeping track of API limits and handling errors gracefully. - When to use: This approach is feasible if you want a direct, cloud-native solution, and you're okay with some overhead due to API calls for service discovery. Option B: Create a Service Directory namespace. Use API calls to register the services during deployment, and query during runtime. - Pros: - Google Cloud's Service Directory is built for dynamic service discovery, allowing easy management of service names and endpoints. - Simplifies the management of services by abstracting away manual ENV variable updates. - Scalable and integrates well with the Google Cloud ecosystem, especially Cloud Run and Cloud Functions. - Cons: - Requires extra configuration during service registration and querying at runtime. - There is an additional cost associated with using the Service Directory API, though it is minimal compared to alternatives. - When to use: This option is ideal for dynamic service discovery with minimal overhead, as it is designed to handle service registration and discovery in a scalable and efficient way. This is the most cloud-native and scalable solution. Option C: Rename the Cloud Functions and Cloud Run services endpoint using a well-documented naming convention. - Pros: - Simplicity in implementation as it only relies on consistent namin...

Author: Ravi Patel · Last updated Jul 4, 2026

You work for a financial services company that has a container-first approach. Your team develops microservices applications. A Cloud Build pipeline creates the container image, runs regression tests, and publishes the image to Artifact Registry. You need to ensure that only containers that have passed the regression tests are de...

To ensure that only containers that have passed the regression tests are deployed to Google Kubernetes Engine (GKE) clusters, you need a solution that integrates with Binary Authorization in a way that allows verification and enforcement based on test results. Let's evaluate the options: Option A: Create an attestor and a policy. After a container image has successfully passed the regression tests, use Cloud Build to run Kritis Signer to create an attestation for the container image. - Pros: - This approach leverages Kritis Signer, which is designed for creating attestations that link container images with evidence (like successful tests). - Kritis integrates well with Binary Authorization, allowing a policy to enforce that only signed and validated images can be deployed. - It's a well-supported solution for ensuring that only validated container images are deployed based on specific criteria (like passing regression tests). - Cons: - While this approach is valid, it requires configuring Kritis Signer, which adds some complexity, but it's manageable with the right expertise. - When to use: This option is appropriate when you need strong control and validation over your container images, including signing them after regression tests have passed. It's especially effective if you want a system with formal attestation. Option B: Deploy Voucher Server and Voucher Client components. After a container image has successfully passed the regression tests, run Voucher Client as a step in the Cloud Build pipeline. - Pros: - Voucher provides a way to secure and validate container images in a Kubernetes environment, integrating with Binary Authorization. - It has a broader application for validating container images and other software artifacts. - Cons: - This approach requires deploying and managing the Voucher infrastructure (Server and Client), which adds complexity and maintenance overhead. - It's a more heavyweight solution compared to using Kritis Signer, especially in a container-first approach where simpler, native integrations are preferred. - When to use: This is useful in environments where you want a more comprehensive policy and enforcement for multiple types of software artifacts, but it introduces more infrastructure complexity than necessary for just ensuring test-passed containers. Option C: Set the Pod Security Standard ...

Author: Ethan · Last updated Jul 4, 2026

You are reviewing and updating your Cloud Build steps to adhere to best practices. Currently, your build steps include: 1. Pull the source code from a source repository. 2. Build a container image 3. Upload the built image to Artifact Registry. You need to add a step to perform a vulnerability scan of the built container image, and you want the results of the scan...

To determine the best option for adding a vulnerability scan step to the Cloud Build pipeline, let's evaluate each option in terms of minimizing disruptions to other teams' processes, ease of integration, and compliance with Google Cloud best practices. Option A: Enable Binary Authorization, and configure it to attest that no vulnerabilities exist in a container image. - Pros: - Binary Authorization can help enforce security policies and control which container images can be deployed to GKE based on pre-defined rules. - It integrates with Google Cloud and could theoretically be used to enforce policies around vulnerabilities. - Cons: - Binary Authorization does not directly scan images for vulnerabilities; it is more focused on ensuring only approved images are deployed. - Setting up Binary Authorization to check vulnerabilities would require additional infrastructure, such as integrating with a vulnerability scanner, which is outside of Binary Authorization's core functionality. - This would likely introduce unnecessary complexity and overhead, especially since it’s not designed specifically for vulnerability scanning. - When to use: This could be useful for controlling which images are deployed based on policy, but it doesn't directly address the need for vulnerability scanning. Not the best choice for this use case. Option B: Upload the built container images to your Docker Hub instance, and scan them for vulnerabilities. - Pros: - Many third-party services, such as Docker Hub, offer vulnerability scanning for container images. - Cons: - This introduces a third-party dependency that is not fully integrated with Google Cloud, requiring an external service for scanning. - Managing images outside of Google Cloud (i.e., in Docker Hub) could disrupt workflows and complicate management, especially if you're trying to stick to Google Cloud-native tools. - This would add complexity to the process, as the team would have to handle the upload and scanning steps separately, introducing additional integration points. - When to use: This option is better suited for teams that prefer or require external scanning tools. It's not ideal for teams that want to keep everything within Google Cloud. Option C: Enable the Container Scanning API in Artifact Registry, and scan the built container images for vulnerabilities. - Pros: - Artifact Registry is a native Google Cloud service, and enabling Contai...

Author: ElectricLionX · Last updated Jul 4, 2026

You are developing an online gaming platform as a microservices application on Google Kubernetes Engine (GKE). Users on social media are complaining about long loading times for certain URL requests to the application. You need to investigate performance bottlenecks in the ap...

To investigate performance bottlenecks and high latency in your online gaming platform, it's essential to choose the option that provides actionable insights and is aligned with best practices for cloud-native applications. Let's evaluate the options: Option A: Configure GKE workload metrics using kubectl. Select all Pods to send their metrics to Cloud Monitoring. Create a custom dashboard of application metrics in Cloud Monitoring to determine performance bottlenecks of your GKE cluster. - Pros: - Cloud Monitoring provides a great overview of system health, and using GKE workload metrics can help identify resource bottlenecks (CPU, memory, etc.). - It's suitable for tracking the performance of clusters, nodes, and pods at a high level. - GKE native integration with Cloud Monitoring is a strong advantage as it aligns with Google Cloud's best practices. - Cons: - While you can monitor infrastructure performance, this approach is more focused on infrastructure-level metrics (e.g., CPU, memory, pod utilization) and does not specifically track HTTP request latency or performance bottlenecks at the application level. - It doesn't focus directly on application-level performance (e.g., HTTP request latency, specific URL paths), which is needed to resolve the issue of slow loading times in the context of user-facing requests. - When to use: This is ideal for investigating infrastructure-level performance issues but is less effective for troubleshooting latency at the application level (specifically HTTP request-level analysis). Option B: Update your microservices to log HTTP request methods and URL paths to STDOUT. Use the logs router to send container logs to Cloud Logging. Create filters in Cloud Logging to evaluate the latency of user requests across different methods and URL paths. - Pros: - Cloud Logging enables detailed logs of HTTP requests, and by logging HTTP methods and URL paths, you can focus on specific routes that may be causing performance issues. - This approach provides a clear view of the latency across different URL paths and methods, helping you identify specific performance bottlenecks at the application level. - It is relatively easy to implement and doesn’t require major code changes beyond adding logging statements. - Cons: - While useful for log-based analysis, this approach does not provide fine-grained performance insights (e.g., request timing, processing time, or dependencies between services) which are crucial for deeper application performance investigation. - Logging is passive and requires analysis through filters and log queries, which may be slower and less immediate compared to real-time tracing. - When to use: This is a good option if you're looking to quickly identify which URL paths and HTTP methods are leading to higher latencies, but it might be less efficient for tracing and debugging complex interactions between micr...

Author: Lina Zhang · Last updated Jul 4, 2026

You need to load-test a set of REST API endpoints that are deployed to Cloud Run. The API responds to HTTP POST requests. Your load tests must meet the following requirements: * Load is initiated from multiple parallel threads. * User traffic to the API originates from multiple source IP addresses. * Load can be scal...

To load-test a set of REST API endpoints deployed on Cloud Run and meet the specified requirements (parallel threads, multiple source IP addresses, scalable load), let's evaluate each option in terms of scalability, ease of configuration, and Google-recommended best practices. Option A: Create an image that has cURL installed, and configure cURL to run a test plan. Deploy the image in a managed instance group, and run one instance of the image for each VM. - Pros: - Managed instance group ensures automatic scaling based on demand, so you can handle increasing load efficiently. - Each VM will have its own IP address, helping to meet the requirement of multiple source IP addresses. - Cons: - cURL is a relatively simple tool for making HTTP requests, but it may not provide advanced features for distributed load testing (like managing concurrency, metrics collection, or testing at scale). - Creating and managing a custom image with cURL could add unnecessary complexity for load testing compared to more specialized tools. - Scaling might require additional manual configuration (e.g., scaling instances based on load), which could complicate the setup. - When to use: This option is suitable for basic load testing, but it lacks the advanced capabilities of a more specialized, scalable testing solution and could require more manual setup and monitoring. Option B: Create an image that has cURL installed, and configure cURL to run a test plan. Deploy the image in an unmanaged instance group, and run one instance of the image for each VM. - Pros: - Like Option A, using cURL provides a simple way to send HTTP requests, and an unmanaged instance group allows you to manually control the number of instances. - Cons: - Unmanaged instance groups do not have automatic scaling, which means you would need to manually manage scaling. This is less efficient and harder to maintain than managed instance groups. - cURL is still a basic tool for load testing, and managing concurrent users with multiple VMs may not be as efficient as using a dedicated load testing framework. - There's no built-in way to monitor or scale based on demand as easily as with managed instance groups. - When to use: This option could be suitable for very small-scale tests or ad-hoc scenarios, but it is not ideal for scalable, high-performance load testing due to the lack of automatic scaling and advanced features. Option C: Deploy a distributed load testing framework on a private Google Kubernetes Engine cluster. Deploy additional Pods as needed to initiate more traffic and support the number of concurrent users. - Pros: - A distributed load testin...

Author: Isabella · Last updated Jul 4, 2026

Your team is creating a serverless web application on Cloud Run. The application needs to access images stored in a private Cloud Storage bucket. You want to give the application Identity and Access Management (IAM) permission to access the images i...

When choosing the best practice for giving a Cloud Run application access to a private Cloud Storage bucket, there are a few key considerations based on security, access control, and best practices recommended by Google. Option A: Enforce signed URLs for the desired bucket. Grant the Storage Object Viewer IAM role on the bucket to the Compute Engine default service account. - Reasoning: - Enforcing signed URLs ensures that only authorized users or services with valid URLs can access the objects, which enhances security. - The Compute Engine default service account is not ideal for Cloud Run because it is tied to the default infrastructure and might not be the most secure option for running Cloud Run services. - Why rejected: - Using the Compute Engine default service account means that you’re using a predefined account that could have broader permissions than needed, violating the principle of least privilege. - This option is less flexible and does not align with the best practice of using a custom service account for Cloud Run services. Option B: Enforce public access prevention for the desired bucket. Grant the Storage Object Viewer IAM role on the bucket to the Compute Engine default service account. - Reasoning: - Enforcing public access prevention is a good security measure, preventing unauthorized access to the bucket from public internet sources. - Similar to Option A, using the Compute Engine default service account is not ideal, as it’s more of a general-purpose account, which might over-permission the service. - Why rejected: - This option still uses the Compute Engine default service account, which is not the recommended practice for serverless services like Cloud Run. It reduces control over the permissions granted and doesn't follow the principle of least privilege. Option C: Enforce signed URLs for the desired bucket. Create and update the Cloud Run service to use a user-managed service account. Grant the Storage...

Author: Aarav2020 · Last updated Jul 4, 2026

You are using Cloud Run to host a global ecommerce web application. Your company's design team is creating a new color scheme for the web app. You have been tasked with determining whether the new color scheme will increase...

When designing a study to determine whether a new color scheme will increase sales for a live production eCommerce web application, it's important to consider how to measure the impact without causing disruptions, maintaining statistical validity, and ensuring that the results can be attributed specifically to the new color scheme. Let's analyze each option: Option A: Use an external HTTP(S) load balancer to route a predetermined percentage of traffic to two different color schemes of your application. Analyze the results to determine whether there is a statistically significant difference in sales. - Reasoning: - This is a form of A/B testing where two versions of the application (one with the original color scheme and one with the new color scheme) are tested on different user segments. - This allows for a fair comparison of the color schemes by distributing traffic evenly between both versions and comparing the results. - Why selected: A/B testing is a standard method for evaluating the effectiveness of changes like color schemes and allows you to analyze the impact on sales in a statistically sound way. Traffic is split in a controlled manner, ensuring minimal disruption and clear analysis of the effect of the new color scheme. Option B: Use an external HTTP(S) load balancer to route traffic to the original color scheme while the new deployment is created and tested. After testing is complete, reroute all traffic to the new color scheme. Analyze the results to determine whether there is a statistically significant difference in sales. - Reasoning: - This option suggests testing the new color scheme only after a new deployment is created. However, it doesn't involve testing the two schemes concurrently. - Why rejected: You cannot determine if any observed sales differences are due to the color scheme change alone, as o...

Author: Max · Last updated Jul 4, 2026

You are a developer at a large corporation. You manage three Google Kubernetes Engine clusters on Google Cloud. Your team's developers need to switch from one cluster to another regularly without losing access to their preferred development tools. You want to c...

When managing multiple Google Kubernetes Engine (GKE) clusters, it's crucial to enable developers to switch between clusters seamlessly while ensuring a streamlined, efficient, and secure workflow. Here’s the analysis of each option: Option A: Ask the developers to use Cloud Shell and run `gcloud container clusters get-credentials` to switch to another cluster. - Reasoning: - Cloud Shell is a fully managed environment provided by Google Cloud, which comes pre-configured with the `gcloud` CLI and `kubectl` tools. This would allow developers to switch clusters by running the `gcloud container clusters get-credentials` command. - Why rejected: While Cloud Shell provides an easy way to access multiple clusters, it is not ideal for developers who need to work regularly with multiple clusters across different development environments. Cloud Shell is more suited for ad-hoc access, rather than continuous, localized access to the clusters for day-to-day development work. Option B: In a configuration file, define the clusters, users, and contexts. Share the file with the developers and ask them to use `kubectl config` to add cluster, user, and context details. - Reasoning: - Kubernetes configuration files (`kubeconfig`) store cluster details, authentication information, and contexts. Developers can define multiple clusters and contexts in the same `kubeconfig` file and easily switch between clusters by switching contexts using `kubectl config use-context`. - Why selected: This is the most efficient and flexible solution. The `kubeconfig` file allows developers to seamlessly switch between clusters by switching contexts. It is a Google-recommended best practice for ma...

Author: Elijah · Last updated Jul 4, 2026

You are a lead developer working on a new retail system that runs on Cloud Run and Firestore. A web UI requirement is for the user to be able to browse through all products. A few months after go-live, you notice that Cloud Run instances are terminated with HTTP 500: Container instances are exceeding memory limits errors during busy times. This error coincides with spikes in the number of Firestore queries...

The issue you're facing involves Cloud Run instances crashing due to memory limit violations, likely caused by inefficient Firestore queries when there are spikes in traffic. Your goal is to optimize system performance while preventing Cloud Run instances from crashing and reducing Firestore queries. Let's analyze the options: Option A: Modify the query that returns the product list using cursors with limits. - Reasoning: - Firestore queries can become inefficient and lead to high memory consumption when the result set is large. Using cursors (i.e., pagination) allows you to query products in smaller chunks instead of loading all the products at once, which reduces memory usage and the number of queries sent at a given time. - By limiting the number of items per query, you can avoid overwhelming both the Cloud Run instance and Firestore. - Why selected: This approach is optimal because it reduces the memory load on Cloud Run and minimizes the number of Firestore queries by efficiently paginating through the product list. Cursors are a best practice for handling large datasets and improving the performance of Firestore queries. Option B: Create a custom index over the products. - Reasoning: - Firestore automatically indexes fields for simple queries, but creating a custom index can improve performance for more complex queries. - However, creating a custom index would likely not address the root issue, which is memory usage caused by loading too many products at once. While indexing may improve query speed, it doesn’t address the problem of excessive memory consumption due to large result sets. - Why rejected: While indexing can improve the speed of specific queries, it doesn’t solve the...

Author: Benjamin · Last updated Jul 4, 2026

You are a developer at a large organization. Your team uses Git for source code management (SCM). You want to ensure that your team follows Google-recommended best practices to manage code t...

When choosing an SCM process, it's important to select a method that promotes collaboration, continuous integration, and delivery, while adhering to best practices for code management. Let's break down each option based on Google-recommended practices for high software delivery rates and team collaboration. Option A: Each developer commits their code to the main branch before each product release, conducts testing, and rolls back if integration issues are detected. - Reasoning: - This process commits directly to the main branch, which can introduce risks of breaking the main branch due to untested or incomplete code. - Testing is reactive, occurring after the commit, which means issues could go unnoticed until later stages, slowing down the release process. - Why rejected: Committing directly to the main branch before testing and without a more structured review process puts the stability of the main branch at risk. This approach doesn't align with modern continuous integration practices, which emphasize testing early and often. It also doesn't provide isolation for individual developer work. Option B: Each group of developers copies the repository, commits their changes to their repository, and merges their code into the main repository before each product release. - Reasoning: - This process involves creating copies of the repository (forking) for each developer or team, which can lead to unnecessary complexity and overhead. Merging only before a release introduces a large, potentially risky integration process that could cause conflicts or issues in the main branch. - Why rejected: Forking and merging before a product release is not efficient or effective in a fast-paced development environment. It introduces risks of integration failures and reduces the speed of feedback since merging large changes at the end creates bottlenecks. Continuous integration practices encourage smaller, more frequent merges to detect issues early. Option C: Each de...

Author: Aria · Last updated Jul 4, 2026

You have a web application that publishes messages to Pub/Sub. You plan to build new versions of the application locally and want to quickly test Pub/Sub int...

To determine the best option for local testing of Pub/Sub integration, let's analyze each option based on key factors such as ease of local setup, the need for using a local emulator versus a real cloud service, and how to configure your application for testing. Option A: Install Cloud Code on the integrated development environment (IDE). Navigate to Cloud APIs, and enable Pub/Sub against a valid Google Project ID. When developing locally, configure your application to call pubsub.googleapis.com. - Reasoning: This option involves using the actual Google Cloud Pub/Sub service, meaning the application communicates with the real cloud API. While this might seem straightforward, the significant drawback is that it requires internet access and potentially incurs costs for API usage. Also, this is not ideal for local development, as it might slow down iterations since each test needs to reach the cloud and you would rely on real infrastructure. - Rejected because: It’s not suitable for fast, local testing and development due to dependencies on cloud infrastructure and potential costs. Option B: Install the Pub/Sub emulator using gcloud, and start the emulator with a valid Google Project ID. When developing locally, configure your application to use the local emulator with `${gcloud beta emulators pubsub env-init}`. - Reasoning: This option uses the Pub/Sub emulator, which mimics the behavior of the real Pub/Sub API in a local environment. This is an excellent choice for quick testing and local development, as it doesn't require internet access or real Google Clo...

Author: Ishaan · Last updated Jul 4, 2026

Your ecommerce application receives external requests and forwards them to third-party API services for credit card processing, shipping, and inventory management as shown in the diagram. Your customers are reporting that your application is running slowly at unpredictable times. The...

To diagnose the cause of inconsistent performance in your ecommerce application, let's evaluate each of the options based on key factors like ease of implementation, ability to capture relevant metrics, and the ability to trace performance issues effectively. Option A: Install the OpenTelemetry library for your respective language, and instrument your application. - Reasoning: OpenTelemetry allows for detailed tracing and monitoring, providing insights into how requests are handled, where they are spent (e.g., credit card processing, shipping, inventory management), and identifying bottlenecks. By instrumenting your application, you can capture performance metrics at a fine-grained level, which helps in identifying slow requests or services that might be causing performance issues. - Selected because: This option is ideal for diagnosing the cause of inconsistent performance as it provides detailed observability at both the application and service level. It allows tracing of individual requests across the entire flow, identifying where time is being spent. Option B: Install the Ops Agent inside your container and configure it to gather application metrics. - Reasoning: The Ops Agent is designed to collect system-level metrics such as CPU, memory, disk usage, and network performance. While this can provide useful information about the overall health of the system, it does not give detailed insights into application-level performance or trace individual requests through the system. - Rejected because: While useful for gathering host-level metrics, it does not address the application-level performance issues or trace external API calls, which is crucial for diagnosing the root cause of inconsistent performance. Option C: Modify your application to read an...

Author: Ming · Last updated Jul 4, 2026

You are developing a new application. You want the application to be triggered only when a given file is updated in your Cloud Storage bucket. Your trigger might change, so your process must support different types of triggers. You want the configur...

To determine the best solution for your use case, let's evaluate each option based on ease of configuration, flexibility for future changes, and how well it supports triggering based on a file update in Cloud Storage. Option A: Configure Cloud Storage events to be sent to Pub/Sub, and use Pub/Sub events to trigger a Cloud Build job that executes your application. - Reasoning: This approach involves setting up Cloud Storage events to send notifications to a Pub/Sub topic, and then using Pub/Sub to trigger a Cloud Build job. While this setup can work, it introduces unnecessary complexity. Cloud Build is typically used for CI/CD workflows, not for directly handling application logic. This means you'd need to set up a Cloud Build configuration for each change in the file, which could make it harder to manage and scale for a simple file-update-triggered process. It also introduces a level of indirection with Pub/Sub and Cloud Build that could be overkill. - Rejected because: It introduces unnecessary complexity and overhead with Cloud Build when a simpler solution exists. Option B: Create an Eventarc trigger that monitors your Cloud Storage bucket for a specific filename, and set the target as Cloud Run. - Reasoning: Eventarc can be used to route events from Cloud Storage (or other sources) to different targets like Cloud Run. It's flexible and can handle different types of triggers (e.g., file updates, specific filename patterns) and route them to Cloud Run, where your application is hosted. Eventarc provides an abstraction for event routing that makes it easy to change triggers in the future, which is important for your requirement of changing triggers over time. This solution is highly scalable and fits well in serverless environments. - Selected because: It provides flexibility,...

Author: Ravi Patel · Last updated Jul 4, 2026

You are defining your system tests for an application running in Cloud Run in a Google Cloud project. You need to create a testing environment that is isolated from the production environment. You want to fully automate the creation of t...

To determine the best option for automating the creation of an isolated test environment in Google Cloud with minimal effort, we need to consider factors such as environment isolation, automation efficiency, ease of setup, and the ability to test without affecting the production environment. Option A: Using Cloud Build, execute Terraform scripts to create a new Google Cloud project and a Cloud Run instance of your application in the Google Cloud project. - Reasoning: This option proposes using Terraform to create an entirely new Google Cloud project, which provides full isolation between the production and testing environments. By creating a separate project, you ensure that the test environment is completely isolated from production. This method is ideal if you need complete isolation and control over the resources in the testing environment. - Rejected because: Although this ensures full isolation, it is more effort-intensive to set up and manage multiple projects. You would need to handle the creation, configuration, and teardown of an entire new project, which might be overkill for just testing. Managing multiple projects can also increase complexity when it comes to billing and resource management. Option B: Using Cloud Build, execute a Terraform script to deploy a new Cloud Run revision in the existing Google Cloud project. Use traffic splitting to send traffic to your test environment. - Reasoning: This option involves deploying a new revision of the application in the existing project and using traffic splitting to direct traffic to the test environment. It offers a simpler approach than creating a whole new project, as it utilizes the existing project and focuses only on isolating the environment within that project by using Cloud Run revisions and traffic splitting. Traffic splitting is a good strategy to control how much traffic goes to the test environment without affecting production traffic. - Se...

Author: Liam · Last updated Jul 4, 2026

You are a cluster administrator for Google Kubernetes Engine (GKE). Your organization's clusters are enrolled in a release channel. You need to be informed of relevant events that affect your G...

To determine the best solution for staying informed about relevant events that affect your Google Kubernetes Engine (GKE) clusters, we need to consider factors such as automation, ease of integration with other services, and the reliability of the notifications. Here's an analysis of the options: Option A: Configure cluster notifications to be sent to a Pub/Sub topic. - Reasoning: Configuring cluster notifications via Pub/Sub allows GKE to automatically send notifications about relevant events, such as available upgrades or security bulletins, to a Pub/Sub topic. This is a highly effective and automated solution for receiving real-time notifications about events affecting the cluster. The integration with Pub/Sub also allows you to set up further automation, like triggering workflows or alerting systems. - Selected because: This option provides real-time notifications and a robust, automated system for monitoring GKE events. It's easy to integrate with other systems like alerting services, logging, or automation pipelines. Option B: Execute a scheduled query against the google_cloud_release_notes BigQuery dataset. - Reasoning: The google_cloud_release_notes dataset contains release notes for various Google Cloud services, including GKE. Executing a scheduled query could provide you with detailed release notes, including information on available upgrades and security updates. However, this is a more indirect and manual approach compared to using automated notifications. It also requires maintaining a scheduled query ...

Author: Nia · Last updated Jul 4, 2026

You are tasked with using C++ to build and deploy a microservice for an application hosted on Google Cloud. The code needs to be containerized and use several custom software libraries that your team has built. You do not want to...

When considering how to deploy the microservice on Google Cloud, there are several factors to take into account, such as the need for infrastructure management, scalability, ease of deployment, and integration with custom software libraries. Let’s break down the options based on these considerations: Option A: Use Cloud Functions to deploy the microservice - Cloud Functions is a serverless platform that automatically manages infrastructure for you. It’s ideal for stateless functions that need to be executed in response to events. - Reason for rejection: Cloud Functions would require a significant redesign of the microservice to fit into a serverless, event-driven paradigm. Moreover, integrating custom libraries in Cloud Functions can be cumbersome, as there are specific runtime environments supported, and the libraries may not be easy to install or compatible. Cloud Functions is not suitable for running complex microservices that require specific dependencies and configurations. Option B: Use Cloud Build to create the container, and deploy it on Cloud Run - Cloud Build helps automate the process of building a container image from the source code and custom libraries. - Cloud Run is a fully managed platform for running containerized applications. It abstracts infrastructure management, allowing you to focus on the application itself. - Reason for selection: Cloud Run is a great choice for microservices as it handles scaling automatically and requires minimal management. Cloud Build simplifies the CI/CD pipeline to build your container image. Since Cloud Run can run Docker containers, it will easily integrate with your custom libraries and any dependencies. You don’t need to worry about maintaining the infrastructure, as Cloud Run automatically handles scaling, load balancing, and resource management. This option fits well for microservices that need flexibility in deployment without managing servers. Option C: ...

Author: Amira · Last updated Jul 4, 2026

You need to containerize a web application that will be hosted on Google Cloud behind a global load balancer with SSL certificates. You don't have the time to develop authentication at the application level, and you want to offload SSL encryption and management from ...

Let's break down the options based on the key factors: time to develop, managing SSL, and using managed services for simplicity and scalability. Option A: Host the application on Google Kubernetes Engine, and deploy an NGINX Ingress Controller to handle authentication - NGINX Ingress Controller can be used to manage routing, SSL termination, and authentication at the ingress level in Kubernetes. - Reason for rejection: While NGINX Ingress can be used to manage SSL and authentication, it requires configuring SSL certificates and authentication at the application level, which you don't want to develop yourself. NGINX can help with SSL offloading but would still require manual handling of authentication (like using JWTs or OAuth), which contradicts the requirement to avoid developing authentication. It also involves more management and custom configuration compared to fully managed services. Option B: Host the application on Google Kubernetes Engine, and deploy cert-manager to manage SSL certificates - cert-manager is a tool used within Kubernetes to automate the management and renewal of SSL certificates, integrating with Let's Encrypt or other certificate providers. - Reason for rejection: While cert-manager automates SSL management, it still requires Kubernetes management and does not offload the need for application-level authentication. In addition, cert-manager will require more configuration to integrate with your app compared to using fully managed services. Managing a Kubernetes cluster and certificates manually isn't the best fit when you prefer to avoid additional configuration and infrastructure management. Option C: Host the application on Compute Engine, and configure Cloud Endpoints for your application - Cloud Endpoints is a managed API gateway solution that can handle authentication, SSL certificates, ...

Author: ThunderBear · Last updated Jul 4, 2026

You manage a system that runs on stateless Compute Engine VMs and Cloud Run instances. Cloud Run is connected to a VPC, and the ingress setting is set to Internal. You want to schedule tasks on Cloud Run. You create a service account and grant it the roles/run.invoker Identity and Access Management (...

Let's break down the options based on the need to schedule tasks on Cloud Run, particularly given the 403 Permission Denied error encountered when testing the schedule. Option A: Grant the service account the roles/run.developer IAM role - Explanation: The `roles/run.developer` IAM role grants broader permissions, including the ability to create and manage Cloud Run services. However, this role does not directly address the problem of invoking a Cloud Run service. What you need for the service account is permission to invoke the Cloud Run service, which is already being granted by the `roles/run.invoker` IAM role. - Reason for rejection: Since the error is about invoking Cloud Run, the `roles/run.invoker` role should already be sufficient for invocation. Granting `roles/run.developer` is unnecessary and introduces excessive permissions, which is not ideal in terms of security principles. Option B: Configure a cron job on the Compute Engine VMs to trigger Cloud Run on schedule - Explanation: This option would involve manually setting up a cron job on Compute Engine VMs to invoke Cloud Run services. While this is a valid method for triggering Cloud Run on a schedule, it would introduce additional complexity and infrastructure management (i.e., the Compute Engine VMs). - Reason for rejection: This option goes against the goal of using managed services (like Cloud Run) for scheduling tasks. Adding a cron job on Compute Engine VMs introduces more infrastructure management, which complicates the setup and maintenance compared to using Cloud-native managed services like Cloud Scheduler. Option C: Change the Cloud Run ingress setting to 'Internal and Cloud Load Balancing' - Explanation: The Cloud Run ingress setting controls who can access the service....

Author: Rahul · Last updated Jul 4, 2026

You work on an application that relies on Cloud Spanner as its main datastore. New application features have occasionally caused performance regressions. You want to prevent performance issues by running an automated performance test with Cloud Build for each c...

When considering the best approach for automating performance tests using Cloud Build for each commit made to an application relying on Cloud Spanner, there are key factors to consider: efficiency, cost, data consistency, and isolation of tests. Let’s break down the options: Option A: Create a new project with a random name for every build. Load the required data. Delete the project after the test is run. - Explanation: This option suggests creating a completely new project for every build, along with the associated data, and deleting the project afterward. - Reason for rejection: Creating and deleting entire projects for each build is an inefficient approach. It involves unnecessary overhead in project creation and deletion, which could be slow and costly. The time spent provisioning and cleaning up the entire project would likely outweigh the benefits. Additionally, this approach can complicate resource management and does not provide an efficient way to manage Cloud Spanner data consistency. Option B: Create a new Cloud Spanner instance for every build. Load the required data. Delete the Cloud Spanner instance after the test is run. - Explanation: This option suggests creating a new Cloud Spanner instance for each test, loading the data, and deleting the instance afterward. - Reason for rejection: While this option isolates each test in its own Cloud Spanner instance, it is inefficient and costly. Cloud Spanner instances are not lightweight, and frequently creating and deleting instances would incur significant costs and time delays, especially if you're running multiple commits at the same time. The time required to provision instances and load data is too high for efficient automated testing. Option C: Create a project with a Cloud Spanner instance and the required data. Adjust the Cloud Build build file to automatically restore the data to its previous state after the...

Author: ElectricLionX · Last updated Jul 4, 2026

Your company's security team uses Identity and Access Management (IAM) to track which users have access to which resources. You need to create a version control system that can integrate with your security team's processes. You want your solution to suppor...

When considering the best version control strategy for integration with your security team's processes, and balancing fast release cycles, frequent merges, and minimizing merge conflicts, let’s break down each option: Option A: Create a Cloud Source Repositories repository, and use trunk-based development - Cloud Source Repositories is a fully managed Git repository by Google Cloud, which integrates well with other Google Cloud services and IAM for access control. - Trunk-based development involves developers frequently committing small changes to the main branch (trunk) to avoid long-lived feature branches and minimize merge conflicts. This strategy encourages rapid integration and minimizes divergence from the main branch. - Reason for selection: Using trunk-based development with Cloud Source Repositories is ideal for fast release cycles and minimizing merge conflicts because it ensures that changes are continuously integrated into the main branch, reducing long-lived branches and divergent code. Furthermore, Cloud Source Repositories can be easily managed using IAM policies for access control, making it a good fit for your company's security team’s processes. Option B: Create a Cloud Source Repositories repository, and use feature-based development - Feature-based development involves creating branches for each new feature, which can lead to longer-lived branches and potential merge conflicts when these branches are merged back into the main branch. - Reason for rejection: While feature-based development can be useful for isolated work, it tends to cause more merge conflicts, especially with frequent merges. It can also slow down the release cycle as features are developed separately and merged later, which goes against the goal of fast release cycles and reducing merge conflicts. Option C: Create a GitHub repository, mirror it to a Cloud Source ...

Author: Rohan · Last updated Jul 4, 2026

You recently developed an application that monitors a large number of stock prices. You need to configure Pub/Sub to receive messages and update the current stock price in an in-memory database. A downstream service needs the most up-to-date prices in the in-memory database to perform stock trading transactions. Each message contai...

To configure Pub/Sub for monitoring stock prices and updating the in-memory database, you need to select the appropriate subscription type based on the requirements of message delivery, ordering, and transactional consistency. Let's evaluate each option: Option A: Create a push subscription with exactly-once delivery enabled. - Exactly-once delivery ensures that each message is delivered and processed only once, preventing duplicate processing. - Push subscriptions send messages to a predefined HTTP endpoint, which can be beneficial if you want the system to automatically push data to your service. Why it's not ideal: - Push subscriptions are typically used when you want the system to automatically send messages to a predefined HTTP endpoint, but in this case, the stock price updates need to be processed and stored in an in-memory database. Using push can add complexity in handling the incoming requests. - Exactly-once delivery might be overkill if you're more concerned with ordering and message processing speed than ensuring no duplicates. Rejecting this option: While useful for ensuring no duplicates, the push method could add overhead in the processing pipeline, especially when dealing with high-frequency updates like stock prices. Option B: Create a pull subscription with both ordering and exactly-once delivery turned off. - Pull subscriptions require the service to request messages from the Pub/Sub system, providing more control over when and how messages are processed. - No ordering or exactly-once delivery means messages may be processed out of order, and there might be a risk of duplicates. Why it's not ideal: - In this scenario, you want to ensure that stock prices are processed in the correct order (latest stock price update for each stock symbol). - Without ordering, updates to the same stock symbol might arrive out of order, which is critical for your use case, where the most recent price must be used for trading decisions. ...

Author: Maya · Last updated Jul 4, 2026

You are a developer at a social media company. The company runs their social media website on-premises and uses MySQL as a backend to store user profiles and user posts. Your company plans to migrate to Google Cloud, and your learn will migrate user p...

When designing Firestore collections for a social media application that needs to store user profiles and user posts, the structure of your collections and documents is critical for performance, scalability, and ease of access. Let's evaluate the options based on Firestore best practices. Option A: Create one root collection for user profiles, and create one root collection for user posts. - This option creates two independent root collections: one for user profiles and one for user posts. Why it's not ideal: - Access patterns: If a user’s profile and posts need to be accessed together frequently (e.g., when displaying the user's profile along with their posts), this structure would require separate queries to both collections, leading to inefficiency in some use cases. - Firestore querying limitations: Firestore doesn’t support joins or complex queries across multiple root collections. Therefore, accessing a user’s profile and posts together might lead to multiple queries or complex client-side logic. Rejecting this option: This structure could lead to performance inefficiencies when trying to access both the user profile and their posts together frequently. Option B: Create one root collection for user profiles, and create one subcollection for each user's posts. - This approach stores user profiles in a root collection and uses subcollections for each user's posts. Why this is ideal: - Hierarchical structure: It follows Firestore’s hierarchical data model and aligns with the use case of associating posts with specific users. It also scales better since Firestore is designed to efficiently handle subcollections. - Efficient access: If you need to access a user’s profile and their posts together, you can first fetch the user’s profile document and then access the posts subcollection. Firestore provides efficient querying on subcollections and you can retrieve only the required data. - Scalability: Firestore scales better with subcollections because the system can handle large numbers of subcollection documents independently from the parent document, reducing the risk of hitting document size limits in the root collection. This is the best option because it provides a...

Author: Vikram · Last updated Jul 4, 2026

Your team recently deployed an application on Google Kubernetes Engine (GKE). You are monitoring your application and want to be alerted when the average memory consumption of yo...

When configuring alerts for memory consumption in a Kubernetes environment (like on Google Kubernetes Engine, GKE), you want a solution that is both efficient and integrated with GKE’s native monitoring and alerting tools. Let's evaluate each option: Option A: Create a Cloud Function that consumes the Monitoring API. Create a schedule to trigger the Cloud Function hourly and alert you if the average memory consumption is outside the defined range. - Cloud Function + Monitoring API: While using a Cloud Function to consume the Monitoring API is technically feasible, it would add unnecessary complexity. You’d need to write custom logic to periodically fetch memory consumption data, handle the scheduling, and trigger alerts if certain thresholds are exceeded. Why it's not ideal: - Overengineering: The use of Cloud Functions for periodic checks is an overly complex approach, given that Cloud Monitoring already provides native alerting functionality. - Maintenance overhead: You would need to handle error conditions, manage scheduling, and ensure the Cloud Function runs reliably. This adds unnecessary complexity for a task that can be done directly within Cloud Monitoring. Rejecting this option: There’s no need to build custom Cloud Functions for this use case when Google Cloud provides a native solution (Cloud Monitoring). Option B: In Cloud Monitoring, create an alerting policy to notify you if the average memory consumption is outside the defined range. - Cloud Monitoring: This is the most straightforward and optimal approach. Cloud Monitoring integrates directly with GKE and allows you to define alerting policies based on specific metrics like memory usage. Why this is ideal: - Built-in functionality: Cloud Monitoring is designed to work seamlessly with GKE. It provides easy access to metrics like memory consumption, and you can create alerts directly within the console. - Efficient alerting: You can set thresholds for memory consumption (such as 20% and 80%) and configure notifications (via email, SMS, or other methods) when these thresholds are exceeded. - No need for additional infrastructure: This option leverages Google Cloud’s native tools without requiring any custom code, making it easy to configure, manage, and scale. This is the best ...

Author: Emily · Last updated Jul 4, 2026

You manage a microservice-based ecommerce platform on Google Cloud that sends confirmation emails to a third-party email service provider using a Cloud Function. Your company just launched a marketing campaign, and some customers are reporting that they have not received order confirmation emails. You discover that the services trigge...

When dealing with the issue of failed email deliveries and HTTP 500 errors from your Cloud Function, it’s essential to focus on minimizing the risk of losing email data while ensuring that the system remains resilient and reliable. Let's analyze the options: Option A: Increase the Cloud Function's timeout to nine minutes. - Cloud Function Timeout: The default timeout for Cloud Functions is 60 seconds, but it can be increased up to 9 minutes (540 seconds). Increasing the timeout would allow the function to run longer if the email service provider is slow to respond. Why it's not ideal: - Unsolved underlying issue: Increasing the timeout does not address the root cause of the 500 errors, which may be caused by the email service or an issue in the Cloud Function itself. If the email provider or function experiences issues, increasing the timeout won't prevent future failures. - Timeouts aren't always effective: If the third-party email service is unreliable, simply waiting longer will not solve the problem. This could potentially increase system latency, and it doesn't provide a mechanism to retry or recover from failures. Rejecting this option: It is better to address the reliability of the email process itself rather than simply increasing timeouts. Option B: Configure the sender application to publish the outgoing emails in a message to a Pub/Sub topic. Update the Cloud Function configuration to consume the Pub/Sub queue. - Pub/Sub for Email Queuing: This option involves publishing the email requests to a Pub/Sub topic, which decouples the email sending process from the original triggering application. The Cloud Function would then consume messages from the Pub/Sub topic to send emails. Why this is ideal: - Decoupling: By using Pub/Sub, you create an asynchronous, fault-tolerant message queue. This ensures that even if the Cloud Function fails or the email service provider is temporarily unavailable, the email requests are not lost and can be retried later. - Retry Mechanism: Pub/Sub allows for built-in retries and dead-letter queues, which means failed messages can be retried or sent to a separate queue for further investigation, reducing the risk of email loss. - Scalability: Pub/Sub scales automatically and ensures that messages are processed reliably. It also allows for a more resilient system that can handle intermittent failures without loss of data. This is the best option because it introduces resilienc...

Author: Arjun · Last updated Jul 4, 2026

You have a web application that publishes messages to Pub/Sub. You plan to build new versions of the application locally and need to quickly test Pub/Sub int...

When configuring local testing for Pub/Sub integration, it’s important to consider how you can test the application without interacting with the actual Google Cloud services, ensuring fast feedback and minimizing costs. Let's evaluate each option: Option A: In the Google Cloud console, navigate to the API Library, and enable the Pub/Sub API. When developing locally configure your application to call pubsub.googleapis.com. - Explanation: This option involves enabling the Pub/Sub API in the Google Cloud console and configuring your local application to connect to the actual Google Cloud Pub/Sub service via `pubsub.googleapis.com`. Why it's not ideal: - Cost and Latency: Every message sent or received will interact with the actual cloud service, which can incur costs, especially during frequent testing with many new builds. This is less efficient for local development, where you typically want to test without connecting to the live environment. - Slower feedback: Testing with the actual cloud service may introduce latency and slow down the local testing process, which is counterproductive when trying to quickly test new builds. - Not optimized for local testing: Pub/Sub is a managed service, and direct interaction can be slow and costly for frequent local tests. Rejecting this option: This approach is better suited for production environments, not for quick local testing during development. Option B: Install the Pub/Sub emulator using gcloud, and start the emulator with a valid Google Project ID. When developing locally, configure your application to use the local emulator by exporting the PUBSUB_EMULATOR_HOST variable. - Explanation: This option suggests using the Pub/Sub emulator, which is a local version of the Google Cloud Pub/Sub service. The emulator can be started using the `gcloud` command, and your application can be configured to point to this local emulator by setting the `PUBSUB_EMULATOR_HOST` environment variable. Why this is ideal: - Local testing: The Pub/Sub emulator allows for testing Pub/Sub integration locally without needing to interact with the actual cloud service. This eliminates latency and costs associated with making real calls to the cloud service. - Fast feedback: Since the emulator runs locally, you get near-instant feedback when testing new builds, making it much faster than interacting w...

Author: Lucas · Last updated Jul 4, 2026

You recently developed an application that monitors a large number of stock prices. You need to configure Pub/Sub to receive a high volume messages and update the current stock price in a single large in-memory database. A downstream service needs the most up-to-date prices in the in-memory database to perform stock trading transactions. Each messa...

When setting up your Pub/Sub subscription for high-volume stock price updates, the goal is to ensure that your system can efficiently receive messages, keep the stock prices current in an in-memory database, and handle potential issues like message duplication or ordering. Let's analyze each option: A) Create a pull subscription with exactly-once delivery enabled. - Exactly-once delivery guarantees that each message is processed once and only once, which is crucial when updating stock prices to avoid duplicates. However, this could introduce latency, especially with high-volume stock price updates, as it ensures no duplicates are processed at the cost of performance. - Pull subscription requires your system to repeatedly pull messages from Pub/Sub, which can lead to inefficiency if you need to constantly poll for updates. This can also result in delay between receiving and processing messages. - Downside: Pulling can become slower or inefficient when there’s a large volume of messages coming in at a high rate, as you have to manage the polling and processing rate, potentially causing backlogs. B) Create a push subscription with both ordering and exactly-once delivery turned off. - Push subscription pushes messages directly to your service, ensuring that you don’t have to poll for updates, which can reduce the delay between receiving and processing the messages. However, with ordering and exactly-once delivery turned off, you might face issues with message duplication or out-of-order delivery. - Downside: Stock prices could potentially arrive out of order, and you could have duplicate messages. This might be acceptable if the application can handle occasional duplication or reordering without critical issues, but for stock trading,...

Author: ThunderBear · Last updated Jul 4, 2026

Your team has created an application that is hosted on a Google Kubemetes Engine (GKE) cluster. You need to connect the application to a legacy REST service that is deployed in two GKE clusters in two different regions. You want to connect your application to the legacy service in a way that is resilient and requires the fewest number of steps. Y...

To connect your application in Google Kubernetes Engine (GKE) to a legacy REST service deployed in two GKE clusters in different regions, the solution should meet these key requirements: 1. Resilience – The solution must ensure high availability across regions, so if one region goes down, traffic can be routed to the other region. 2. Health checks – You need to perform health checks on the legacy service to ensure that traffic is only sent to healthy instances of the service. 3. Minimum steps – The setup should be as simple as possible while achieving the necessary resilience and monitoring. Let's evaluate the options in detail: A) Use Traffic Director with a sidecar proxy to connect the application to the service. - Traffic Director is a fully managed traffic management solution for microservices that provides traffic routing, load balancing, and failover. Using a sidecar proxy with Traffic Director helps in achieving resilience across multiple regions, and it supports features like load balancing and health checks. - The sidecar proxy can run in your application’s pods and handle traffic routing, while Traffic Director ensures intelligent routing between services across regions. - Why selected: This option provides resilience by intelligently routing traffic across the two regions and includes built-in health checks, which can be customized to run on a separate port. This setup is highly available, scalable, and requires minimal configuration once Traffic Director and the sidecar proxies are set up. B) Set up a proxyless Traffic Director configuration for the application. - Proxyless means that no sidecar proxies are deployed in the application pods. While Traffic Director would still manage traffic routing and load balancing, the absence of a sidecar proxy means that features like fine-grained traffic management, service discovery, and health checks become more challenging to implement. - Why rejected: Proxyless configurations are typically used for applications that don’t require the level of observability or traffic management that sidecar proxies provide. For health checks and resilience across regions, this would not be as effective or easy to manage as with sidecars. C) Configure the legacy service's firewall to allow health checks originating f...

Author: David · Last updated Jul 4, 2026

You are monitoring a web application that is written in Go and deployed in Google Kubernetes Engine. You notice an increase in CPU and memory utilization. You need to determine whic...

To determine which functions in your Go-based web application are consuming the most CPU and memory resources, the best approach will depend on tools and strategies for profiling and monitoring. Let’s analyze each option based on this context: A) Add print commands to the application source code to log when each function is called, and redeploy the application. - Why rejected: Adding print statements would give you basic logging, but this approach is inefficient and error-prone. It would not provide a detailed view of resource utilization, and you'd have to analyze logs manually. This method doesn't give a clear or precise understanding of CPU and memory usage, and redeploying frequently for changes like this can also be cumbersome and time-consuming. It's also not ideal for identifying specific functions that are resource-intensive. B) Create a Cloud Logging query that gathers the web application's logs. Write a Python script that calculates the difference between the timestamps from the beginning and the end of the application's longest functions to identify time-intensive functions. - Why rejected: While Cloud Logging can capture logs, and using a script might help in some scenarios, this approach lacks precision and efficiency for tracking CPU and memory usage. It is based on the timestamps of function execution, which does not directly correlate with resource consumption like CPU or memory. CPU and memory profiling require more targeted tools and methods to measure resource usage, not just execution times. C) Import OpenTelemetry and Trace export packages into your application, and create the trace provider. Review the latency d...

Author: David · Last updated Jul 4, 2026

You are developing a flower ordering application. Currently you have three microservices: * Order Service (receives the orders) * Order Fulfillment Service (processes the orders) * Notification Service (notifies the customer when the order is filled) You need to determine how the services will communicate with each other. You want incoming orders to be processed quickly and you need to collect order in...

Author: Liam · Last updated Jul 4, 2026

You recently deployed an application to GKE where Pods are writing files to a Compute Engine persistent disk. You have created a PersistentVolumeClaim (PVC) and a PersistentVolume (PV) object on Kubernetes for the disk, and you reference the PVC in the deployment manifest file. You recently expanded the size of the persistent disk because the application has used up almost a...

In this scenario, the goal is to make sure that the expanded disk size is visible to the application Pods running in Google Kubernetes Engine (GKE). When you increase the size of a persistent disk in Google Cloud, you also need to ensure that Kubernetes recognizes the new size and allows the Pods to access the additional space. Let’s evaluate the options: A) Set the spec.capacity.storage value of the PV object to match the size of the persistent disk. Apply the updated configuration by using kubectl. - Why rejected: The `spec.capacity.storage` value of the PersistentVolume (PV) specifies the total size of the volume. However, updating this field in the PV object does not trigger an automatic resize of the volume. The actual size of the persistent disk is managed by Google Cloud, and Kubernetes does not automatically resize the file system inside the Pod just by changing the PV object. The PV configuration itself does not dynamically adjust the disk partitions or file system to reflect the new size. B) Recreate the application Pods by running the kubectl delete deployment DEPLOYMENT_NAME && kubectl apply deployment.yaml command, where the DEPLOYMENT_NAME parameter is the name of your deployment and deployment.yaml is its manifest file. - Why rejected: Recreating the Pods alone will not automatically resize the disk within the container. While deleting and recreating Pods can cause Kubernetes to remount the PersistentVolume (PV), it does not resize the underlying disk partition or file system. This action does not resolve the issue of the disk expansion not being visible inside the Pods. Simply recreating Pods doesn't trigger the necessary disk r...

Author: Kai99 · Last updated Jul 4, 2026

You work for an ecommerce company. You are designing a new Orders API that will be exposed through Apigee. In your Apigee organization, you created two new environments named orders-test and orders-prod. You plan to use unique URLs named test.lnk-42.com/api/v1/orders and Ink-42.com/a...

Let's break down each option and analyze them based on the requirement to ensure that each environment only uses the assigned URL. Option A: Steps: 1. Attach orders-test and orders-prod to the orders environment group. 2. Add each hostname to the appropriate environment. Analysis: - The first step, attaching both orders-test and orders-prod to the orders environment group, is too generic and doesn’t clearly associate the environments with specific URLs. The environment group should represent a broader scope, but separating the environments (test and prod) based on their respective URLs is important. - The second step, adding each hostname to the appropriate environment, is correct in the sense of assigning URLs to environments, but the grouping of both test and prod into one environment group can lead to confusion or misconfigurations. Why it's rejected: This option creates a lack of clarity between test and production environments because both environments are attached to a single "orders" group. Option B: Steps: 1. Attach orders-test and orders-prod to the orders environment group. 2. Add each hostname to the orders environment group. Analysis: - Similar to Option A, attaching both orders-test and orders-prod to the same orders environment group doesn’t properly isolate the environments. - The environment group here is not helpful in segregating test and production traffic or configurations. - Adding both hostnames to the same environment group makes it challenging to enforce different policies or behavior for test versus production environments. Why it's rejected: Again, this lacks proper isolation between the test and production environments. Hostnames should ideally be attached to distinct environment groups to avoid misconfigurations. Option C: Steps: 1. Attach orders-test to the test environment group, and attach orders-prod to the production environment group. 2. Add e...

Author: Zara · Last updated Jul 4, 2026

You are developing an application that uses microservices architecture that includes Cloud Run, Bigtable, and Pub/Sub. You want to conduct the testing and debugging process as quickly as po...

Let's break down each option to understand how it would contribute to testing and debugging in a microservices architecture while minimizing costs and improving development speed: Option A: Steps: - Use Cloud Shell Editor and Cloud Shell to deploy the application. - Test the functionality by using the Google Cloud console in the project. Analysis: - Cloud Shell is a free, browser-based terminal that provides easy access to Google Cloud resources. It’s useful for managing cloud resources directly. - Cloud Shell Editor gives you an integrated development environment (IDE) for working on code in the cloud, which simplifies the deployment and testing process. - However, testing by using the Google Cloud console alone can be cumbersome and doesn’t directly support local testing of your cloud services like Pub/Sub or Bigtable. - This option could lead to higher costs if you deploy too many resources for testing because there's no focus on reducing the number of cloud resources during development. Why it's rejected: While Cloud Shell and the Cloud Console can be useful, they don't support local testing of cloud resources, making this method less efficient for testing microservices, especially when you're trying to minimize costs and speed up testing. Option B: Steps: - Use emulators to test the functionality of cloud resources locally. - Deploy the code to your Google Cloud project. Analysis: - Using emulators allows you to run Google Cloud resources like Pub/Sub and Bigtable locally, which helps with fast iteration and lower costs because you don't need to provision actual cloud resources for local testing. - Emulators simulate cloud resources locally, allowing for easier testing without incurring the full cost of using cloud services, especially important in early stages of development. - Once the code works locally, you can deploy it to Google Cloud for full testing, which provides a good balance of cost reduction and functionality validation. Why it's a good option: Emulators are well-suited for minimizing cost during development. They help in local testing, allowing for faster debugging and testing without using cloud resources, which can be expensive. Why it’s not the best option: Emulators might not fully replicate cloud behavior, especially under scale, and may not be ideal for testing how services interact at a larger scale on...

Author: Ravi Patel · Last updated Jul 4, 2026

You are a lead developer at an organization that recently integrated several Google Cloud services. These services are located within Virtual Private Cloud (VPC) environments that are secured with VPC Service Controls and Private Service Connect endpoints. Developers across your organization use different operating systems, development frameworks, and integrated development environments (IDEs). You need to recommend a developer environment that will ensure consistency in the developer process and improve the overall developer experience. You want this solution to:...

Let's analyze each option to find the best solution for enforcing consistent security controls, providing access to Google Cloud resources and applications within the VPC, and allowing the installation of custom tools and utilities in the development environments. Option A: Steps: - Use Cloud Workstations and allow developers to create their own custom images. Analysis: - Cloud Workstations provide fully managed, customizable cloud environments for development, which is a great choice for consistency. - Allowing developers to create their own custom images gives flexibility and allows them to install tools and utilities specific to their needs. - However, this approach may lead to inconsistencies in the developer environments, as each developer could create slightly different images. - Managing and enforcing consistent security controls and ensuring VPC access could be harder if the developers have too much flexibility. Why it's rejected: While flexible, allowing each developer to create custom images could lead to inconsistencies in both security and setup. It would also be harder to enforce strict security standards. Option B: Steps: - Use Cloud Workstations with preconfigured base images. - For custom tools and utilities, use custom images that are rebuilt weekly. Analysis: - Cloud Workstations with preconfigured base images ensure a standardized environment for all developers. This approach enforces consistency and simplifies security controls, as the base images can be tightly controlled. - Allowing the installation of custom tools and utilities via weekly rebuilt custom images ensures that developers can still have the flexibility to install necessary tools without compromising consistency. - This solution strikes a balance between flexibility and control, ensuring a secure, consistent environment that is also adaptable to developer needs. Why it's a good option: This solution offers a good balance of security and flexibility. Preconfigured base images ensure consistency and security, while weekly rebuilt custom images allow for necessary changes without deviating from the overall standard. Why it's not perfect: This approach requires more management to ensure the custom images are updated on a regular basis, which could be an additional overhead. Option C: Steps: - Use the Cloud Code extension with the IDEs that are used across the...

Author: Ahmed97 · Last updated Jul 4, 2026

You are preparing to conduct a load test on your Cloud Run service by using JMeter. You need to orchestrate the steps and services to use for an effective load test and ana...

Let's analyze each option carefully to understand the best approach for conducting a load test on Cloud Run services while following Google-recommended practices. Option A: Steps: - Install JMeter on your local machine. - Create a log sink to BigQuery. - Use Looker to analyze the results. Analysis: - Running JMeter locally for a load test is generally not recommended for large-scale load tests, especially with services like Cloud Run, because your local machine may not have enough resources to generate the required traffic efficiently. - While creating a log sink to BigQuery is a good idea for storing logs, analyzing load test results directly through Looker from BigQuery can be more complex and require custom setup. - The primary issue is that using a local machine for load testing doesn't scale well for large tests, which is essential for testing cloud-based services like Cloud Run. Why it's rejected: The local machine will likely become a bottleneck, making this approach unsuitable for large or effective load testing. Also, the analysis through Looker would require extra setup and complexity for this scenario. Option B: Steps: - Set up a Compute Engine instance, install JMeter on the instance. - Create a log sink to a Cloud Storage bucket. - Use Looker Studio to analyze the results. Analysis: - A Compute Engine instance gives you better scalability than running JMeter locally, but Cloud Storage is not typically the best choice for log sinks when doing performance analysis. Logs in Cloud Storage are static, and retrieving them for detailed analysis could be cumbersome. - While Looker Studio is useful for data visualization, the initial choice of Cloud Storage adds extra steps to access and process logs for analysis. - The choice of Cloud Storage for logging might not be optimal for a detailed, structured analysis of load test results, which would benefit from more direct querying and aggregation. Why it's rejected: Using Cloud Storage adds unnecessary complexity for log aggregation and analysis. The logs would need to be manually retrieved and processed for analysis, making this option less efficient for load testing. Option C: Steps: - Set up a Compute Engine instance, install JMeter on the i...

Author: Grace · Last updated Jul 4, 2026

You are designing a Node.js-based mobile news feed application that stores data on Google Cloud. You need to select the application's database. You want the database to have zonal resiliency out of the box, low latency responses, ACID compliance, an optional middle tier...

Let's evaluate each option carefully to determine the best database for your Node.js-based mobile news feed application, considering the specified requirements. Requirements Breakdown: 1. Zonal resiliency out of the box: The database should be resilient to zonal failures without requiring manual configurations. 2. Low latency responses: The database should provide fast, low-latency reads and writes for mobile users. 3. ACID compliance: The database should support ACID transactions, ensuring data consistency and reliability. 4. Optional middle tier: The ability to have a middle layer or logic between the app and the database, if necessary. 5. Semi-structured data storage: The database should support flexible, schema-less storage for semi-structured data (e.g., JSON). 6. Network-partition-tolerant and offline-mode client libraries: The client library should support offline functionality and handle network partitions, enabling the app to continue functioning even in the case of network disruptions. Option A: Configure Firestore and use the Firestore client library in the app. Analysis: - Firestore is a NoSQL database designed for building mobile and web applications, providing zonal resiliency by default and replication across multiple regions in a region. It also supports offline mode for mobile apps, allowing them to continue functioning when there is no network connectivity. - It supports semi-structured data storage with flexible document models (JSON-like documents), which is a good fit for your application’s requirements. - Firestore also provides ACID transactions for ensuring data consistency and reliability. - The Firestore client library is built with network-partition tolerance in mind, handling offline scenarios and syncing data when the connection is restored. - Firestore is a strong option for low-latency responses due to its optimized architecture for mobile apps, with built-in replication and automatic scaling. Why it's selected: Firestore fits all of your requirements, especially for mobile applications that require offline support, zonal resiliency, low latency, semi-structured data, and ACID compliance. It's highly recommended for mobile apps with these characteristics. Option B: Configure Bigtable and use the Bigtable client in the app. Analysis: - Bigtable is a NoSQL database designed for large-scale, high-throughput workloads, typically used for time-series data, IoT, and large datasets. It is highly scalable and provides low-latency responses, but it does not support ACID transactions, which are required for your app. - Bigtable is not a good fit for semi-structured data as it ...

Author: Liam · Last updated Jul 4, 2026

You are developing an application component to capture user behavior data and stream the data to BigQuery. You plan to use the BigQuery Storage Write API. You need to ensure that the data that arrives in BigQuery does not have a...

To ensure that user behavior data arriving in BigQuery does not have any duplicates while using the BigQuery Storage Write API, we need to assess the available options based on simplicity, scalability, and the ability to handle duplicates effectively. Let's review each option: A) Create a write stream in the default type. - Explanation: The default type of the write stream in the BigQuery Storage Write API allows data to be written directly to BigQuery, but it does not guarantee that duplicates are avoided. - Why it’s rejected: This approach does not inherently provide any mechanisms for deduplication. Therefore, it doesn't meet the requirement of ensuring that the data has no duplicates. B) Create a write stream in the committed type. - Explanation: The committed write stream type in BigQuery Storage Write API ensures that data is written in a durable and consistent way. Once data is written to BigQuery, it is committed and cannot be overwritten. - Why it’s rejected: While it guarantees that data is written once and only once, it does not inherently provide a mechanism for deduplication. It’s useful for ensuring atomicity, but does not directly prevent duplicate records if they are sent multiple times. C) Configure a Kafka cluster. Use a primary universally unique identifier (UUID) for duplicate messages. - Explanation: Kafka is a distributed event streaming platform, and using a UUID for each message ensures uniqueness, making it a good option to detect and prevent duplicates. Each message can be tracked using its UUID. - Why it’s rejected: While using UUIDs can be effective in identifying dupli...

Author: Olivia Johnson · Last updated Jul 4, 2026

You maintain a popular mobile game deployed on Google Cloud services that include Firebase, Firestore, and Cloud Functions. Recently, the game experienced a surge in usage, and the application encountered HTTP 429 RESOURCE_EXHAUSTED errors when accessing the Firestore API. The application has now stabilized. You want to...

To resolve the HTTP 429 RESOURCE_EXHAUSTED errors in your application and ensure it can handle future surges in usage, let's analyze each option carefully. A) Request a quota increase, and modify the application code to retry the Firestore API call with fixed backoff. - Explanation: Requesting a quota increase would provide more capacity to handle increased traffic. Modifying the application code to retry with fixed backoff means that, in the case of failure, the retry times are constant (i.e., the delay between retry attempts does not change). - Why it’s rejected: Fixed backoff is not ideal for handling high traffic surges. A fixed backoff may lead to unnecessary repeated attempts in cases of high load, which could cause further congestion and degrade performance. It is not as efficient as exponential backoff, which scales better for bursty traffic and reduces the chance of overwhelming the service with retries. B) Request a quota increase, and modify the application code to retry the Firestore API call with exponential backoff. - Explanation: Requesting a quota increase will raise the capacity of the Firestore API to handle more requests, while exponential backoff ensures that retry attempts gradually increase the time between retries (e.g., the first retry is at 1 second, the next at 2 seconds, then 4, and so on). This prevents a flood of retry attempts and reduces strain on the system, which is particularly beneficial in high-traffic scenarios. - Why it’s selected: Exponential backoff is best suited for high-traffic or bursty usage patterns, such as during a marketing campaign, as it provides a more controlled retry mechanism. It allows the system to intelligently manage load by spacing out retry attempts, which is essential in avoiding further 429 errors while ...

Author: BlazingPhoenix22 · Last updated Jul 4, 2026

You are developing a mobile application that allows users to create and manage to-do lists. Your application has the following requirements: * Store and synchronize data between different mobile devices. * Support offline access. * Provide real-time updates on each user's ...

To determine the best approach for your mobile application, let's evaluate each option based on the requirements: storing and synchronizing data across different devices, supporting offline access, and providing real-time updates, while minimizing operational effort. A) Create a Cloud SQL for MySQL instance. Implement a data model to store to-do list information. Create indexes for the most heavily and frequently used queries. - Explanation: Cloud SQL is a fully managed relational database, suitable for transactional data. It supports SQL-based queries and indexes for efficient data retrieval. - Why it’s rejected: While Cloud SQL can store and synchronize data, it doesn't provide native support for real-time updates or offline access. Implementing offline functionality and real-time synchronization would require additional custom development, increasing operational complexity. For real-time updates, you'd likely need to use websockets or polling, which increases effort. Thus, this solution doesn't meet the operational-effort minimization goal and is more suited for structured transactional applications rather than a mobile app with the mentioned requirements. B) Create a Bigtable instance. Design a database schema to avoid hotspots when writing data. Use a Bigtable change stream to capture data changes. - Explanation: Bigtable is a distributed NoSQL database designed for scalability and high throughput. It's ideal for storing large amounts of time-series or structured data. Bigtable change streams can be used for capturing and streaming updates. - Why it’s rejected: Bigtable is primarily designed for high-performance, large-scale analytics or operational workloads, not for real-time data synchronization across mobile devices. The complexity of managing Bigtable, handling schema design to avoid hotspots, and integrating change streams for real-time updates adds significant operational overhead. Additionally, Bigtable doesn’t provide native offline support, so a custom solution would be needed for offline access. It's overkill for the use case, as it's more suited for big data and analytics scenarios. C) Use Firestore as the database. Configure Firestore offline persistence to cache a copy of the Firestore data. Listen to ...

Author: GlowingTiger · Last updated Jul 4, 2026

You manage an application deployed on GKE clusters across multiple environments. You are using Cloud Build to run user acceptance testing (UAT) tests. You have integrated Cloud Build with Artifact Analysis, and enabled the Binary Authorization API in all Google Cloud projects hosting your environments. You want only container images that h...

To meet the goal of ensuring only container images that have passed automated UAT tests are deployed to the production environment, you need to sign the image with an attestation after successful UAT and configure Binary Authorization to enforce this attestation before deploying to production. Let's review each option carefully. A) After the UAT phase, sign the attestation with a key stored as a Kubernetes secret. Add a GKE cluster-specific rule in Binary Authorization for the UAT Google Cloud project. - Explanation: This option suggests signing the attestation with a key stored as a Kubernetes secret and adding a GKE cluster-specific rule in the UAT project. However, this is not ideal because the goal is to enforce the attestation during deployment to production, not within the UAT environment itself. - Why it’s rejected: The rule should be added to the production environment, as it’s important to ensure only images that pass UAT are deployed to production. Adding the rule to the UAT environment doesn't enforce control over what is deployed to production. B) After the UAT phase, sign the attestation with a key stored as a Kubernetes secret. Add a GKE cluster-specific rule in Binary Authorization for the production Google Cloud project policy. - Explanation: This option involves signing the attestation with a key stored as a Kubernetes secret and adding the rule to the production environment. While this ensures that only images passing UAT are deployed to production, using a key stored as a Kubernetes secret for signing isn't ideal because it could create challenges in managing security and access control. - Why it’s rejected: Using a Kubernetes secret to store the signing key isn't the best practice for managing cryptographic keys at scale. Kubernetes secrets can be exposed if not properly secured, and this approach doesn’t leverage the more secure options available in Google Cloud. C) After the UAT phase, sign the attestation with a key stored in Cloud Key Management Service (KMS). Add a...

Author: Kai99 · Last updated Jul 4, 2026

You work for a company that operates an ecommerce website. You are developing a new integration that will manage all order fulfillment steps after orders are placed. You have created multiple Cloud Functions to process each order. You need to orchestrate the execution of the functions, us...

To determine the best solution for orchestrating the execution of Cloud Functions in your ecommerce order fulfillment integration, let's evaluate each option based on the requirement of minimizing latency and managing the execution flow effectively. A) Use Workflows to call the functions, and use callbacks to handle the execution logic. - Explanation: Workflows is a serverless orchestration service that helps coordinate the execution of multiple services, including Cloud Functions. Callbacks are a common technique for asynchronous tasks, where a function signals its completion and triggers further actions. - Why it’s rejected: Using callbacks would introduce unnecessary complexity and potentially increase latency. Callbacks typically involve waiting for an external signal, which could slow down the orchestration and would be more complex to manage compared to a more direct flow control mechanism like conditional jumps. This approach doesn't fully optimize the orchestration for latency. B) Use Workflows to call the functions, and use conditional jumps to handle the execution logic. - Explanation: Workflows allows you to define a series of steps to execute, including conditional logic for making decisions based on the output of previous steps. This approach directly supports efficient orchestration with minimal latency, as it allows for immediate branching decisions based on each step's outcome. - Why it’s selected: Workflows is designed to minimize latency in orchestration by allowing conditional jumps within the workflow based on function outputs. It provides the flexibility to handle different execution paths with minimal overhead. This solution is fully managed, serverless, and optimized for quick execution of tasks, which align...

Author: Lucas · Last updated Jul 4, 2026

You are currently pushing container images to Artifact Registry and deploying a containerized microservices application to GKE. After deploying the application, you notice that the services do not behave as expected. You use the kubectl get pods command to inspect the state of the ...

To troubleshoot the Pod in the CrashLoopBackoff state, let's review each option and analyze the reasoning: A) Connect to the problematic Pod by running the kubectl exec -it POD_NAME - /bin/bash command where the POD_NAME parameter is the name of the problematic Pod. Inspect the logs in the /var/log/messages folder to determine the root cause. - Reasoning: This option suggests using `kubectl exec` to enter the container and inspect logs from within the Pod. However, if the Pod is in a CrashLoopBackoff state, the container may not even start properly to provide an interactive session. Additionally, logs inside the container itself (e.g., under `/var/log/messages`) may not provide the necessary insights because the root cause likely resides in the application logs, not the system logs. Hence, this option is not ideal in this case. - Rejected: Not the best option since it may not allow you to troubleshoot the problem effectively. B) Execute the gcloud projects get-iam-policy PROJECT_ID command where the PROJECT_ID parameter is the name of the project where your Artifact Registry resides. Inspect the IAM bindings of the node pool’s service account. Validate if the service account has the roles/artifactregistry.reader role. - Reasoning: This option addresses the possibility that the Pod might not have access to pull the necessary container images from Artifact Registry. However, if the application has already been deployed and is in a CrashLoopBackoff state, the issue is more likely related to the application code or container configuration rather than IAM permissions, which would typically prevent the Pod from being deployed in the first place. If the Pod was deploye...

Author: SilverBear · Last updated Jul 4, 2026

You use Cloud Build to build and test container images prior to deploying them to Cloud Run. Your images are stored in Artifact Registry. You need to ensure that only container images that have passe...

Let's evaluate each option for ensuring that only container images that have passed testing are deployed to Cloud Run, while minimizing operational overhead: A) Deploy a new revision to a Cloud Run service. Assign a tag that allows access to the revision at a specific URL without serving traffic. Test that revision again. Migrate the traffic to the Cloud Run service after you confirm that the new revision is performing as expected. - Reasoning: This option describes a manual process where you deploy a revision to Cloud Run and test it before routing traffic. While it does allow testing before deployment, it involves manual steps and operational overhead. Additionally, assigning tags and migrating traffic adds complexity compared to an automated approach. This does not fully automate the process and is less efficient. - Rejected: While it offers control, this method is manual and more error-prone, which adds unnecessary complexity. B) Enable Binary Authorization on your Cloud Run service. Create an attestation if the container image has passed all tests. Configure Binary Authorization to allow only images with appropriate attestation to be deployed to the Cloud Run service. - Reasoning: Binary Authorization allows you to set up policies that ensure only container images that meet certain criteria, such as passing tests, can be deployed. This solution is automated, secure, and minimizes operational overhead. You can create an attestation (a verification) for the image, ensuring that it has passed testing. Once this attestation is created, Binary Authorization will enforce the policy, allowing only authorized images to be deployed to Cloud Run. This is the ...

Author: Max · Last updated Jul 4, 2026

You are developing a scalable web application for internal users. Your organization uses Google Workspace. You need to set up authentication to the application for the users, and then deploy the application on Google Cloud. You plan to use cloud-na...

To set up authentication for the internal users of your scalable web application with minimal infrastructure management and cloud-native features, let's evaluate each option: A) Create a Compute Engine VM, configure a web server, and deploy the application in a VPC. - Reasoning: While creating a VM and manually configuring a web server might work for hosting the application, this option introduces significant infrastructure management overhead. You would need to handle provisioning, maintenance, scaling, and security of the VM, which goes against the goal of minimizing infrastructure management. It’s not cloud-native and doesn't leverage scalable, managed services like Cloud Run or Identity Aware Proxy. - Rejected: This option requires significant manual effort to manage the infrastructure, making it less suitable for a scalable and low-maintenance solution. B) Containerize the application, and deploy it as a Cloud Run service. - Reasoning: Cloud Run is a fully managed service that automatically handles scaling and infrastructure management. It is designed for deploying containerized applications with minimal overhead. Since the application is for internal users, deploying on Cloud Run is ideal for scaling and managing the application with minimal maintenance effort. Cloud Run also integrates easily with other Google Cloud services and offers robust security features. - Selected: This is a great option as it leverages cloud-native features, minimizes infrastructure management, and provides scalability. C) Configure Cloud SQL database with a table containing the users and password hashes. Add an authentication screen to ensure that only internal users can access the application. - Reasoning: While Cloud SQL can be used for storing user credentials, managing passwords, and handling authentication logic, this approach requires manual implementation of the authentication system, which increases compl...

Author: Mia · Last updated Jul 4, 2026