Google Practice Questions, Discussions & Exam Topics by our Authors
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
In this scenario, HipLocal is experiencing occasional application failures in their APIs and needs to collect application-specific information to troubleshoot the issue. The solution must focus on gathering detailed, real-time application-level logs, metrics, and other performance data to identify the root cause of the problem.
Let's analyze each option:
Option A: Take frequent snapshots of the virtual machines.
- Explanation: Taking frequent snapshots of the virtual machines (VMs) is a method of capturing the current state of the VMs for recovery or backup purposes. However, snapshots are not helpful for troubleshooting application-level issues like API failures or performance bottlenecks.
- Drawbacks:
- Not Useful for Troubleshooting: Snapshots are more useful for data recovery in case of failures but do not provide real-time insights into application performance or issues.
- No Real-Time Data: This approach does not provide real-time application logs or metrics that can help diagnose intermittent application failures.
Rejected: This option does not address the need for troubleshooting application failures and does not provide useful data for performance analysis.
Option B: Install the Cloud Logging agent on the virtual machines.
- Explanation: Cloud Logging (formerly Stackdriver) can aggregate logs from various sources, including application logs. Installing the Cloud Logging agent on the VMs will enable the collection of logs generated by the applications running on those VMs.
- Benefits:
- Detailed Application Logs: It allows you to collect detailed logs for troubleshooting, including error messages, stack traces, and any other logging information produced by the application.
- Centralized Logging: Logs can be aggregated in a centralized location in Google Cloud, making it easier to monitor and analyze failures.
- Drawbacks:
- Not Enough for Complete Troubleshooting: While Cloud Logging provides valuable information, it doesn't give the full picture of application performance (such as latency or bottlenecks) in real time.
Selected: This is the most appropriate option because it will allow HipLocal to gather critical application logs for troubleshooting their API failures.
Option C: Install the Cloud Monitoring agent on the virtual mac...
Author: Daniel · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
In this case, HipLocal has connected their Hadoop infrastructure to Google Cloud Platform (GCP) using Cloud Interconnect in order to query data stored on persistent disks. To establish an appropriate IP strategy, we need to consider their goal of securely connecting their on-premises infrastructure to GCP and managing network traffic efficiently.
Let's evaluate the options:
Option A: Create manual subnets.
- Explanation: In Google Cloud, subnets are used to define IP address ranges for virtual private cloud (VPC) networks. Manual subnets allow you to specify custom IP ranges for your VPC. This approach is useful when you need complete control over the IP address space.
- Benefits:
- Flexibility: You can define your subnets and IP address ranges exactly as needed.
- Advanced Control: Useful for complex networking setups that require segmentation or detailed routing rules.
- Drawbacks:
- More Complexity: Setting up manual subnets can be complex and may require additional configuration, especially in larger, more dynamic environments.
- Not Ideal for Simplicity: HipLocal is aiming to reduce infrastructure management time and cost, so the complexity of manual subnets might not align with this goal.
Rejected: This option offers flexibility but adds unnecessary complexity, especially since HipLocal is looking to reduce management overhead.
Option B: Create an auto mode subnet.
- Explanation: In Google Cloud, VPC networks can be configured in "auto mode" or "custom mode." An auto mode VPC automatically creates subnets for each region with predefined IP ranges, which simplifies the networking setup.
- Benefits:
- Simplicity: Auto mode provides an easy and quick setup of subnets without having to define custom ranges.
- Standardized Setup: Ideal for less complex networking needs where predefined IP ranges and automatic subnet creation are sufficient.
- Easy to Scale: Automatically creates subnets in new regions, which is useful as HipLocal expands its footprint.
- Drawbacks:
- Less Flexibility: Auto mode might not provide the level of IP range customization that manual subnets do.
- Possible IP Range Conflicts: Since Google automatically assigns subnets, there’s a small chance of conflicts if HipLocal has very specific network requirements.
Selected: This is the best option because it simplifies the setup an...
Author: Liam · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
In this case, HipLocal needs to ensure secure and authorized access to internal apps while expanding globally and following Google Cloud's recommended practices. Here's an analysis of the options provided:
A) Cloud VPN
Cloud VPN connects on-premises networks to Google Cloud via an encrypted tunnel, allowing secure communication between different locations. While this provides secure access for applications, it's primarily used for connecting networks (e.g., on-premises to cloud) and does not specifically cater to controlling access to individual applications.
Rejection Reason:
- This service is ideal for inter-network communication rather than secure application-level access. HipLocal's requirement is to manage authorized access to internal apps, and Cloud VPN isn't focused on securing individual app access.
B) Cloud Armor
Cloud Armor is a security service that provides DDoS protection and WAF (Web Application Firewall) capabilities for applications running on Google Cloud. It’s primarily used to protect applications from external threats such as attacks.
Rejection Reason:
- While Cloud Armor provides security for apps, it's designed more for mitigating attacks rather than controlling access to internal applications in a secure, authenticated manner. It's not specifically geared toward ensuring authorized access to internal applications or dealing with user authentication.
C) Virtual Private Cloud (VPC)...
Author: Kunal · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
HipLocal is looking to reduce the number of on-call engineers and eliminate manual scaling, while adopting a more scalable and automated architecture. Here’s an analysis of each service option to determine which two will best support these goals:
A) Use Google App Engine services
Google App Engine (GAE) is a fully managed platform-as-a-service (PaaS) that automatically handles infrastructure, scaling, and provisioning. It abstracts away the need to manage servers, which fits HipLocal's requirement to reduce infrastructure management time and cost.
Reasons for selecting:
- GAE offers automatic scaling, meaning that it can automatically adjust resources based on demand, which would reduce the need for manual scaling and on-call engineers.
- GAE is serverless, aligning with HipLocal’s desire to move to a serverless architecture to handle elastic scaling.
- It integrates well with Google Cloud’s monitoring and logging services, which is part of HipLocal’s requirement to provide usage metrics and better understand user activity.
B) Use serverless Google Cloud Functions
Google Cloud Functions are event-driven, serverless functions that can scale automatically based on demand. Cloud Functions allow HipLocal to handle specific tasks such as processing API requests, performing analytics, and triggering actions without worrying about the underlying infrastructure.
Reasons for selecting:
- Cloud Functions are serverless and automatically scale based on demand, reducing the need for manual intervention and on-call engineers.
- They are event-driven and can be easily integrated into a microservices architecture, which allows HipLocal to scale specific parts of their app independently.
- Cloud Functions offer the ability to gather user activity metrics by processing events and logs, which fits HipLocal's requirement to better understand user activity and monetize the product.
C) Use Knative to build and deploy serverless applications
Knative is an open-source framework for deploying serverless applications on Kubernetes. While Knative can handle serverless workloads, it is typic...
Author: Henry · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
In order to meet HipLocal's business requirements and scale globally, particularly to handle an increasing number of concurrent users and ensure high availability, the method of storing application state becomes a critical decision. Let's analyze each option:
A) Use local SSDs to store state
Local SSDs offer high-speed storage but are tied to individual virtual machines (VMs) in a specific region. Local SSDs are temporary storage devices, and their data is lost if the VM is stopped or restarted, which makes them unsuitable for storing persistent state in a globally distributed application.
Rejection Reason:
- Local SSDs are not designed for persistent state storage in distributed applications, especially when global scaling is required.
- They do not provide the durability and availability needed for HipLocal's application, particularly as they expand into multiple regions.
B) Put a memcache layer in front of MySQL
Memcache can be used as a caching layer to accelerate database queries by storing frequently accessed data in memory. However, it is not suitable for persistent state storage because it does not provide durability, and it would be inefficient to rely solely on it for critical state data.
Rejection Reason:
- Memcache is intended for caching and not as a primary storage solution for application state.
- While it improves read performance, it doesn't meet the requirement of a persistent, scalable solution to store state in a globally distributed environment.
C) Move the state storage to Cloud Spanner
Cloud Spanner is a fully managed, horizontally scalable, relational database service that combines the features of traditional relational databases with the scalability of NoSQL. It offers global distribution, strong consistency, and high availability, making it a perfect...
Author: Benjamin · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
To determine the best service for HipLocal's public APIs, we need to consider several key factors such as API management, security, scalability, and monitoring. Let’s evaluate each option based on these requirements.
A) Cloud Armor
Google Cloud Armor is primarily used for protecting applications from DDoS (Distributed Denial of Service) attacks and providing security at the edge. It helps in securing web applications by filtering traffic, but it is not specifically designed for managing APIs.
Rejection Reason:
- Cloud Armor is a security service for protecting against external threats like DDoS attacks. While important for securing APIs, it doesn't provide the necessary functionality for API management, such as routing, monitoring, or managing usage.
- HipLocal’s requirement is to manage public APIs, which involves more than just protection from threats. It includes managing authentication, access control, monitoring, and scaling, which Cloud Armor does not offer.
B) Cloud Functions
Google Cloud Functions is a serverless compute service that allows you to run code in response to HTTP requests, events, or other triggers. It is well-suited for event-driven architectures and serverless functions but does not provide the full suite of API management features.
Rejection Reason:
- Cloud Functions is great for serverless code execution but does not directly manage APIs. While it can be used to handle API requests, it lacks API-specific management features like authentication, rate limiting, and analytics, which are necessary for a scalable and secure API service.
- HipLocal’s needs include proper API management, which Cloud Functions alone doesn’t fully address.
C) Cloud Endpoints
Cloud Endpoints is a fully managed API gateway that provides the features necessary for managing APIs, such as authentication, authorization, API monitoring, rate limiting, and logging. It is designed speci...
Author: Rahul · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
To determine the best configuration for improving the resilience of HipLocal's MySQL deployment while meeting both business and technical requirements, let’s analyze the options based on scalability, availability, and operational efficiency.
A) Use the current single instance MySQL on Compute Engine and several read-only MySQL servers on Compute Engine
This option involves maintaining the current single instance MySQL on Compute Engine and adding read-only MySQL replicas.
Rejection Reason:
- Scalability: This setup still relies on the single MySQL instance as the master, which remains a single point of failure. While read replicas can help with read traffic, they do not address the issue of failover and high availability for write operations.
- Operational Complexity: Managing MySQL instances on Compute Engine (including the setup of read replicas, backup management, and failover mechanisms) requires significant operational effort. This doesn’t align with the goal of reducing infrastructure management time and cost.
- Cloud-native benefits: The solution does not take full advantage of cloud-native features like automated failover and easy scaling, which would be beneficial as HipLocal expands globally.
B) Use the current single instance MySQL on Compute Engine, and replicate the data to Cloud SQL in an external master configuration
This option proposes keeping the current MySQL instance on Compute Engine and replicating it to a Cloud SQL instance in an external master configuration.
Rejection Reason:
- Operational Complexity: Using an external master configuration requires manual management of replication, failover, and consistency. This setup introduces operational overhead, as it needs to ensure that replication is properly configured and maintained.
- Scalability: The setup does not provide automatic high availability or scalability, which is necessary for handling growth and traffic in new regions. It also doesn’t reduce infrastructure management time, which is a key requirement.
- Cloud-native limitations: The solution does not make full use of cloud-native features like automatic failover or integrated redundancy, which would be beneficial for ensuring consistent uptime and ease of management.
C) Replace the current single instance MySQL instance with Cloud SQL, and configure high availability
This option suggests replacing the MySQL instance with Cloud SQL and enabling high availability.
Reasons for selecting:
- High Availabili...
Author: Oscar · Last updated Jul 4, 2026
Your application is running in multiple Google Kubernetes Engine clusters. It is managed by a Deployment in each cluster. The Deployment has created multiple replicas of your Pod in each cluster. You want to view the logs sent t...
To view the logs for all replicas in your Deployment across multiple Google Kubernetes Engine (GKE) clusters, you need a command that can aggregate the logs from multiple pods (which are distributed across different clusters). Let's analyze each option:
Option A: `kubectl logs [PARAM]`
- Explanation: `kubectl logs` is used to fetch the logs for a specific Pod or container. If you have multiple pods across multiple clusters, you would have to run this command for each individual pod, which makes it cumbersome when dealing with multiple clusters and replicas.
- Rejected: This option only shows logs from one pod at a time, so it's inefficient for viewing logs from all replicas in all clusters simultaneously.
Option B: `gcloud logging read [PARAM]`
- Explanation: This command allows you to query logs stored in Google Cloud's Logging (formerly Stackdriver). This service can aggregate logs across multiple clusters and services, making it a more appropriate choice for centralized logging.
- Selected: This option would allow you to fetch logs from all of your clusters as long as logging is enabled and configured properly in your GKE environment. It's the most efficient way to get logs from multiple clusters at once.
Option C: `kubectl exec ... journalctl`
- Explanation:...
Author: Aditya · Last updated Jul 4, 2026
You are using Cloud Build to create a new Docker image on each source code commit to a Cloud Source Repositories repository. Your application is built on every commit to the master branch. You want to releas...
To release specific commits to the master branch in an automated manner using Cloud Build, let's analyze each option and the factors involved:
Option A: Manually trigger the build for new releases
- Explanation: This approach involves manually triggering the build process when a new release is needed. While this would allow you to release specific commits, it is not automated and requires human intervention to start the build process each time a release is made.
- Rejected: Since the goal is to automate the release process, this option does not meet the requirement. It requires manual effort, making it less efficient and not scalable for automated releases.
Option B: Create a build trigger on a Git tag pattern. Use a Git tag convention for new releases
- Explanation: This is a very effective approach for automating releases. You can configure a build trigger in Cloud Build to automatically trigger the build process whenever a Git tag matching a specific pattern is pushed to the master branch. Using a Git tag convention (e.g., `v1.0.0`, `release-1.0`, etc.) for new releases allows you to control exactly which commits are included in a release, as tags are typically used for marking stable points in a repository.
- Selected: This option is optimal for automating the release process because it allows you to release specific commits in a controlled manner through Git tags, and Cloud Build will automatically trigger builds for those tagged commits. This method is ideal when releases are defined by version tags and you need automated deployments for each release.
Option C: Create a build trigger on a Git branch name pattern. Use a Git branch naming convention for new releases
- Explanation: While this app...
Author: Manish · Last updated Jul 4, 2026
You are designing a schema for a table that will be moved from MySQL to Cloud Bigtable. The MySQL table is as follows:
How shoul...
When designing a row key for Cloud Bigtable, it's crucial to select a key that will ensure efficient access patterns for the data you intend to query. Let's analyze each option based on typical usage patterns in Bigtable and consider the trade-offs:
Option A: Set Account_id as a key
- Explanation: Setting just the `Account_id` as the row key is a simple approach, but it can lead to inefficient querying in some cases. If you're accessing the table by `Event_timestamp` or if your data is concentrated around specific account IDs (e.g., some account IDs have many events), it could cause hotspots, where requests for specific accounts overwhelm a subset of Bigtable nodes. This could result in poor performance.
- Rejected: This option doesn't account for the time-based nature of event data and could lead to uneven distribution of load across Bigtable nodes, causing performance bottlenecks.
Option B: Set Account_id_Event_timestamp as a key
- Explanation: Combining `Account_id` and `Event_timestamp` as the row key ensures that data is grouped by account and ordered by event timestamp. This approach is great for queries that require accessing all events for a specific account in chronological order. The data will be organized by account ID, and within each account, the events will be sorted by timestamp. This is a typical pattern for time-series data, which is often used in Bigtable.
- Selected: This option is well-suited for both efficient access to data by account and timestamp and avoiding hotspots. It allows efficient retrieval of all events for a given account while maintaining chronological order within the account. It's the best approach when querying by account and timestamp is common.
Option C: Set Event_timestamp_Account_id as a ...
Author: Akash · Last updated Jul 4, 2026
You want to view the memory usage of your application deployed on Compute Engine.
What should you d...
To view the memory usage of your application deployed on Compute Engine, you need a method that allows you to monitor system-level metrics like CPU and memory usage. Let's analyze each option:
Option A: Install the Stackdriver Client Library
- Explanation: The Stackdriver Client Library is used for integrating monitoring and logging features into your application code. This library helps send custom metrics, logs, and trace data from your application to Google Cloud. However, it is primarily used to monitor application-specific metrics rather than system-level resources like memory usage.
- Rejected: This option is not suitable for monitoring system-level metrics such as memory usage because it’s focused on application-level integration, not on system resource monitoring.
Option B: Install the Stackdriver Monitoring Agent
- Explanation: The Stackdriver Monitoring Agent (now part of Google Cloud Operations suite) collects detailed system metrics, including memory usage, CPU usage, disk I/O, and more, from your Compute Engine instances. It sends this data to Google Cloud Monitoring, where you can track the performance of your instances over time.
- Selected: This option is ideal for tracking memory usage because the agent directly monitors the system's resource utilization. It provides detailed and real-time metrics on memory and other system resources, which is exactly what you're looking for to monitor your application’s memory usage on Compute Engine.
Option C: Use the Stackdriver Metrics Explorer
- Explanation: Stackdriver Metrics Explorer (now part of Google Cloud Monitoring) is a tool that...
Author: Olivia · Last updated Jul 4, 2026
You have an analytics application that runs hundreds of queries on BigQuery every few minutes using BigQuery API. You want to find out how m...
To track how much time your queries take to execute in BigQuery, you need a method that specifically measures the performance of query execution, including the duration of each query. Let's analyze each option:
Option A: Use Stackdriver Monitoring to plot slot usage
- Explanation: Stackdriver Monitoring (now part of Google Cloud Operations Suite) can monitor various metrics related to BigQuery, such as slot usage, which measures the processing power (slots) consumed by queries. However, slot usage only indicates how much computational resource is being consumed and doesn't directly show how long a query takes to execute.
- Rejected: Slot usage does not directly correspond to query execution time. It may provide an indirect indicator (e.g., a query using more slots might take longer), but it doesn't give the exact duration of the query's execution. This option is not ideal for tracking query execution time specifically.
Option B: Use Stackdriver Trace to plot API execution time
- Explanation: Stackdriver Trace is used for tracking the time taken by HTTP requests and API calls. It can show how long it takes for an API request to be processed, but it does not provide information about how long a BigQuery query takes to execute. This is more useful for tracking application-level API request times rather than BigQuery query execution times.
- Rejected: This option tracks API execution time but does not provide detailed information about the execution time of BigQuery queries. It is not directly suited for your requirement to track the time BigQuery queries take.
Option C:...
Author: Aarav2020 · Last updated Jul 4, 2026
You are designing a schema for a Cloud Spanner customer database. You want to store a phone number array field in a customer table. You also want to allow users to...
Let's evaluate each option for designing the schema based on the given requirements: storing a phone number array field in the customer table and enabling customers to be searched by phone number.
A) Create a table named Customers. Add an Array field in a table that will hold phone numbers for the customer.
Analysis:
- This option proposes storing an array of phone numbers directly in the customer table. While this is a simple and straightforward design, Cloud Spanner does not support indexing on array fields. This would make it difficult to search by phone number efficiently, as array fields are not indexed. As a result, this schema could lead to poor performance when querying by phone number.
Reasoning:
- Drawback: Searching by phone number in an array field would require scanning all customers, leading to inefficiency for large datasets. This option is not suitable if search performance by phone number is required.
Rejected due to lack of indexing on array fields.
---
B) Create a table named Customers. Create a table named Phones. Add a CustomerId field in the Phones table to find the CustomerId from a phone number.
Analysis:
- This option creates a separate Phones table where each phone number is stored as a record, and a CustomerId field links each phone number to a customer.
- This design provides a more flexible schema, where each phone number is treated as an individual record and can be indexed.
- Searching by phone number can be done easily via a secondary index on the phone number field.
Reasoning:
- Pros: This structure is relational and can handle any number of phone numbers per customer, as the phones are stored as individual records. The secondary index on the phone number would allow fast searches by phone number, and the CustomerId allows linking back to the customer.
- Drawback: There is a need for a join between the Customers and Phones tables, which could add some complexity in queries and may involve performance trade-offs in highly transactional workloads.
Selected Option: This is a solid choice for flexible data mo...
Author: John · Last updated Jul 4, 2026
You are deploying a single website on App Engine that needs to be accessible via the URL http://www....
Let's evaluate each option for deploying a website on App Engine and ensuring it is accessible via the URL `http://www.altostrat.com/`.
A) Verify domain ownership with Webmaster Central. Create a DNS CNAME record to point to the App Engine canonical name `ghs.googlehosted.com`.
Analysis:
- In this option, verifying domain ownership with Webmaster Central (now called Google Search Console) is a required step to prove ownership of the domain.
- A CNAME record is created to point to `ghs.googlehosted.com`, which is the canonical name for App Engine applications.
- App Engine typically requires a CNAME to route traffic to your service when you use a custom domain.
Reasoning:
- Pros: This approach uses the standard method of pointing a domain to App Engine using a CNAME record, which works well with App Engine’s infrastructure for custom domain routing.
- Drawback: No need for dispatch.yaml since a simple CNAME setup suffices for routing traffic to the App Engine service.
Selected option: This is a valid approach, and it's the most common method for linking a custom domain to an App Engine app.
---
B) Verify domain ownership with Webmaster Central. Define an A record pointing to the single global App Engine IP address.
Analysis:
- This option suggests using an A record that points directly to the global App Engine IP address.
- While it's possible to use A records to point a domain to an IP address, Google App Engine doesn't recommend using static IP addresses for routing traffic because App Engine services are designed to scale dynamically, and IP addresses can change.
Reasoning:
- Drawback: App Engine does not offer a fixed IP address for your service. If the IP address changes, your website would be inaccessible until...
Author: Aria · Last updated Jul 4, 2026
You are running an application on App Engine that you inherited. You want to find out whether the application is using insecure binaries or ...
Let's analyze each option for determining whether the application is using insecure binaries or is vulnerable to XSS (Cross-Site Scripting) attacks on App Engine:
A) Cloud Armor
Analysis:
- Cloud Armor is a service that provides network security for Google Cloud resources. It helps protect your applications from DDoS attacks and can create security policies to filter incoming traffic, but it does not directly analyze the application code or its security vulnerabilities.
Reasoning:
- Drawback: Cloud Armor is focused on network-level security (e.g., filtering malicious traffic, protecting against DDoS), not on scanning for insecure binaries or application-level vulnerabilities like XSS.
Rejected because Cloud Armor is not designed for finding code vulnerabilities like XSS or insecure binaries.
---
B) Stackdriver Debugger
Analysis:
- Stackdriver Debugger allows you to inspect the application state during execution in real-time, enabling you to analyze variables, requests, and other aspects of the application.
Reasoning:
- Drawback: While it’s helpful for debugging and inspecting the code execution, Stackdriver Debugger does not specifically analyze vulnerabilities like insecure binaries or XSS. It's more of a tool for live debugging rather than security scanning.
Rejected because Stackdriver Debugger is used for debugging, not vulnerability scanning.
---
C) Cloud Security Scanner
Analysis:
- Cloud Security Scanner is a securit...
Author: Sofia · Last updated Jul 4, 2026
You are working on a social media application. You plan to add a feature that allows users to upload images. These images will be 2 MB `" 1 GB in size. You want to minimize the...
Let's analyze each option for uploading images in your social media application, considering the need to minimize infrastructure operations overhead.
A) Change the application to accept images directly and store them in the database that stores other user information.
Analysis:
- Storing images directly in a relational database would require significant overhead because databases are not optimized for handling large binary files like images. Storing large files directly in the database would increase storage requirements, make queries slower, and result in higher costs due to the large volume of data.
Reasoning:
- Drawback: Databases are typically not optimized for managing large files, which could lead to performance issues and scalability concerns as your user base grows. This approach also places a significant load on the database, making it harder to manage over time.
Rejected due to performance and scalability issues when handling large image files directly in a database.
---
B) Change the application to create signed URLs for Cloud Storage. Transfer these signed URLs to the client application to upload images to Cloud Storage.
Analysis:
- Signed URLs allow clients to upload directly to Cloud Storage without routing the data through your application server. This significantly reduces infrastructure overhead by offloading the file upload process to Cloud Storage, where it is optimized for storing large files. The signed URLs provide controlled, temporary access to Cloud Storage, ensuring security without requiring the application to handle the file data directly.
Reasoning:
- Pros: This option reduces the load on your application server and simplifies image handling by leveraging Cloud Storage for efficient file storage and retrieval. Additionally, it reduces the amount of infrastructure management required since Cloud Storage handles most of the scaling and operations.
- Security: Signed URLs can be configured with an expiration time and specific permissions, ensuring secure access to Cloud Storage for file uploads.
Selected option: This is the most efficient choice for minimizing infrastructure overhead, leveraging Cloud Storage and signed URLs to allow users to upload images securely withou...
Author: Harper · Last updated Jul 4, 2026
Your application is built as a custom machine image. You have multiple unique deployments of the machine image. Each deployment is a separate managed instance group with its own template. Each deployment requires a unique set of configuration values. You want to provide these unique values to each deployment bu...
Let's analyze each option for providing unique configuration values to each deployment of the custom machine image in Compute Engine, using out-of-the-box features of Compute Engine.
A) Place the unique configuration values in the persistent disk.
Analysis:
- Persistent disks are used for storing data that needs to persist beyond the lifetime of a virtual machine (VM), such as databases or logs.
- Storing configuration values on a persistent disk would mean you would need to mount the disk each time a new instance is created. This introduces extra complexity and can incur additional costs for managing persistent storage across deployments.
Reasoning:
- Drawback: Persistent disks are not designed for holding configuration data that is specific to individual instances or deployments. This would increase overhead and complexity in accessing and managing configuration values.
Rejected because using a persistent disk is not an ideal or efficient solution for instance-specific configuration values.
---
B) Place the unique configuration values in a Cloud Bigtable table.
Analysis:
- Cloud Bigtable is a NoSQL database service, typically used for large-scale data storage and real-time analytics. It is highly scalable and suited for time-series data, IoT, and large applications requiring high throughput.
- Storing configuration data in Bigtable would introduce unnecessary complexity and overhead, as Bigtable is designed for large-scale, structured data rather than simple configuration values.
Reasoning:
- Drawback: Cloud Bigtable is overkill for storing and retrieving simple configuration values. It adds unnecessary complexity for the scenario of providing deployment-specific configuration to individual instances.
Rejected because Bigtable is too complex for the task of storing deployment-specific configuration data.
---
C) Place the unique configuration values in the instance template startup script.
Analysis:
- The instance template startup script allows you to run commands or scripts when an in...
Author: Olivia · Last updated Jul 4, 2026
Your application performs well when tested locally, but it runs significantly slower after you deploy it to a Compute Engine instance. You need to...
To diagnose why your application is running slower on a Compute Engine instance than locally, it’s important to focus on performance profiling and identifying which part of the application is experiencing delays. Here's an analysis of each option:
A) File a ticket with Cloud Support indicating that the application performs faster locally.
- Rejected: Filing a support ticket may lead to further delays in identifying the root cause of the performance issue. It does not provide immediate insight or diagnostics about what might be causing the slow performance. It's a reactive rather than a proactive approach, and it’s typically used for deeper, unresolved issues, not for optimizing performance.
B) Use Cloud Debugger snapshots to look at a point-in-time execution of the application.
- Rejected: Cloud Debugger allows you to examine the application's state and variable values at specific points in time. However, it’s more useful for identifying issues related to the application's logic or errors rather than performance bottlenecks. It’s not specifically designed to analyze and diagnose performance issues, so it's not the best tool in this scenario.
C) Use Cloud Profiler to determine which functions within the application take the longest amount of time.
- Selected: Cloud Profiler is specifically designed for performance profiling. It helps identify functions or parts of your code that are consuming the most time and resources, whic...
Author: NebulaEagle11 · Last updated Jul 4, 2026
You have an application running in App Engine. Your application is instrumented with Stackdriver Trace. The /product-details request reports details about four known unique products at /sku-details as shown bel...
To reduce the time it takes for the `/product-details` request to complete, the goal is to optimize the performance of retrieving the necessary details for the products. Let's break down each option:
A) Increase the size of the instance class.
- Rejected: Increasing the instance size might provide more CPU or memory resources to handle higher loads, but this approach is not necessarily the best for reducing latency in a situation where the problem is related to waiting for external resources (e.g., calls to `/sku-details`). This may improve throughput under heavy load but would not directly address the underlying issue of slow external calls, especially if those external calls are the bottleneck.
B) Change the Persistent Disk type to SSD.
- Rejected: Persistent Disk type is generally used for storage performance, not for optimizing network or external API calls. If the `/sku-details` calls are external web service calls, the disk speed will not improve the latency or performance of these calls. SSDs improve read/write operations, but they won’t solve the issue of time spent waiting for external calls.
C) Change /product-details to perform the requests in parallel.
- Selected: If the `/product-details` request involves fetching data for multiple products by making sequential calls to `/sku-details`, performing these calls in parallel can reduce the overall time. Parallelizing the requests allows the system to wait on multiple network calls simultaneously ...
Author: Rahul · Last updated Jul 4, 2026
Your company has a data warehouse that keeps your application information in BigQuery. The BigQuery data warehouse keeps 2 PBs of user data. Recently, your company expanded your user base to include EU users and needs to comply with these requirements:
* Your company must be able to delete all user account information upon use...
To meet the compliance requirements for handling EU user data and ensuring the ability to delete user data upon request, let's analyze each option carefully.
A) Use BigQuery federated queries to query data from Cloud Storage.
- Rejected: BigQuery federated queries allow you to query external data sources, such as Cloud Storage, without importing the data into BigQuery. However, this does not directly address the issue of data compliance (such as region-specific storage and deleting data on request). It’s more about querying data across different systems and doesn't fulfill the requirements of having EU user data in a specific region or complying with the deletion requirement.
B) Create a dataset in the EU region that will keep information about EU users only.
- Selected: This option directly addresses the requirement to store EU user data in a specific region (the EU region). By creating a separate dataset specifically for EU users, you can ensure that the data is stored in compliance with EU data residency regulations. Furthermore, this approach helps you isolate the data for easier management and deletion upon user request. It aligns well with the requirement for location-specific data storage.
C) Create a Cloud Storage bucket in the EU region to store information for EU users only.
- Rejected: While storing data in Cloud Storage in the EU region can be part of a solution, the primary data warehouse solution here is BigQuery. Storing user data in Cloud Storage and not directly in BigQuery would be a divergence from the data management process your company is using for its main data warehouse, making it less efficient for managi...
Author: Aarav2020 · Last updated Jul 4, 2026
Your App Engine standard configuration is as follows:
service: production
instance_class: B1
You want to limit the application to 5 instances...
To limit the number of instances in an App Engine standard environment, it’s important to understand the different scaling configurations in App Engine. Let's break down each option:
A) manual_scaling: instances: 5 min_pending_latency: 30ms
- Rejected: In the App Engine standard environment, `manual_scaling` is used to specify a fixed number of instances that the application should always run. However, the `instances` key in `manual_scaling` does not have a `min_pending_latency` parameter. `min_pending_latency` is used in basic scaling and not in `manual_scaling`. So, this option would result in an invalid configuration.
B) manual_scaling: max_instances: 5 idle_timeout: 10m
- Rejected: `manual_scaling` is used to specify a fixed number of instances. However, the correct way to limit the number of instances is to use `instances` (e.g., `instances: 5`), not `max_instances`. The `max_instances` option is not available under `manual_scaling`—it is instead used in basic scaling and automatic scaling configurations. Therefore, this option won't work.
C) basic_scaling: instances: 5 min_pending_latency: 30ms
- Rejected: This option uses `basic_scaling`, which allows instances to scale based on request load. The `instances` key in `basic_scaling` specifies the initial number of instances, but it does n...
Author: Olivia · Last updated Jul 4, 2026
Your analytics system executes queries against a BigQuery dataset. The SQL query is executed in batch and passes the contents of a SQL file to the BigQuery
CLI. Then it redirects the BigQuery CLI output to another process. However, you are getting a permissio...
To resolve the permission error when executing a SQL query via the BigQuery CLI, we need to focus on ensuring that the service account running the query has the necessary permissions to execute the query and access the required data. Let’s review each option:
A) Grant the service account BigQuery Data Viewer and BigQuery Job User roles.
- Selected: The BigQuery Data Viewer role allows the service account to read data in BigQuery, while the BigQuery Job User role is necessary for running jobs (such as executing SQL queries). This combination ensures that the service account has both the permissions to access the data and execute queries in BigQuery. These roles are typically sufficient for executing queries and interacting with BigQuery, addressing the permission error issue.
B) Grant the service account BigQuery Data Editor and BigQuery Data Viewer roles.
- Rejected: While the BigQuery Data Editor role gives the ability to modify data in BigQuery, it is not needed for simply executing a query (which only requires BigQuery Data Viewer permissions). Additionally, the BigQuery Data Viewer role is sufficient to access the data, but BigQuery Job User is still needed for executing queries. This option gives more permissions than necessary for executing the query and doesn’t include the BigQuery Job User role, which is needed for running queries.
C) Create a view in BigQuery from the SQL query and SELECT...
Author: Lucas · Last updated Jul 4, 2026
Your application is running on Compute Engine and is showing sustained failures for a small number of requests. You have narrowed the cause down to a single
Compute Engine i...
When dealing with an unresponsive Compute Engine instance, there are several actions you can take. Let’s break down the options and evaluate them based on the scenario where the instance is unresponsive to SSH but you've already narrowed down the issue to this specific instance:
A) Reboot the machine
- Reasoning: Rebooting is often a quick way to resolve temporary issues such as software glitches, resource exhaustion, or kernel panics. If the instance is stuck due to a transient issue, a reboot could potentially restore normal functionality.
- Rejected Because: While it’s a good first step to try, this approach doesn't give you visibility into why the instance failed in the first place. If the root cause is something deeper (e.g., hardware failure, software misconfiguration), a reboot may not resolve the issue, and the instance may fail again.
B) Enable and check the serial port output
- Reasoning: The serial port output provides detailed system logs that are not affected by SSH or the operating system's networking stack. If the system is unresponsive via SSH, you can use the serial port to check boot logs and kernel panic information. This would help in diagnosing issues such as hardware failures, kernel crashes, or other low-level problems that are preventing the instance from becoming responsive.
- Selected Because: Checking the serial port output gives you critical diagnostic information, allowing you to understand what's going wrong with the instance without needing to log in via SSH. This is particularly important if the issue is not related to softw...
Author: Evelyn · Last updated Jul 4, 2026
You configured your Compute Engine instance group to scale automatically according to overall CPU usage. However, your application's response latency increases sharply before the cluster has finished adding up instances. You want to provide a more consistent latency experience for your end users...
To address the issue of sharp latency spikes before the Compute Engine instance group finishes scaling up, you need to focus on making adjustments that enable the autoscaler to react faster and avoid service degradation. Let's analyze the options:
A) Add the label `=D7=92=E2=82=ACAUTOSCALE=D7=92=E2=82=AC` to the instance group template
- Reasoning: Labels are typically used to organize and manage resources within Google Cloud, but they do not directly affect autoscaling behavior or response time. Adding labels like this will not impact the latency or scaling process.
- Rejected Because: Labels don't have a direct effect on scaling or latency, making this option irrelevant for your goal of improving the response latency.
B) Decrease the cool-down period for instances added to the group
- Reasoning: The cool-down period is the time the autoscaler waits after scaling up before considering additional scaling actions. If the cool-down period is too long, the autoscaler might delay the addition of new instances even after a high load is detected. Decreasing the cool-down period allows the autoscaler to react more quickly and add instances faster when needed.
- Selected Because: This option directly addresses the problem of latency spikes. A shorter cool-down period would reduce the time delay between detecting high load and actually scaling the instance group, resulting in more consistent latency and a faster response to increased traffic.
C) Increase the target CPU usage for the instance group autoscaler
- Reasoning: Increasing the target CPU usage would make the autoscaler wait until the CPU usage is higher before adding new instances. This would de...
Author: Lina Zhang · Last updated Jul 4, 2026
You have an application controlled by a managed instance group. When you deploy a new version of the application, costs should be minimized and the number of instances should not increase. You want to ensure that, when each new ins...
In this scenario, you want to deploy a new version of your application while ensuring that the number of instances does not increase and that the deployment only continues if the new instances are healthy. Let's break down the options:
A) Perform a rolling-action with maxSurge set to 1, maxUnavailable set to 0
- Reasoning:
- maxSurge set to 1: Allows one extra instance during the deployment process, so you would temporarily have one additional instance in your group, which could increase costs.
- maxUnavailable set to 0: Ensures that no instances are taken down during the deployment, meaning the number of running instances remains the same as before the update.
- Rejected Because: This option violates the requirement to minimize costs and ensure the number of instances does not increase. Even though the number of running instances doesn’t decrease, there will be an additional instance for the duration of the deployment.
B) Perform a rolling-action with maxSurge set to 0, maxUnavailable set to 1
- Reasoning:
- maxSurge set to 0: Prevents any additional instances from being created, which helps in ensuring that no extra costs are incurred.
- maxUnavailable set to 1: Allows one instance to be unavailable during the deployment. This means that while the new version is being deployed, an old instance can be taken down without increasing the number of instances.
- Selected Because: This option ensures that no additional instances are created, which minimizes costs. It also allows the deployment to continue if the new instance is healthy and available, and it ensures that the number of running instances does not increase during the process.
C) Perform a rolling-action with maxHealthy set to...
Author: ThunderBear · Last updated Jul 4, 2026
Your application requires service accounts to be authenticated to GCP products via credentials stored on its host Compute Engine virtual machine instances. You want to distribute these...
In this scenario, the goal is to securely distribute service account credentials to Compute Engine virtual machine instances so that the application can authenticate to GCP products. Let’s evaluate the options based on the security and best practices of managing credentials.
A) Use HTTP signed URLs to securely provide access to the required resources
- Reasoning: Signed URLs are a secure way to grant temporary access to resources (like Google Cloud Storage files), but they are not a method for distributing service account credentials for authentication to GCP products. They are typically used to access specific objects in cloud storage and would not apply to distributing authentication credentials for service account access to other GCP resources.
- Rejected Because: This option is not suited to distribute service account credentials or provide the proper authentication mechanism for the application to interact with GCP services.
B) Use the instance's service account Application Default Credentials to authenticate to the required resources
- Reasoning: This is the recommended method for authenticating Compute Engine instances to GCP products. When a Compute Engine VM is created, you can assign a service account to it. By default, the VM uses the service account's Application Default Credentials (ADC) for authenticating to Google Cloud services. This method is secure and managed by GCP, as the credentials are automatically handled by the instance’s metadata server. It doesn't require manually storing, distributing, or managing credentials.
- Selected Because: This approach is secure and scalable. The instance can authenticate seamlessly without needing to store or distribute credentials manually, which reduces the risk of credential leaks or mismanagement.
C) Generate a P12 file from the GCP Console after the instance is deployed, and ...
Author: FrostFalcon88 · Last updated Jul 4, 2026
Your application is deployed in a Google Kubernetes Engine (GKE) cluster. You want to expose this application publicly behind a Cloud ...
To expose an application deployed in a Google Kubernetes Engine (GKE) cluster publicly behind a Cloud Load Balancing HTTP(S) load balancer, you need to use Kubernetes resources that allow you to create the necessary load balancing configuration. Let's evaluate the options:
A) Configure a GKE Ingress resource
- Reasoning: An Ingress is a Kubernetes resource that manages external access to the services within a Kubernetes cluster, typically HTTP(S). However, just configuring an Ingress resource alone doesn’t automatically create the load balancer. It requires an Ingress controller to be set up (like the GKE Ingress controller), and the Ingress resource typically routes traffic to services rather than directly provisioning a load balancer.
- Rejected Because: While an Ingress helps manage external access, it doesn't directly provision a Cloud Load Balancing HTTP(S) load balancer by itself. It needs the associated Ingress controller and is mainly used for managing routing and rules for HTTP traffic, rather than creating a load balancer.
B) Configure a GKE Service resource
- Reasoning: A Service in Kubernetes is used to define how to access a set of Pods. However, configuring a Service resource by itself does not expose your application to the internet. For public exposure via a Load Balancer, you would need to define the Service with the appropriate type, like LoadBalancer.
- Rejected Because: A regular Service resource does not expose your application to the internet. You need a specific configuration (such as LoadBalancer) to create an external-facing load balancer.
C) Configure a GKE Ingress resource with type: LoadBalancer
...
Author: Liam · Last updated Jul 4, 2026
Your company is planning to migrate their on-premises Hadoop environment to the cloud. Increasing storage cost and maintenance of data stored in HDFS is a major concern for your company. You also want to make minimal changes to ...
To determine the best approach for migrating your on-premises Hadoop environment to the cloud, several key factors should be considered: storage cost, maintenance, minimal changes to existing data analytics jobs, and leveraging cloud-native features. Let's break down the options and evaluate each one:
Option A: Migrate your data stored in Hadoop to BigQuery. Change your jobs to source their information from BigQuery instead of the on-premises Hadoop environment.
- Pros: BigQuery is a fully managed, serverless data warehouse that can provide substantial cost savings compared to maintaining on-premises Hadoop storage. It's designed for high performance on analytics workloads and can scale effortlessly.
- Cons: Migrating to BigQuery would require significant changes to your existing data analytics jobs, as they are designed for Hadoop. This might involve rewriting jobs to use SQL instead of MapReduce or Spark. It also changes the way you access and manage your data (moving from HDFS to a columnar database structure).
- Conclusion: This option might be more suitable if you're looking for a complete overhaul of your analytics environment and can afford to re-engineer your workflows. However, it's not ideal if the goal is minimal changes to existing jobs and architecture.
Option B: Create Compute Engine instances with HDD instead of SSD to save costs. Then perform a full migration of your existing environment into the new one in Compute Engine instances.
- Pros: This option allows you to replicate your on-premises Hadoop environment on the cloud by using Compute Engine, and using HDD storage could provide cost savings on storage compared to SSDs.
- Cons: While this approach allows you to replicate your existing setup, it would require maintaining and managing infrastructure, leading to higher operational overhead. The storage savings may not be enough to offset the cost of maintaining virtual machines, and you lose the scalability and managed services benefits that the cloud offers.
- Conclusion: This option is more akin to a "lift and shift" migration, which might not fully address the growing concerns of storage cost and the management burden. It's more useful for scenarios where you want to replicate the existing environment closely but with limited cloud-native optimizations.
Option C: Create a Cloud Dataproc cluster on Google Cloud Platform, and then migrate your Hadoop environment to the new Cloud Dataproc cluster. Move your HDFS data into ...
Author: Vivaan · Last updated Jul 4, 2026
Your data is stored in Cloud Storage buckets. Fellow developers have reported that data downloaded from Cloud Storage is resulting in slow API performance.
You want to research the i...
To investigate the slow API performance when downloading data from Cloud Storage, you would want to focus on diagnosing the performance of your Cloud Storage interaction specifically. Here's an evaluation of each option:
Option A: `gsutil test -o output.json gs://my-bucket`
- Analysis: This command seems to be malformed and does not correspond to any valid `gsutil` command syntax. The string `-o` appears to be some encoding error or a typo.
- Conclusion: This is not a valid command and will not provide useful information.
Option B: `gsutil perfdiag -o output.json gs://my-bucket`
- Analysis: `gsutil perfdiag` is a valid command used to diagnose performance issues with Cloud Storage. It collects diagnostic data and can help analyze slow download or upload speeds, and it outputs the results into a file (e.g., `output.json`). This is a tool specifically built to help with diagnosing performance problems with Cloud Storage, which makes it highly relevant for your issue.
- Conclusion: This is the best option for diagnosing slow download performance from Cloud Storage, as it is designed to gather performance-related data specific to Cloud Storage.
Option C: `gcloud compute scp example-instance:~...
Author: Sofia · Last updated Jul 4, 2026
You are using Cloud Build build to promote a Docker image to Development, Test, and Production environments. You need to ensure that the same Docker image is deployed to each of...
When promoting a Docker image through different environments (Development, Test, and Production), it's essential to ensure that the same Docker image is deployed consistently across all environments. Let’s analyze the options and see which one is most appropriate for this scenario.
Option A: Use the latest Docker image tag.
- Analysis: The `latest` tag is commonly used in Docker to signify the most recent version of an image. However, relying on `latest` can lead to issues because:
- The `latest` tag is mutable, meaning that it can change over time. For example, if a new image is built and pushed with the `latest` tag, the image in production might differ from the one in Development or Test if the `latest` tag was updated in between deployments.
- This creates uncertainty and can result in deploying different versions of the image to different environments unintentionally.
- Conclusion: This is not the best option for ensuring consistency across environments, as it doesn’t guarantee that the same image is used in all stages.
Option B: Use a unique Docker image name.
- Analysis: A unique Docker image name means each image will have a distinct name, likely reflecting an environment or build-specific detail. While this could work, it would require creating a new image name for every build and every environment (e.g., `myapp-dev`, `myapp-test`, `myapp-prod`). This can quickly become complex to manage and doesn't solve the issue of ensuring the same image is deployed across all environments.
- Conclusion: This approach adds complexity and is not ideal for promoting a consistent image across environments, as you would need to track different image names for each stage.
Option C: Use the digest of the Docker image.
- Analysis: A Docker image digest is a cryptographic hash of the image's contents. This provides a unique, immutable identifie...
Author: MysticJaguar44 · Last updated Jul 4, 2026
Your company has created an application that uploads a report to a Cloud Storage bucket. When the report is uploaded to the bucket, you want to publish a message to a Cloud Pub/Sub topic. You want to implem...
To address the requirement of triggering a message to a Cloud Pub/Sub topic when a report is uploaded to a Cloud Storage bucket, we need a solution that is easy to implement and provides the necessary automation. Let’s evaluate each option:
Option A: Configure the Cloud Storage bucket to trigger Cloud Pub/Sub notifications when objects are modified.
- Analysis: Cloud Storage supports notifications to Cloud Pub/Sub when an object is created, modified, or deleted. This is a native feature that requires minimal setup.
- You would configure the Cloud Storage bucket to send a notification to a Cloud Pub/Sub topic when the report is uploaded.
- It’s a simple and native integration that minimizes custom code and operational overhead, and it directly fulfills the requirement of sending a message when an object is uploaded.
- Conclusion: This is a great choice because it leverages Cloud Storage's built-in feature to publish messages to Cloud Pub/Sub with minimal effort and configuration.
Option B: Create an App Engine application to receive the file; when it is received, publish a message to the Cloud Pub/Sub topic.
- Analysis: Using App Engine would involve building a custom application to handle the file upload and publishing the message. While App Engine is a fully managed platform, it still requires more effort to set up the application, handle file uploads, and then manage the communication with Cloud Pub/Sub.
- It introduces unnecessary complexity compared to native integration, especially when Cloud Storage itself can trigger Cloud Pub/Sub notifications.
- Conclusion: While feasible, this option is over-engineered for the task and requires more development and configuration compared to other solutions.
Option C: Create a Cloud Function that is triggered by the Cloud Storage bucket. In the Clo...
Author: Ella · Last updated Jul 4, 2026
Your teammate has asked you to review the code below, which is adding a credit to an account balance in Cloud Datastore.
Wh...
Let’s review the provided options and determine which improvement would best suit the task of adding a credit to an account balance in Cloud Datastore.
Option A: Get the entity with an ancestor query.
- Analysis: Ancestor queries in Cloud Datastore are used to maintain a hierarchical structure of entities and ensure that queries are consistent within a given ancestor. However, in the context of updating an account balance, there’s no need to use an ancestor query unless you're working with a parent-child relationship between entities. Ancestor queries could introduce unnecessary complexity if the entities aren’t hierarchical.
- Conclusion: This is not the best option unless there's a clear requirement for ancestor-based consistency (which isn't mentioned in the problem). It doesn’t directly address the need to safely update the account balance with proper transactional handling.
Option B: Get and put the entity in a transaction.
- Analysis: Transactions in Cloud Datastore ensure that multiple operations (such as reading and writing an entity) are atomic. This means that if your application retrieves an account entity, modifies the balance, and then updates the entity, it needs to be done inside a transaction to ensure consistency. If there are any concurrent changes, a transaction can help avoid race conditions, ensuring that the balance is correctly updated without losing data or causing inconsistencies.
- Using transactions is a key strategy when performing multiple steps that need to be consistent, which is exactly what this case entails: getting the account, modifying the balance, and updating the account.
- Conclusion: This is the best option because it addresses the need for atomicity and ensures data consistency when performing the balance update. Transactions provide a mechanism to avoi...
Author: Sophia · Last updated Jul 4, 2026
Your company stores their source code in a Cloud Source Repositories repository. Your company wants to build and test their code on each source code commit to the repository and requires a solutio...
To determine the best method for building and testing code on each source code commit with minimal operational overhead, let's evaluate each option.
A) Use Cloud Build with a trigger configured for each source code commit.
- Reasoning: Cloud Build is a fully managed service for continuous integration and continuous deployment (CI/CD). It integrates well with Cloud Source Repositories and offers a straightforward solution to trigger builds on each source code commit. It is designed to minimize operational overhead because Google Cloud manages the infrastructure, and you only focus on configuration. With Cloud Build, there is minimal setup, no need to manage VM instances, and you get an auto-scaling service that handles builds as they are triggered by the repository.
- Pros:
- Fully managed.
- Scalable and reliable.
- Simple to configure.
- Integrated with Google Cloud.
- Minimal operational overhead.
- Cons:
- Limited to the features provided by Cloud Build (though this is typically sufficient for most CI/CD workflows).
B) Use Jenkins deployed via the Google Cloud Platform Marketplace, configured to watch for source code commits.
- Reasoning: Jenkins is a popular open-source tool for CI/CD, but deploying it via GCP Marketplace requires more management. You must handle Jenkins server provisioning, scaling, updates, and maintenance. This option increases operational overhead due to the need to maintain the Jenkins infrastructure, handle scalability concerns, and ensure security.
- Pros:
- Highly customizable.
- Popular tool with a vast ecosystem of plugins.
- Cons:
- Not fully managed.
- Requires more maintenance and operational overhead.
- Scalability and performance need to be handled manually.
- More complex configuration compared to Cloud Build.
C) Use a Compute Engine virtual machine instance with an open-source continuous integration tool, configured to watch for source code commits.
- Reasoning: Using Compute Engine VMs with open-source C...
Author: Lucas · Last updated Jul 4, 2026
You are writing a Compute Engine hosted application in project A that needs to securely authenticate to a Cloud ...
To securely authenticate a Compute Engine-hosted application in project A to access a Cloud Pub/Sub topic in project B, we need to ensure proper cross-project authentication while adhering to the principle of least privilege and minimizing operational overhead.
Let's evaluate the options one by one:
A) Configure the instances with a service account owned by project B. Add the service account as a Cloud Pub/Sub publisher to project A.
- Reasoning: This option involves assigning a service account owned by project B to the Compute Engine instances in project A. The service account would then be granted Cloud Pub/Sub publisher roles in project A. While this approach allows the service account in project B to access the Pub/Sub topic, it creates a situation where a service account from another project (project B) is used in project A. This method is typically not ideal, as it introduces unnecessary complexity and doesn't align with the best practice of using service accounts from the project where the resources are located.
- Pros:
- Allows a service account from project B to access the resources in project A.
- Cons:
- Not a best practice because it's confusing and less intuitive to use a service account from another project in this way.
B) Configure the instances with a service account owned by project A. Add the service account as a publisher on the topic.
- Reasoning: This option suggests using a service account owned by project A to authenticate the Compute Engine instances. The service account from project A would then be granted Cloud Pub/Sub publisher access to the topic in project B. This is a straightforward and correct approach, as the service account belongs to the same project as the Compute Engine instance and can be granted the necessary permissions on the Pub/Sub topic in project B.
- Pros:
- Simple and follows the best practice of using a service account from the same project for authentication.
- Minimal complexity, as you’re handling permissions within the scope of project A.
- Scalable and easier to manage.
- Cons:
- Requires appropriate IAM permissions on the Pub/Sub topic in project B.
C) Configure Appli...
Author: Matthew · Last updated Jul 4, 2026
You are developing a corporate tool on Compute Engine for the finance department, which needs to authenticate users and verify that they are in the finance ...
To authenticate users in the office department and verify that they are in the department using G Suite, the best approach would rely on leveraging Google Cloud's identity and access management tools and the existing corporate G Suite (now Google Workspace) setup. Let’s evaluate each option:
A) Enable Cloud Identity-Aware Proxy on the HTTP(s) load balancer and restrict access to a Google Group containing users in the office department. Verify the provided JSON Web Token within the application.
- Reasoning: This option is ideal because Cloud Identity-Aware Proxy (IAP) allows you to securely control access to your application based on user identity and attributes. By configuring IAP to restrict access to users in a Google Group for the office department, only authenticated users within that group can access the application. The application can then verify the JSON Web Token (JWT) issued by Google's authentication service, which is a secure and standard way to authenticate users.
- Pros:
- IAP integrates well with Google Workspace (G Suite) for managing user access.
- No need for manual certificate management.
- Verifying the JWT is a standard and secure method of authentication.
- Centralized user management via Google Groups and G Suite.
- Scalable and secure without additional overhead.
- Cons:
- Requires proper setup and configuration of IAP and Google Groups.
B) Enable Cloud Identity-Aware Proxy on the HTTP(s) load balancer and restrict access to a Google Group containing users in the office department. Issue client-side certificates to everybody in the office team and verify the certificates in the application.
- Reasoning: This option combines IAP with client-side certificates, which adds an extra layer of authentication. However, managing client-side certificates can be complex and cumbersome, especially in a large organization. While certificates provide additional security, they are often unnecessary if you already have Google Groups for identity management and JWT-based authentication through IAP.
- Pros:
- Adds an additional layer of security.
- Cons:
- Issuing and managing client certificates is operationally complex.
- More difficult to scale and maintain compared to JWT-based authentication.
- May introduce more overhead in managing certificates for each user.
C) Configure Cloud Armor Security Poli...
Author: Nathan · Last updated Jul 4, 2026
Your API backend is running on multiple cloud providers. You want to generate reports for the network latency of your ...
To generate network latency reports for an API running on multiple cloud providers, we need to focus on tools that can measure and trace the performance of the API calls across different environments.
Let's evaluate the options:
A) Use Zipkin collector to gather data.
- Reasoning: Zipkin is a distributed tracing system that helps track requests across multiple services, including network latency between services. It collects trace data that can help visualize latency in API calls. While Zipkin can be integrated into systems running across multiple cloud providers, it's primarily focused on trace data and network latency. If the API is using Zipkin for tracing, it can provide the data needed to generate latency reports.
- Pros:
- Good for tracing requests across distributed systems.
- Can track network latency between services, which is key for this use case.
- Cons:
- Zipkin is not a Google Cloud-native tool and would require additional setup and integration if you're primarily using Google Cloud services. However, it's still a valid option for multi-cloud environments.
B) Use Fluentd agent to gather data.
- Reasoning: Fluentd is a log collector and aggregator used for collecting logs from various sources and shipping them to various backends like Stackdriver, Elasticsearch, or others. While Fluentd is useful for log collection, it isn't specialized for measuring network latency or trace data. It can aggregate logs that may contain latency information, but it won't directly provide the detailed insights needed to generate precise network latency reports.
- Pros:
- Useful for log aggregation.
- Can collect relevant logs that may contain latency data.
- Cons:
- Fluentd does not directly provide network latency or tracing data.
- Would require additional processing to extract latency insights from logs, which complicates the process.
C) Use Stackdriver Trace to generate reports.
- Reasoning: Stackdriver Trace (now part of Google Cloud's operations suite) is a managed distributed tracing tool that automatically collects data about the latency of your API requests. It helps in tracing requests across services, providing insights into network latency and performance bottlenecks. This tool works well in multi-cloud environments, especially when integrating with Google Cloud, a...
Author: Grace · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
To determine the best database for storing user activity in HipLocal's scenario, we need to consider the following key factors:
1. Scalability: As HipLocal is expanding globally and experiencing rapid growth, the database solution must support high scalability, especially to handle large volumes of user activity data.
2. Serverless Architecture: HipLocal wants to reduce infrastructure management time and costs, which means they need a solution that can scale elastically with demand (serverless).
3. Global Availability: Since HipLocal is expanding globally, the solution should support availability across multiple regions with low latency, ensuring a consistent experience for users worldwide.
4. Analytics Integration: HipLocal wants to store user activity data and integrate it with cloud analytics platforms to derive insights into user behavior.
5. Ease of Management: Reducing infrastructure management is a priority. The solution should be easy to manage and should align with Google Cloud's best practices.
Let’s evaluate the options:
A) BigQuery
- Reasoning: BigQuery is a fully managed serverless data warehouse designed for large-scale analytics. It's excellent for running large queries and analytics on massive datasets, like user activity logs. BigQuery is highly scalable, can integrate with other Google Cloud services, and provides low-latency data querying.
- Pros:
- Fully serverless and scales elastically.
- Excellent for analytics and can handle vast amounts of data.
- Supports integration with other GCP services (e.g., Dataflow for ETL).
- Cons:
- While BigQuery is great for analytics, it's not optimized for transactional data, which might be needed for real-time user activity storage.
B) Cloud SQL
- Reasoning: Cloud SQL is a fully managed relational database that supports MySQL, PostgreSQL, and SQL Server. While it provides strong consistency and is easier to manage than self-hosted databases, it’s more suitable for transactional workloads rather than large-scale analytics.
- Pros:
- Managed database service for SQL workloads.
- Strong transactional consistency.
- Easy to use and integrates well with other GCP services.
- Cons:
- May not scale as well as Cloud Spanner or BigQuery for large volumes of user activity data.
- Less suited for global scaling with high availability across multiple regions.
- Not a se...
Author: Aarav · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
In this scenario, HipLocal needs to ensure secure access control for their application and backend systems. Given the need for strong authentication, authorization, and security best practices, it's important to evaluate the firewall configuration options based on the security, scalability, and functionality requirements outlined.
Analysis of the options:
1. Option A: Block all traffic on port 443
Blocking all traffic on port 443 would prevent secure HTTPS traffic from reaching the application. This is unsuitable since port 443 is used for secure communication over HTTPS, and blocking it would stop the users from accessing the application securely. This option would severely hinder the application's functionality and is therefore not appropriate.
2. Option B: Allow all traffic into the network
Allowing all traffic into the network without restriction is highly insecure. This would create a vulnerability where any type of traffic from any source could access the network. This does not meet the requirement of strong authentication and authorization and violates security best practices. This option should also be rejected.
3. Option C: Allow traffic on port 443 for a specifi...
Author: FlamePhoenix2025 · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
In this scenario, the goal is to prepare user reviews for analysis by the data science team at HipLocal. The data science team will likely need to ensure that any sensitive information in the user reviews is handled appropriately. Additionally, they must follow security and compliance guidelines, especially with respect to privacy regulations like GDPR.
Let's evaluate each option in the context of the case study:
Option A: Use the Cloud Data Loss Prevention (DLP) API for redaction of the review dataset
The Cloud DLP API is specifically designed to help with the identification and redaction of sensitive data. However, redaction is a method of removing or masking sensitive data, which may make it difficult to analyze the full review text effectively, as key information is completely removed. This option is useful in cases where you need to protect sensitive information but would not be ideal for preparing data that needs to be analyzed for insights, as the information may be overly modified or stripped out entirely.
Option B: Use the Cloud Data Loss Prevention (DLP) API for de-identification of the review dataset
The Cloud DLP API can also be used for de-identification, which means it will transform sensitive information (such as names, email addresses, or phone numbers) into pseudonyms or anonymized values, rather than completely removing the information. This allows the data science team to maintain most of the content for analysis while ensuring privacy and se...
Author: Suresh · Last updated Jul 4, 2026
Case study -
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.
To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.
To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. If the case study has an
All Information tab, note that the information displayed is identical to the information displayed on the subsequent t...
In order for HipLocal to store application state and meet their stated business requirements (such as scaling, availability, and consistency across regions), it’s important to carefully evaluate the database services available on Google Cloud. Here’s an analysis of each option:
Option A: Cloud Spanner
Cloud Spanner is a fully managed, scalable, relational database that offers global distribution, horizontal scaling, and strong consistency. It is designed to handle high throughput and low-latency access, making it an excellent fit for applications that need to serve global users across multiple regions. With Cloud Spanner, HipLocal can store application state while ensuring:
- Global scalability to handle more concurrent users.
- High availability and consistency across different regions.
- Support for distributed transactions, which can be critical as HipLocal expands globally.
- Compliance with regulations (such as GDPR) due to its robust security features.
This is the most suitable option for scaling across regions and handling complex, global applications.
Option B: Cloud Datastore
Cloud Datastore is a NoSQL database designed for applications that require scalability and low-latency data access. It is a good fit for applications that don't need complex SQL queries and have a flexible schema. However, Cloud Datastore doesn't provide the strong consistency and relational capabilities that Cloud Spanner offers, and it’s not designed for transactional workloads across multiple regions with high consistency requirements. Given that HipLocal needs to scale globally and ensure consistent state across regions, Cloud Datastore may not meet all the business requirements for relational data and strong consistency across differen...
Author: Sofia2021 · Last updated Jul 4, 2026
You have an application deployed in production. When a new version is deployed, you want to ensure that all production traffic is routed to the new version of your application. You also want to keep the previous version deployed so that you...
To determine which deployment strategy is best for the scenario described (where you want to route all traffic to the new version but keep the previous version for potential rollback), let’s review each of the options in detail:
Option A: Blue/Green Deployment
Blue/green deployment involves maintaining two separate environments: Blue (the current live environment) and Green (the new version). With this strategy:
- You deploy the new version of your application in the Green environment.
- Once the Green environment is tested and verified, you can route all traffic to it, making it the live environment.
- The Blue environment remains intact and can be kept in reserve in case a rollback is needed.
- Benefits: It ensures zero downtime and a quick rollback option, as you can simply switch traffic back to the Blue environment if there’s an issue with the Green version.
Why this is the best option: This deployment strategy directly addresses the requirement to keep the previous version deployed for a quick rollback. It ensures that production traffic is fully routed to the new version (Green) while keeping the previous version (Blue) intact and available for a revert if needed.
Option B: Canary Deployment
In a canary deployment, the new version is rolled out incrementally to a small subset of users or servers (the "canary group") before being gradually rolled out to the entire user base. This strategy:
- Allows you to test the new version on a limited scale.
- If the canary group experiences issues, you can halt or roll back the deployment.
- Once the new version is verified, it is fully deployed to all users.
Why this is not ideal: While a canary deployment allows you to test the new version with a small subset of users, it does not immediately route all traffic to the new version and...
Author: Kunal · Last updated Jul 4, 2026
You are porting an existing Apache/MySQL/PHP application stack from a single machine to Google
Kubernetes Engine. You need to determine how to containerize the application. Your approach sho...
When porting an existing Apache/MySQL/PHP application stack to Google Kubernetes Engine (GKE), you need to containerize the application with a focus on high availability, maintainability, and alignment with Google-recommended best practices. Let's evaluate each of the options provided in detail:
Option A: Package each component in a separate container. Implement readiness and liveness probes.
This is the best practice when deploying to Kubernetes for several reasons:
- Separation of concerns: By placing each component (Apache, MySQL, PHP) in its own container, you follow the microservices principle, which allows for better scalability and maintenance. This separation also enables each container to be independently scaled and managed, ensuring high availability for each component.
- Readiness and liveness probes: Implementing these probes ensures that Kubernetes can check the health of each container and can restart any unhealthy containers, enhancing the availability of your application.
- Kubernetes best practices: Kubernetes is designed to work best with multiple containers, each handling a specific task (such as Apache, MySQL, etc.). This approach aligns with Google’s best practices for containerized applications and ensures you can scale and manage the application effectively.
Why this is the best option: This option is the most aligned with Google-recommended best practices for Kubernetes, ensuring that each component is independently managed and has high availability. Readiness and liveness probes also ensure that the components are running correctly and that Kubernetes can handle restarts or scaling automatically.
Option B: Package the application in a single container. Use a process management tool to manage each component.
This option suggests packaging Apache, MySQL, and PHP into a single container, which violates a key principle of containerization: one service per container. While using a process management tool could allow you to manage multiple services within the same container, this creates challenges:
- No independent scaling: The components cannot be scaled independently, as they are bundled into one container.
- Harder to troubleshoot and maintain: Debugging or managing the components becomes more difficult since they are all in one container. If one service fails, you might have to restart the entire container.
- Google best practices: This is not a recommended approach in Kubernetes environments, where modularity and the ability to scale individual services are critical.
Why this is rejected: While technically feasible, packaging multiple services into a singl...
Author: VioletCheetah55 · Last updated Jul 4, 2026
You are developing an application that will be launched on Compute Engine instances into multiple distinct projects, each corresponding to the environments in your software development process (development, QA, staging, and production). The instances in each project have the same application code but a different configuration. During deployment, each instance should r...
When choosing the best option for configuring the application based on the environment each Compute Engine instance serves, we need to consider factors such as simplicity, automation, scalability, and the ease with which the application can be configured in a multi-project setup.
Let's go over each option:
A) When creating your instances, configure a startup script using the `gcloud` command to determine the project name that indicates the correct environment.
- This option involves configuring a startup script on the instance that uses the project name to infer the environment (e.g., development, QA, staging, or production).
- Pros: Startup scripts can automatically run at instance startup, which is convenient for initialization. It’s a good choice if the environment is tightly tied to the project name.
- Cons: This approach is not flexible, as it hardcodes the environment logic into the instance's startup script. It also introduces a dependency on the `gcloud` command, which may not always be available in the context of all environments. Additionally, this method doesn't separate the logic for querying the configuration, making it less modular and scalable.
- Best scenario: This could work in small-scale environments or specific use cases where the project name directly maps to the environment and the startup script is easy to manage.
B) In each project, configure a metadata key `environment` whose value is the environment it serves. Use your deployment tool to query the instance metadata and configure the application based on the `environment` value.
- This option involves setting a metadata key `environment` for each project and querying this metadata during deployment to configure the application appropriately.
- Pros: It centralizes the environment information in instance metadata, which is easily accessible by deployment tools. This is a clean, scalable solution because the metadata is consistent and external to the application code. It decouples the environment configuration from the instance itself and the application logic, making it more maintainable.
- Cons: Metadata might need to be queried at deployment time, and there could be slight complexity in managing deployment tools, though this is generally minimal.
- Best scenario: This is an ideal solution for managing multiple environments across projects, as it centralizes environment configuration and allows flexibility in deploying configurations dynamically.
C) Deploy your chosen deployment tool on an instance in each project. Use a deployment job to retrieve the appropriate configuration file from your versio...
Author: Leah · Last updated Jul 4, 2026
You are developing an ecommerce application that stores customer, order, and inventory data as relational tables inside Cloud Spanner. During a recent load test, you discover that Spanner per...
Let's break down the potential causes for the performance scaling issue in your Cloud Spanner-based ecommerce application, considering each option and how they might affect performance.
A) The use of 64-bit numeric types for 32-bit numbers.
- Explanation: Using a 64-bit numeric type for 32-bit numbers could lead to inefficiencies in terms of storage and memory usage. While this may increase the storage requirement slightly, it wouldn't generally cause a significant performance bottleneck in terms of query processing or scaling in Cloud Spanner.
- Why Rejected: This would not explain the performance issue you're experiencing during load testing. The impact on scalability would be minor since Cloud Spanner is designed to scale horizontally and handle varying data types efficiently. The issue is more likely due to other factors like indexing or query structure rather than simply using larger numeric types when smaller types could suffice.
B) The use of the STRING data type for arbitrary-precision values.
- Explanation: The STRING data type in Cloud Spanner is often used for text or variable-length data. If arbitrary-precision numeric values (like very large numbers or values requiring high precision) are stored as STRING, this could lead to performance inefficiencies during queries or index lookups, as Cloud Spanner would treat them as string data instead of optimized numeric types.
- Why Rejected: While using STRING for arbitrary-precision values is inefficient and could result in slower queries or more complex data handling, this is not the most likely explanation for the scalability issue. In practice, using numeric types (like `NUMERIC` or `FLOAT64`) for numeric values would be a better choice, but this alone would not likely prevent the system from scaling well under load.
C) The use of Version 1 UUIDs as primary keys that increase monotonically.
- Explanation: Version 1 UUIDs (UUIDv1) are based on the current timestamp and include the machine’s MAC address, resulting in a UUID that increases monotonically over time. When used as ...
Author: Madison · Last updated Jul 4, 2026
You are developing an application that reads credit card data from a Pub/Sub subscription. You have written code and completed unit testing. You need to test the
Pu...
When testing a Pub/Sub integration before deploying to Google Cloud, it's important to verify that both the message publishing and subscription handling work correctly. The goal is to test the interaction between your application and Pub/Sub in an environment that mimics production as closely as possible, without actually affecting production data.
Let’s evaluate each option:
A) Create a service to publish messages, and deploy the Pub/Sub emulator. Generate random content in the publishing service, and publish to the emulator.
- Explanation: In this option, you would use the Pub/Sub emulator, which simulates Google Cloud Pub/Sub locally. You would create a service that generates random content and publishes to the emulator.
- Pros: The Pub/Sub emulator allows for local testing without needing to connect to the actual Google Cloud infrastructure. It’s useful for testing the application’s behavior with simulated Pub/Sub interactions.
- Cons: Generating random content might not reflect the exact structure of real credit card data or other domain-specific data, which could limit the accuracy of the test. It’s also more useful for unit or integration tests rather than for testing end-to-end functionality.
- Best scenario: This could be used if you want to focus on testing the behavior of your application under controlled conditions with random data, but it may not provide a full test of your application's interaction with production-like data.
B) Create a service to publish messages to your application. Collect the messages from Pub/Sub in production, and replay them through the publishing service.
- Explanation: This option suggests collecting messages in production and replaying them through the service to test the integration.
- Pros: This could be useful for testing with real production data, ensuring that your application behaves correctly with actual messages.
- Cons: Collecting and replaying production messages could violate privacy and data protection regulations (e.g., handling sensitive customer data like credit card numbers). It also introduces unnecessary risks by interacting with production data when you could test in a safe environment.
- Best scenario: This should generally be avoided unless you have very strict controls and anonymization for testing with production data, which is typically not recommended.
C) ...
Author: StarlightBear · Last updated Jul 4, 2026
You are designing an application that will subscribe to and receive messages from a single Pub/Sub topic and insert corresponding rows into a database. Your application runs on Linux and leverages preemptible virtual machines to reduce c...
To design a graceful shutdown mechanism for an application that subscribes to and receives messages from a Pub/Sub topic and inserts corresponding rows into a database, we need to ensure that the application finishes its work properly before shutting down. The primary goal is to give the application time to finish any in-progress database operations and to stop processing messages from Pub/Sub gracefully.
Let's evaluate each option based on the goal of achieving a graceful shutdown:
A) Write a shutdown script that uses inter-process signals to notify the application process to disconnect from the database.
- Explanation: This option suggests sending an inter-process signal (e.g., `SIGTERM`) to the application process, instructing it to disconnect from the database and stop processing. Inter-process signals are a standard way to communicate with processes, especially in a Linux environment.
- Pros: Using signals is an efficient and standard way to communicate with processes, and it allows the application to handle the shutdown process in a controlled manner. The application can catch the signal and perform a graceful shutdown by closing database connections and cleaning up resources.
- Cons: The main limitation here is that it depends on the application being designed to handle specific signals correctly (e.g., by catching `SIGTERM` or `SIGINT`). If the application doesn't handle signals properly, it may not shut down gracefully.
- Best scenario: This is a good option if the application is designed to handle shutdown signals, as it allows for a clean and controlled shutdown. It is also efficient and direct.
B) Write a shutdown script that broadcasts a message to all signed-in users that the Compute Engine instance is going down and instructs them to save current work and sign out.
- Explanation: This option involves notifying users that the instance is shutting down, instructing them to save their work and sign out.
- Pros: This would work well in user-facing applications where you need to notify human users to save their work before the shutdown. It is useful for applications where there is active user interaction.
- Cons: In this case, the application processes data from Pub/Sub and inserts it into a database rather than dealing directly with users. Broadcasting a message to users is unnecessary and irrelevant for this type of background service. It doesn't address the core concern of gracefully handling the application’s interaction with Pub/Sub and the database.
- Best scenario: This option is not ideal for a background service like the one described, as it doesn't help with database connections or managing the application’s workflow during shutdown.
C) Write a shutdown script that writes a file in a location that is being polled by the application once every five minutes. After the file is read, the application disconnects from the database.
- Explanation: This option involves creating a file t...
Author: Zara · Last updated Jul 4, 2026
You work for a web development team at a small startup. Your team is developing a Node.js application using Google Cloud services, including Cloud Storage and Cloud Build. The team uses a Git repository for version control. Your manager calls you over the weekend and instructs you to make an emergency update to one of the company's websites, and you're the only developer available. You need to access Google Cloud to ...
In this scenario, you need to access and update the source code without storing it locally on a non-corporate computer. The solution should ensure that you can safely make changes, use Git for version control, and deploy the update while maintaining security and compliance.
Let's evaluate each option:
A) Use a text editor and the Git command line to send your source code updates as pull requests from a public computer.
- Explanation: In this option, you'd use a text editor and Git from a public computer to edit the source code and send updates as pull requests.
- Pros: This allows you to directly edit and commit changes to the Git repository.
- Cons: Using a public computer introduces security risks, especially if sensitive data (such as credentials or API keys) is involved. Additionally, this method doesn't provide a secure, isolated environment for development. There are risks related to the privacy and integrity of the code since it's being done on a non-corporate, potentially insecure machine.
- Best scenario: This could work in a pinch, but it is not ideal for secure, corporate environments. It is risky because you may not have control over the security or environment of the public machine.
B) Use a text editor and the Git command line to send your source code updates as pull requests from a virtual machine running on a public computer.
- Explanation: This option suggests running a virtual machine (VM) on a public computer and using it to make updates to the Git repository.
- Pros: This isolates your development environment from the public computer and provides more control over the environment.
- Cons: While the VM is isolated, the public computer still introduces security risks. The VM would have to be securely configured, and you still have to trust the public machine to some extent. Additionally, setting up a VM may be overkill for a simple emergency fix and could require extra setup time and resources.
- Best scenario: This option might be useful if you're trying to isolate the development environment on a public computer, but it's overly complex for a quick fix and still involves some security concerns.
C) Use Cloud Shell and the built-in code editor for development. Send your source code updates as pull requests.
- Explanation: Cloud Shell is a browser-based development environment provided by Google Cloud. It offers access to Google Cloud services, including version control through Git, and provides a built-in editor for writing code.
- Pros: Cloud Shell is a secure, managed environment that runs in the cloud, so you don't have to worry about...
Author: Aarav2020 · Last updated Jul 4, 2026
Your team develops services that run on Google Kubernetes Engine. You need to standardize their log data using Google-recommended practices and make the data more ...
When choosing the best options for standardizing log data using Google-recommended practices, it is important to focus on two factors: ease of implementation and the efficiency of log analysis. Let’s evaluate the options:
A) Create aggregated exports on application logs to BigQuery to facilitate log analytics.
Reason for rejection: Exporting logs to BigQuery is a good option for log analysis, but it is a step that is generally done after logs have been properly structured and captured in Cloud Logging. This option may be beneficial in later stages for querying and analyzing large datasets but doesn’t directly standardize logs at the point of generation. Therefore, while it’s useful for analytics, it’s not a best practice for the first step in standardizing log data.
B) Create aggregated exports on application logs to Cloud Storage to facilitate log analytics.
Reason for rejection: Cloud Storage is typically used for long-term log storage, not for structured log analysis. It doesn’t provide native querying capabilities or real-time log aggregation like BigQuery. Additionally, it is less efficient for real-time log analytics because the logs would need to be processed separately, rather than being immediately available for analysis. This option doesn’t align with Google’s best practices for standardizing logs.
C) Write log output to standard output (stdout) as single-line JSON to be ingested into Cloud Logging as structured logs.
Reason for selection: Writing logs in structured JSON format to `stdout` allows logs to be ingested into Cloud Logging as structured logs, which is highly recommended by Google for standardization. Structured logs are easier to search, filter, and analyze. This step ensures that logs are automatically captu...
Author: Alexander · Last updated Jul 4, 2026
You are designing a deployment technique for your new applications on Google Cloud. As part of your deployment planning, you want to use live traffic to gather performance metrics for both new and existing applicat...
When selecting the appropriate deployment technique to gather performance metrics using live traffic and test against the full production load, it is crucial to ensure that the method allows you to test real-world conditions while minimizing risk. Let’s analyze each option:
A) Use canary deployment
Reason for rejection: A canary deployment gradually shifts a small percentage of traffic to the new version, starting with a small subset of users (the "canaries") and progressively increasing the percentage. While this is great for minimizing risk and ensuring the new version is stable, it doesn’t allow you to test against the full production load. Canary deployments are designed for incremental rollouts rather than testing under full load conditions. Therefore, this approach would not meet the goal of testing the performance against the full production load prior to launch.
B) Use blue/green deployment
Reason for rejection: A blue/green deployment involves switching between two environments (the current live environment, “blue,” and a new version, “green”) after testing the new version. This technique is effective for zero-downtime deployments and quick rollbacks. However, blue/green deployments do not inherently allow you to test the new version against live traffic until the switch is made, and they focus more on ensuring seamless deployment rather than testing with full production load before launch. This option also typically involves routing all production traffic to the new environment once the switch happens, which does not align with gathering performance metrics with live traffic before the full launch.
C) Use rolling updates deployment
Reason for ...
Author: Rahul · Last updated Jul 4, 2026
You support an application that uses the Cloud Storage API. You review the logs and discover multiple HTTP 503 Service Unavailable error responses from the
API. Your application logs the error and does not take any further action. You want...
When implementing retry logic for handling HTTP 503 (Service Unavailable) errors from the Cloud Storage API, the goal is to ensure that the retries are effective in overcoming temporary service disruptions, without overwhelming the service or creating excessive retries. Let's analyze each option to determine the best approach based on Google's recommended practices for retrying failed operations.
A) Retry the failures in batch after a set number of failures is logged.
Reason for rejection: This approach involves batching retries, which is inefficient when handling individual failures. HTTP 503 errors are typically transient, meaning they may resolve quickly. By waiting for a set number of failures to accumulate before retrying, you risk unnecessary delays, as each error might require an immediate retry. This approach doesn’t provide the best user experience or system reliability, as it’s less responsive to individual failures.
B) Retry each failure at a set time interval up to a maximum number of times.
Reason for rejection: Retrying each failure at a fixed time interval (such as every 5 seconds) does not take into account the possibility of increasing load or decreasing service availability over time. HTTP 503 errors typically indicate temporary issues that may resolve after a short period, and retrying at fixed intervals can be inefficient. It could lead to too many retries happening too quickly, potentially causing congestion or further resource contention on the service.
C) Retry each failure at increasing time intervals up to a maximum number of tries.
Reason for selection: Exponential backoff with ...
