Google Practice Questions, Discussions & Exam Topics by our Authors
You are developing a single-player mobile game backend that has unpredictable traffic patterns as users interact with the game throughout the day and night. You want to optimize costs by ensuring that you have enough resources to handle requests, but minimize over-p...
Let's analyze each option based on the requirement to handle unpredictable traffic while minimizing costs and efficiently managing traffic spikes.
A) Cloud Run
- Benefit: Cloud Run is a fully managed serverless compute platform that automatically scales based on incoming requests. It scales down to zero when there is no traffic, meaning you only pay for the resources consumed during active requests. It is ideal for applications with unpredictable traffic and spikes, as it automatically adjusts to the traffic pattern.
- Drawback: While Cloud Run is a great option for stateless workloads or microservices, it might not be ideal for all game backends, especially if you need to manage persistent connections or require more specific resource management or complex configurations that aren't well-suited to Cloud Run's stateless nature. However, for many mobile game backends that are highly dynamic and don't require persistent state, this is often a good choice.
- Why It's Selected: Cloud Run is cost-effective, scales automatically based on demand, and helps minimize over-provisioning. This makes it a suitable choice for unpredictable traffic patterns.
B) Compute Engine with managed instance groups
- Benefit: Managed instance groups (MIGs) allow you to create and scale virtual machine instances based on load. It automatically adjusts the number of instances up or down, which is useful for handling traffic spikes.
- Drawback: Unlike Cloud Run, which is serverless, Compute Engine requires you to manage virtual machines, including configuring instances, scaling policies, and potentially dealing with idle resources. While it provides more control over the underlying infrastructure, it might not be as efficient as Cloud Run in terms of cost since it can involve over-provisioning (especially during off-peak times). Additionally, scaling might not be as quick or as seamless as serverless platforms.
- Why It's Not Ideal: While MIGs can handle scaling, the potential for over-provisioning makes it less cost-effective compared to serverless solutions like Cloud Run, especially for workloads with unpredictable traffic.
C) Compute Engine with unmanaged instance groups
- Benefit: Unmanaged instance groups provide flexibility in how instances are c...
Author: Liam · Last updated Jul 4, 2026
The development teams in your company want to manage resources from their local environments. You have been asked to enable developer access to each team's Google Cloud projects. You want to maxim...
Let's break down each option based on the goal of enabling developer access to Google Cloud projects efficiently while following best practices.
A) Add the users to their projects, assign the relevant roles to the users, and then provide the users with each relevant Project ID.
- Drawback: While adding users directly to individual projects and assigning roles works, it can become cumbersome if the number of developers or projects increases. Each user would need to be managed individually for every project, which is not efficient at scale. Additionally, this approach can be error-prone and more challenging to manage, especially as projects grow.
- Rejection Reason: This method lacks scalability and introduces unnecessary complexity when managing multiple developers or projects.
B) Add the users to their projects, assign the relevant roles to the users, and then provide the users with each relevant Project Number.
- Drawback: Similar to option A, this approach still requires managing users and roles individually per project. However, using the Project Number instead of the Project ID doesn't significantly improve scalability or manageability. The use of project numbers also adds an extra layer of confusion compared to using the Project ID, which is generally preferred for clarity and consistency.
- Rejection Reason: Again, this approach lacks scalability, and using project numbers is less intuitive compared to using project IDs.
C) Create groups, add the users to their groups, assign the relevant roles to the groups, and then provide the users with each relevant Project ID.
- Benefit: Using groups to manage users allows for much more efficient management of access across multiple projects. Instead of adding users individually to projects, you can assign roles t...
Author: Krishna · Last updated Jul 4, 2026
Your company's product team has a new requirement based on customer demand to autoscale your stateless and distributed service running in a Google Kubernetes Engine (GKE) duster. You want to find a solution ...
To determine the best solution for autoscaling a stateless and distributed service in Google Kubernetes Engine (GKE), it's important to assess each option in the context of minimizing changes and fulfilling the autoscaling requirements within a two-week time frame. Let's analyze each option based on the following criteria:
1. Stateless Nature of the Service: Stateless services typically don't rely on the internal state of the application. The key requirement is scaling the number of replicas of pods rather than modifying pod configurations such as resource limits.
2. Two-Week Timeline: The solution needs to be easy to implement with minimal changes in the existing setup. This excludes options that might require major rework or long testing cycles.
Option Analysis:
A) Deploy a Vertical Pod Autoscaler (VPA), and scale based on CPU load
- Vertical Pod Autoscaler (VPA) adjusts the resource limits (CPU and memory) of individual pods. It is ideal for scaling applications where the resource requirements for individual pods change over time.
- Why it’s not ideal: Since the service is stateless, scaling based on individual pod resource adjustments is less relevant because the stateless nature benefits more from horizontal scaling (scaling the number of pod replicas) rather than adjusting resources for each pod.
B) Deploy a Vertical Pod Autoscaler (VPA), and scale based on a custom metric
- Vertical Pod Autoscaler with custom metrics allows for adjusting resource limits based on custom metrics, but the fundamental issue is that this still doesn't address the stateless nature of the service. Again, modifying resource requests per pod isn’t the optimal approach when scaling out stateless services.
- Why it’s not ideal: The stateless service likely needs to scale out in terms of replicas, not necessarily adjusting the CPU and memory limits of each individual pod.
C) Deploy a Horizontal Pod Autoscaler (HPA), and scale based on the CPU load
- Horizontal Pod Autoscale...
Author: Liam · Last updated Jul 4, 2026
Your application is composed of a set of loosely coupled services orchestrated by code executed on Compute Engine. You want your application to easily bring up new Compute Engine instances ...
To ensure that your application, composed of loosely coupled services orchestrated by code executed on Compute Engine, can easily bring up new Compute Engine instances that find and use a specific version of a service, you need to select a solution that enables flexibility, scalability, and dynamic service discovery. Let's analyze each option in the context of these needs:
Option Analysis:
A) Define your service endpoint information as metadata that is retrieved at runtime and used to connect to the desired service
- Metadata in Google Cloud can be dynamically set at the instance level, and instances can retrieve metadata using the Google Cloud Metadata server.
- Why this could work: Metadata is well-suited for configuration data that is needed by applications at runtime. It is flexible and can be updated without needing to modify the instance or redeploy the application. If the service version information or endpoint can be stored in metadata, new instances can fetch this metadata to connect to the correct service version.
- Why it’s ideal: This solution supports dynamic service discovery, which is important when you need to bring up new instances and ensure they are connected to the correct version of the service.
B) Define your service endpoint information as label data that is retrieved at runtime and used to connect to the desired service
- Labels in Google Cloud are generally used for resource management, filtering, and organization. While labels are useful for grouping and categorizing resources, they aren't typically designed to store dynamic configuration data like service endpoints.
- Why it's not ideal: Labels are not intended for holding runtime-specific configuration like service endpoints. Using labels for this purpose could lead to complexity and difficulty in managing your service discovery process.
C) Define your...
Author: Kunal · Last updated Jul 4, 2026
You are developing a microservice-based application that will run on Google Kubernetes Engine (GKE). Some of the services need to access different Google Cloud APIs. How should you set up authentication of...
In a Google Kubernetes Engine (GKE) environment, securing authentication for services that need to access Google Cloud APIs is critical. Google Cloud recommends specific practices to ensure that services can authenticate securely without relying on service account keys that are hard to manage and rotate. Let’s evaluate the available options based on best practices:
Option Analysis:
A) Use the service account attached to the GKE node
- What it implies: This option would grant the GKE node itself (rather than individual pods) access to the Google Cloud APIs using the service account attached to the node. However, the node’s service account may have broad permissions, potentially over-permissioning the pods running on the node.
- Why it's not ideal: While it may seem convenient to use the node's service account, it leads to the issue of "least privilege" violations. Pods should only be given the minimum necessary permissions to avoid security risks. Granting access at the node level could result in unnecessary exposure of sensitive data or resources.
B) Enable Workload Identity in the cluster via the gcloud command-line tool
- What it implies: Workload Identity is a feature that allows Kubernetes workloads (i.e., pods) to authenticate to Google Cloud APIs using Google identities (service accounts) with more fine-grained permission control. It avoids managing service account keys directly.
- Why this is ideal: This approach follows the Google-recommended best practice. Workload Identity allows you to securely map Kubernetes service accounts to Google Cloud service accounts, thus ensuring that your workloads only have the minimum permissions they need to access the APIs. It also simplifies credential management since you don’t need to handle service account keys manually.
C) Access the Google service account keys from a secret management service
- What it implies: This would mean storing Google service account keys in a secret management service like Google Cloud Secret Manager or HashiCorp Vault.
- Why it’s not ideal: Storing service account keys in a secret management service introduces complexity, and it does not align with the best practices recommended by Google. Ser...
Author: Lucas · Last updated Jul 4, 2026
Your development team has been tasked with maintaining a .NET legacy application. The application incurs occasional changes and was recently updated. Your goal is to ensure that the application provides consistent results while moving through the CI/CD pipeline from environment to environment. You want to minimize the cost of deployment while making sure that e...
Given the requirements and constraints outlined in the scenario, let's evaluate each option to determine the most suitable solution for maintaining the legacy .NET application while ensuring consistency and minimizing deployment costs, especially without the use of containers, which are not yet approved by your organization.
Option Analysis:
A) Rewrite the application using .NET Core, and deploy to Cloud Run. Use revisions to separate the environments.
- What it implies: This option suggests rewriting the application in .NET Core (a cross-platform framework), and deploying it to Cloud Run, which is a fully managed service designed to run containers. Cloud Run uses containerized applications but handles the orchestration for you.
- Why it's not ideal: The main issue here is that containers are not approved in your organization. Cloud Run requires containers, so this option would require circumventing the no-containers policy, making it unsuitable.
B) Use Cloud Build to deploy the application as a new Compute Engine image for each build. Use this image in each environment.
- What it implies: This option suggests using Cloud Build to automate the process of creating a new Compute Engine image for each build. The image would then be used to deploy the application across various environments.
- Why this could work: By packaging the application into a specific Compute Engine image, you ensure that the same environment is replicated across different stages (development, staging, production), ensuring consistency. The image would have all necessary dependencies bundled, and environment differences would be minimized.
- Why it's ideal: This solution directly addresses the need for consistency across environments while minimizing deployment costs by avoiding manual configuration of each environment. Since containers are not allowed, building and deploying a new Compute Engine image for each build is a good alternative.
C) Deploy the application using MS Web Deploy, and make sure to always use the latest, patched MS Windows Server base image in Compute Engine.
- What it implies: This option suggest...
Author: Ahmed97 · Last updated Jul 4, 2026
The new version of your containerized application has been tested and is ready to deploy to production on Google Kubernetes Engine. You were not able to fully load-test the new version in pre-production environments, and you need to make sure that ...
To ensure that your containerized application does not encounter performance problems once deployed to production on Google Kubernetes Engine (GKE), while automating the deployment process, the solution should focus on gradual traffic ramp-up, performance monitoring, and automated rollback if issues arise. Let’s analyze each option:
Option Analysis:
A) Use Cloud Load Balancing to slowly ramp up traffic between versions. Use Cloud Monitoring to look for performance issues.
- What it implies: This option suggests using Cloud Load Balancing to manage traffic between the old and new versions, gradually ramping up traffic to the new version. Cloud Monitoring is then used to detect performance issues during the process.
- Why it's not ideal: While this approach could help manage traffic, it doesn’t offer the level of fine-grained control and automation provided by Kubernetes-native deployment strategies like canary or blue/green deployments. Also, there are no clear rollback mechanisms if performance issues are detected, which is a significant drawback when dealing with production environments.
B) Deploy the application via a continuous delivery pipeline using canary deployments. Use Cloud Monitoring to look for performance issues, and ramp up traffic as the metrics support it.
- What it implies: This option involves using a canary deployment strategy within a continuous delivery pipeline. The new version of the application would be deployed to a small subset of users (the canary), and Cloud Monitoring would be used to assess performance. If no issues are detected, the traffic is gradually ramped up.
- Why this is ideal: Canary deployments are well-suited for this situation. They allow you to test the new version in production with minimal risk, starting with a small number of users and gradually increasing traffic based on performance metrics. The automation of this process is also handled within a continuous delivery pipeline, which meets the requirement of automating the deployment. Moreover, performance metrics from Cloud Monitoring ensure that any issues are caught early.
- Why it's better than A: Canary deployments offer more control over the gradual rollout of traffic and provide better rollback options if issues arise. It is a more sophisticated and Kubernetes-native method compared to using just Cloud Load Balancing.
C) Deploy the application via a continuous delivery pipeline using blue/green deployments. Use Cloud Monitoring to look for performance issues, and launch fully when the metrics support it.
- What it implies: This option involves using b...
Author: Ming88 · Last updated Jul 4, 2026
Users are complaining that your Cloud Run-hosted website responds too slowly during traffic spikes. You want to provide a better u...
To address the slow response time during traffic spikes, we need to focus on improving how the application handles high loads efficiently, ensuring scalability, and reducing bottlenecks. Here's a breakdown of each option:
A) Read application configuration and static data from the database on application startup.
- Issue: This approach can introduce significant delays at the application startup phase. If the application depends on data from the database during startup, this could create a slow initialization process, especially when the system is under heavy load.
- Drawback: On traffic spikes, instances might need to restart or scale up quickly, leading to long initialization times due to the dependency on the database. This does not directly address the issue of responding quickly during spikes.
- Scenario: This could be used when your data is highly dynamic and needs to be fetched on each startup, but it’s not ideal for handling traffic spikes.
B) Package application configuration and static data into the application image during build time.
- Advantage: By including static data and configuration directly within the application image, the application doesn't have to rely on fetching this data from external resources at runtime. This reduces the overhead during initialization, which is especially helpful when scaling to meet high traffic demands.
- Drawback: This approach is less flexible since the static data is baked into the image and would require rebuilding the application image if the configuration or data changes.
- Scenario: Best for applications where configuration and data rarely change and can be bundled with the application, ensuring fast startup time...
Author: Daniel · Last updated Jul 4, 2026
You are a developer working on an internal application for payroll processing. You are building a component of the application that allows an employee to submit a timesheet, which then initiates several steps:
* An email is sent to the employee and manager, notifying them that the timesheet was submitted.
* A timesheet is sent to payroll processing for the vendor's API.
* A timesheet is sent to the data warehouse for headcount planning.
These steps are not dependent on each other and ca...
To determine the best approach for implementing the payroll processing system where multiple steps are performed independently, we need to evaluate how to handle scalability, error handling, and the decoupling of different tasks. Let's go through each option:
A) Deploy a Cloud Function for each step that calls the corresponding downstream system to complete the required action.
- Advantage: Cloud Functions are lightweight, easy to deploy, and scale automatically. Each step being handled by a separate function allows for clear separation of concerns and independent scaling.
- Drawback: While Cloud Functions handle individual tasks well, managing multiple functions for different steps may increase complexity. Additionally, error handling would have to be built into each individual function, potentially leading to duplicated logic. As new steps are added, managing each one as a separate Cloud Function could become difficult.
- Scenario: Suitable for small, isolated tasks where each action needs to be handled separately and quickly, but scalability and centralized error handling might become a challenge as the application grows.
B) Create a Pub/Sub topic for each step. Create a subscription for each downstream development team to subscribe to their step's topic.
- Advantage: This approach allows you to decouple each step in the process and have multiple teams independently work on their own steps. It also provides flexibility, as new steps can be added by simply creating new topics and subscriptions. Error handling can be tailored by each team for their specific task.
- Drawback: Managing multiple Pub/Sub topics for each step may introduce overhead, and there might be more complex communication between different teams' services. However, this complexity is generally manageable and allows for scalability.
- Scenario: Ideal when different teams need to work on specific, independent tasks (such as email notification, payroll API, and headcount data) and error handling can be isolated for each component...
Author: Layla · Last updated Jul 4, 2026
You are designing an application that uses a microservices architecture. You are planning to deploy the application in the cloud and on-premises. You want to make sure the application can scale...
When designing an application with microservices architecture that needs to scale up on demand and leverage managed services, it’s important to focus on scalability, ease of management, and the ability to use managed services wherever possible. Let's evaluate each option:
A) Deploy open-source Istio in a multi-cluster deployment on multiple Google Kubernetes Engine (GKE) clusters managed by Anthos.
- Advantage: Istio, when deployed in a multi-cluster environment, can provide powerful service mesh capabilities, including traffic management, service discovery, and observability across environments. Anthos can manage multiple clusters, ensuring consistent policies and configuration across both on-premises and cloud-based environments.
- Drawback: Although Istio and Anthos are robust for managing complex service meshes, deploying and maintaining Istio in a multi-cluster setup can be operationally complex. It requires expertise to configure and manage, especially when considering scaling on demand.
- Scenario: Ideal for large-scale, complex applications requiring advanced traffic management, monitoring, and service mesh functionality. However, the operational complexity might be overkill for simpler use cases.
B) Create a GKE cluster in each environment with Anthos, and use Cloud Run for Anthos to deploy your application to each cluster.
- Advantage: This approach offers a managed and scalable solution, as Cloud Run for Anthos allows you to deploy and scale containerized applications on Kubernetes clusters while benefiting from the abstraction that Cloud Run provides (such as automatic scaling). Anthos provides a unified management layer across the on-premises and cloud environments, making it easier to deploy and manage across both.
- Drawback: Cloud Run for Anthos is designed for containerized applications, and if your application architecture doesn’t align well with containers or microservices, it might introduce additional complexity.
- Scenario: Ideal when you want to use managed services for scaling and deployment, and you have containerized microservice...
Author: Arjun · Last updated Jul 4, 2026
You want to migrate an on-premises container running in Knative to Google Cloud. You need to make sure that the migration doesn't affect your application's deployment strategy, and you want to use a ful...
When migrating an on-premises container running in Knative to Google Cloud, it’s essential to choose a fully managed service that supports containers, provides seamless scaling, and aligns with the application’s deployment strategy without causing disruption. Let’s evaluate each option:
A) Cloud Run
- Advantage: Cloud Run is a fully managed service that supports containers and scales automatically based on incoming traffic, making it a perfect match for applications initially running in Knative. Cloud Run abstracts away the underlying infrastructure, allowing you to focus on deploying and managing the container without worrying about scaling or infrastructure management. It provides a similar experience to Knative, which makes migration easy without changing the deployment strategy.
- Drawback: Cloud Run is designed primarily for stateless applications. If your application requires persistent state or complex configurations, Cloud Run may not be suitable.
- Scenario: Best suited for applications that are stateless or require lightweight container management with automatic scaling. Ideal for migrating from Knative, as it supports containerized workloads with minimal operational overhead.
B) Compute Engine
- Advantage: Compute Engine provides virtual machines (VMs) and offers complete control over the underlying infrastructure, which is useful for applications that need full control over the environment.
- Drawback: Using Compute Engine for containerized workloads would require managing the entire virtual machine infrastructure, including scaling, patching, and maintenance. This would defeat the purpose of using a fully managed service, as it introduces significant operational overhead.
- Scenario: Compute Engine is more appropriate for legacy applications or when you need full control ove...
Author: Nathan · Last updated Jul 4, 2026
This architectural diagram depicts a system that streams data from thousands of devices. You want to ingest data into a pipeline, store the data, and analyze the data using SQL st...
When designing a data pipeline for streaming data from thousands of devices, the selection of appropriate Google Cloud services for each step is critical to ensure scalability, manageability, and the ability to perform real-time data analysis. Let's break down each step and analyze the options:
Step 1: Ingest Data
- Options: App Engine, Dataflow, Pub/Sub
- App Engine: While App Engine is a fully managed platform, it is primarily designed for serving web applications, not for data ingestion or streaming. It’s more suited for hosting web services and applications rather than ingesting large-scale streaming data.
- Dataflow: Dataflow is a fully managed service for batch and stream processing but is not typically used for raw data ingestion; it's more about processing data once ingested.
- Pub/Sub: Pub/Sub is designed for real-time data ingestion and can handle large amounts of streaming data from thousands of devices. It is the best option for ingesting high-throughput streaming data into a pipeline.
Conclusion for Step 1: Pub/Sub is the best option for ingesting data as it is designed for handling real-time, high-volume streaming data.
Step 2: Process Data
- Options: Pub/Sub, Dataflow, Firestore
- Pub/Sub: Pub/Sub is good for ingestion but not for data processing or transformation. It is a messaging system that triggers events, but you need additional tools for processing.
- Dataflow: Dataflow is a fully managed service for stream and batch data processing. It is a great choice for transforming and processing data after it is ingested by Pub/Sub.
- Firestore: Firestore is a ...
Author: Elijah · Last updated Jul 4, 2026
Your company just experienced a Google Kubernetes Engine (GKE) API outage due to a zone failure. You want to deploy a highly available GKE architecture that minimizes service int...
To address the need for high availability in Google Kubernetes Engine (GKE) while minimizing service interruptions during a zone failure, the architecture should be designed in a way that accounts for fault tolerance and minimizes the impact of infrastructure issues like zone failures.
Let's break down the options:
A) Deploy Zonal clusters:
- Explanation: A zonal cluster is deployed within a single availability zone. While it is simple to set up and can be cost-effective for certain use cases, it is vulnerable to service disruption if the zone fails. This directly conflicts with the goal of high availability during a zone failure.
- Why rejected: Zonal clusters do not provide the required fault tolerance for high availability in the event of a zone failure. If the zone goes down, the entire cluster will be impacted.
- Scenario use: Zonal clusters could be used for non-critical applications or where downtime is acceptable, but not for highly available services.
B) Deploy Regional clusters:
- Explanation: Regional clusters span multiple availability zones (or regions) within a Google Cloud region. This architecture ensures that if one zone fails, the workload can be shifted to other zones within the same region, providing higher availability and redundancy.
- Why selected: Regional clusters provide fault tolerance and minimize downtime during a zone failure. Since the clusters are distributed across multiple zones, a failure in one zone will not disrupt the entire service. This meets the requirement for high availability in the event of a zone failure.
- Scenario use: Regional clusters are ideal for highly available production systems that need to be resilient to zone failures.
...
Author: Amira · Last updated Jul 4, 2026
Your team develops services that run on Google Cloud. You want to process messages sent to a Pub/Sub topic, and then store them. Each message must be processed exactly once to avoid duplication of data and any ...
To process messages sent to a Pub/Sub topic and store them while ensuring each message is processed exactly once, let's evaluate the options in terms of simplicity, cost, and avoiding duplication.
Option Evaluation:
A) Process the messages with a Dataproc job, and write the output to storage:
- Explanation: Dataproc is a managed Apache Hadoop and Spark service. While it can process large-scale data, it is overkill for processing messages from Pub/Sub in a simple and efficient manner. Dataproc jobs typically need more setup and configuration compared to other more lightweight alternatives.
- Why rejected: Dataproc is complex and introduces unnecessary overhead in terms of setup and maintenance, which makes it not the cheapest or simplest option. It also doesn't inherently support Pub/Sub message deduplication.
- Scenario use: Suitable for large-scale, batch-based, and complex data processing workloads, but not ideal for simple Pub/Sub message processing with deduplication.
B) Process the messages with a Dataflow streaming pipeline using Apache Beam's PubSubIO package, and write the output to storage:
- Explanation: Dataflow (which uses Apache Beam) is a fully managed service for stream and batch data processing. It provides robust support for Pub/Sub message ingestion, processing, and writing to destinations like Cloud Storage or BigQuery. Dataflow can also be configured to ensure "exactly once" processing semantics, avoiding duplication or conflicts.
- Why selected: Dataflow is designed for streaming data and can handle Pub/Sub messages efficiently. It provides the simplest and most cost-effective solution for processing and storing messages, ensuring exactly once delivery. Additionally, it's fully managed, reducing operational complexity.
- Scenario use: Ideal for real-time data processing with deduplication, particularly for Pub/Sub message processing, making it the best fit for your use case.
C) Process the messages with a Cloud Function, and write the results to a Big...
Author: Deepak · Last updated Jul 4, 2026
You are running a containerized application on Google Kubernetes Engine. Your container images are stored in Container Registry. Your team uses CI/CD practices. You need to prevent the d...
Explanation of the Options:
Option A:
- Web Security Scanner: This tool is used to crawl your web applications for vulnerabilities like XSS, CSRF, and other web application security issues. However, it does not provide vulnerability scanning for the container images themselves.
- Attestation & Binary Authorization: While this part ensures that only containers with the correct attestation can be deployed, it assumes the presence of a manual attestation based on reviewing application logs. Since Web Security Scanner isn't designed to scan container images, this method is not the most effective for preventing deployments based on known container vulnerabilities.
Rejected because Web Security Scanner isn't focused on container image vulnerability scanning.
Option B:
- Web Security Scanner: Like in Option A, Web Security Scanner is not ideal for container image vulnerabilities. It only scans web applications, not the container images themselves.
- Attestation & Binary Authorization: Again, you would manually review scan results and provide an attestation, but the core issue—vulnerability scanning on container images—is not addressed by this option.
Rejected because Web Security Scanner doesn't handle container image vulnerability scans.
Option C:
- Container Scanning API: This API scans the container images in Google Container Registry for known vulnerabilities. This is directly related to the objective of preventing the deployment of containers with critical vulnerabilities.
- Attestation & Binary Authorization: You manually review...
Author: Noah Williams · Last updated Jul 4, 2026
You have an on-premises application that authenticates to the Cloud Storage API using a user-managed service account with a user-managed key. The application connects to Cloud Storage using Private Google Access over a Dedicated Interconnect link. You discover that requests from the application to acce...
To diagnose the issue where an on-premises application is receiving a 403 Permission Denied error when attempting to access Cloud Storage, let's evaluate each option and determine the most likely cause based on the situation:
Option Evaluation:
A) The folder structure inside the bucket and object paths have changed:
- Explanation: If the folder structure or object paths within the Cloud Storage bucket have changed, the application might not be able to find the resources it is trying to access, leading to errors. However, this would usually result in a 404 Not Found error, not a 403 Permission Denied error.
- Why rejected: The error is a 403 Permission Denied, which typically indicates an issue with permissions or authentication, not with the resource being found. Therefore, this option is unlikely to be the root cause.
B) The permissions of the service account's predefined role have changed:
- Explanation: If the service account's permissions or roles (such as `roles/storage.objectViewer` or `roles/storage.objectAdmin`) have changed, this would result in a 403 Permission Denied error. Permissions are directly tied to roles and any changes here could revoke access to the Cloud Storage bucket.
- Why selected: This is a likely cause. If the permissions of the service account's predefined role were altered, the service account might no longer have the correct permissions to access the objects in Cloud Storage, resulting in the 403 error.
C) The service account key has been rotated but not updated on the application server:
-...
Author: Olivia · Last updated Jul 4, 2026
You are using the Cloud Client Library to upload an image in your application to Cloud Storage. Users of the application report that occasionally the upload does not complete and the client library reports an HTTP 504 Gateway Timeout error. Yo...
To make the application more resilient to the HTTP 504 Gateway Timeout error while uploading images to Cloud Storage, we need to implement a solution that effectively handles intermittent errors like timeouts and ensures that the upload process eventually succeeds. Let's analyze each option in detail.
Option Evaluation:
A) Write an exponential backoff process around the client library call:
- Explanation: Exponential backoff is a widely recommended strategy for handling transient errors like timeouts. When a request fails, the application waits for an increasing amount of time before retrying the operation (e.g., retry after 1 second, then 2 seconds, then 4 seconds, and so on). This approach reduces the likelihood of overwhelming the server and increases the chances of success on subsequent retries. It's especially useful for dealing with timeouts and temporary network issues.
- Why selected: This is the best solution for handling HTTP 504 Gateway Timeout errors. Exponential backoff is a robust, standard pattern recommended by Google Cloud and other services for retrying failed operations without overwhelming the system, making it a resilient and efficient approach. It adapts to transient issues and reduces the chance of repeated failures over time.
- Scenario use: Ideal for scenarios where intermittent timeouts or server overloads may occur, and the application needs to automatically retry failed operations.
B) Write a one-second wait time backoff process around the client library call:
- Explanation: A fixed backoff process, like waiting exactly one second between retries, can also help, but it does not adapt to varying error conditions. It may retry too quickly in some cases or not quickly enough in others, which may not be optimal for handling transient errors like HTTP 504. Fixed wait times do not scale well to larger systems or issues with intermittent network congestion or server overload.
- Why rejected: A fixed wait time backoff is less adaptive and may not be as effective in situations where the server or network is temporarily overloaded. It does not offer the flexibility of exponential backoff to handle varying delays in response times.
- Scenario use: Could be used for simpler systems where the issue is not as transient or frequent, but exponential backoff is a more robust solution.
C) Desig...
Author: Lina Zhang · Last updated Jul 4, 2026
You are building a mobile application that will store hierarchical data structures in a database. The application will enable users working offline to sync changes when they are back online. A backend service will enrich the data in the database using a service account. The applicat...
Let's evaluate each option based on the requirements of storing hierarchical data, offline sync, scalability, and security.
A) Cloud SQL, and assign the roles/cloudsql.editor role to the service account
- Reasoning:
- Cloud SQL is a managed relational database service. It works well for structured data, but it's not specifically optimized for hierarchical data structures. It typically requires a more complex schema and management for relationships, especially when scaling to large amounts of data.
- Offline Sync: While Cloud SQL can handle offline sync through manual data management or custom solutions, it's not optimized for syncing offline changes to complex hierarchical data.
- Scalability: Cloud SQL can scale vertically (i.e., by increasing resources), but it’s not as efficient for horizontal scaling (i.e., scaling out with multiple distributed nodes). This may become a bottleneck for a very popular app.
- IAM Role: The roles/cloudsql.editor role grants full access to Cloud SQL instances, but that might be more permissive than necessary, especially considering the security needs.
- Rejection Reason: Cloud SQL is not ideal for hierarchical data and might require complex scaling and management. It is more suited for structured relational data rather than scalable hierarchical storage.
B) Bigtable, and assign the roles/bigtable.viewer role to the service account
- Reasoning:
- Bigtable is a NoSQL database designed for scalability and performance with massive amounts of data. It is optimized for time-series data or large datasets with key-value access patterns.
- Offline Sync: Bigtable is not well suited for hierarchical data because it is a column-family store and does not support complex relationships or nested data structures.
- Scalability: Bigtable is highly scalable and can handle large amounts of data, but it is better suited for specific use cases like time-series or wide-column data storage.
- IAM Role: The roles/bigtable.viewer role grants read-only access to Bigtable, which is inappropriate for an application that needs to modify data in real-time, especially when the backend enriches data.
- Rejection Reason: Bigtable is not suitable for hierarchical data, and the roles/bigtable.viewer...
Author: Aria · Last updated Jul 4, 2026
Your application is deployed on hundreds of Compute Engine instances in a managed instance group (MIG) in multiple zones. You need to deploy a new instance template to fix a critical vulnerability immediately but must avoid im...
To deploy a new instance template and update the managed instance group (MIG) without impacting the service, it's important to ensure that the deployment happens with minimal disruption, ensuring that instances can be updated without downtime. Let's analyze each option.
A) Set the Max Surge to 100%
- Reasoning:
- Max Surge controls how many additional instances are created during an update to handle the transition, allowing for more capacity while instances are being replaced. Setting Max Surge to 100% means that for every instance being replaced, an additional instance is created.
- This would temporarily double the number of instances, providing redundancy during the update, which helps ensure no service disruption. This setting is beneficial for ensuring that the service remains available during the update.
- Rejection Reason: The disadvantage of setting Max Surge to 100% is that it may create excess capacity, leading to potentially unnecessary resource usage or increased cost, but it is ideal if you need to ensure service availability with minimal impact.
B) Set the Update mode to Opportunistic
- Reasoning:
- Opportunistic update mode allows for instances to be updated only when the group has excess capacity, meaning that updates will not happen immediately or unless there is room to do so without impacting the service. This mode prioritizes minimizing disruption by applying the updates opportunistically when possible.
- Rejection Reason: While Opportunistic may minimize impact, it does not guarantee the update will happen in a timely manner. If a critical vulnerability must be patched...
Author: Max · Last updated Jul 4, 2026
You made a typo in a low-level Linux configuration file that prevents your Compute Engine instance from booting to a normal run level. You just created the Compute Engine instance today and have done no...
To correct the typo in a low-level Linux configuration file preventing your Compute Engine instance from booting to a normal run level, it's important to choose an option that allows access to the instance when it is not booting normally. Let's analyze each option based on the scenario.
A) Download the file using scp, change the file, and then upload the modified version
- Reasoning:
- SCP (Secure Copy Protocol) requires that the instance be running or at least bootable to a point where it can accept SSH connections. If the instance isn't booting normally due to the typo, this approach will not work since you won't be able to access the instance via SCP.
- Rejection Reason: This method requires the instance to be accessible via SSH, which is not possible in this scenario because the instance is not booting to a normal run level.
B) Configure and log in to the Compute Engine instance through SSH, and change the file
- Reasoning:
- SSH would also require the instance to be bootable and accessible. Since the instance is not booting to a normal run level, SSH access won't be available.
- Rejection Reason: This method won't work since the instance is unable to boot normally and thus cannot be accessed via SSH.
C) Configure and log in to the Compute Engine instance through the serial port, and change the file
- Reasoning:
- Serial Console Access is a special feature that allows you to access your instance even when it is not booting ...
Author: Zara · Last updated Jul 4, 2026
You are developing an application that needs to store files belonging to users in Cloud Storage. You want each user to have their own subdirectory in Cloud Storage. When a new user is created...
In Google Cloud Storage, there is no concept of "directories" in the traditional sense. Instead, directories are simulated using the object naming system. This means you can use slashes ("/") in object names to simulate a directory structure, but the directory itself doesn’t actually exist until an object is placed inside it.
Let’s evaluate each option based on the requirement: creating a new "subdirectory" for a user when they are created.
A) Create an object with the name of the subdirectory ending with a trailing slash ('/') that is zero bytes in length.
- Reasoning:
- This approach simulates a directory by creating an object with a name that ends in a slash (`/`). It’s a common way to create a folder-like structure in Cloud Storage.
- The object will be zero bytes in length, effectively creating a placeholder object representing the subdirectory.
- Advantages: This is a valid approach because objects ending with a slash are treated as directories by Cloud Storage's listing and can be used to group other files.
- Selected Option: This works well for simulating directories, ensuring that each user has their own subdirectory in Cloud Storage.
B) Create an object with the name of the subdirectory, and then immediately delete the object within that subdirectory.
- Reasoning:
- This option first creates an object and then deletes it. While this would create a "directory" temporarily, deleting the object would remove the directory simulation and leave no placeholder for the subdirectory.
- Rejection Reason: Deleting the object right after creating it undermines the idea of...
Author: Aarav2020 · Last updated Jul 4, 2026
Your company's corporate policy states that there must be a copyright comment at the very beginning of all source files. You want to write a custom step in Cloud Build that is triggered by each source commit. You need the trigger to validate...
Let's evaluate each option based on the requirement: ensuring that a copyright comment is present in each source file at the beginning, validating and potentially adding one as part of the Cloud Build process triggered by each source commit.
A) Build a new Docker container that examines the files in /workspace and then checks and adds a copyright for each source file. Changed files are explicitly committed back to the source repository.
- Reasoning:
- The /workspace directory in Cloud Build is where the source code resides during the build process. This approach involves creating a custom Docker container to check for the copyright at the beginning of each file, and if missing, it adds the copyright comment.
- Committing changed files back to the source repository would ensure that the repository is updated with the newly added copyright comment. However, automatically committing changes could lead to unwanted changes in the repository, especially if files are modified outside of the intended process, which might disrupt version control or trigger unnecessary commits.
- Rejection Reason: Automatically committing back to the source repository could violate certain development policies, potentially leading to unnecessary changes in the commit history.
B) Build a new Docker container that examines the files in /workspace and then checks and adds a copyright for each source file. Changed files do not need to be committed back to the source repository.
- Reasoning:
- This option is more aligned with the goal. The /workspace directory contains the files being built in the Cloud Build environment. The custom Docker container will check and add the copyright comments as necessary during the build process.
- Not committing the changes back to the repository means the source code in the repository itself will remain untouched, preventing unnecessary commits or modifications to the repository’s history.
- Selected Option: This option ensures that the copyright comments are added during the build process without interfering with the repository, keeping the reposito...
Author: Siddharth · Last updated Jul 4, 2026
One of your deployed applications in Google Kubernetes Engine (GKE) is having intermittent performance issues. Your team uses a third-party logging solution. You want to install this soluti...
In this scenario, where you want to install a third-party logging solution on each node in your GKE cluster to view logs, let's analyze each option based on the key factors of scalability, manageability, and compatibility.
A) Deploy the third-party solution as a DaemonSet
- Explanation: A DaemonSet is a Kubernetes resource that ensures that a copy of a specific pod is running on each node in a cluster. This is a good fit for software that needs to run on all nodes, such as a logging agent. By deploying the logging solution as a DaemonSet, you ensure that the logging software is automatically installed and configured on every node in the cluster, without having to modify individual nodes or manage installations manually.
- Why this option is best: The DaemonSet ensures that the solution is deployed consistently across all nodes, scaling with the cluster as nodes are added or removed. This is ideal for logging solutions that need to collect logs from every node without manual intervention.
B) Modify your container image to include the monitoring software
- Explanation: This approach involves embedding the logging software into your container images so that the software runs as part of the containerized application.
- Why this option is rejected: While this might work for some use cases, it's not ideal for this scenario. The logging solution should ideally run on the node level to capture logs from all containers, not just the individual containers themselves. Embedding it into the container image would limit it to only the logs generated by that specific container an...
Author: Charlotte · 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 subse...
To redesign HipLocal's architecture to support a large increase in users, it's essential to consider scalability, performance, and management. Let's analyze each option based on key factors like the nature of the application, database requirements, scalability, and ease of management.
Option A: Use Google Kubernetes Engine (GKE) to run the application as a microservice. Run the MySQL database on a dedicated GKE node.
- Pros: GKE is a powerful service for managing microservices and scaling containerized applications. It provides high scalability, automatic management, and orchestration of containerized workloads. Running the application as microservices would allow easier updates, scaling, and failure isolation.
- Cons: Running MySQL on a GKE node is not ideal for scalability. MySQL typically requires high availability and is better suited for managed database services. Running MySQL on GKE could lead to performance bottlenecks, difficulties in scaling the database, and challenges with redundancy and backups.
- Why rejected: While GKE is a strong option for running scalable applications, MySQL should be managed separately in a more scalable solution like CloudSQL for proper database management.
Option B: Use multiple Compute Engine instances to run MySQL to store state information. Use a Google Cloud-managed load balancer to distribute the load between instances. Use managed instance groups for scaling.
- Pros: Compute Engine can provide dedicated virtual machines for MySQL, and the load balancer would help distribute traffic efficiently. Managed instance groups will scale the application automatically to meet demand.
- Cons: Running MySQL on Compute Engine can become complex, especially as it requires manual management for scaling, failover, and backups. Cloud-managed databases, like CloudSQL, offer better performance, scalability, and ease of management.
- Why rejected: This option introduces unnecessary complexity in managing MySQL. Using Compute Engine for MySQL is not as effective as using a managed database service like CloudSQL, which can scale automatically and ensure better uptime and performance.
Option C: Use Memorystore to store session information and CloudSQL to stor...
Author: Charlotte · 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 subse...
To increase API development speed while maintaining a stable testing environment that meets feature requirements, HipLocal needs to adopt practices that allow for faster development and reliable quality assurance (QA). Let's analyze the options based on this objective.
Option A: Include unit tests in their code, and prevent deployments to QA until all tests have a passing status.
- Pros: Unit tests help ensure that individual parts of the code work as expected, which is crucial for maintaining stability as the application scales. By preventing deployments until all unit tests pass, HipLocal can catch issues early in the development process, reducing the risk of introducing bugs into the QA environment.
- Cons: This approach, while useful, may slow down the development process, especially if the unit tests are not well-optimized. It can also lead to bottlenecks if developers are waiting for tests to pass before they can deploy their code.
- Why rejected: While unit tests are necessary and improve stability, this approach alone may not be sufficient to speed up API development, especially if the QA process still relies heavily on manual testing or lacks automated integration and performance testing.
Option B: Include performance tests in their code, and prevent deployments to QA until all tests have a passing status.
- Pros: Performance testing is vital for understanding how the API handles load and stress, particularly when scaling for a large number of users. Preventing deployments until performance tests pass can ensure that the API will scale effectively in production and meet performance expectations.
- Cons: Similar to unit tests, performance testing can slow down the development process if it’s not optimized or if the tests are too resource-intensive. It may also create bottlenecks in the development pipeline, delaying deployment.
- Why rejected: While...
Author: StarlightBear · 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 subse...
To determine the best option for configuring authentication and authorization in the Cloud Client Libraries for HipLocal’s application, let’s examine the requirements, including the principle of least privileged access, which is crucial to secure interactions between the application and Google Cloud.
Analysis of each option:
1. Option A: Create an API key. Use the API key to interact with Google Cloud.
- Pros: API keys are relatively easy to implement and can be used to authenticate requests to Google Cloud services.
- Cons: API keys are less secure than service accounts because they do not provide the same level of granularity in access control (i.e., least privilege). API keys are not tied to specific users or roles and can potentially be compromised if not handled properly. Additionally, API keys don't support the same advanced features as service accounts (such as role-based access control).
- Why rejected: API keys do not allow for least privileged access, which is a key requirement for this scenario.
2. Option B: Use the default compute service account to interact with Google Cloud.
- Pros: Using the default compute service account can work if you’re using Google Cloud's Compute Engine and need basic interactions.
- Cons: This service account generally has broad permissions, which is not ideal for least privileged access. By using the default service account, the application could inadvertently gain more permissions than necessary, violating the principle of least privilege.
- Why rejected: It doesn’t ensure the least privileged access, as the default service account often has broad permissions.
3. Option C: Create a service account for the application. Export and deploy the private key for the application. Use the service account to interact with Google Cloud.
- Pros: Service accounts provide a more secure way of managing authentication and authorization for applications. By creating a dedicated service account, you can assign it the sp...
Author: Michael · Last updated Jul 4, 2026
You are in the final stage of migrating an on-premises data center to Google Cloud. You are quickly approaching your deadline, and discover that a web API is running on a server slated for decommissioning. You need to recommend a solution to modernize this API while migrating to Google Cloud. The modernized web API must meet the following requirements:
* Autoscales during high traffic periods at the end of each month
* Written in Python 3.x
*...
To modernize and migrate your web API to Google Cloud, you need to consider factors like auto-scaling, ease of deployment, and minimizing operational overhead while ensuring cost-effectiveness. Let's break down each option and assess its pros and cons based on your specific requirements:
Option A: Modernize and deploy the code on App Engine flexible environment
- Pros:
- Auto-scaling: App Engine flexible environment provides automatic scaling based on demand, which is useful for handling high traffic periods at the end of the month.
- Python 3.x support: Fully supports Python, making it compatible with your current codebase.
- Managed Infrastructure: Google Cloud manages the underlying infrastructure, reducing operational overhead.
- Rapid Deployment: Developers can quickly deploy new versions of the API with minimal effort.
- Cons:
- Cost: Can be more expensive than other options like App Engine Standard or Compute Engine, especially when resources scale up under heavy traffic.
- Flexibility: While flexible, this environment is not as lightweight or cost-effective as App Engine Standard for some use cases.
Option B: Modernize and deploy the code on App Engine standard environment
- Pros:
- Auto-scaling: App Engine standard environment automatically scales up and down based on traffic, which is ideal for handling spikes at the end of the month.
- Cost-effective: More cost-efficient than the flexible environment because it uses Google-managed instances optimized for web apps.
- Easy deployment: Like the flexible environment, it allows rapid deployment with minimal effort from developers.
- Python 3.x support: Supports Python, and the environment is designed to easily run Python applications.
- Cons:
- Limited Customization: App Engine standard has stricter limitations (e.g., specific OS environments) compared to the flexible environment, so if your API has custom dependencies or configurations that are unsupported, this may not work.
- Scaling constraints: May not handle extremely large or very specific use cases for auto-scaling and performance tuning as well as the flexible environment.
Option C: Deploy the modernized application to an n1-standard-1 Compute Engine instance
- Pros:
- Full control: You have complete control over the virtual machine (VM), OS, and environment.
- Flexibility: You can run any software stack, so it's ideal for legacy applications or when customization is needed.
- Auto-scaling: Can be achieved using Google Cloud's managed instance groups, but requires configuration.
- Cons:
- Operational Overhead: You are responsible for managi...
Author: MysticJaguar44 · Last updated Jul 4, 2026
You are developing an application that consists of several microservices running in a Google Kubernetes Engine cluster. One microservice needs to connect to a third-party database running on-premises. You need to store credentials to the database an...
To determine the best solution for storing credentials securely while allowing rotation in a Google Kubernetes Engine (GKE) cluster, let's evaluate the options one by one:
A) Store the credentials in a sidecar container proxy, and use it to connect to the third-party database.
Analysis:
- Security: Storing credentials inside a sidecar container can introduce security risks. If the container is compromised, it may expose the credentials.
- Credential rotation: While the sidecar proxy could potentially manage credential rotation, this requires custom solutions and doesn't follow best practices for secret management and rotation.
- Use case: This option might be useful in scenarios where you need to perform additional logic, such as traffic manipulation, but it's generally not the best practice for handling sensitive credentials.
Conclusion: This option is not ideal for securely storing and rotating credentials.
B) Configure a service mesh to allow or restrict traffic from the Pods in your microservice to the database.
Analysis:
- Security: A service mesh such as Istio can secure and manage traffic between services (e.g., encrypting communication) but does not directly address credential management or rotation.
- Credential rotation: This option does not inherently solve the problem of securely storing and rotating database credentials. It focuses more on traffic control and security (e.g., authorization, encryption) but does not solve the core issue of how to handle credentials securely.
Conclusion: While a service mesh can provide network security benefits, it is not designed for managing credentials and does not address credential rotation.
C) Store the credentials in an encrypted volume mount, and associate a Persistent Volume Claim with the client Pod.
Analysis:
- Security: Storing credentials in a volume mount could be encrypted, bu...
Author: NightmareDragon2025 · Last updated Jul 4, 2026
You manage your company's ecommerce platform's payment system, which runs on Google Cloud. Your company must retain user logs for 1 year for internal auditing purposes and for 3 years to meet compliance requirements. You need to store new user logs on Google Cloud to minimize on-premises storage usage and ensu...
To determine the best approach for storing user logs on Google Cloud while meeting the requirements for internal auditing and compliance, we need to evaluate each option based on factors such as ease of use, retention compliance, and searchability. Let's break down each option:
A) Store the logs in a Cloud Storage bucket with bucket lock turned on.
Analysis:
- Retention compliance: Cloud Storage's bucket lock feature allows you to set an immutable retention policy, which ensures that the logs are retained for a defined period and cannot be deleted or altered before that time. This is suitable for compliance purposes.
- Searchability: While Cloud Storage is durable and scalable, it is not optimized for log searchability. Logs stored in Cloud Storage would need to be manually indexed or processed to make them searchable.
- Retention period: With bucket lock, you can set a retention period that would fulfill both the 1-year internal auditing and the 3-year compliance requirements.
- Effort minimization: This option minimizes manual effort in managing retention, but it requires additional work if you need to make the logs easily searchable.
Conclusion: This is a solid choice for retention but lacks built-in searchability. It is more appropriate when immutability and compliance are paramount, but additional steps would be needed to optimize searchability.
B) Store the logs in a Cloud Storage bucket with a 3-year retention period.
Analysis:
- Retention compliance: Setting a retention period of 3 years meets the compliance requirement, but it does not meet the internal auditing requirement for 1 year. This option does not allow for retention of logs for 1 year before transitioning to a 3-year retention period.
- Searchability: Similar to option A, Cloud Storage is not optimized for log searchability, so you would need additional infrastructure to make the logs easily searchable.
- Effort minimization: While easy to configure for a 3-year retention period, it does not satisfy the internal auditing re...
Author: Michael · Last updated Jul 4, 2026
Your company has a new security initiative that requires all data stored in Google Cloud to be encrypted by customer-managed encryption keys. You plan to use Cloud Key Management Service (KMS) to configure access to the keys. You need to follow th...
To ensure security and follow the "separation of duties" principle, along with Google-recommended best practices, we need to focus on how to securely manage customer-managed encryption keys (CMEK) in Cloud Key Management Service (KMS). The goal is to separate key management duties from other operations to reduce the risk of unauthorized access and provide strict control over who can manage the keys and who can use them.
Analysis of each option:
1. Option A: Provision Cloud KMS in its own project.
- Pros: Creating a separate project for Cloud KMS aligns with the separation of duties principle, as it isolates key management from the actual data usage. This reduces the risk of key exposure by isolating the key management operations from the project where the data is being used.
- Why selected: Google recommends separating key management duties from data usage duties for better security and compliance. This separation ensures that only specific users can access the keys without the ability to access the actual data being encrypted, enforcing proper role segmentation.
- Why not rejected: This is a best practice to implement separation of duties and complies with security standards.
2. Option B: Do not assign an owner to the Cloud KMS project.
- Pros: This may appear to limit the risk of unauthorized access to key management if no one has full access to the KMS project.
- Cons: However, this can create operational challenges. Someone will need to manage key management activities, such as creating keys, rotating keys, and configuring permissions. Assigning an owner role to the KMS project is necessary for proper administrative control over key management tasks.
- Why rejected: Not assigning an owner role would hinder key management tasks and make it difficult to follow security best practices for managing and rotating keys.
3. Option C: Provision Cloud KMS in the project where the keys are being used.
- Pros: This may simplify the setup and allow closer integration with the data stored in the project.
- Cons: This does not follow the separation of duties princip...
Author: GlowingTiger · Last updated Jul 4, 2026
You need to migrate a standalone Java application running in an on-premises Linux virtual machine (VM) to Google Cloud in a cost-effective manner. You decide not to take the lift-and-shift approach, and instead you plan to...
To modernize your standalone Java application by converting it to a container, the goal is to transform the current setup into a more scalable, manageable solution on Google Cloud, leveraging containers. Since you're not taking a lift-and-shift approach, you're aiming for a solution that modernizes the app rather than simply replicating the VM.
Analysis of each option:
1. Option A: Use Migrate for Anthos to migrate the VM to your Google Kubernetes Engine (GKE) cluster as a container.
- Pros: Migrate for Anthos is a tool designed to migrate virtual machines to containers and Kubernetes environments. It automates the process of containerizing an existing VM workload, which could be beneficial for migrating a standalone Java application to Google Kubernetes Engine (GKE).
- Cons: While this option works for migrating the VM directly to a GKE cluster as a container, it doesn’t align with your goal of modernizing the application by converting it into a container. Instead, it focuses more on migrating the VM directly to GKE. It still retains a VM-based architecture, which may not be as cost-effective or efficient as fully containerizing the application from scratch.
- Why rejected: This is more of a "lift-and-shift" solution, not modernizing the application to leverage the benefits of containerization fully.
2. Option B: Export the VM as a raw disk and import it as an image. Create a Compute Engine instance from the Imported image.
- Pros: This option allows you to migrate the existing VM to Google Cloud, preserving the environment as-is.
- Cons: This approach essentially replicates the VM in Google Cloud without modernizing the application. It doesn't align with your goal of transforming the application into a container, and it would not lead to the benefits of a containerized solution (e.g., scalability, portability, ease of management).
- Why rejected: This is another lift-and-shift approach, where the VM is moved to Compute Engine without converting it into a container. This is not in line with the plan to modernize the app.
3. Option C: Use Migrate for Compute Engine to migrate the VM t...
Author: Noah · Last updated Jul 4, 2026
Your organization has recently begun an initiative to replatform their legacy applications onto Google Kubernetes Engine. You need to decompose a monolithic application into microservices. Multiple instances have read and write access to a configuration file, which is stored on a shared file system. You want...
To decompose a monolithic application into microservices while minimizing the effort required and avoiding rewriting the application code, you need to focus on maintaining the current behavior of the application and ensuring that multiple instances can access the configuration file efficiently, especially during the transition to microservices.
Analysis of each option:
1. Option A: Create a new Cloud Storage bucket, and mount it via FUSE in the container.
- Pros: Cloud Storage is a highly scalable and durable option for storing files, and using FUSE allows you to mount it as a file system in a container.
- Cons: FUSE-based mounts can introduce complexity and performance concerns, particularly for workloads requiring high throughput or low-latency access. Additionally, using FUSE to mount Cloud Storage might not provide the most efficient file-sharing solution in a Kubernetes environment.
- Why rejected: While Cloud Storage is suitable for storing large amounts of data, using FUSE in a Kubernetes environment can be complex and less efficient than other methods tailored for Kubernetes-native storage solutions.
2. Option B: Create a new persistent disk, and mount the volume as a shared PersistentVolume.
- Pros: Persistent disks are a good option for reliable block storage in Google Cloud, and Kubernetes provides native support for mounting persistent volumes.
- Cons: Persistent disks are block storage, which typically isn't ideal for shared file systems that need to be concurrently accessed by multiple instances. Block storage volumes are not as suited for concurrent read/write access by multiple services without complex management of file locking, which could lead to issues in this scenario.
- Why rejected: Persistent disks are not well-suited for shared access across multiple instances. Using block storage with Kubernetes would require more effort to manage file synchronization and access control.
3. Option C: Create a new Filestore instance, and mount the volume as an NFS PersistentVolume.
- Pros: Filestore is a managed file storage solution that supports N...
Author: Zara1234 · Last updated Jul 4, 2026
Your development team has built several Cloud Functions using Java along with corresponding integration and service tests. You are building and deploying the functions and launching the tests using Cloud Build. Your Cloud Build job is ...
To address the issue of deployment failures after successful code validation, let's consider the given options one by one and determine which one would be the most appropriate based on the key factors of the problem:
Option A: Check the maximum number of Cloud Function instances
- Scenario: This option would be relevant if the issue involves scaling limits or resource exhaustion. For example, if there’s a high volume of traffic causing Cloud Functions to hit maximum concurrency or instance limits, this could result in failures.
- Why it's rejected: The problem you're encountering seems to be related to deployment failure immediately after code validation, not after the function is deployed and scaling issues occur. Therefore, checking the maximum number of instances isn't a likely cause of the problem in this case.
Option B: Verify that your Cloud Build trigger has the correct build parameters
- Scenario: This option would be relevant if there was an issue with how Cloud Build was configured. For example, misconfigured build triggers or incorrect build parameters could cause the deployment process to fail.
- Why it's rejected: The problem specifically states that the failure occurs after successful validation of the code. This suggests that the build parameters and validation are correct, and the issue lies somewhere in the deployment process rather than in the trigger configuration.
Option C: Retry the tests using the truncated exponential backoff polling strategy
- Scenario: This...
Author: FrostFalcon88 · Last updated Jul 4, 2026
You manage a microservices application on Google Kubernetes Engine (GKE) using Istio. You secure the communication channels between your microservices by implementing an Istio AuthorizationPolicy, a Kubernetes NetworkPolicy, and mTLS on your GKE cluster. You discover that HTTP requests be...
Let's break down the issue step by step and analyze the cause of the connection issue. We have several factors involved: Istio AuthorizationPolicy, Kubernetes NetworkPolicy, mTLS, and HTTP requests between Pods.
Option A: A Kubernetes NetworkPolicy resource is blocking HTTP traffic between the Pods
- Scenario: This would be a likely cause if the NetworkPolicy is incorrectly configured to block HTTP traffic between specific Pods or namespaces.
- Why it's rejected: The problem specifically mentions that some HTTP requests between Pods fail, while others succeed. If the NetworkPolicy were the root cause, it would block all traffic for those Pods, not selectively allow certain URLs to succeed and others to fail. Therefore, this is not the most likely explanation.
Option B: The Pod initiating the HTTP requests is attempting to connect to the target Pod via an incorrect TCP port
- Scenario: This issue would occur if there was a misconfiguration in the port specification or if the Pods are attempting to connect on a port that is not open or listening on the target Pod.
- Why it's rejected: The failure is specific to certain URLs, not all requests. If the port were incorrect, the failure would likely happen for all HTTP requests, not just specific URLs. Therefore, this isn't the cause of the issue.
Option C: The Authorization Policy of your cluster is blocking HTTP requests for specific paths within your application
- Scenario: Istio's AuthorizationPolicy can restrict access to speci...
Author: Charlotte · Last updated Jul 4, 2026
You recently migrated an on-premises monolithic application to a microservices application on Google Kubernetes Engine (GKE). The application has dependencies on backend services on-premises, including a CRM system and a MySQL database that contains personally identifiable information (PII). The backend services must remain on-premises to meet regulatory requirements.
You established a Cloud VPN connection between your on-premises data center and Google Cloud. You notice that some requests fro...
Let's analyze the problem and each possible solution in depth:
You are dealing with fluctuating bandwidth and latency issues in the Cloud VPN connection between your on-premises services and your microservices running on Google Kubernetes Engine (GKE). The key factor here is addressing the latency and ensuring that your microservices application doesn't crash due to these network issues.
Option A: Use Memorystore to cache frequently accessed PII data from the on-premises MySQL database
- Scenario: Memorystore is a managed in-memory store that can be used to cache frequently accessed data, which might help reduce the number of direct requests to the on-premises MySQL database.
- Why it's selected: If the MySQL database is being queried frequently for certain data (like PII), caching this data in Memorystore would reduce the number of network calls to the on-premises database, thus mitigating latency and preventing the application from being impacted by bandwidth fluctuations.
- Why it's rejected: While caching with Memorystore can reduce load on the database and improve performance, it doesn't directly address the underlying latency issues with the VPN connection itself. It helps with frequently accessed data, but if the latency issue is widespread or non-cached data is still needed, this solution alone might not resolve the broader problem.
Option B: Use Istio to create a service mesh that includes the microservices on GKE and the on-premises services
- Scenario: Istio's service mesh can help with observability, traffic management, and security for communication between microservices. It could potentially help in managing the communication between your microservices on GKE and the on-premises services.
- Why it's rejected: While Istio is excellent for service discovery, secure communication, and fine-grained traffic control, it does not directly solve issues related to fluctuating network bandwidth or latency. It might help you control and observe traffic better, but the root cause of the latency (fluctuating VPN bandwidth) would still exist. Therefore, this solution does not directly address the problem at hand.
...
Author: Max · Last updated Jul 4, 2026
Your company has deployed a new API to a Compute Engine instance. During testing, the API is not behaving as expected. You want to monitor the application over 12 hours to diagnose the problem withi...
Let's analyze the tools and their suitability for diagnosing the application problem over 12 hours without redeploying the application.
Option A: Cloud Trace
- Scenario: Cloud Trace helps you track the latency of HTTP requests as they pass through your system. It provides insights into request paths, where delays are occurring, and can help identify bottlenecks in the application. It’s useful for monitoring the latency of services and requests.
- Why it's rejected: Cloud Trace focuses on measuring request latencies and analyzing performance, but it doesn't provide deep visibility into the application’s internal behavior or code execution. If you're trying to diagnose issues with the logic of the application (such as incorrect behavior or errors), Cloud Trace wouldn't be sufficient, as it focuses more on request timings.
Option B: Cloud Monitoring
- Scenario: Cloud Monitoring provides an overview of the health and performance of resources, including metrics for Compute Engine instances and other cloud services. It tracks resource usage, such as CPU, memory, disk, and network usage.
- Why it's rejected: While Cloud Monitoring can give insights into system health and resource usage, it doesn't provide detailed insights into the behavior of the application itself (such as debugging or analyzing code execution). It's not suitable for pinpointing application-level issues without additional logging or debugging capabilities.
Option C: Cloud Debugger Logpoints
- Scenario: Cloud Debugger lets you set "logpoints" in your live application without redeploying it. These logpoints allow you to add log messages at specific lines of c...
Author: Matthew · Last updated Jul 4, 2026
You are designing an application that consists of several microservices. Each microservice has its own RESTful API and will be deployed as a separate Kubernetes Service. You want to ensure that the consumers of these APIs aren't impacted when there is a change to your API, and also ensure that third-party systems aren't interrupted wh...
Let's analyze the different options in terms of Google-recommended best practices for ensuring that consumers of the APIs aren't impacted by changes, and ensuring that third-party systems aren’t interrupted when new versions of the API are released:
Option A: Use an Ingress that uses the API's URL to route requests to the appropriate backend
- Scenario: Ingress is a Kubernetes resource that manages external access to the services within a cluster, typically HTTP. It can route traffic based on URL paths or hostnames, allowing you to manage access to different versions of your API based on the URL structure.
- Why it's selected: Using Ingress with URL-based routing (such as `/v1` for version 1 and `/v2` for version 2) is a best practice for handling API versioning in a way that allows consumers to request specific versions of the API. This approach ensures that changes in one version of the API do not impact consumers using an older version. Furthermore, it allows third-party systems to continue to use the specific version they need without being interrupted by new releases.
- Why other options are rejected:
- B (Service Discovery): While service discovery is crucial for connecting microservices within the cluster, it does not directly address the proble...
Author: Ava · Last updated Jul 4, 2026
Your team is building an application for a financial institution. The application's frontend runs on Compute Engine, and the data resides in Cloud SQL and one Cloud Storage bucket. The application will collect data containing PII, which will be stored...
To secure the PII data in the scenario described, it’s important to ensure that both the Cloud SQL database and the Cloud Storage bucket are protected and can only be accessed in a controlled manner by authorized components of the system. Here’s the reasoning for each option:
Option A:
1. Create firewall rules to allow only the frontend to communicate with the Cloud SQL database: This will restrict database access to only the frontend application, which is a good step for securing the database, but it does not address the security of the Cloud Storage bucket.
2. Using IAM, allow only the frontend service account to access the Cloud Storage bucket: IAM permissions can be used to restrict access to the Cloud Storage bucket, which is a good practice for ensuring that only authorized components can access the data stored there.
Limitations: While this option restricts access to both the Cloud SQL database and the Cloud Storage bucket, it doesn't provide an additional layer of security like private access or a service perimeter. This could be adequate in cases where your application only operates within a single network and does not need to separate data access more granularly.
Option B:
1. Create firewall rules to allow only the frontend to communicate with the Cloud SQL database: This is similar to Option A and ensures that only the frontend can communicate with the database.
2. Enable private access to allow the frontend to access the Cloud Storage bucket privately: By using private access, the frontend can access the Cloud Storage bucket without traversing the public internet, adding a layer of security.
Limitations: This option introduces private access, which enhances security over the public internet, but it doesn't fully leverage the more robust security measures available, such as service perimeters provided by VPC-SC. It also assumes the bucket and database are in the same project or VPC network, which may not be the best approach for highly sensitive data like PII.
Option C:
1. Configure a private IP address for Cloud SQL: Configuring Cloud SQL with a private IP ensures that database traffic does not travel over the public in...
Author: Kai · Last updated Jul 4, 2026
You are designing a chat room application that will host multiple rooms and retain the message history for each room. You have selected Firestore a...
When designing a chat room application with Firestore as the database, it's crucial to structure the data in a way that is both efficient for querying and scalable. Let's evaluate each option:
Option A:
- Create a collection for the rooms. For each room, create a document that lists the contents of the messages.
Evaluation:
- This structure is not ideal for Firestore, as storing a large number of messages in a single document can lead to performance issues. Firestore has a limit of 1 MB per document, and storing all the messages in one document would violate this limit if the chat room is active.
- It also limits querying efficiency since querying through a large array inside a document can be cumbersome, especially for operations like pagination or retrieving new messages.
Limitations: Storing all messages in one document becomes impractical for rooms with a lot of messages, potentially causing scalability issues.
Option B:
- Create a collection for the rooms. For each room, create a collection that contains a document for each message.
Evaluation:
- This structure is a more scalable and efficient approach. Each message is stored as its own document within a sub-collection inside the room document. This setup allows for efficient querying and pagination since messages are stored individually.
- Firestore scales well in this setup, as documents can be indexed, and it allows for efficient retrieval of individual messages or querying for new messages.
Benefits: This is the most flexible and scalable structure, allowing for efficient reads and writes, and enabling real-time updates for new messages in each room.
Option C:
- Create a collection for the rooms. For each room, create a document that contains a collection for documents, each of which contains a message.
Evaluation:
- This option is somewhat redundant. You are nesting collections and ...
Author: Sam · Last updated Jul 4, 2026
You are developing an application that will handle requests from end users. You need to secure a Cloud Function called by the application to allow authorized end users to authenticate to the function via the application while restricting access to unauthorized users. You will in...
When securing a Cloud Function and ensuring only authorized users can access it, while following Google-recommended best practices for authentication and authorization, we need to carefully consider the permissions and deployment process. Let's analyze each option:
Option A:
- Deploy from a source code repository and grant users the roles/cloudfunctions.viewer role.
Evaluation:
- The roles/cloudfunctions.viewer role allows users to view Cloud Functions, but does not provide any permissions to invoke or call the function. This role is suitable for users who only need to see the configuration or logs of the function, not to execute it. Therefore, it is not appropriate for allowing users to authenticate and call the function.
Limitations: Users with this role won't be able to invoke the Cloud Function, which is the required behavior in this case since the users need to call the function.
Option B:
- Deploy from a source code repository and grant users the roles/cloudfunctions.invoker role.
Evaluation:
- The roles/cloudfunctions.invoker role allows users to invoke Cloud Functions, which is exactly what we want in this case. By assigning this role, we can control who is authorized to trigger the Cloud Function.
- Google Sign-In will be used to authenticate end users, so we will also need to verify the identity of the users making requests (e.g., by validating their ID token). This role grants appropriate permissions to invoke the function, but we can integrate authentication mechanisms such as Google Sign-In to further secure the function.
Benefits: This is the correct role for allowing users to invoke the Cloud Function while restricting access to unauthorized users. After authenticating users with Google Sign-In, we can check their token and ensure they are authorized to call the fun...
Author: Sofia · Last updated Jul 4, 2026
You are running a web application on Google Kubernetes Engine that you inherited. You want to determine whether the application is using libraries with known vulnera...
To determine whether your web application on Google Kubernetes Engine (GKE) is using libraries with known vulnerabilities or is vulnerable to attacks such as Cross-Site Scripting (XSS), you need a tool that specifically helps assess security vulnerabilities in web applications.
Option A: Google Cloud Armor
- Google Cloud Armor provides protection against distributed denial-of-service (DDoS) attacks and web application attacks like SQL injection and XSS. However, Cloud Armor is primarily focused on defense and security policy enforcement for incoming traffic, not vulnerability scanning. It is useful for mitigating attacks but does not help with determining whether your application is vulnerable to known threats or specific vulnerabilities like those in libraries.
Limitations: While it protects against threats, it doesn't directly help identify vulnerabilities in your code or libraries.
Option B: Debugger
- The Debugger in Google Cloud allows you to inspect the state of your application, pause execution, and debug it in real time. However, it is not specifically designed for security assessments or vulnerability detection. It is a tool for debugging and troubleshooting, not for scanning code for vulnerabilities or detecting XSS risks.
Limitations: The debugger doesn't analyze code for vulnerabilities or provide security insights. It is not a suitable tool for identifying known vulnerabilities in libraries or assessing XSS risks.
Option C: Web Security Scanner
- Web Security Sc...
Author: Maya2022 · Last updated Jul 4, 2026
You are building a highly available and globally accessible application that will serve static content to users. You need to configure the storage and serving components. You want to minimize manage...
To build a highly available, globally accessible application that serves static content while minimizing management overhead, latency, and maximizing reliability, we need to carefully evaluate each option in terms of performance, scalability, and management. Here's a breakdown of the options:
Option A:
1. Create a managed instance group. Replicate the static content across the virtual machines (VMs).
2. Create an external HTTP(S) load balancer.
3. Enable Cloud CDN, and send traffic to the managed instance group.
Evaluation:
- A managed instance group (MIG) automatically scales VMs based on demand, which is good for ensuring availability. However, replicating static content across multiple VMs increases complexity and management overhead. You will need to manage the distribution of static files and synchronization between VMs.
- The external HTTP(S) load balancer combined with Cloud CDN helps to distribute traffic efficiently and reduce latency by caching content at edge locations.
Limitations: Although this option is highly scalable, the need to manage static content replication across VMs introduces unnecessary overhead for serving static content, which can be more efficiently handled by a storage solution like Cloud Storage.
Option B:
1. Create an unmanaged instance group. Replicate the static content across the VMs.
2. Create an external HTTP(S) load balancer.
3. Enable Cloud CDN, and send traffic to the unmanaged instance group.
Evaluation:
- An unmanaged instance group does not provide automatic scaling or health checks, so you would need to manually manage the VMs. This increases the management overhead and reduces reliability because the system does not handle failover or scaling automatically.
- Cloud CDN is used to cache content at the edge, which is good for latency reduction, but the unmanaged instance group adds unnecessary complexity.
Limitations: The lack of automatic scaling in an unmanaged instance group leads to higher operational complexity and potential issues with availability. Managing static content across VMs also increases overhead.
Option C:
1. Create a Standard storage class, regional Cloud Storage bucket. Put the static content in the bucket.
2. Reserve an exter...
Author: Chloe · 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 subse...
To answer the question of reducing latency for database interactions with the least amount of effort, we need to evaluate the options based on the current scenario, including the existing infrastructure, the goal of scaling globally, and the ability to maintain minimal operational effort.
Option Analysis:
A) Migrate the database to Bigtable and use it to serve all global user traffic.
- Bigtable is a NoSQL database ideal for workloads that require low latency, high throughput, and massive scalability. While it excels in large-scale, high-volume data environments (such as IoT or time-series data), it is not designed for transactional consistency or SQL-like queries. HipLocal uses MySQL, a relational database, which may rely on complex queries and transactions, making Bigtable unsuitable for their needs.
- Rejection Reason: Bigtable would require significant changes to the existing application logic and data model, making it unsuitable as a low-effort option.
B) Migrate the database to Cloud Spanner and use it to serve all global user traffic.
- Cloud Spanner is a fully managed, scalable relational database with strong consistency across regions, which makes it an ideal solution for global-scale applications. It allows for seamless scaling and low-latency read and write operations across multiple regions, which is exactly what HipLocal needs.
- Benefits: Cloud Spanner offers horizontal scaling, global distribution, and built-in replication across regions. It also supports SQL queries, which aligns with the current MySQL environment, and would reduce the complexity of switching to a non-relational database.
- Rejection Reason: While Cloud Spanner is a good option for reducing latency and scaling globally, the migration effort might still require significant changes to the current database schema and application code. ...
Author: SolarFalcon11 · 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 subse...
Option Analysis:
A) Cloud Profiler
- Cloud Profiler is a performance analysis tool that helps identify the performance bottlenecks in an application. It provides insights into CPU, memory, and thread usage to optimize the efficiency of applications.
- Rejection Reason: While Cloud Profiler helps optimize performance, it doesn't directly address the business requirement of monitoring and defining service level indicators (SLIs) and service level objectives (SLOs). It is more about performance profiling rather than tracking service health or metrics that align with SLIs/SLOs.
B) Cloud Monitoring
- Cloud Monitoring is a comprehensive monitoring solution that allows users to gather, view, and analyze metrics, logs, and events for various Google Cloud services and applications. It helps you define custom service level indicators (SLIs) and service level objectives (SLOs), making it the ideal solution for tracking and managing application performance at scale. It allows businesses to establish clear uptime and performance thresholds to monitor and alert the teams.
- Benefits: Cloud Monitoring is directly aligned with HipLocal’s business requirements for tracking and monitoring SLIs and SLOs, which are essential for defining and ensuring service performance. It can be used to monitor application health, analyze performance, and respond to any service-related issues based on pre-defined thresholds.
- Selected Reason: This product is the best fit because it directly helps define SLIs and SLOs, meeting the core business requirements for monitoring application pe...
Author: Evelyn · 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 subse...
Option Analysis:
A) Create a service account and download its key. Use the key to authenticate to Cloud Key Management Service (KMS) to obtain the database credentials.
- Cloud Key Management Service (KMS) is used to manage cryptographic keys for securing data. However, KMS is typically used for encrypting and decrypting data, not specifically for managing database credentials. Storing the database credentials as plain text and using KMS to "obtain" them is not a good practice, as it still involves storing the credentials insecurely.
- Rejection Reason: This approach does not directly address securing the credentials in a proper way. The database credentials would still be stored in an insecure manner before they are passed to KMS for decryption.
B) Create a service account and download its key. Use the key to authenticate to Cloud Key Management Service (KMS) to obtain a key used to decrypt the database credentials.
- While this approach involves using KMS for decryption, it still requires storing the database credentials insecurely somewhere before decryption. This still doesn’t fully mitigate the risk of credentials being stolen while stored in plain text.
- Rejection Reason: Similar to Option A, this solution does not fully address the issue of securely storing database credentials. It primarily focuses on encryption/decryption, not on properly securing sensitive data at rest.
C) Create a service account and grant it the roles/iam.serviceAccountUser role. Impersonate as this account and authenticate using the Cloud SQL Proxy.
- The Cloud SQL Proxy allows applications to securely connect to Cloud SQL databases by using the IAM credentials of a service account. While it offers secure connectivi...
Author: ThunderBear · 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 subse...
Option Analysis:
A) Create new Cloud SQL instances in Europe and North America for testing and deployment. Provide developers with local MySQL instances to conduct testing on the application changes.
- Cloud SQL is a managed database service in Google Cloud that supports MySQL, PostgreSQL, and SQL Server. Creating new Cloud SQL instances in different regions (Europe and North America) would allow HipLocal to scale their application to new regions, addressing latency and availability concerns.
- Providing developers with local MySQL instances for testing changes could help resolve the issue of schema changes by allowing isolated environments for developers to conduct tests without impacting the live environment.
- Rejection Reason: The need to replicate schemas frequently and provide developers with local instances might still create unnecessary complexity and could result in the application not being easily scalable or adaptable to rapidly changing requirements across regions.
B) Migrate data to Bigtable. Instruct the development teams to use the Cloud SDK to emulate a local Bigtable development environment.
- Bigtable is a NoSQL, horizontally scalable database suitable for applications that require low latency and high throughput, particularly for large datasets. However, Bigtable is not ideal for applications that rely on relational data with frequent schema changes.
- Emulating a local Bigtable environment for developers could introduce overhead and complexity, as Bigtable operates differently from relational databases like MySQL. Bigtable may not handle complex queries or frequent schema modifications as efficiently as a relational database.
- Rejection Reason: Bigtable would not fit the need of HipLocal, which is currently using a MySQL database that likely requires relational capabilities and frequent schema changes. The option is more suitable for specific use cases like time-series data or analytics, not for relational database operations with frequent schema changes.
C) Move from Cloud SQL to MySQL hosted on Compute Engine. Replicate hosts across regions in the Americas and Europe. Provide developers with local MySQL instances to conduct testing on the application changes.
- Moving from Cloud SQL to MySQL on ...
Author: Zain · Last updated Jul 4, 2026
You are writing from a Go application to a Cloud Spanner database. You want to optimize your application's performance using ...
Option Analysis:
A) Write to Cloud Spanner using Cloud Client Libraries
- Cloud Client Libraries are officially supported libraries that provide a high-level, idiomatic interface for interacting with Google Cloud services, including Cloud Spanner. These libraries are optimized for performance and scalability, and they adhere to Google’s recommended best practices.
- The Cloud Client Libraries are specifically designed to work seamlessly with Cloud Spanner, offering built-in features like connection pooling, retries, and consistent error handling, which can significantly enhance performance and reliability in Go applications.
- Selected Reason: This option is recommended because it is the most direct and optimal way to interact with Cloud Spanner. It offers built-in optimizations, better error handling, and ease of use, making it the best choice for performance.
B) Write to Cloud Spanner using Google API Client Libraries
- Google API Client Libraries provide lower-level access to Google Cloud APIs. While they can be used to interact with Cloud Spanner, they are generally not as optimized as Cloud Client Libraries. API Client Libraries typically require more manual configuration and management, such as handling retries and connection pooling.
- Rejection Reason: While this is a valid option, it is not as optimized for use with Cloud Spanner as Cloud Client Libraries. The API Client Libraries are more suited for lower-level, fine-grained access to Google Cloud services, which may not be necessary or ideal for most common use cases involving Cloud Spanner.
C) W...
Author: FrostFalcon88 · Last updated Jul 4, 2026
You have an application deployed in Google Kubernetes Engine (GKE). You need to update the application to make authorized requests to Google Cloud managed services. You want this to be a one-time setup, and you need to follow security best practices of auto-rotating your security keys and storing them in an...
To determine the best option for updating the application deployed in Google Kubernetes Engine (GKE) to make authorized requests to Google Cloud managed services, let's evaluate each option based on security best practices, ease of implementation, and automatic key rotation.
Option A: Assign the Google Cloud service account to your GKE Pod using Workload Identity.
- Explanation: Workload Identity allows Kubernetes workloads (Pods) to impersonate Google Cloud service accounts without needing to manage and store long-lived credentials (like keys). The service account is associated with the pod, and it provides identity federation between GKE and Google Cloud IAM. The credentials are automatically handled by Google Cloud and rotate securely. This setup aligns with Google Cloud best practices by eliminating the need for service account keys while ensuring proper access control and key rotation.
- Why Selected: This option is the most secure and scalable. Workload Identity uses IAM roles and provides seamless integration with Google Cloud services. It automates key rotation, reduces the risk of key exposure, and avoids storing sensitive credentials in Kubernetes secrets or embedding them in code.
- Rejection of Others:
- B (Kubernetes Secret): While storing the service account key in a Kubernetes Secret...
Author: Liam · Last updated Jul 4, 2026
You are planning to deploy hundreds of microservices in your Google Kubernetes Engine (GKE) cluster. How should you secure communicatio...
To secure communication between hundreds of microservices in Google Kubernetes Engine (GKE), we need to consider scalability, security features, and ease of management. Here's a breakdown of the options and why one stands out over the others:
Option A: Use global HTTP(S) Load Balancing with managed SSL certificates to protect your services.
- Explanation: Global HTTP(S) Load Balancing with managed SSL certificates is primarily used for securing external traffic (from clients to services) via SSL/TLS encryption. While it provides end-to-end encryption for incoming traffic, it does not address internal communication between microservices within the GKE cluster.
- Why Rejected: This option only handles external traffic, not internal service-to-service communication. In a microservices environment, it's crucial to secure internal communication as well, and this solution does not address that need.
Option B: Deploy open-source Istio in your GKE cluster, and enable mTLS in your Service Mesh.
- Explanation: Istio is a powerful open-source service mesh that can manage microservice communication, provide observability, and enforce security policies. Enabling mutual TLS (mTLS) ensures that communication between microservices is encrypted, authenticated, and authorized. Istio is widely used for securing internal traffic in Kubernetes environments.
- Why Rejected: While Istio is a very powerful solution, it can be complex to manage and configure, especially when deploying it in large-scale environments. The open-source version may lack certain enterprise features, such as centralized support, enhanced scalability, and advanced capabilities.
Option C: Install cert-manager on GKE to automatically renew SSL certificates.
- Explanation: Cert-manager is a Kubernetes-native tool for managing SSL certificates and can automate certificate issuance and renewal. While cert-manager is useful for managing certificates, it doesn't specifically address securing the internal communication between services. It would need to be used in conjunction wit...
Author: Liam · Last updated Jul 4, 2026
You are developing an application that will store and access sensitive unstructured data objects in a Cloud Storage bucket. To comply with regulatory requirements, you need to ensure that all data objects are available for at least 7 years after their initial creation. Objects created more than 3 years ago are accessed very infrequent...
To meet the requirements of storing and accessing sensitive unstructured data in Cloud Storage while ensuring compliance with the 7-year retention period and optimizing storage costs, let’s evaluate each option based on key factors like cost optimization, ease of management, and regulatory compliance.
Option A: Set a retention policy on the bucket with a period of 7 years.
- Explanation: A retention policy ensures that objects cannot be deleted or overwritten before the specified retention period ends. Setting a 7-year retention policy ensures compliance with the regulatory requirement that objects must be available for at least 7 years.
- Why Selected: This option guarantees that the data cannot be deleted before the required retention period (7 years). It aligns well with regulatory compliance and data integrity requirements. It doesn't directly address cost optimization, but it's necessary for ensuring that the data is available for the specified period.
- Why Rejected: This option alone doesn't handle the cost optimization aspect, which will be addressed by moving the data to a lower-cost storage class after 3 years.
Option B: Use IAM Conditions to provide access to objects 7 years after the object creation date.
- Explanation: IAM Conditions control access to resources based on specific attributes. However, IAM conditions are designed to manage permissions and control access rather than enforcing retention or cost optimization strategies.
- Why Rejected: While IAM conditions can control access, they don’t address the key requirement to ensure the data remains accessible for at least 7 years or optimize the storage cost. This option doesn’t deal with the need to reduce storage costs or enforce retention for long periods.
Option C: Enable Object Versioning to prevent objects from being accidentally deleted for 7 years after object creation.
- Explanation: Object versioning allows you to keep multiple versions of an object in a bucket, protecting against accidental deletion or overwriting. This ensures that previous versions of an object can be retrieved even if the latest version is deleted.
- Why Rejected: While versioning ensures data recovery, it doesn't provide a direct solution for retention compliance or cost optimization. Retention policies are better suited for ensuring compliance, and versioning alone would not address the need for cost-effective storage (as it...
