Google Practice Questions, Discussions & Exam Topics by our Authors

You need to redesign the ingestion of audit events from your authentication service to allow it to handle a large increase in traffic. Currently, the audit service and the authentication system run in the same Compute Engine virtual machine. You plan to use the following Google Cloud tools in the new architecture: * Multiple Compute Engine machines, each running an instance of the authentication service * Multiple Compute Engine machines, each running an instance of the audit servi...

When redesigning the ingestion of audit events from the authentication service to handle a large increase in traffic, it's important to create a scalable and efficient system. Google Cloud Pub/Sub provides the ability to decouple services, and it allows for horizontal scaling of both the authentication and audit services. We need to focus on ensuring the system can scale efficiently and handle the load while maintaining message delivery guarantees. Let’s review the options based on these requirements. A) Create one Pub/Sub topic. Create one pull subscription to allow the audit services to share the messages. Reason for rejection: While this approach could work initially, it becomes a bottleneck as traffic increases. Having a single pull subscription for all audit service instances means that all instances will have to share the same subscription, potentially leading to message contention or slower processing speeds. Additionally, the audit services may not be able to process messages in parallel, reducing overall throughput. This setup is not ideal for scaling under high traffic. B) Create one Pub/Sub topic. Create one pull subscription per audit service instance to allow the services to share the messages. Reason for selection: Creating one Pub/Sub topic for all authentication events ensures that the events are centralized. By creating one pull subscription per audit service instance, each audit service instance can independently pull messages from the same topic, thus allowing parallel processing and better scalability. This ensures that each audit service instance can handle a portion of the traffic and allows the system to scale efficiently by adding more instances as needed. This approach optimizes the distribution of messages and leverages Pub/Sub's horizontal scaling capabilities. C) Create one Pub/Sub topic. Create one push subscription with the endpoint pointing to a load balancer in front of the audit services. Reason for rejection: While using a push subscription with a load balancer might seem like a good idea, it has some potential drawbacks. Push subscriptions can lead to delivery delays or failures if the audit service...

Author: Ahmed · Last updated Jul 4, 2026

You are developing a marquee stateless web application that will run on Google Cloud. The rate of the incoming user traffic is expected to be unpredictable, with no traffic on some days and large spikes on other days. You need the application to automatically s...

To develop a stateless web application on Google Cloud that can automatically scale up and down based on unpredictable traffic, while minimizing costs, the best solution would depend on both the application's architecture and the scaling capabilities of the services. Let's analyze each option: A) Build the application in Python with Firestore as the database. Deploy the application to Cloud Run. Reason for selection: Cloud Run is designed for stateless applications, and it offers automatic scaling based on incoming traffic, including scaling down to zero when there is no traffic, which is ideal for unpredictable traffic patterns. Cloud Run is serverless, meaning you only pay for the resources consumed during requests, which is cost-efficient. Firestore, a fully-managed NoSQL database, integrates well with Cloud Run, making this solution a scalable, cost-effective, and efficient choice. This setup would minimize costs during periods of low or no traffic while scaling up automatically during peak traffic. B) Build the application in C with Firestore as the database. Deploy the application to App Engine flexible environment. Reason for rejection: App Engine flexible environment supports autoscaling, but it doesn’t scale as efficiently as Cloud Run, especially for stateless applications. While it can handle large traffic spikes, it may incur higher costs during low-traffic periods compared to Cloud Run because the instances can still run when there are no requests, unlike Cloud Run which scales down to zero. App Engine flexible environment may also require more configuration and management. Firestore is still a good database choice, but the deployment option here is not as optimized for cost and scaling efficiency as Cloud Run. C) Build the application in Python with C...

Author: IronLion88 · Last updated Jul 4, 2026

You have written a Cloud Function that accesses other Google Cloud resources. You want to secure the environment using t...

When securing a Cloud Function using the principle of least privilege, the goal is to grant only the necessary permissions required to access the resources, while avoiding giving excessive or unnecessary access. Let's evaluate each option: Option A: Create a new service account that has Editor authority to access the resources. The deployer is given permission to get the access token. - Why rejected: The Editor role grants broad access to a wide range of resources within the project, which violates the principle of least privilege. The Editor role allows the service account to modify resources, not just access them, which could lead to security vulnerabilities. - Scenario it could be used: This approach could be used in scenarios where the service account needs broad, unfettered access across multiple resources and you are okay with potentially over-permissioning the service account. Option B: Create a new service account that has a custom IAM role to access the resources. The deployer is given permission to get the access token. - Why rejected: This option involves creating a custom IAM role, but it still allows the deployer to access the access token without further defining what actions they can perform with it. While creating a custom IAM role is a step toward least privilege, the lack of restriction for the deployer regarding the use of the access token is not ideal. - Scenario it could be used: This option might be suitable when the deployer needs very limited access to the r...

Author: Aria · Last updated Jul 4, 2026

You are a SaaS provider deploying dedicated blogging software to customers in your Google Kubernetes Engine (GKE) cluster. You want to configure a secure multi-tenant platform to ensure that each customer has access ...

When deploying multi-tenant software on Google Kubernetes Engine (GKE) for a SaaS application, the main goal is to ensure that each customer’s resources are isolated and secured, while also preventing one tenant from accessing or affecting another's workloads. Let’s evaluate each option: Option A: Enable Application-layer Secrets on the GKE cluster to protect the cluster. - Why rejected: While securing secrets is crucial, this option focuses on managing sensitive information like API keys or passwords at the application level. It doesn’t address tenant isolation or workload separation, which is the main concern in a multi-tenant environment. - Scenario it could be used: This is useful in securing secrets but doesn’t address the isolation of customers or workloads. Option B: Deploy a namespace per tenant and use Network Policies in each blog deployment. - Why selected: This option provides strong isolation at the Kubernetes level by creating a separate namespace for each tenant (customer). Namespaces offer logical separation, ensuring that tenants’ resources (such as blogs and related components) do not interact or interfere with each other. Network Policies can further enforce security boundaries by restricting communication between workloads in different namespaces, ensuring that each tenant’s blog cannot access others' workloads. - Key factors: - Isolation: Namespaces provide a clean boundary for resource allocation and access. - Security: Network Policies can limit traffic between tenants, ensuring tenant A cannot communicate with tenant B’s resources. ...

Author: VioletCheetah55 · Last updated Jul 4, 2026

You have decided to migrate your Compute Engine application to Google Kubernetes Engine. You need to build a container image and push it to Artifac...

To migrate your Compute Engine application to Google Kubernetes Engine (GKE) and build a container image that you can push to Artifact Registry using Cloud Build, you need to follow the proper steps to build, tag, and push the image. Let’s evaluate each option. Option A: Run `gcloud builds submit` in the directory that contains the application source code. - Why selected: This is the correct way to trigger a build using Cloud Build. The `gcloud builds submit` command builds the container image from the application source code in the current directory and automatically pushes the image to Artifact Registry (or another specified container registry). This approach is key for automating the build and push process. - Key factors: - Triggers the build from your local directory. - Pushes the container image to the chosen registry. - Scenario it can be used: This command is typically used when you are working in the project’s source code directory and need to build and deploy a container image. Option B: Run `gcloud run deploy app-name --image gcr.io/$PROJECT_ID/app-name` in the directory that contains the application source code. - Why rejected: This command is used to deploy an application to Google Cloud Run, not to build or push a container image. It requires an existing image in the container registry but doesn’t address the container build process, which is part of the question. - Scenario it could be used: This command is used when deploying to Cloud Run after an image has been built and pushed to a container registry. It is not used for building or pushing images to Artifact Registry. Option C: Run `gcloud container images add-tag gcr.io/$PROJECT_ID/app-name gcr.io/$PROJECT_ID/app-name:latest` in the directory that contains the application source code. - Why rejected: This command is used to add a tag to an existing container image that’s alr...

Author: Zain · Last updated Jul 4, 2026

You are developing an internal application that will allow employees to organize community events within your company. You deployed your application on a single Compute Engine instance. Your company uses Google Workspace (formerly G Suite), and you nee...

In this scenario, the goal is to allow employees to authenticate to the internal application deployed on a Compute Engine instance securely from anywhere while leveraging Google Workspace for authentication. Let’s evaluate each option: Option A: Add a public IP address to your instance, and restrict access to the instance using firewall rules. Allow your company's proxy as the only source IP address. - Why rejected: This option involves exposing your Compute Engine instance with a public IP but restricting access using a proxy IP address. While this provides some security, it doesn’t fully address authentication or allow seamless access for employees. The use of a company proxy might limit flexibility and could cause issues for employees accessing the application from different locations, especially if they are not always behind the proxy. - Scenario it could be used: This might work for highly controlled environments where all employees are required to go through a specific proxy, but it lacks integration with a more secure, scalable, and centralized authentication solution like Google Workspace. Option B: Add an HTTP(S) load balancer in front of the instance, and set up Identity-Aware Proxy (IAP). Configure the IAP settings to allow your company domain to access the website. - Why selected: This option is the best choice because it uses Identity-Aware Proxy (IAP), a Google Cloud service that enables secure access to applications deployed on Google Cloud based on user identity. By integrating IAP, you can leverage Google Workspace for authentication, allowing employees to sign in using their company credentials. IAP provides secure, context-aware access control, ensuring only authorized users within your domain can access the application. - Key factors: - Scalability: IAP works seamlessly with cloud resources and scales with the application. - Security: Authentication is tied directly to Google Workspace (formerly G Suite), leveraging your existing identity management solution. - Flexibility: Employees can access the ...

Author: Olivia · Last updated Jul 4, 2026

Your development team is using Cloud Build to promote a Node.js application built on App Engine from your staging environment to production. The application relies on several directories of photos stored in a Cloud Storage bucket named webphotos-staging in the staging environment. After the promotion, these photos must be available in...

In this scenario, the goal is to automate the process of promoting a Node.js application from staging to production while ensuring that photos stored in the Cloud Storage bucket `webphotos-staging` are transferred to `webphotos-prod` in the production environment. Let’s evaluate each option: Option A: Manually copy the photos to webphotos-prod. - Why rejected: While this option may work in a small, manual scenario, it introduces human error and is not scalable or efficient in the context of automation. Manually copying the photos is not ideal because it requires intervention each time you promote the application to production. Automation is crucial to avoid the risk of forgetting to copy files and to streamline deployment processes. - Scenario it could be used: This might be appropriate for a one-off or very small-scale operation where automation is not necessary, but it is not a suitable solution for ongoing, repeatable deployments. Option B: Add a startup script in the application's app.yaml file to move the photos from webphotos-staging to webphotos-prod. - Why rejected: The `app.yaml` file in App Engine is used to configure deployment settings, including scaling and routing configurations. Adding a startup script in the `app.yaml` file would not be the right place to move the photos. The startup script is executed when the application starts, but moving large amounts of data (such as photos between Cloud Storage buckets) should be handled during the build or deployment process, not at runtime. Additionally, relying on startup scripts to perform this action could delay application startup and complicate maintenance. - Scenario it could be used: This could work in a very basic case, but it's not a good practice for data migration as it introduces del...

Author: Ming88 · Last updated Jul 4, 2026

You are developing a web application that will be accessible over both HTTP and HTTPS and will run on Compute Engine instances. On occasion, you will need to SSH from your remote laptop into one of the Compute Engine instances to conduct mainten...

In this scenario, we are focused on configuring the web servers on Compute Engine instances to follow Google-recommended best practices, ensuring that the app is accessible over both HTTP and HTTPS and can be maintained securely. A) Set up a backend with Compute Engine web server instances with a private IP address behind a TCP proxy load balancer. - Reasoning: The TCP proxy load balancer allows HTTP and HTTPS traffic to be securely routed to the backend servers. However, using a private IP address for web server instances means that remote SSH access for maintenance would require a more complex setup (e.g., VPN or bastion host) since these instances are not directly accessible from the public internet. - Rejection: While this setup can be used in highly secure environments, SSH access from a remote laptop is not straightforward. A bastion host or additional secure methods would be required to access the private instances. B) Configure the firewall rules to allow all ingress traffic to connect to the Compute Engine web servers, with each server having a unique external IP address. - Reasoning: Allowing all ingress traffic and giving each web server a public IP address can make the system vulnerable to security threats. This option does not follow best practices for securing your infrastructure because exposing the web servers directly to the internet can increase the attack surface. - Rejection: This option does not meet security best practices and could expose your instances to unnecessary risks. Publicly exposing your web servers is generally not recommended. C) Configure Cloud Identity-Aware Proxy API for SSH access. Then configure the Compute Engine servers with private IP addresses behind an HTTP(s) load balancer for the appl...

Author: Emma · Last updated Jul 4, 2026

You have a mixture of packaged and internally developed applications hosted on a Compute Engine instance that is running Linux. These applications write log records as text in loca...

To meet the goal of sending logs from a Compute Engine instance to Cloud Logging, the selected solution needs to ensure efficient, real-time logging and integration with Google Cloud's logging infrastructure. Let's analyze the available options: A) Pipe the content of the files to the Linux Syslog daemon. - Reasoning: The Syslog daemon is traditionally used for logging system messages, and it can be configured to send logs to Cloud Logging. However, setting up and maintaining this pipeline can be complex, especially since the logs in question are coming from both packaged and internally developed applications. It would require additional configurations to forward logs from different sources correctly and reliably. - Rejection: While feasible, this solution is less flexible and could become complex as the variety of applications and log sources increase. It also might not be as straightforward as other Google Cloud-native solutions. B) Install a Google version of fluentd on the Compute Engine instance. - Reasoning: Fluentd is a highly flexible and scalable data collector for unified logging. The Google Cloud version of fluentd is specifically designed to work seamlessly with Cloud Logging. It can easily collect logs from various sources, including local log files, and forward them directly to Cloud Logging. - Why selected: This is the most appropriate solution as it’s designed for the task, integrates directly with Cloud Logging, and can handle logs from both packaged and internally developed applications. Fluentd is optimized for log collection and forwarding to Google Cloud services, making it a highly efficient choice. C) Install...

Author: Emma · Last updated Jul 4, 2026

You want to create `fully baked` or `golden` Compute Engine images for your application. You need to bootstrap your application to connect to the appropriate database according to the environ...

Let's evaluate each of the options to determine which one is the best approach for bootstrapping the application to connect to the correct database based on the environment (test, staging, production) while creating a `fully baked` or `golden` Compute Engine image. A) Embed the appropriate database connection string in the image. Create a different image for each environment. - Reasoning: While this approach may work, it introduces complexity and redundancy, as you would have to maintain different images for each environment (test, staging, production). Every time an update or change is required, you'd have to create a new image for each environment, which is inefficient and difficult to scale. - Rejection: This approach is not flexible and leads to unnecessary image proliferation. It also lacks the ability to adapt dynamically to changes in the environment. It’s better to have one image that can be configured based on the environment at runtime. B) When creating the Compute Engine instance, add a tag with the name of the database to be connected. In your application, query the Compute Engine API to pull the tags for the current instance, and use the tag to construct the appropriate database connection string. - Reasoning: Using instance tags is a viable approach, and the application can use the Compute Engine API to fetch the tags and determine the database to connect to. However, querying the API for tags is an extra step that introduces unnecessary complexity. It’s generally more efficient to use instance metadata, which is specifically designed for storing environment-specific information like configuration values. - Rejection: While it’s a workable approach, querying the Compute Engine API for tags could introduce some overhead, and metadata is a more appropriate method for storing configuration values in this context. C) When creating the Compute Engine instance, create a metadata item with a key of `DATABASE` and a value for the appropriate database con...

Author: Vikram · Last updated Jul 4, 2026

You are developing a microservice-based application that will be deployed on a Google Kubernetes Engine cluster. The application needs to read and write to a Spanner database. You want to follow security best practices while m...

Let's evaluate each of the options to determine the best way to configure your microservice-based application to retrieve Spanner credentials while following security best practices and minimizing code changes. A) Configure the appropriate service accounts, and use Workload Identity to run the pods. - Reasoning: Workload Identity is a feature in GKE that allows Kubernetes workloads to authenticate as Google Cloud service accounts. This provides a way to securely access Google Cloud resources (like Spanner) without storing credentials in the application itself. The Kubernetes service account is mapped to a Google Cloud service account that has the necessary permissions to access Spanner. - Why selected: This option follows the principle of least privilege and Google Cloud's best practices by allowing your application to securely authenticate to Google Cloud resources without hardcoding credentials. It minimizes code changes, as you can use the Kubernetes service account to authenticate automatically. Additionally, Workload Identity eliminates the need to manage service account keys, which improves security. B) Store the application credentials as Kubernetes Secrets, and expose them as environment variables. - Reasoning: Storing credentials as Kubernetes Secrets can be done, but it is not a best practice for accessing Google Cloud services like Spanner. Although Kubernetes Secrets provide some level of security by storing sensitive data, exposing these secrets as environment variables increases the risk of accidentally leaking them (for example, in logs or through misconfigured permissions). - Rejection: Storing credentials manually, especially in environment variables, is not the most secure or recommended approach for accessing Google Cloud services. It requires more management overhead and can lead to security risks, especially if the secrets are mishandled or exposed unintentionally. C) Configure the appropriate routing rules, and use a ...

Author: Ella · Last updated Jul 4, 2026

You are deploying your application on a Compute Engine instance that communicates with Cloud SQL. You will use Cloud SQL Proxy to allow your application to communicate to the database using the service account associated with the application's instance. You want to follow the Googl...

In this scenario, you're deploying an application on a Compute Engine instance that communicates with Cloud SQL via Cloud SQL Proxy, and you want to follow the principle of least privilege by ensuring the service account only has the necessary permissions to interact with Cloud SQL. A) Assign the Project Editor role. - Reasoning: The Project Editor role provides broad permissions across all Google Cloud services within the project, including managing resources like Compute Engine, Cloud SQL, and more. This is a highly permissive role that gives the service account more access than required to interact with Cloud SQL. - Rejection: This is not a good practice, as it violates the principle of least privilege. The service account should only have the permissions needed to interact with Cloud SQL, not broader project-wide permissions. Giving excessive permissions increases the security risk. B) Assign the Project Owner role. - Reasoning: The Project Owner role provides full control over all resources in the project, including the ability to modify IAM roles, manage billing, and configure all services. It is the most permissive role and should never be assigned to a service account unless absolutely necessary. - Rejection: This option is highly inappropriate for this use case. The service account should have minimal permissions to interact with Cloud SQL, not complete control over all aspects of the project. Assigning this role increases security risks and does not align with Google’s best practices for least privilege. C) Assign the Cloud SQL Client role. - Reasoning...

Author: Ming88 · Last updated Jul 4, 2026

Your team develops stateless services that run on Google Kubernetes Engine (GKE). You need to deploy a new service that will only be accessed by other services running in the GKE cluster. The service wil...

To determine the best approach for deploying the new service in Google Kubernetes Engine (GKE), we need to consider several key factors: 1. Service Scaling Needs: - Stateless services: These services can scale horizontally because they don't store state locally. They can be scaled quickly in response to changing loads. - The service should scale rapidly, so a Horizontal Pod Autoscaler (HPA) is ideal, as it can adjust the number of pods based on resource metrics (like CPU or memory usage) or custom metrics. 2. Service Exposure: - Since the service is only accessed by other services within the same GKE cluster, it doesn't need to be exposed to the outside world. - A ClusterIP Service is the appropriate choice here, as it makes the service accessible only within the cluster. In contrast, a NodePort Service would expose the service outside of the cluster, which is unnecessary and potentially insecure for internal-only services. 3. Vertical vs. Horizontal Autoscaling: - A Vertical Pod Autoscaler (VPA) adjusts the resource limits (CPU, memory) of existing pods but does not scale the number of pods. VPA is useful if you expect the workload of the service to grow or require more resources, but it doesn’t scale the service in terms of pod count. For services with fluctuating or unpredictable loads, Horizontal Pod Autoscaler (HPA), which scales the number of pods, is the better choice. Option Analysis: - Option A: Vertical Pod Autoscaler with Clust...

Author: Rahul · Last updated Jul 4, 2026

You recently migrated a monolithic application to Google Cloud by breaking it down into microservices. One of the microservices is deployed using Cloud Functions. As you modernize the application, you make a change to the API of the service that is backward-incompatible. You ...

When migrating to microservices, it's common to encounter situations where API changes are necessary, but backward compatibility with existing users needs to be preserved. The goal in this scenario is to support both the original (old) API and the new API simultaneously. Key Considerations: 1. Backward Compatibility: The existing callers must continue using the original API, and new callers should use the updated version of the API. 2. Routing Traffic: There needs to be a way to differentiate between the old and new versions of the API and route requests to the appropriate service. 3. Microservices: Each API version is likely to be implemented in a separate Cloud Function, and you must manage API versioning efficiently. Option Analysis: - Option A: Leave the original Cloud Function as-is and deploy a second Cloud Function with the new API. Use a load balancer to distribute calls between the versions. - Rejected because Cloud Functions do not directly support the use of a load balancer in the way traditional services might. Cloud Functions are designed to handle individual function invocations based on HTTP triggers, and using a load balancer to manage traffic between Cloud Functions is not a suitable approach. This method would also require complex manual routing and wouldn't handle API versioning effectively. - Option B: Leave the original Cloud Function as-is and deploy a second Cloud Function that includes only the changed API. Calls are automatically routed to the correct function. - Rejected because Cloud Functions don’t provide automatic routing based on versioning or API request parameters. This ...

Author: Leah Davis · Last updated Jul 4, 2026

You are developing an application that will allow users to read and post comments on news articles. You want to configure your application to store and display user-submitted comments using Firestore. ...

When designing a Firestore schema for an application where users can read and post comments on articles, the main goal is to ensure scalability and efficient querying while maintaining flexibility. Below, I will evaluate each option based on these factors and the requirements of the application. Key Considerations: 1. Scalability: There could be an unknown, potentially large number of comments for each article, so the schema needs to be able to scale well without hitting Firestore's limits on document size or performance. 2. Efficient Querying: The design should allow for easy querying of comments (e.g., retrieving all comments for an article) and should avoid inefficient operations like scanning large arrays. 3. Separation of Concerns: The data should be organized logically to avoid tight coupling between comments and other entities (like users and articles). Option Analysis: - Option A: Store each comment in a subcollection of the article. - Selected because this design follows Firestore's recommended practices for handling one-to-many relationships. By storing each comment in its own document within a subcollection of the article, you achieve the following: - Scalability: Firestore allows subcollections to scale independently of the parent document. This avoids hitting Firestore's 1 MB document size limit and ensures that the number of comments doesn't affect the article document directly. - Efficient Querying: You can easily query for all comments of a specific article by querying the subcollection. This makes it easy to retrieve comments for an article without fetching all the other data of the article itself. - Flexibility: You can store additional metadata (e.g., timestamps, user references, likes) for each comment within its own document, which provides flexibility in case the comment structure evolves over time. ...

Author: Oliver · Last updated Jul 4, 2026

You recently developed an application. You need to call the Cloud Storage API from a Compute Engine instance that do...

When your application is running on a Compute Engine instance that doesn't have a public IP address, the key challenge is enabling access to Google Cloud services like Cloud Storage without relying on the public internet. Since the Compute Engine instance doesn't have a public IP address, we need to ensure that it can still communicate with Google Cloud services securely and efficiently within Google's private network. Key Considerations: 1. No Public IP: The Compute Engine instance doesn't have a public IP, meaning it can't directly access Google Cloud services over the internet. 2. Access to Google Cloud Services: You need to enable the instance to call Google Cloud APIs (like Cloud Storage) without using a public IP. 3. Private Access: The solution needs to route the requests through Google's private network to avoid exposing the Compute Engine instance to the internet. Option Analysis: - Option A: Use Carrier Peering: - Rejected because Carrier Peering is designed for connecting on-premises networks with Google Cloud via a carrier's network. It’s useful for connecting your data center to Google Cloud but is not necessary or suitable for enabling private access from a Compute Engine instance to Google Cloud services like Cloud Storage. This is an overkill and not the right approach for your scenario. - Option B: Use VPC Network Peering: - Rejected because VPC Network Peering is used to connect two Virtual Private Cloud (VPC) networks. While it enables communication between resources in different VPC networks, it ...

Author: Liam123 · Last updated Jul 4, 2026

You are a developer working with the CI/CD team to troubleshoot a new feature that your team introduced. The CI/CD team used HashiCorp Packer to create a new Compute Engine image from your development branch. The image was successfully bui...

When troubleshooting a newly created Compute Engine image that isn't booting up, it’s important to first identify the underlying issue without unnecessarily repeating the build process or introducing new changes. Here’s a breakdown of the available options based on this goal: Key Considerations: 1. Root Cause Diagnosis: The first step is to diagnose why the image is not booting. We need to focus on checking the boot process, error logs, or any misconfigurations that could prevent the instance from starting. 2. Efficient Investigation: Rather than recreating or rebuilding images immediately, the investigation should focus on easily accessible logs and debugging tools. 3. Logs and Debugging: Utilizing the serial port logs and Cloud Logging is a direct and effective way to gather insights about the issue without needing to recreate the entire environment. Option Analysis: - Option A: Create a new feature branch, and ask the build team to rebuild the image. - Rejected because this approach does not address the immediate issue of the instance not booting. Rebuilding the image could be a last resort after identifying the root cause. Simply rebuilding the image without understanding the issue will likely lead to the same outcome, and we need to first identify what went wrong. - Option B: Shut down the deployed virtual machine, export the disk, and then mount the disk locally to access the boot logs. - Rejected because this approach adds unnecessary complexity. Exporting the disk and mounting it locally may not be the fastest or most effective way to diagnose a boot...

Author: Carlos Garcia · Last updated Jul 4, 2026

You manage an application that runs in a Compute Engine instance. You also have multiple backend services executing in stand-alone Docker containers running in Compute Engine instances. The Compute Engine instances supporting the backend services are scaled by managed instance groups in multiple regions. You want your calling application to be loosely coupled. You need to be able to invoke distinct...

To choose the most appropriate Google Cloud feature for invoking backend services based on an HTTP header, we need to evaluate the provided options based on key factors such as service discovery, routing based on request attributes (like HTTP headers), and load balancing capabilities. Option A: Traffic Director Traffic Director is a fully managed traffic control plane that supports global load balancing and intelligent routing for microservices. It is often used in conjunction with service meshes, such as Istio, and allows for advanced routing and traffic management across services based on HTTP headers, cookies, or other attributes. - Why it could work: Traffic Director can route requests based on HTTP headers, enabling fine-grained control over how requests are routed to different backend services. - Why it might not be ideal: Traffic Director is typically used when services are deployed in a service mesh architecture, which may require additional complexity, such as setting up Istio or another service mesh layer. Option B: Service Directory Service Directory is a service discovery platform that allows services to register themselves and allows other services to find them, but it doesn’t inherently offer routing capabilities based on HTTP request attributes. - Why it doesn't fit: While it supports service discovery, it does not support routing based on HTTP headers. It's more about helping applications locate services rather than routing traffic dynamically based on request attributes. Option C: Anthos Service Mesh Anthos Service Mesh is a managed serv...

Author: Deepak · Last updated Jul 4, 2026

Your team is developing an ecommerce platform for your company. Users will log in to the website and add items to their shopping cart. Users will be automatically logged out after 30 minutes of inactivity. When users log back in, their shopping cart should be saved. H...

To choose the best method for storing session and shopping cart information in the given eCommerce scenario, we need to consider several factors such as scalability, session persistence, reliability, and ease of management. Let’s evaluate each of the options based on these key factors. Option A: Store the session information in Pub/Sub, and store the shopping cart information in Cloud SQL Pub/Sub is primarily used for real-time messaging and event-driven architectures, not for session management. It's excellent for decoupling services but is not ideal for storing session data due to its transient, message-passing nature. Cloud SQL, on the other hand, is a relational database that would be suitable for storing structured data like shopping cart contents. However, using Pub/Sub for session management is a mismatch, as it does not maintain state or handle session expiration well. - Why it doesn’t fit: Pub/Sub is not designed for persistent session storage. It is a messaging service, not a data store for long-lived session data. Option B: Store the shopping cart information in a file on Cloud Storage where the filename is the SESSION ID Cloud Storage is a highly durable and scalable object storage service, but storing session data as files is not the best choice for managing user sessions in real-time applications. - Why it doesn’t fit: Storing shopping cart data in files can lead to inefficient retrieval and management of session data. While Cloud Storage is highly durable, it lacks the necessary features (like fast lookups, easy updates, and automatic session expiration) that databases or caching solutions provide. Option C: Store the session and shopping cart information in a MySQL database running on multiple Compute Engine instances MySQL can certainly store session and shopping cart information, but managing a database on Compute Engine instances introduces operational complexity. You would need to handle high availability, scaling, and database replication manually. Additionally, Compute Engine does not automatically scale to handle...

Author: Sofia · Last updated Jul 4, 2026

You are designing a resource-sharing policy for applications used by different teams in a Google Kubernetes Engine cluster. You need to ensure that all applications c...

To design a resource-sharing policy for applications used by different teams in a Google Kubernetes Engine (GKE) cluster, we need to ensure that resources are allocated efficiently and fairly while also providing control over resource usage and isolation. Let's evaluate the given options to determine the best approach. Option A: Specify the resource limits and requests in the object specifications Resource limits and requests in Kubernetes define how much CPU and memory a pod can request and how much it can use. Requests ensure that the system reserves resources for the pod, while limits ensure that the pod doesn't consume more resources than allowed. - Why it fits: Setting resource requests and limits ensures that each application gets the resources it needs and prevents any single application from consuming excessive resources. It helps in resource allocation and prevents resource contention. - Why it might not be enough: While this is a good practice for managing resources at the individual pod level, it does not address resource sharing across teams or enforcing resource policies at a broader level, such as limiting resource usage by teams or namespaces. Option B: Create a namespace for each team, and attach resource quotas to each namespace Namespaces in Kubernetes provide a way to partition the cluster and isolate resources between teams. Resource quotas allow administrators to set limits on the total amount of CPU, memory, or storage that can be used within a namespace. - Why it fits: Using namespaces for teams ensures isolation, and attaching resource quotas to each namespace enforces a fair allocation of resources among teams. This ensures that no team can consume all available resources and helps maintain system stability. - Why it might not be enough: While resource quotas help in limiting resource consumption within a namespace, it does not automatically handle default resource settings for applications or ensure that each application can access the resources it needs. Option C: Create a LimitRange to specify the default compute resource requirements for each namespace A LimitRange is a Kubernetes object that can specify default resource requests and limits for containers in a namespace. It ensures that every pod has a set of default resource values if they are not explicitly specified. - Why it fits: A...

Author: MysticJaguar44 · Last updated Jul 4, 2026

You are developing a new application that has the following design requirements: * Creation and changes to the application infrastructure are versioned and auditable. * The application and deployment infrastructure uses Google-managed services as much as possible...

To design the application's architecture with the given requirements, we need to consider the following factors: 1. Versioning and Auditability of infrastructure and application code. 2. Use of Google-managed services as much as possible. 3. Serverless compute platform to run the application. Option A: 1. Store the application and infrastructure source code in a Git repository: This ensures version control and auditability of both application and infrastructure code. 2. Use Cloud Build to deploy the application infrastructure with Terraform: Cloud Build is a Google-managed service, and Terraform is often used for managing infrastructure as code (IaC). This satisfies the requirement of versioning and auditability. 3. Deploy the application to a Cloud Function as a pipeline step: Cloud Functions is a serverless compute platform and fully managed by Google, fulfilling the requirement for serverless computing. - Why it fits: This option uses a Google-managed service (Cloud Build) for CI/CD and uses Cloud Functions for serverless compute. Terraform provides versioning and audibility for infrastructure management. - Why it might not be ideal: Terraform is a good choice for infrastructure management, but Cloud Functions might not be ideal if the application requires more complex deployment features, such as web servers, databases, or other components that might be better suited to App Engine or Cloud Run. Option B: 1. Deploy Jenkins from the Google Cloud Marketplace: Jenkins is an open-source automation server that requires more management overhead than a fully managed service like Cloud Build. 2. Define a continuous integration pipeline in Jenkins: While Jenkins is powerful, it adds complexity compared to using a fully managed service like Cloud Build. 3. Deploy the application source code to App Engine as a pipeline step: App Engine is a managed platform that would provide serverless compute for the application. - Why it doesn't fit: Using Jenkins for CI/CD adds operational complexity because it requires management and maintenance, which goes against the requirement to use Google-managed services as much as possible. App Engine, however, is a good choice for serverless computing, but the Jenkins overhead makes this less ideal. Option C: 1. Create a continuous integration pipeline on Cloud Build: This uses a fully managed Google service, fulfilling the requirement for versioning and auditability. 2. Deploy the application infrastructure using Deployment Manager templates: Deployment Manager is a Google-managed service for deploying infrastructure. It satisfies t...

Author: Zara · Last updated Jul 4, 2026

You are creating and running containers across different projects in Google Cloud. The application you are developing needs to access Google Cloud servic...

When developing applications running in Google Kubernetes Engine (GKE) that need to access Google Cloud services, the key consideration is ensuring proper authentication and authorization for the containers and the applications they run. We need to use Google Cloud's identity and access management (IAM) system to securely and efficiently handle access to Google Cloud services. Let's review each option and evaluate the best choice. Option A: Assign a Google service account to the GKE nodes Assigning a Google service account to the GKE nodes means the entire set of nodes in the GKE cluster will use the same service account to access Google Cloud services. - Why it doesn’t fit: While this can allow the nodes to access Google Cloud services, it is less secure because it gives broad access to the services, potentially elevating the risk if a node is compromised. It also doesn’t allow fine-grained access control at the pod level. Pod-level authentication is often more appropriate for better security. - When it can be used: This approach can be used for applications that don’t require fine-grained access control for different workloads or services. Option B: Use a Google service account to run the Pod with Workload Identity Workload Identity allows Kubernetes workloads (pods) to use a Google service account for accessing Google Cloud services. It works by linking Kubernetes service accounts to Google service accounts, allowing each pod to authenticate as a specific Google service account, ensuring least privilege access. - Why it fits: This is the most secure and recommended approach. By using Workload Identity, each pod gets its own set of permissions tied to the Google service account, so different workloads can have different levels of access. This is a Google-recommended practice for securing access to Google Cloud services, as it provides fine-grained control and avoids the need to manage credentials manually. - Why it's ideal: It reduces the risk of credential leakage, improves security, and gives precise control over what each pod can access. Workload Identity integrates well wit...

Author: Maya · Last updated Jul 4, 2026

You have containerized a legacy application that stores its configuration on an NFS share. You need to deploy this application to Google Kubernetes Engine (GKE) and do not want the application s...

In order to deploy the legacy application on Google Kubernetes Engine (GKE) while ensuring that it does not serve traffic until after retrieving its configuration from an NFS share, let's break down the options: Option A: Use the `gsutil` utility to copy files from within the Docker container at startup, and start the service using an ENTRYPOINT script. - Pros: Using `gsutil` could allow the application to fetch files from a cloud storage location (like Google Cloud Storage), and the ENTRYPOINT script could ensure that the service only starts after the configuration is retrieved. - Cons: This approach is dependent on Google Cloud Storage, which is different from the required NFS share. This adds unnecessary complexity, as the application is already designed to work with an NFS share, and we are assuming it requires configuration directly from an NFS share. - Conclusion: This option isn't suitable because it uses a different source (Google Cloud Storage) rather than the required NFS share. Option B: Create a PersistentVolumeClaim on the GKE cluster. Access the configuration files from the volume, and start the service using an ENTRYPOINT script. - Pros: This option is Kubernetes-native. It uses a PersistentVolumeClaim (PVC) to ensure that the application has access to the required NFS share. By setting up the NFS as a PersistentVolume (PV) and binding it to a PVC, the application can access its configuration at startup. - Cons: There might be a slight delay in mounting the volume, but Kubernetes guarantees that the pod will not start serving traffic until the volume is mounted. - Conclusion: This is a highly appropriate and efficient way to retrieve the configuration from an NFS share. It also leverages Kubernetes' native functionality for persistent storage, which is ideal for managing shared data. ...

Author: StarryEagle42 · Last updated Jul 4, 2026

Your team is developing a new application using a PostgreSQL database and Cloud Run. You are responsible for ensuring that all traffic is kept private on Google Cloud. You want to use m...

To ensure that all traffic is kept private on Google Cloud while using managed services like Cloud Run and PostgreSQL, we need to follow Google-recommended best practices for secure networking. Let's analyze each option: Option A: 1. Enable Cloud SQL and Cloud Run in the same project. 2. Configure a private IP address for Cloud SQL. Enable private services access. 3. Create a Serverless VPC Access connector. 4. Configure Cloud Run to use the connector to connect to Cloud SQL. - Pros: This approach follows the recommended best practice of keeping the services in the same project, making management simpler. Cloud SQL supports private IPs, which allows the application on Cloud Run to connect securely to the database without exposing traffic to the public internet. Using the Serverless VPC Access connector ensures secure, private communication between Cloud Run and Cloud SQL, keeping all traffic within Google's network. - Cons: This option is very straightforward and efficient for a Cloud Run and Cloud SQL setup in the same project. - Conclusion: This is the recommended approach for ensuring private connectivity between Cloud Run and Cloud SQL while following Google best practices for managed services. Option B: 1. Install PostgreSQL on a Compute Engine virtual machine (VM), and enable Cloud Run in the same project. 2. Configure a private IP address for the VM. Enable private services access. 3. Create a Serverless VPC Access connector. 4. Configure Cloud Run to use the connector to connect to the VM hosting PostgreSQL. - Pros: You can configure private IP for the VM, ensuring that communication remains within a private network. - Cons: This setup introduces more management overhead by having to install and maintain PostgreSQL on a Compute Engine VM, which is not a fully managed service like Cloud SQL. It also increases complexity, as you must handle PostgreSQL updates, backups, and scalability on your own. This approach moves away from the fully managed Cloud SQL service, reducing the benefits of a serverless architecture. - Conclusion: While possible, th...

Author: Emily · Last updated Jul 4, 2026

You are developing an application that will allow clients to download a file from your website for a specific period of time. How should you design the application t...

To design an application that allows clients to download a file for a specific period of time, we need to focus on ensuring secure, scalable, and efficient file delivery. Let's analyze each option: Option A: Configure the application to send the file to the client as an email attachment. - Pros: The file can be delivered directly to the client via email. - Cons: This is not an efficient method for file delivery, especially for large files. Additionally, sending large files as email attachments can result in email size limitations, potential security risks, and a poor user experience. It's also less scalable and doesn't integrate well with modern cloud infrastructure. - Conclusion: This option is not suitable because it introduces scalability issues, limits file size, and is not aligned with Google Cloud's best practices for temporary file sharing. Option B: Generate and assign a Cloud Storage-signed URL for the file. Make the URL available for the client to download. - Pros: This approach is highly scalable and leverages Google Cloud's best practices. Cloud Storage-signed URLs provide secure, time-limited access to a file, which is exactly what the requirement asks for. Once the signed URL expires, access to the file is automatically revoked. This method is ideal for controlling access to files in Cloud Storage without the need for complex infrastructure. - Cons: The only limitation is ensuring that the URL expiration time aligns with the desired time period for the client to access the file. - Conclusion: This is the most efficient and scalable solution, leveraging Google Cloud's native tools for secure and time-limited file access. It aligns with best practices and minimizes infrastructure overh...

Author: Grace · Last updated Jul 4, 2026

Your development team has been asked to refactor an existing monolithic application into a set of composable microservices. Which design aspec...

To refactor a monolithic application into composable microservices, we must focus on key design principles that ensure scalability, maintainability, and flexibility. Let's go through each option: Option A: Develop the microservice code in the same programming language used by the microservice caller. - Pros: This could reduce communication overhead and simplify integration if both the microservice and its caller are in the same language. - Cons: This is not a best practice for microservices. Microservices are designed to be language-agnostic, meaning each service should be decoupled from others and can be developed using the most appropriate technology stack for its needs. Forcing a particular programming language for all services limits flexibility and hinders the benefits of the microservices architecture. - Conclusion: This is not the best approach. Microservices should be technology-agnostic, allowing flexibility in choosing the right tools for each service. Option B: Create an API contract agreement between the microservice implementation and microservice caller. - Pros: This is essential for defining clear interfaces and expectations between services. An API contract ensures that both the microservice implementation and its consumers (callers) are aligned on how to communicate and what data to exchange. This leads to better maintainability and easier integration in the long run. - Cons: None, as this is a core aspect of microservice design. It adds some upfront design work but is crucial for decoupling services and ensuring smooth interactions. - Conclusion: This is a crucial step in the refactoring process. An API contract agreement ensures that microservices can evolve independently without breaking the interactions between them. Option C: Require asynchronous communications between all microservice implementations and microservice callers. - Pros: Asynchronous communication can improve performance, especially for decoupling services and handling high loads. It allows services to continue processing other requests while waiting for a response from a slower service. - Cons: While asynchronous communicat...

Author: Ella · Last updated Jul 4, 2026

You deployed a new application to Google Kubernetes Engine and are experiencing some performance degradation. Your logs are being written to Cloud Logging, and you are using a Prometheus sidecar model for capturing metrics. You need to correlate the metrics and data from...

To troubleshoot performance issues in your application deployed on Google Kubernetes Engine (GKE) and correlate metrics from Prometheus and logs from Cloud Logging, you need to focus on real-time alerting, cost-effectiveness, and efficient correlation of logs and metrics. Let's go through each option: Option A: Create custom metrics from the Cloud Logging logs, and use Prometheus to import the results using the Cloud Monitoring REST API. - Pros: This approach allows you to create custom metrics from Cloud Logging, which can then be integrated with Prometheus. This method could offer flexibility in creating specific metrics from logs. - Cons: While this option enables metric creation from logs, it is more complex and involves additional overhead of developing custom metrics and using the Cloud Monitoring REST API to import these results into Prometheus. It also introduces unnecessary complexity for something that could be achieved in a more streamlined manner. - Conclusion: This option is not the best fit due to the complexity and additional overhead involved in creating custom metrics and using the REST API. Option B: Export the Cloud Logging logs and the Prometheus metrics to Cloud Bigtable. Run a query to join the results, and analyze in Google Data Studio. - Pros: Cloud Bigtable is a scalable, low-latency NoSQL database, and it can store large volumes of data, which could be useful for log and metric storage. Google Data Studio can be used for visualization. - Cons: While Bigtable is good for handling large amounts of data, it is not optimized for real-time analysis and correlation of logs and metrics. This approach also introduces unnecessary complexity, as Bigtable is more suited for storage rather than real-time troubleshooting. Additionally, querying Bigtable and visualizing data in Data Studio could be cumbersome and not efficient for real-time alerting and monitoring. - Conclusion: This option is not ideal as it adds unnecessary complexity and is not well-suited for real-time analysis and alerti...

Author: Sofia · Last updated Jul 4, 2026

You have been tasked with planning the migration of your company's application from on-premises to Google Cloud. Your company's monolithic application is an ecommerce website. The application will be migrated to microservices deployed on Google Cloud in stages. The majority of your company's revenue is generated through online sales, so it is...

To prioritize which functionality to migrate first, several key factors need to be considered: 1. Criticality to Business Operations: The core business operations and revenue-generating features must be migrated first. The functionality with the most direct impact on revenue and user experience should be prioritized. 2. Risk Management: Given that the majority of revenue is generated through online sales, minimizing risk during the migration is essential. A feature with fewer dependencies and integrations, or one that doesn't directly impact user transactions, is ideal. 3. Dependencies: Each feature comes with its own set of integrations and dependencies, which can increase complexity and risk. The more integrations a feature has, the higher the likelihood of migration-related issues. Features with fewer dependencies should be considered for initial migration. Evaluation of the Options: A) Migrate the Product Catalog - Dependencies: It has integrations with the frontend and product database. - Criticality: The product catalog is critical for displaying products to users, but it's less critical to transactions themselves. - Risk: There are fewer integrations compared to other options, meaning it’s likely to be a lower-risk migration with a moderate impact on the user experience. - Conclusion: This is a good option for the first migration as it has a moderate level of complexity and impact on business operations. Users can still make purchases even if the catalog is temporarily unavailable, although it would affect the browsing experience. B) Migrate Payment Processing - Dependencies: It integrates with the frontend, order database, and third-party payment vendors. - Criticality: This feature is critical because it is essential for completing transactions. - Risk: This is a high-risk migration. Migrating payment processing early in the process could lead to significant disruptions, as payment systems are sensitive and involve integrations with third-party ve...

Author: Noah · Last updated Jul 4, 2026

Your team develops services that run on Google Kubernetes Engine. Your team's code is stored in Cloud Source Repositories. You need to quickly identify bugs in the code before it is deployed to production. You want to invest in automat...

To identify bugs in code before deployment and improve developer feedback, the focus should be on automating the build process and enabling continuous integration (CI). Key factors to consider are the efficiency of the feedback loop, automation of builds, and error identification as early as possible in the development cycle. Evaluation of the Options: A) Use Spinnaker to automate building container images from code based on Git tags. - Spinnaker's Role: Spinnaker is a continuous delivery platform designed to automate deployment pipelines, particularly to multiple cloud environments. It excels in orchestrating the deployment of container images but is not specifically designed for CI tasks like building container images. - Why Rejected: While Spinnaker is great for deployment, it does not focus on automating the build process based on Git tags, which is critical for early bug identification. The focus here should be on the build and test phase, not just deployment. - Scenario: Spinnaker would be more appropriate if you wanted to automate deployments rather than building images. B) Use Cloud Build to automate building container images from code based on Git tags. - Cloud Build's Role: Cloud Build is a fully managed CI/CD platform that can automatically build container images, run tests, and execute deployment pipelines. It integrates seamlessly with Cloud Source Repositories and supports building container images based on Git tags. This aligns well with the goal of identifying bugs early in the development process. - Why Selected: Cloud Build can trigger builds automatically when code is committed or when specific Git tags are pushed. This enables early bug detection through automated tests during the build process, giving quick feedback to developers. It also supports integration with other tools, enabling a seamless CI pipeline that improves efficiency and bug identification. - Scenario: This approach is best for automating the CI pipeline, ensuring that builds happen quickly when code changes are made, and that bugs are caught early in the development process. C) Use Spinnaker to automate deploying container images to the product...

Author: Charlotte · Last updated Jul 4, 2026

Your team is developing an application in Google Cloud that executes with user identities maintained by Cloud Identity. Each of your application's users will have an associated Pub/Sub topic to which messages are published, and a Pub/Sub subscription where the same user will retrieve published messages. You need t...

To ensure that only authorized users can publish and subscribe to their own specific Pub/Sub topic and subscription, the key considerations are security (ensuring users can only access their own topics and subscriptions), granularity of access (permissions should be assigned as specifically as possible), and correct role management (assigning the appropriate permissions to ensure only the intended actions are allowed). Evaluation of the Options: A) Bind the user identity to the pubsub.publisher and pubsub.subscriber roles at the resource level. - Roles Involved: The `pubsub.publisher` role allows a user to publish messages to a Pub/Sub topic, and the `pubsub.subscriber` role allows them to subscribe to a subscription. - Granularity: Binding these roles to specific resources (i.e., topics and subscriptions) is the most granular and appropriate method for restricting access to only the user's specific topic and subscription. This ensures that users can only publish to and subscribe to their own topics and subscriptions, as opposed to broader access at the project level. - Why Selected: This is the most secure and appropriate approach because it provides fine-grained access control, limiting permissions to the individual resources (topics and subscriptions) that are associated with each user. It ensures users cannot access resources they are not authorized to use. - Scenario: This approach is perfect for scenarios where each user must have access to their own set of Pub/Sub resources (topics and subscriptions) and not others. B) Grant the user identity the pubsub.publisher and pubsub.subscriber roles at the project level. - Roles Involved: Granting roles at the project level would give users the ability to publish to and subscribe to any Pub/Sub topic and subscription within that project, not just their own. - Why Rejected: This approach is too broad and does not restrict users to their own resources. It violates the requirement of ensuring users can only access their own specific topic and subscription. It would grant excessive permissions to users across the entire project. - Scenario:...

Author: Amira99 · Last updated Jul 4, 2026

You are evaluating developer tools to help drive Google Kubernetes Engine adoption and integration with your development environment,...

To evaluate developer tools that drive Google Kubernetes Engine (GKE) adoption and integrate with development environments such as VS Code and IntelliJ, the key factors to consider are: 1. Seamless integration with IDEs: The tool should work smoothly within the existing developer environment, providing a frictionless experience in terms of coding, building, deploying, and debugging applications. 2. Kubernetes-specific features: Since you're using GKE, the tool should include features that support Kubernetes, containerized applications, and integration with GKE workflows. 3. Ease of use: The tool should be developer-friendly and help streamline workflows, reducing the need for switching between multiple interfaces. Evaluation of the Options: A) Use Cloud Code to develop applications. - Cloud Code Overview: Cloud Code is a set of extensions for popular IDEs like VS Code and IntelliJ. It provides powerful Kubernetes, Cloud Run, and GKE integrations directly inside these IDEs. It helps developers write, test, and deploy Kubernetes applications without leaving the development environment. Cloud Code allows features such as: - Kubernetes cluster management - YAML file validation for Kubernetes configurations - Support for Helm charts - Integration with Cloud Build and other Google Cloud services - Local Kubernetes cluster support via Minikube or Docker Desktop - Why Selected: Cloud Code integrates directly into your existing IDEs (VS Code and IntelliJ), making it the most seamless option for GKE adoption. It enhances the developer experience by providing Kubernetes-related tooling and cloud-native application management directly within the IDE, facilitating easier debugging and deployment of applications on GKE. - Scenario: Ideal for teams developing applications specifically on GKE or cloud-native applications that want a fully integrated experience in their IDE. B) Use the Cloud Shell integrated Code Editor to edit code and configuration files. - Cloud Shell Overview: Cloud Shell is a browser-based shell environment that allows you to manage your Google Cloud resources and edit code in a web-based IDE. The integrated Cloud Shell Editor can be used for editing code and configurations, but it's not as rich in Kubernetes-specific features as Cloud Code. - Why Rejected: While Cloud Shell is convenient for managing resources and editing code, it does not integrate directl...

Author: Nia · Last updated Jul 4, 2026

You are developing an ecommerce web application that uses App Engine standard environment and Memorystore for Redis. When a user logs into the app, the application caches the user's information (e.g., session, name, address, preferences), which is stored for quick retrieval during checkout. While testing your application in a browser...

To troubleshoot the 502 Bad Gateway error in your ecommerce web application, which is caused by the application not connecting to Memorystore for Redis, we need to evaluate the possible causes based on key factors like network connectivity between App Engine and Memorystore, region compatibility, VPC access, and firewall configurations. Evaluation of the Options: A) Your Memorystore for Redis instance was deployed without a public IP address. - Explanation: Memorystore for Redis instances can be configured with either private or public IP addresses. If your Memorystore instance is deployed without a public IP address and your App Engine is attempting to access it using a public IP, the connection will fail, potentially resulting in a 502 Bad Gateway error. - Why Rejected: However, App Engine standard environment cannot access Memorystore over a public IP address. It requires a private IP address to connect. This would not be the root cause in this case, as App Engine requires private IPs for connection to Memorystore, and if it was set up correctly, the error wouldn't likely be due to a missing public IP. - Scenario: If you were using another setup that tried connecting via public IP or if a custom configuration was applied, this option could apply. But App Engine requires private IP access for Memorystore, so this is unlikely the root cause. B) You configured your Serverless VPC Access connector in a different region than your App Engine instance. - Explanation: The Serverless VPC Access connector allows App Engine to communicate with services in a VPC, such as Memorystore. The connector and App Engine must be in the same region for communication to work. If the connector is in a different region than the App Engine instance, the application would fail to connect to Memorystore. - Why Selected: This is the most likely cause. If your Serverless VPC Access connector is in a different region than your App Engine instance, the network path would break, preventing communication with Memorystore. This scenario matches the symptoms you're experiencing, where the application can't connect to Memorystore, resulting in the 502 Bad Gateway error. - Scenario: This is the most likely issue if the setup includes a region mismatch between App Engine and the VPC connec...

Author: Akash · Last updated Jul 4, 2026

Your team develops services that run on Google Cloud. You need to build a data processing service and will use Cloud Functions. The data to be processed by the function is sensitive. You need to ensure that invocations can only happen from aut...

Let's break down each option in terms of security, compliance with Google-recommended best practices, and their suitability to ensure authorized access: A) Enable Identity-Aware Proxy in your project. Secure function access using its permissions. - Reasoning: Identity-Aware Proxy (IAP) is typically used to secure access to web applications running on Google Cloud, specifically for HTTP(S) based applications. However, Cloud Functions are serverless and can be invoked through HTTP triggers, but IAP is not the recommended method to secure Cloud Functions. IAP is more suited for securing web applications or services running on Google Cloud App Engine, Compute Engine, or Cloud Run. - Rejected Reason: This is not the best fit for Cloud Functions since it is tailored to securing HTTP-based services and adds unnecessary complexity when other solutions are more directly suited to securing Cloud Functions. - Scenario: Can be used in scenarios where HTTP-based services need access control beyond simple authentication, but not ideal for Cloud Functions. B) Create a service account with the Cloud Functions Viewer role. Use that service account to invoke the function. - Reasoning: The Cloud Functions Viewer role is designed to allow a user or service to view functions, not to invoke them. For invoking functions, a more specific role such as `Cloud Functions Invoker` is needed. Using this role would not allow the service account to invoke the function. - Rejected Reason: This role provides read-only access to Cloud Functions and is not suitable for securing invocation. - Scenario: Can be used if you only need to view the Cloud Function's configuration or metadata but not to invoke the function. C) Create a service account with the Cloud Functions Invoker role. Use that service account to invoke the function. - Reasoning: The Cloud Functions Invoker role is specifically design...

Author: Olivia · Last updated Jul 4, 2026

You are deploying your applications on Compute Engine. One of your Compute Engine instances failed t...

Let's analyze each option based on its relevance to troubleshooting a failed Compute Engine instance launch: A) Determine whether your file system is corrupted. - Reasoning: File system corruption could cause issues during the boot process or make an instance unresponsive. However, it is typically not the first thing to check when a Compute Engine instance fails to launch because file system corruption generally happens after an instance has successfully started. It's less likely to be the cause of the launch failure. - Rejected Reason: This is a potential cause for issues once the instance is running, but it is not the most common reason for a failed instance launch. - Scenario: Useful when an instance is running but exhibiting problems, such as crashes or slow performance, due to file system corruption. B) Access Compute Engine as a different SSH user. - Reasoning: If you are unable to access your instance via SSH because the primary SSH user is not configured correctly, you can attempt to access the instance using a different SSH user (if multiple users are set up). However, this step is typically useful after the instance has started and you are trying to access it. If the instance failed to launch, SSH access may not be possible, making this a less relevant option. - Rejected Reason: If the instance has failed to launch, you will not be able to SSH into it, regardless of the user. Accessing the instance as a different SSH user is more useful once the instance has started but is not helpful for launch issues. - Scenario: Can be used if the instance is running but SSH access issues arise (wrong SSH key, incorrect user setup, etc.). C) Troubleshoot firewall rules or routes on an instance. - Reasoning: Firewall rules and routes generally affect network connectivity after the instance has started. If the instance is failing to launch, this is not the most immediate factor to consider. If the instance is launched but cannot communicate over the network, firewall issues might be at play, but this is unlik...

Author: Akash · Last updated Jul 4, 2026

Your web application is deployed to the corporate intranet. You need to migrate the web application to Google Cloud. The web application must be available only to company employees and accessible to employees as they travel. You need to ensure the ...

Let's break down each option based on the requirements: ensuring security and accessibility of the web application, minimizing application changes, and providing access to employees both inside and outside the company network. A) Configure the application to check authentication credentials for each HTTP(S) request to the application. - Reasoning: Adding authentication logic directly to the application is a valid way to secure access to it. However, this requires modifying the application itself, which the requirement states should be minimized. This approach may also add complexity to your application, as you would need to handle user authentication, session management, and secure storage of credentials. - Rejected Reason: This involves significant application changes, which contradicts the requirement of minimizing changes to the application. Additionally, implementing secure authentication on your own increases the risk of mistakes and vulnerabilities. - Scenario: Suitable if the application must be highly customized for authentication, but not ideal in this case as it requires major changes to the web app. B) Configure Identity-Aware Proxy to allow employees to access the application through its public IP address. - Reasoning: Identity-Aware Proxy (IAP) is a Google Cloud service that helps you secure access to applications by verifying the identity of users before allowing access. With IAP, you can control access to web applications based on user identity, and you can restrict access to only company employees, ensuring that only authorized users can access the application. This can be done without modifying the web application itself. IAP works seamlessly for both internal and external users, enabling secure access even when employees are traveling. - Selected Reason: IAP is the best fit for this use case, as it requires minimal application changes and ensures secure, identity-based access. It provides an easy way to control who can access the application (only company employees) and ensures the web application is only available to authorized users, regardless of their location. - Scenario: Ideal for applications that need to remain unchanged and be securely accessible both from within the corporate network and externally by employees. C) Configure a Compute Engine instance that requests users to log in to their corporate account. Change the web application DNS t...

Author: Isabella · Last updated Jul 4, 2026

You have an application that uses an HTTP Cloud Function to process user activity from both desktop browser and mobile application clients. This function will serve as the endpoint for all metric submissions using HTTP POST. Due to legacy restrictions, the function must be mapped to a domain that is separate from the domain requested by users on web or mobile sessions. The domain for the Cloud Function is https://fn.example.com. Desktop and mobile clients use the domain htt...

Let's analyze each option based on the requirement that only browser and mobile sessions from the domain https://www.example.com can submit metrics to the Cloud Function, and the domain for the Cloud Function is https://fn.example.com. A) Access-Control-Allow-Origin: - Reasoning: The `Access-Control-Allow-Origin` header with `` allows any origin to access the resource, effectively making the Cloud Function publicly accessible from any domain. This is not secure and would allow requests from any domain, which violates the requirement to restrict access only to the domain https://www.example.com. - Rejected Reason: This would allow any domain to submit metrics to the Cloud Function, which is not desired in this case as we need to restrict access to specific domains. - Scenario: This could be used when you want to allow all domains to access the Cloud Function, which is not suitable for this situation. B) Access-Control-Allow-Origin: https://.example.com - Reasoning: The wildcard (``) is not supported within a subdomain pattern in CORS headers. Therefore, using `https://.example.com` would not work to match all subdomains of `example.com` (like `www.example.com` and others). The CORS standard does not allow the use of wildcards in domain names, so this would not be effective. - Rejected Reason: The wildcard `` inside the domain name is not valid syntax for the CORS `Access-Control-Allow-Origin` header. - Scenario: This might be considered if CORS supported wildcard subdomains, but that is not the case, so it doesn't work here. C) Access-Control-Allow-Origin: https://fn....

Author: Ahmed · Last updated Jul 4, 2026

You have an HTTP Cloud Function that is called via POST. Each submission's request body has a flat, unnested JSON structure containing numeric and text data. After the Cloud Function completes, the collected data should be immediately availa...

Let's analyze each option based on the requirement to persist the POST request data for ongoing and complex analytics, ensuring that the data is available for many users to analyze in parallel. A) Directly persist each POST request's JSON data into Datastore. - Reasoning: Datastore is a NoSQL database designed for low-latency read and write operations. However, it’s not optimized for complex analytics or large-scale analytics queries. While Datastore could store flat, unnested JSON data, it's not designed for high-performance, parallel analytics or complex querying over large datasets. For analytical use cases, a more suitable storage solution is needed. - Rejected Reason: Datastore is not designed for complex analytics. It is more suited for simple key-value lookups and basic querying but lacks the powerful query capabilities required for extensive analytics. - Scenario: Datastore is useful for low-latency transactional applications, but not ideal for analytics-heavy use cases. B) Transform the POST request's JSON data, and stream it into BigQuery. - Reasoning: BigQuery is a fully managed, serverless data warehouse designed specifically for complex analytics on large datasets. It can handle large-scale parallel queries efficiently, making it ideal for analytics purposes. Since the request data is JSON and could be transformed into a format suitable for BigQuery (e.g., flattened to columns), streaming this data into BigQuery would allow ongoing complex analytics by many users in parallel. - Selected Reason: BigQuery is optimized for fast, large-scale data analysis, and streaming data into it directly would ensure that the data is immediately available for complex queries. It is highly scalable and well-suited for the requirement of allowing analytics by multiple users in parallel. - Scenario: This is the best solution for analytics-heavy workloads, especially when complex queries need to be run concurrently by many users. BigQuery’s scalability and optimization for analytics make it ideal for this case. C) Transform the POST request's JSON data, and store it in a regional Cloud SQL cluster. - Reasoning: Cloud SQL...

Author: Lucas · Last updated Jul 4, 2026

Your security team is auditing all deployed applications running in Google Kubernetes Engine. After completing the audit, your team discovers that some of the applications send traffic within the cluster in clear text. You need to ensure that all application traffic is encrypted as ...

To address the requirement of encrypting all application traffic in the cluster while minimizing changes to your applications and maintaining support from Google, we should evaluate the given options based on key factors like minimal application changes, speed of implementation, and supported solutions in GKE (Google Kubernetes Engine). Option Breakdown: A) Use Network Policies to block traffic between applications: - Reasoning: Network policies can restrict traffic between applications at the IP or port level but do not provide encryption. They can control traffic flow but will not encrypt the communication, which is the main requirement here. - Rejected because: Network Policies are useful for segmentation and controlling traffic but do not directly address encryption, which is needed for secure communication between applications. B) Install Istio, enable proxy injection on your application namespace, and then enable mTLS: - Reasoning: Istio is a service mesh that provides comprehensive solutions for managing microservices, including automatic encryption of traffic using mTLS (Mutual Transport Layer Security). Enabling Istio with mTLS will ensure that communication between services is encrypted by default without requiring significant changes to the applications themselves. - Rejected because: Although Istio provides encryption and minimal changes to applications, it requires some installation and setup of Istio components within the Kubernetes cluster. However, it’s well-supported in GKE and allows for quick and robust encryption. This is the most suitable...

Author: Leo · Last updated Jul 4, 2026

You migrated some of your applications to Google Cloud. You are using a legacy monitoring platform deployed on-premises for both on-premises and cloud- deployed applications. You discover that your notification system...

When faced with the issue of slow response times for notifications from a legacy monitoring platform while running cloud applications, it’s important to consider solutions that can optimize performance, align with cloud-native services, and minimize complexity. Let's evaluate each option based on these factors. Option Breakdown: A) Replace your monitoring platform with Cloud Monitoring: - Reasoning: Google Cloud Monitoring (formerly Stackdriver) is a fully managed service built to work with Google Cloud resources and applications. It provides real-time monitoring, alerting, and dashboards specifically designed for the cloud, making it highly efficient and integrated with GCP. - Why selected: Replacing the legacy monitoring system with Cloud Monitoring ensures seamless integration with your cloud applications, providing quicker notification and better scalability. It minimizes overhead and optimizes response times for time-critical alerts. Cloud Monitoring is also optimized for low latency and high efficiency in cloud environments. - Rejected because: The legacy system might still be useful for monitoring on-premises applications, but Cloud Monitoring should be prioritized for cloud applications where performance and integration are crucial. B) Install the Cloud Monitoring agent on your Compute Engine instances: - Reasoning: Installing the Cloud Monitoring agent on Compute Engine instances will enable monitoring of these specific resources. However, it doesn't address the overall issue of notification delays or slow responses across the broader application set, and it’s still somewhat tied to a fragmented monitoring setup. - Rejected because: While the agent helps with monitoring specific instances, it doesn’t resolve the notification delay problem comprehensively across the entire cloud environment. It is a partial solution, and doesn’t fully address integration or performa...

Author: Andrew · Last updated Jul 4, 2026

You recently deployed your application in Google Kubernetes Engine, and now need to release a new version of your application. You need the ability to instantly roll back to the previous version i...

To address the need for quick rollback capabilities while deploying a new version of an application on Google Kubernetes Engine (GKE), we must choose a deployment model that allows for easy and fast reversion to the previous version in case issues arise with the new version. Let’s evaluate each option: Option Breakdown: A) Perform a rolling deployment, and test your new application after the deployment is complete: - Reasoning: A rolling deployment gradually updates pods with the new version of the application. This approach minimizes downtime but does not provide an immediate rollback option. While Kubernetes can roll back automatically to a previous version if something goes wrong during the deployment, the rollback is not instant and may take some time. - Rejected because: While this model is good for continuous updates and reducing downtime, it lacks the immediate rollback feature you are looking for, as the rollback is done incrementally and requires more time to reverse changes compared to models like blue/green. B) Perform A/B testing, and test your application periodically after the new tests are implemented: - Reasoning: A/B testing typically involves serving traffic to two different versions of an application to compare them. This model is used for testing and experimentation rather than deployments. It does not inherently support quick rollbacks or a controlled release of a new version. - Rejected because: A/B testing is not primarily designed for deployment management or quick rollbacks. It focuses more on gathering performance data and user feedback and is less relevant for situations where immediate rollback is crucial. C) Perform a blue/green deployment, and test your new application after the deployment is complete: - Reasoning: A blue/green deployment involves havi...

Author: Alexander · Last updated Jul 4, 2026

You developed a JavaScript web application that needs to access Google Drive's API and obtain permission from users to store files in their Google Drives. You need to s...

To access Google Drive's API and obtain permission from users to store files in their Google Drive, your application needs to authenticate and authorize users. The key factor here is that user consent is required to access their Google Drive, which helps ensure the security and privacy of user data. Let’s evaluate each option to determine the best approach for this scenario. Option Breakdown: A) Create an API key: - Reasoning: An API key is a simple way to authenticate requests, but it does not provide user authentication or authorization. API keys are suitable for accessing public data or for services where user consent is not required. They are also not suitable when accessing personal user data like Google Drive, where explicit user permission is necessary. - Rejected because: API keys cannot facilitate user consent or permission and are not appropriate for accessing private user data, such as files in Google Drive. B) Create a SAML token: - Reasoning: SAML (Security Assertion Markup Language) tokens are used primarily for Single Sign-On (SSO) authentication within enterprise environments. They are not designed for user authentication or authorization for public-facing APIs, especially in the context of web applications accessing third-party services like Google Drive. - Rejected because: SAML tokens are used for identity federation in enterprise settings and are not relevant to authenticating and obtaining user permissions for a web application to access Google Drive. C) Create a service account: - Reasoning: Service accounts are typically used for server-to-server authentication where ...

Author: Mia · Last updated Jul 4, 2026

You manage an ecommerce application that processes purchases from customers who can subsequently cancel or change those purchases. You discover that order volumes are highly variable and the backend order-processing system can only process one request at a time. You want to ensure seamless performance for customers regardless of us...

In this scenario, the main challenge is that the order-processing system can only handle one request at a time, but you want to ensure seamless performance for customers while also guaranteeing that order updates are processed in the exact sequence in which they were generated. Let's evaluate each option to determine the best approach: Option Breakdown: A) Send the purchase and change requests over WebSockets to the backend: - Reasoning: WebSockets provide a full-duplex communication channel between the client and the server, which is well-suited for real-time applications. However, in this case, the backend can only process one request at a time, and WebSockets do not inherently provide sequencing or ordering of requests. This can be a challenge, especially when requests arrive out of order. - Rejected because: While WebSockets allow for real-time communication, they don't solve the problem of sequencing and managing the order of requests, especially under high volumes. WebSockets are typically more useful in scenarios requiring bidirectional, low-latency communication but are not ideal for ensuring the sequential processing of requests in this case. B) Send the purchase and change requests as REST requests to the backend: - Reasoning: REST requests can be used for communication with the backend, but they are typically stateless and do not guarantee ordering or sequencing of requests. Additionally, REST doesn't provide any inherent mechanism to control or manage high traffic volumes or to ensure requests are processed sequentially when the backend is single-threaded. - Rejected because: While RESTful APIs are common and can handle customer requests, they don’t handle ordering of requests in the sequence that they arrive, nor do they provide a mechanism for efficiently managing high traffic or ensuring that updates are processed sequentially. C) Use a Pub/Sub subscriber in pull mode and use a data store to manage ordering: - Reasoning: Pub/Sub in pull mode allows the backend to retrieve messages from the Pub/Sub service as needed. I...

Author: Aria · Last updated Jul 4, 2026

Your company needs a database solution that stores customer purchase history and meets the following requirements: * Customers can query their purchase immediately after submission. * Purchases can be sorted on a variety of fields. * D...

To determine the best database solution for storing customer purchase history, let’s analyze each option based on the stated requirements: Requirements Recap: 1. Immediate querying of customer purchase history after submission. 2. Ability to sort purchases on a variety of fields. 3. Storing distinct record formats simultaneously. Option Analysis: A) Firestore in Native mode - Strengths: - Immediate Querying: Firestore provides real-time synchronization, allowing customers to query their data immediately after submission. - Flexibility: It supports complex queries and can scale horizontally. You can query on various fields, including nested data. - Distinct Record Formats: Firestore supports flexible schema design, allowing you to store diverse formats (e.g., text, numbers, arrays, etc.). - Weaknesses: - Query Complexity: While Firestore allows for sorting and filtering, complex queries may not be as efficient as SQL-based systems for highly relational data. Some advanced queries might require careful indexing and may not be as performant as other solutions when dealing with very complex or large datasets. B) Cloud Storage using an object read - Strengths: - Scalability: Cloud Storage can handle very large amounts of data, and it's good for storing objects such as images, large logs, or files. - Record Formats: Cloud Storage supports different object types and formats (JSON, XML, CSV, etc.). - Weaknesses: - No Querying Capabilities: Cloud Storage is essentially a file storage service, and it doesn’t provide built-in query support like databases. Customers can only retrieve the entire file or object; sorting and querying on specific fields would require custom solutions, making it a poor fit for real-time querying and sorting on multiple fields. - No Real-time Updates: New purchase history data won’t be immediately accessible for querying unless the data is processed externally. C) Cloud SQL using a SQL SELECT statement - Strengths: - Immediate Querying: SQL databases like Cloud SQL (which supports PostgreSQL, MySQL, etc.) allow immediate querying and efficient querying of data with complex SQL SELECT stat...

Author: Emma Brown · Last updated Jul 4, 2026

You recently developed a new service on Cloud Run. The new service authenticates using a custom service and then writes transactional information to a Cloud Spanner database. You need to verify that your application can support up to 5,000 read and 1,000 write transactions per sec...

To determine the best approach for verifying that your Cloud Run service can handle 5,000 read and 1,000 write transactions per second while identifying potential bottlenecks, we need to consider the following requirements: - Ability to autoscale the infrastructure for testing purposes. - Scalability and flexibility of the test to simulate realistic load. - Analyzing performance and identifying bottlenecks in a Cloud-native environment. Let’s break down each option: A) Build a test harness to generate requests and deploy it to Cloud Run. Analyze the VPC Flow Logs using Cloud Logging. - Strengths: - Autoscaling: Cloud Run automatically scales based on the incoming request load, which can simulate varying levels of traffic. - Cloud-native solution: This approach works well in the context of a serverless architecture (Cloud Run), where you can generate load within the same environment. - Logging: VPC Flow Logs with Cloud Logging can provide insights into network traffic and help identify potential bottlenecks. - Weaknesses: - Complexity of test generation: Building a custom test harness may involve significant development effort and may not be as straightforward as using dedicated load-testing tools. - Limited Test Visibility: While VPC Flow Logs can help with network traffic analysis, they are not as rich or focused on the detailed performance analysis of the service itself as other monitoring tools (like Cloud Trace or Cloud Monitoring). This option is feasible but might require extra work to set up the test harness and to gain deeper insights into specific bottlenecks in Cloud Run. B) Create a Google Kubernetes Engine (GKE) cluster running the Locust or JMeter images to dynamically generate load tests. Analyze the results using Cloud Trace. - Strengths: - Dynamic Load Testing: Both Locust and JMeter are powerful tools for load testing, and they can simulate a large volume of requests with fine-grained control. - Autoscaling: GKE can be configured to autoscale based on the load, allowing for scalable test environments. - Detailed Insights: Cloud Trace would give deep insights into latency, distributed traces, and bottlenecks across services (such as the custom service and Cloud Spanner interactions). - Weaknesses: - Complexity: Setting up a GKE cluster and running a load-testing tool within it adds more complexity compared to other options, especially when working with autoscaling and managing infrastructure. - Overkill for a Cloud Run-based Service: GKE introduces more overhead compared to simpler serverless solutions like Cloud Run, making it less suited for a service already running on Cloud Run. While this option is powerful and provides rich load-testing capabilities, it may be overly complex for testing a Cloud Run service, especially when you already have Cloud-native solutions that can handle autoscaling more easily. C) Create a Cloud Task to generate a test load. Use Cloud Scheduler to run 60,000 Cloud...

Author: Emma · Last updated Jul 4, 2026

You are using Cloud Build for your CI/CD pipeline to complete several tasks, including copying certain files to Compute Engine virtual machines. Your pipeline requires a flat file that is generated in one builder in the pipeline to be accessible by subsequent bui...

To determine the best approach for sharing a flat file between builders in a Cloud Build CI/CD pipeline, we need to evaluate the available options based on factors like accessibility, ease of use, scalability, and compatibility within the CI/CD environment. Option Analysis: A) Store and retrieve the file contents using Compute Engine instance metadata. - Strengths: - Easy to access metadata: Metadata on Compute Engine instances is easily accessible and allows passing data to and from the instance. - Weaknesses: - Not Ideal for Cloud Build: Cloud Build is a managed service running in containers, and it does not inherently use or store data in Compute Engine instance metadata. Using instance metadata is not a recommended approach for persisting data between Cloud Build steps, especially because it's not designed to share data between steps within a pipeline. - Not Persistent or Accessible Across Steps: Compute Engine metadata is typically tied to individual instances and wouldn’t persist across Cloud Build pipeline steps in a way that’s easily accessible. This option is not suitable because Cloud Build is a containerized environment, and Compute Engine instance metadata is not designed for sharing files between build steps. B) Output the file contents to a file in /workspace. Read from the same /workspace file in the subsequent build step. - Strengths: - Built-in Cloud Build Feature: The `/workspace` directory is shared across all steps within the same Cloud Build job. Any file written to `/workspace` in one step is automatically available to subsequent steps. - Simple to Implement: This is a native solution within Cloud Build that requires no external services and automatically works across all steps in the pipeline. - Weaknesses: - Limited to Single Build: This solution works only within a single Cloud Build pipeline. If you need to persist the file across different pipeline runs or across other services, it may not be suitable. This is a great solution if you need the file to be accessible across different steps within a single Cloud Build job. It’s simple, efficient, and designed specifically for Cloud Build's use case. C) Use gsutil to output the file contents to a Cloud Storage object. Read from the same object in the subsequent build step. - Strengths: - Persistent Storage: Cloud Storage is highly durable and persistent. If you need the file to be available across different pipeline runs or need to store the file ...

Author: Joseph · Last updated Jul 4, 2026

Your company's development teams want to use various open source operating systems in their Docker builds. When images are created in published containers in your company's environment, you need to scan them for Common Vulnerabilities and Exposures (CVEs). The scanning proc...

To choose the best approach for scanning Docker images for Common Vulnerabilities and Exposures (CVEs) without impacting software development agility, let's analyze each option based on key factors like integration with existing systems, ease of implementation, and maintaining agile workflows. Option Analysis: A) Enable the Vulnerability scanning setting in the Container Registry. - Strengths: - Managed Service: Container Registry integrates with Google Cloud’s vulnerability scanning, making it a straightforward, managed solution. It automates the scanning of images stored in the registry for known vulnerabilities (CVEs) as they are pushed to the registry. - Non-invasive: The scan happens after the image is created and stored, meaning it doesn't interrupt development workflows or slow down the image build process. - Automated and Continuous: Scanning occurs every time a new image is uploaded to the registry, ensuring continuous security checks without manual intervention. - Weaknesses: - Limited to Google Cloud Registry: This solution is tightly integrated with Google Cloud’s Container Registry, meaning that teams using other container registries may face limitations. - After-the-fact: While scanning the image in the registry is beneficial, vulnerabilities are detected after the build process, so teams will only know about vulnerabilities post-build. This option is optimal for security automation within the container ecosystem and minimizes the impact on development speed, making it a great choice for CI/CD pipelines using Docker. B) Create a Cloud Function that is triggered on a code check-in and scan the code for CVEs. - Strengths: - Early Detection: Scanning code at the commit level can catch vulnerabilities early in the development cycle. - Flexibility: You can customize the Cloud Function to scan for CVEs or other security issues according to your own requirements. - Weaknesses: - Manual and Complex Setup: Setting up a Cloud Function to perform vulnerability scans on each code check-in requires significant custom development. It can be complex to maintain, and would likely slow down the development cycle if it triggers each time code is checked in. - Not Optimal for Containers: This solution doesn’t directly focus on the container image or its dependencies. Vulnerabilities in base images or the Dockerfile itself may go undetected unless additional layers of scanning are implemented. While useful for code-level vulnerability scanning, this solution is not tailored for container image security and may create friction in the development process due to additional scanning steps and complexity. C)...

Author: Lucas · Last updated Jul 4, 2026

You are configuring a continuous integration pipeline using Cloud Build to automate the deployment of new container images to Google Kubernetes Engine (GKE). The pipeline builds the application from its source code, runs unit and integration tests in separate steps, and pushes the container to Container Registry. The application runs on a Python web server. The Dockerfile is as follows: FROM python:3.7-alpine - COPY . /app - WORKDIR /app - RUN pip install -r re...

To optimize the build time in your continuous integration (CI) pipeline for deploying container images to Google Kubernetes Engine (GKE), let’s evaluate each option based on how it can help improve efficiency and reduce build time. Option Analysis: A) Select a virtual machine (VM) size with higher CPU for Cloud Build runs. - Strengths: - Potential Performance Boost: Selecting a higher CPU machine could increase the processing speed, allowing the build process (including code compilation, testing, and Docker image creation) to complete faster. This could benefit the build time, especially for computationally intensive steps. - Weaknesses: - Cost Implications: Higher CPU VMs would increase the cost of Cloud Build runs. While it might speed up the builds, this option might not be the most efficient in terms of balancing cost with performance. It's also not a solution that targets the underlying inefficiencies in the build process (such as redundant steps or slow Docker image builds). - Doesn't address root causes: This may improve performance slightly but doesn't address specific areas like Docker image layer caching or reducing redundant steps, which are typically where optimization is needed. This option might help improve performance slightly, but it's not the most effective way to tackle longer build times. We’ll look for other options that address build optimizations more directly. B) Deploy a Container Registry on a Compute Engine VM in a VPC, and use it to store the final images. - Strengths: - Potential for Customization: Having a custom Container Registry could provide more control over how images are stored and accessed. - Weaknesses: - Increased Complexity: Setting up a custom Container Registry on a Compute Engine VM adds unnecessary complexity to your CI/CD pipeline. It's not necessary because Google Container Registry (GCR) and Artifact Registry are already managed services optimized for storing container images. - No direct impact on build time: This does not address the core issues affecting the build time. The bottleneck is in the build process itself, not the storage of images. This option is not ideal because it complicates the pipeline setup and does not improve the actual build time. The existing Container Registry is sufficient for this use case. C) Cache the Docker image for subsequent builds using the --cache-from argument in your build config file. - Strengths: - Efficient Layer Caching: Using the `--cache-from` argument allows Docker to reuse layers from a previously built image, reducing the time spent on re-building unchanged layers. This can significantly speed up the build process, especially if there are no changes to the dependencies or code in certain layers. - Optimizes for Incremental Builds: This approach is especially useful in CI pipelines where images are built frequently and most layers don’t change between builds. - Weaknesses: - ...

Author: Julian · Last updated Jul 4, 2026

You are building a CI/CD pipeline that consists of a version control system, Cloud Build, and Container Registry. Each time a new tag is pushed to the repository, a Cloud Build job is triggered, which runs unit tests on the new code builds a new Docker container image, and pushes it into Container Registry. The last step of your pipeline should deploy the new container to your production Google Kubernetes Engine (GKE) cluster. You need to select a tool and deployment strategy t...

To meet the requirements outlined in the scenario, let's break down the pros and cons of each option: A) Trigger a Spinnaker pipeline configured as an A/B test of your new code and, if it is successful, deploy the container to production. - A/B Testing: A/B testing typically involves routing traffic to two different versions (A and B) of the application. This is useful for testing user behavior and performance metrics, but it's not directly focused on deployment and rollback strategies. Additionally, A/B testing requires careful control over how users are routed to different versions. - Drawback: It doesn't necessarily ensure zero downtime or ease of rollback, and testing might be user-facing, which isn’t ideal for ensuring full automation of testing before going live. A/B tests are more often used for feature comparison rather than deployment pipelines. - Rejection Reason: A/B testing doesn't directly satisfy the zero-downtime deployment and rollback requirements. B) Trigger a Spinnaker pipeline configured as a canary test of your new code and, if it is successful, deploy the container to production. - Canary Test: A canary deployment involves rolling out the new version of the application to a small subset of users first (the "canaries"). If everything works as expected, the rollout is gradually expanded until it reaches all users. This ensures zero downtime and allows you to fully test the new code in production-like conditions without impacting the majority of users. - Testing Before Rollout: Canaries are highly suitable for fully automated testing and allow for testing in production before fully rolling out to users. - Rollback: If the canary deployment fails, it can be easily rolled back since only a small subset of traffic was affected. - Benefits: This approach satisfies the zero-downtime requirement, allows for automated testing, and enables quick rollback. - Selected Option: This is a strong option that matches the requirements closely. C) Trigger another Cloud Build job that uses the Kubernetes CLI tools to deploy your new container to your GKE clu...

Author: Aria · Last updated Jul 4, 2026

Your operations team has asked you to create a script that lists the Cloud Bigtable, Memorystore, and Cloud SQL databases running within a project. The script should allow users to submit a f...

Let's analyze the options to determine the best approach for retrieving and filtering the database lists (Cloud Bigtable, Memorystore, and Cloud SQL) for a given project. A) Use the HBase API, Redis API, and MySQL connection to retrieve database lists. Combine the results, and then apply the filter to display the results. - Drawback: This approach relies on using APIs directly for each service (HBase API for Cloud Bigtable, Redis API for Memorystore, and MySQL connection for Cloud SQL). While this might be feasible, it introduces unnecessary complexity. APIs often require setting up connections, handling authentication, and managing data retrieval at a more granular level. Additionally, filtering data at the application level after retrieving all data can be inefficient and cumbersome. - Rejection Reason: This approach adds unnecessary complexity and manual steps, especially when the cloud-native `gcloud` commands are capable of fetching and filtering the data directly. B) Use the HBase API, Redis API, and MySQL connection to retrieve database lists. Filter the results individually, and then combine them to display the results. - Drawback: Like option A, this approach still requires using the APIs for each service and applying the filter manually after retrieving the data. This is again more complex than necessary, as the cloud-native `gcloud` CLI provides tools for retrieving and filtering the data directly. - Rejection Reason: This option is unnecessarily complex and doesn't take advantage of the built-in functionality provided by `gcloud` commands for listing and filtering resources. C) Run `gcloud bigtable instances list`, `gcloud redis instances list`, and `gcloud sql databases list`. Use a filter within the application, and then display the results. - Drawback: This approach...

Author: Amira · Last updated Jul 4, 2026

You need to deploy a new European version of a website hosted on Google Kubernetes Engine. The current and new websites must be accessed via the same HTTP(S) load balancer'...

Let's analyze the options based on the goal of deploying a new version of the website in Europe, while using the same external IP address but different domain names for the current and new versions of the website. A) Define a new Ingress resource with a host rule matching the new domain - Benefit: Creating a new Ingress resource with a host rule for the new domain allows you to specify routing rules for the new version of the website under the new domain. The load balancer would handle traffic and route it based on the host in the HTTP request. However, this option assumes that you will be creating a new Ingress resource without consideration for the existing IP address or other configurations. - Drawback: While defining a new Ingress resource allows you to handle the new domain, it might not guarantee the use of the same external IP address as the existing one unless explicitly managed. It doesn't directly address the requirement of using the same external IP address. B) Modify the existing Ingress resource with a host rule matching the new domain - Benefit: Modifying the existing Ingress resource adds a new host rule for the new domain. Since you're using the same Ingress, the existing load balancer configuration and external IP address remain unchanged. This is a simple and effective way to handle multiple domain names while routing traffic to different services in the cluster. - Drawback: This option works well for managing different domains under the same load balancer IP. However, if the new version requires significant changes to the backend configuration or services, you may want to ensure separate control over the routes. Still, in many scenarios, adding a new host rule to the existing Ingress is the most straightforward option. - Why It's Selected: This option meets the requirement of using the same external IP while routing traffic to different domains, and it avoids the complexity of creating new resources or managing IP addresses. ...

Author: FlamePhoenix2025 · Last updated Jul 4, 2026

What Our Friends Say

What Our Friends Say

Google Practice Questions, Discussions & Exam Topics by our Authors

You are developing a marquee stateless web application that will run on Google Cloud. The rate of the incoming user traffic is expected to be unpredictable, with no traffic on some days and large spikes on other days. You need the application to automatically s...

You have written a Cloud Function that accesses other Google Cloud resources. You want to secure the environment using t...

You are a SaaS provider deploying dedicated blogging software to customers in your Google Kubernetes Engine (GKE) cluster. You want to configure a secure multi-tenant platform to ensure that each customer has access ...

You have decided to migrate your Compute Engine application to Google Kubernetes Engine. You need to build a container image and push it to Artifac...

You are developing an internal application that will allow employees to organize community events within your company. You deployed your application on a single Compute Engine instance. Your company uses Google Workspace (formerly G Suite), and you nee...

You are developing a web application that will be accessible over both HTTP and HTTPS and will run on Compute Engine instances. On occasion, you will need to SSH from your remote laptop into one of the Compute Engine instances to conduct mainten...

You have a mixture of packaged and internally developed applications hosted on a Compute Engine instance that is running Linux. These applications write log records as text in loca...

You want to create `fully baked` or `golden` Compute Engine images for your application. You need to bootstrap your application to connect to the appropriate database according to the environ...

You are developing a microservice-based application that will be deployed on a Google Kubernetes Engine cluster. The application needs to read and write to a Spanner database. You want to follow security best practices while m...

You are deploying your application on a Compute Engine instance that communicates with Cloud SQL. You will use Cloud SQL Proxy to allow your application to communicate to the database using the service account associated with the application's instance. You want to follow the Googl...

Your team develops stateless services that run on Google Kubernetes Engine (GKE). You need to deploy a new service that will only be accessed by other services running in the GKE cluster. The service wil...

You recently migrated a monolithic application to Google Cloud by breaking it down into microservices. One of the microservices is deployed using Cloud Functions. As you modernize the application, you make a change to the API of the service that is backward-incompatible. You ...

You are developing an application that will allow users to read and post comments on news articles. You want to configure your application to store and display user-submitted comments using Firestore. ...

You recently developed an application. You need to call the Cloud Storage API from a Compute Engine instance that do...

You are a developer working with the CI/CD team to troubleshoot a new feature that your team introduced. The CI/CD team used HashiCorp Packer to create a new Compute Engine image from your development branch. The image was successfully bui...

Your team is developing an ecommerce platform for your company. Users will log in to the website and add items to their shopping cart. Users will be automatically logged out after 30 minutes of inactivity. When users log back in, their shopping cart should be saved. H...

You are designing a resource-sharing policy for applications used by different teams in a Google Kubernetes Engine cluster. You need to ensure that all applications c...

You are developing a new application that has the following design requirements: * Creation and changes to the application infrastructure are versioned and auditable. * The application and deployment infrastructure uses Google-managed services as much as possible...

You are creating and running containers across different projects in Google Cloud. The application you are developing needs to access Google Cloud servic...

You have containerized a legacy application that stores its configuration on an NFS share. You need to deploy this application to Google Kubernetes Engine (GKE) and do not want the application s...

Your team is developing a new application using a PostgreSQL database and Cloud Run. You are responsible for ensuring that all traffic is kept private on Google Cloud. You want to use m...

You are developing an application that will allow clients to download a file from your website for a specific period of time. How should you design the application t...

Your development team has been asked to refactor an existing monolithic application into a set of composable microservices. Which design aspec...

You deployed a new application to Google Kubernetes Engine and are experiencing some performance degradation. Your logs are being written to Cloud Logging, and you are using a Prometheus sidecar model for capturing metrics. You need to correlate the metrics and data from...

Your team develops services that run on Google Kubernetes Engine. Your team's code is stored in Cloud Source Repositories. You need to quickly identify bugs in the code before it is deployed to production. You want to invest in automat...

You are evaluating developer tools to help drive Google Kubernetes Engine adoption and integration with your development environment,...

Your team develops services that run on Google Cloud. You need to build a data processing service and will use Cloud Functions. The data to be processed by the function is sensitive. You need to ensure that invocations can only happen from aut...

You are deploying your applications on Compute Engine. One of your Compute Engine instances failed t...

Your web application is deployed to the corporate intranet. You need to migrate the web application to Google Cloud. The web application must be available only to company employees and accessible to employees as they travel. You need to ensure the ...

You have an HTTP Cloud Function that is called via POST. Each submission's request body has a flat, unnested JSON structure containing numeric and text data. After the Cloud Function completes, the collected data should be immediately availa...

Your security team is auditing all deployed applications running in Google Kubernetes Engine. After completing the audit, your team discovers that some of the applications send traffic within the cluster in clear text. You need to ensure that all application traffic is encrypted as ...

You migrated some of your applications to Google Cloud. You are using a legacy monitoring platform deployed on-premises for both on-premises and cloud- deployed applications. You discover that your notification system...

You recently deployed your application in Google Kubernetes Engine, and now need to release a new version of your application. You need the ability to instantly roll back to the previous version i...

You developed a JavaScript web application that needs to access Google Drive's API and obtain permission from users to store files in their Google Drives. You need to s...

Your company needs a database solution that stores customer purchase history and meets the following requirements: * Customers can query their purchase immediately after submission. * Purchases can be sorted on a variety of fields. * D...

You recently developed a new service on Cloud Run. The new service authenticates using a custom service and then writes transactional information to a Cloud Spanner database. You need to verify that your application can support up to 5,000 read and 1,000 write transactions per sec...

You are using Cloud Build for your CI/CD pipeline to complete several tasks, including copying certain files to Compute Engine virtual machines. Your pipeline requires a flat file that is generated in one builder in the pipeline to be accessible by subsequent bui...

Your company's development teams want to use various open source operating systems in their Docker builds. When images are created in published containers in your company's environment, you need to scan them for Common Vulnerabilities and Exposures (CVEs). The scanning proc...

Your operations team has asked you to create a script that lists the Cloud Bigtable, Memorystore, and Cloud SQL databases running within a project. The script should allow users to submit a f...

You need to deploy a new European version of a website hosted on Google Kubernetes Engine. The current and new websites must be accessed via the same HTTP(S) load balancer'...