Google Practice Questions, Discussions & Exam Topics by our Authors
The new version of your containerized application has been tested and is ready to be deployed to production on Google Kubernetes Engine (GKE). You could not fully load-test the new version in your pre-production environment, and you need to ensure that the applic...
To determine the best approach for deploying a new version of your containerized application on Google Kubernetes Engine (GKE) while ensuring that there are no performance issues, let’s evaluate the options based on key factors such as automation, traffic management, performance monitoring, and rollback capability.
Option A: Deploy the application through a continuous delivery pipeline by using canary deployments. Use Cloud Monitoring to look for performance issues, and ramp up traffic as supported by the metrics.
- Pros:
- Canary deployments are a great way to test new versions of an application with a small percentage of traffic before fully rolling it out. This limits the impact of any potential performance problems.
- Cloud Monitoring provides visibility into the performance of your application, allowing you to monitor the health of the canary deployment and gradually ramp up traffic based on metrics.
- The process is automated, and traffic ramp-up can be controlled based on performance data.
- Cons:
- Canary deployments require the setup of an automated pipeline that gradually increases traffic to the new version, which can be more complex to configure but provides a safer deployment strategy.
- Conclusion: This option is ideal when you want to minimize risk by exposing a small portion of users to the new version first. It's the safest approach when you haven't fully load-tested the application.
Option B: Deploy the application through a continuous delivery pipeline by using blue/green deployments. Migrate traffic to the new version of the application and use Cloud Monitoring to look for performance issues.
- Pros:
- Blue/green deployments involve running two separate environments (one for the old version and one for the new version) and switching traffic from blue (old version) to green (new version).
- This approach provides a clear way to manage traffic between versions and is straightforward for automated rollbacks.
- Cons:
- While blue/green deployments are effective in managing risk, they can be more resource-intensive because you need to run two separate environments simultaneously.
- It doesn’t provide the gradual traffic ramp-up that canary deployments offer, meaning that any performance issues would affect all users immediately once the traffic is switched over.
- Conclusion: This is a good option for a more straightforward deployment but doesn’t offer the gradual rollout and performance monitoring that canary deployments do, which would be preferable in your situation where load testing wasn’t fully done.
Option C: Deploy the application by using kubectl and use Config Connector to slowly ramp up traffic between versions. Use Cloud Monitoring to look for...
Author: Alexander · Last updated Jul 10, 2026
You are managing an application that runs in Compute Engine. The application uses a custom HTTP server to expose an API that is accessed by other applications through an internal TCP/UDP load balancer. A firewall rule allows access to the API port from 0.0.0.0/0. You need to configur...
To address this requirement, the goal is to log each IP address that accesses the API exposed by your application using the fewest number of steps. Let's analyze the options in detail:
Option A: Enable Packet Mirroring on the VPC
- Explanation: Packet Mirroring captures network packets at the VPC level and sends them to a destination for analysis. While this could capture the traffic details, it is more focused on network traffic inspection and troubleshooting, not specifically logging IP addresses that access the API.
- Why rejected: This is more complex and resource-intensive than necessary. It's not primarily designed to log traffic access for an API; it's more suited for security and performance monitoring purposes.
- Use case: Useful for debugging and traffic inspection in highly controlled scenarios.
Option B: Install the Ops Agent on the Compute Engine instances
- Explanation: The Ops Agent collects logs and metrics from Google Cloud resources, but it doesn't automatically log network traffic details such as which IP addresses accessed an API. It’s primarily used for collecting system-level logs and metrics.
- Why rejected: While this provides a way to collect application logs and metrics, it doesn't directly address the need to log the IP addresses accessing the API.
- Use case: Best suited for collecting logs related to the system's state, application performance, and infrastructure metrics, not for capturing IP-level access logs.
Option C: Enable logging on the firewall rule
- Explanation: This option allows logging...
Author: Ahmed97 · Last updated Jul 10, 2026
Your company runs an ecommerce website built with JVM-based applications and microservice architecture in Google Kubernetes Engine (GKE). The application load increases during the day and decreases during the night. Your operations team has configured the application to run enough Pods to hand...
To automate scaling in a Google Kubernetes Engine (GKE) environment based on varying load, you need to consider both pod and node scaling. Let’s break down the options and analyze which is best suited to meet the requirement of scaling efficiently while maintaining optimal performance.
Option A: Configure the Vertical Pod Autoscaler, but keep the node pool size static.
- Explanation: The Vertical Pod Autoscaler (VPA) automatically adjusts the CPU and memory requests/limits of pods based on their usage, but it does not scale the number of pods. However, keeping the node pool size static means there is no automatic scaling of nodes in the cluster, which could lead to either underutilization (if fewer pods are needed) or resource exhaustion (if more pods are needed) when traffic spikes.
- Why rejected: This option will optimize pod resource allocation (CPU/memory) but will not handle scaling the number of pods or nodes to meet changing loads. Since your traffic changes throughout the day, this would leave you vulnerable to resource shortages or inefficiency.
- Use case: This might be useful if resource usage optimization per pod is your primary concern but does not meet the scaling requirement for both pods and nodes.
Option B: Configure the Vertical Pod Autoscaler, and enable the cluster autoscaler.
- Explanation: The VPA will adjust the resource requests/limits for individual pods, while the cluster autoscaler will automatically scale the node pool up or down based on the number of unschedulable pods (when there aren’t enough resources to run new pods). While this setup could help ensure that pods have the right resource allocation and the cluster adjusts its node pool size to fit the pods, it doesn't scale the number of pods themselves. For dynamic workloads where pod count needs to change, this is not sufficient.
- Why rejected: While the node pool scaling and pod resource adjustments are handled, this option doesn’t automatically scale the number of pods based on demand, which is crucial for handling varying loads in an ecommerce environment.
- Use case: Ideal if only resource allocation for individual pods needs to be optimized, but not suitable when the number of pods also needs to change dynamic...
Author: Mia · Last updated Jul 10, 2026
Your organization wants to increase the availability target of an application from 99.9% to 99.99% for an investment of $2,000. The application's current revenue is $1,000,000. You need to determine whether the inc...
To determine whether the increase in availability is worth the $2,000 investment, we need to calculate the value of the improved availability and compare it with the cost. Here's a breakdown of the factors and options:
Key Factors:
1. Current revenue: $1,000,000
2. Current availability: 99.9%
3. Target availability: 99.99%
4. Investment required: $2,000
Understanding Availability Impact:
- Availability levels: Moving from 99.9% to 99.99% reduces downtime significantly. The impact of downtime on revenue needs to be considered:
- 99.9% availability results in approximately 8.77 hours of downtime per year.
- 99.99% availability results in approximately 52.6 minutes of downtime per year.
The goal is to assess how much downtime reduction corresponds to an increase in revenue and how much that increase in revenue is worth.
Calculating the Value of Improved Availability:
- Downtime at 99.9% availability: 8.77 hours of downtime
- Downtime at 99.99% availability: 52.6 minutes of downtime
- Difference in downtime: 8.77 hours - 52.6 minutes ≈ 8.23 hours saved by improving availability.
Now, let’s calculate how much downtime costs in terms of revenue:
- Revenue per hour: ( frac{1,000,000}{365 imes 24} ) = $114.16 per hour.
- Total downtime savings per year: 8.23 hours × $114.16 = approximately $939.8.
Given the downtime ...
Author: Lucas · Last updated Jul 10, 2026
A third-party application needs to have a service account key to work properly. When you try to export the key from your cloud project, you receive an error: 'The organization policy constraint iam.disableServiceAccounKeyCreation is enforced.' You need to mak...
To solve this issue while adhering to Google’s security best practices, let's break down the scenario and evaluate the options:
Key Facts:
- The error you're encountering is related to the iam.disableServiceAccountKeyCreation policy, which is an organization-level policy preventing the creation of service account keys.
- You need to make a third-party application work, which requires the use of a service account key.
- Google recommends avoiding service account keys whenever possible, as they can be risky if leaked or compromised. Instead, service-to-service authentication using IAM roles and Service Accounts (without keys) is preferred.
Option Analysis:
Option A: Enable the default service account key, and download the key.
- Explanation: This option would allow you to download a key for the default service account, but the root problem is the organization policy (iam.disableServiceAccountKeyCreation). Even if you enable the default key, the organization policy will still prevent the creation of new keys.
- Why rejected: This does not solve the underlying issue of the organization policy blocking key creation. It’s a temporary workaround at best and doesn’t align with security best practices.
- Use case: This is not recommended as a long-term solution because it still violates the principle of minimizing the use of service account keys.
Option B: Remove the iam.disableServiceAccountKeyCreation policy at the organization level, and create a key.
- Explanation: This option would remove the policy entirely at the organization level, allowing the creation of service account keys. However, it would reduce the overall security posture for the organization, as it removes the restriction for all projects in the organization.
- Why rejected: This violates the principle of least privilege and the security best practices enforced by Google. Disabling the policy at the organization level would allow service account keys to be created freely, which could lead to potential security risks, such as accidental leaks or unauthorized access.
- Use case: This would be effective in situations wher...
Author: Madison · Last updated Jul 10, 2026
Your team is writing a postmortem after an incident on your external facing application. Your team wants to improve the postmortem policy to include triggers that indicate whether an incident requires a postmortem. Based on Site Reliabili...
To define effective triggers for when a postmortem should be created, it's essential to align with Site Reliability Engineering (SRE) best practices. The goal is to ensure that incidents impacting users, data, or critical services are properly analyzed to prevent recurrence and improve system reliability.
Key Factors in SRE:
- Postmortems are usually generated when incidents significantly impact users or system reliability.
- Learning from failures: Postmortems are used as a tool for learning from incidents, improving system design, and refining operations.
- Critical impacts: Typically, incidents that cause service degradation, data loss, or customer-impacting outages trigger a postmortem.
Option Analysis:
Option A: An external stakeholder asks for a postmortem.
- Explanation: While requests from external stakeholders (such as customers or partners) might indicate concern, the need for a postmortem should be based on the severity of the incident, not just external pressure. A postmortem should be based on impact, not on a request alone.
- Why rejected: It’s not the most reliable trigger since external stakeholders' requests don’t necessarily reflect the incident's impact on the system or its users.
- Use case: Can be considered in some contexts, but it’s not a best practice to rely solely on external requests to trigger postmortems.
Option B: Data is lost due to an incident.
- Explanation: Data loss is a critical incident. Losing data typically requires a postmortem, as it has a significant impact on users, customers, and possibly compliance requirements. This fits well with SRE practices since it signals a severe disruption in service.
- Why selected: Data loss directly impacts user trust, service availability, and legal compliance. It's a key indicator for requiring a postmortem.
- Use case: Data loss in a production environment demands a thorough investigation to understand how the failure occurred, identify root causes, and improve processes.
Option C: An internal stakeholder requests a postmortem.
- Explanation: Internal requests might reflect concerns within the team, but a postmortem should primarily be triggered by t...
Author: Benjamin · Last updated Jul 10, 2026
You are implementing a CI/CD pipeline for your application in your company's multi-cloud environment. Your application is deployed by using custom Compute Engine images and the equivalent in other cloud providers. You need to implement a solution that will enable you to build an...
To implement a CI/CD pipeline in a multi-cloud environment with custom Compute Engine images and the equivalent in other cloud providers, we need to consider the key factors like flexibility, ease of adaptation to multiple clouds, ability to build custom images, and the deployment process.
Let's analyze the options:
A) Cloud Build with Packer
- Strengths:
- Packer is specifically designed for creating custom machine images for multiple environments, including GCP, AWS, Azure, and others. It is widely used to automate the creation of images that can be used in multi-cloud setups.
- Cloud Build integrates well with Packer to automate the building of images. This setup would allow you to create custom images on different cloud platforms, making it a perfect choice for a multi-cloud environment.
- It is highly flexible and adaptable as Packer templates can be easily modified to handle future cloud changes.
- Weaknesses:
- It does not inherently handle the deployment process. You would need a separate tool for deployment, which can introduce complexity if not integrated properly.
- Requires additional setup for deployment and orchestration.
B) Cloud Build with Google Cloud Deploy
- Strengths:
- Google Cloud Deploy is designed for deploying applications on Google Cloud using built-in deployment pipelines. It works well for deployments within the GCP ecosystem.
- Cloud Build can work with Google Cloud Deploy to automate deployments once the build pipeline is complete.
- Weaknesses:
- Limited to GCP: This option is more suited for a single-cloud GCP environment, and does not offer the flexibility required for multi-cloud environments. It does not directly support building custom images for other cloud providers.
- This option may not be the best fit for your multi-cloud needs, as it is not adaptable for other cloud environments.
C) Google Kubernetes Engine with Google Cloud Deploy
- Strengths:
- ...
Author: Aarav2020 · Last updated Jul 10, 2026
Your application's performance in Google Cloud has degraded since the last release. You suspect that downstream dependencies might be causing some requests to take longer to complete. You need to in...
To address the issue of degraded performance in your application, especially with the suspicion that downstream dependencies might be causing delays, it's important to choose a tool that helps trace request performance and pinpoint where bottlenecks are occurring. Let’s evaluate the options:
A) Configure Error Reporting in your application
- Strengths:
- Error Reporting automatically collects and groups errors from your application, providing visibility into issues like exceptions and crashes.
- Weaknesses:
- Error Reporting focuses mainly on errors and exceptions, not on performance or latency issues. While it helps you identify crashes, it won't provide detailed information on what is causing requests to take longer, especially if the issue lies in downstream dependencies.
- It’s not ideal for investigating performance degradation that may not necessarily involve errors but rather slower response times.
- Use case: If your app is encountering frequent errors (e.g., exceptions or crashes), this tool is useful. However, for investigating performance degradation due to latency, it’s not the right tool.
B) Configure Google Cloud Managed Service for Prometheus in your application
- Strengths:
- Prometheus is widely used for monitoring and alerting, and Google Cloud Managed Service for Prometheus provides a fully managed version of it. It can collect time-series metrics from your application, such as CPU, memory usage, or custom metrics.
- Weaknesses:
- Prometheus is primarily focused on collecting metrics over time and doesn’t give in-depth information about the latency of individual requests or tracing downstream dependencies. While Prometheus can give insights into system resource consumption and performance at a higher level, it doesn’t offer direct insights into which specific requests or services are causing the delays.
- Use case: Useful for overall system health monitoring and alerting based on custom metrics, but it’s not designed for tracing specific slow requests or pinpointing dependencies causing performance issues.
C) Configure Cloud Profiler in your application
- Strengths:
- Cloud Profiler...
Author: Ishaan · Last updated Jul 10, 2026
You are creating a CI/CD pipeline in Cloud Build to build an application container image. The application code is stored in GitHub. Your company requires that production image builds are only run against the main branch and that the change control team approves all pu...
To meet the requirements of automating the image build process, ensuring that production image builds are only triggered from the main branch, and enforcing approval from the change control team for all pushes to the main branch, we need to choose the right combination of options that fulfill both the automation and approval requirements.
A) Create a trigger on the Cloud Build job. Set the repository event setting to ‘Pull request’.
- Strengths:
- Pull request triggers can ensure that builds only happen when code is reviewed via pull requests, which is useful in an approval workflow.
- Weaknesses:
- This option won’t trigger builds on pushes to the main branch directly. It is useful for building code from pull requests but doesn't meet the requirement for triggering builds only on pushes to the main branch for approved code.
- It doesn't enforce that the code on the main branch is approved or prevent direct pushes without approval.
- Use case: Suitable if you want to build from pull requests before merging to the main branch but doesn’t directly help with restricting builds to the main branch.
B) Add the OWNERS file to the Included files filter on the trigger.
- Strengths:
- An OWNERS file helps manage permissions for specific files in the repository, providing fine-grained control over who can approve changes.
- Weaknesses:
- While the OWNERS file is useful for controlling access to certain parts of the repository, it does not directly address the need to restrict the build to the main branch or enforce approval workflow in Cloud Build.
- Use case: This could be helpful in managing file-level access but is not directly related to controlling the build process for the main branch.
C) Create a trigger on the Cloud Build job. Set the repository event setting to ‘Push to a branch’.
- Strengths:
- This push-to-branch trigger ensures that builds are triggered when a push is made to a specific branch, such as the main branch.
- This helps automate the build process for changes pushed directly to the main branch.
- Weaknesses:
- Without additional approval mechanisms, a push directly to the main branch could bypass the necessary approvals, which is against the requirement.
- Use case: Good for triggering buil...
Author: MysticJaguar44 · Last updated Jul 10, 2026
You built a serverless application by using Cloud Run and deployed the application to your production environment. You want to identify the resource utiliz...
To monitor the resource utilization of a serverless application deployed on Cloud Run for cost optimization, you need to focus on monitoring CPU and memory usage, as these are directly tied to resource consumption and associated costs. Let’s evaluate the options based on this:
A) Use Cloud Trace with distributed tracing to monitor the resource utilization of the application
- Strengths:
- Cloud Trace is ideal for monitoring latency and tracing the flow of requests in your application across services.
- Weaknesses:
- Cloud Trace is not designed to track resource utilization like CPU or memory. It focuses on request tracing, helping you identify performance bottlenecks and delays in request handling.
- Distributed tracing does not provide direct insights into resource consumption or cost optimization, which are needed in this case.
- Use case: Best for tracking performance issues related to requests and latencies, but not useful for resource utilization.
B) Use Cloud Profiler with Ops Agent to monitor the CPU and memory utilization of the application
- Strengths:
- Cloud Profiler provides detailed insights into CPU and memory usage, helping you identify hotspots and inefficiencies in your application’s code. This can help with optimizing resource usage.
- Ops Agent helps to collect telemetry data and can be used to monitor resource usage at a granular level.
- Weaknesses:
- Cloud Profiler is more focused on profiling code execution rather than tracking container-level resource utilization over time. While useful for identifying inefficiencies in the code, it does not directly provide monitoring of container-level CPU and memory usage for cost optimization purposes.
- It’s more of a tool for developers to optimize code rather than a tool for monitoring resources at the application infrastructure level.
- Use case: Excellent for debugging and optimizing code performance, but not the best tool for monitoring overall resource utilization in a serverle...
Author: Aarav · Last updated Jul 10, 2026
Your company is using HTTPS requests to trigger a public Cloud Run-hosted service accessible at the https://booking-engine-abcdef.a.run.app URL. You need to give developers the ability to test the latest ...
To allow developers to test the latest revisions of your Cloud Run-hosted service before exposing it to customers, you need a solution that enables staging or pre-production access to the service while preventing public access. Let's evaluate the options based on this requirement.
A) Run the `gcloud run deploy booking-engine --no-traffic --tag dev` command. Use the https://dev--booking-engine-abcdef.a.run.app URL for testing.
- Strengths:
- The `--no-traffic` flag deploys the service without sending any traffic to it immediately. This is useful for testing new revisions without affecting the live service.
- The `--tag dev` flag allows you to label this revision as a development or test version.
- This creates a separate URL (e.g., `https://dev--booking-engine-abcdef.a.run.app`) for testing that the developers can use without exposing it to customers.
- Weaknesses:
- The URL provided is publicly accessible since the service is still hosted on Cloud Run. However, this is not a significant issue if the service is purely for developer testing.
- Use case: Perfect for allowing developers to test the latest revision in an isolated environment, while still being able to access it via a distinct URL.
B) Run the `gcloud run services update-traffic booking-engine --to-revisions LATEST=1` command. Use the https://booking-engine-abcdef.a.run.app URL for testing.
- Strengths:
- The `gcloud run services update-traffic` command allows you to manage the traffic split between revisions of your service. You can point a portion of the traffic to the latest revision without deploying the revision to production.
- Weaknesses:
- Using `https://booking-engine-abcdef.a.run.app` exposes the service to the public, which is not what you want for private testing before exposing it to customers.
- This option is useful for a staged rollout of new revisions in production, but not ideal for private developer testing before public exposure.
- Use case: Useful for gradual traffic shifts and can be used when you want to gradually roll out updates to the entire user base but not for private testing.
C) Pass the `curl –H “Authorization:Bearer $(gcloud auth print-identity-token)”` auth token. Use the...
Author: Noah · Last updated Jul 10, 2026
You are configuring connectivity across Google Kubernetes Engine (GKE) clusters in different VPCs. You notice that the nodes in Cluster A are unable to access the nodes in Cluster B. You suspect that the workload access issue is due to the network configuration. You need to troubleshoot the issue but do not have...
To troubleshoot network connectivity issues between two GKE clusters in different VPCs, let's analyze the options:
A) Install a toolbox container on the node in Cluster A to confirm that the routes to Cluster B are configured appropriately.
- Reasoning: While installing a toolbox container on a node in Cluster A can give you access to network diagnostic tools, you need execute access to workloads and nodes, which you don't have in this scenario. This option assumes you can access the nodes, but you’re restricted from doing so.
- Rejected: This option requires access to the nodes directly, which you do not have.
B) Use Network Connectivity Center to perform a Connectivity Test from Cluster A to Cluster B.
- Reasoning: The Network Connectivity Center in Google Cloud allows you to analyze and troubleshoot connectivity between Google Cloud services. It provides an easy-to-use interface for running tests across VPCs, making it a good option to check connectivity without needing direct access to nodes or workloads.
- Selected Option: This option doesn't require execute access to workloads and nodes and directly tests connectivity between the two clusters at the network layer. It’s the most appropriate choice for your scenario, as it allows you to verify routes and connectivity issues across VPCs and services without needing access to individual clusters or nodes.
C) Use a debug container to run the traceroute command from Cluste...
Author: Rohan · Last updated Jul 10, 2026
You manage an application that runs in Google Kubernetes Engine (GKE) and uses the blue/green deployment methodology. Extracts of the Kubernetes manifests are shown below:
The Deployment app-green was updated to use the new version of the application. During post-deployment monitoring, you notice that the majority of user requests are failing. You did not observe th...
To mitigate the incident impact on users and help the developers troubleshoot the issue, let's evaluate the options:
A) Update the Deployment app-blue to use the new version of the application.
- Reasoning: In a blue/green deployment, the green environment represents the new version, while the blue environment represents the old (stable) version. If the majority of requests are failing after the new version (green) was deployed, updating the blue environment to the new version would cause both environments to run the same (potentially faulty) version. This could worsen the issue since it eliminates the fallback to the stable version.
- Rejected: This option would remove the fallback to the old (blue) version, worsening the issue rather than mitigating it.
B) Update the Deployment app-green to use the previous version of the application.
- Reasoning: Since the green deployment is where the new (potentially problematic) version of the application was rolled out, rolling it back to the previous version (from blue) would restore the stable version. This would quickly mitigate the impact on users by ensuring that only the stable version (blue) is serving traffic, while allowing the developers time to troubleshoot the issues in the green environment.
- Selected Option: This option is the most appropriate. It restores the stable version to serve traffic, mitigating the issue on user requests and providing the time needed for developers to address the issues in the new version (green).
C) Change the selector on the Service app-svc to app: my-app.
- Reasoning: The selecto...
Author: Emma · Last updated Jul 10, 2026
You are running a web application deployed to a Compute Engine managed instance group. Ops Agent is installed on all instances. You recently noticed suspicious activity from a specific IP address. You need to configure Cloud Monitoring to view t...
To configure Cloud Monitoring to view the number of requests from a specific IP address with minimal operational overhead, let’s evaluate each option:
A) Configure the Ops Agent with a logging receiver. Create a logs-based metric.
- Reasoning: The Ops Agent is already installed on all instances, and it supports configuring a logging receiver to collect logs. By creating a logs-based metric, you can capture logs (such as web server access logs) and define a metric that counts the number of requests from the specific suspicious IP address. This approach leverages Cloud Logging and Cloud Monitoring to efficiently capture the data without needing to modify the application.
- Selected Option: This is the most efficient and minimal-overhead solution. It does not require any changes to the application or extra custom scripts. It uses existing infrastructure (Ops Agent, logs, and metrics) to gather and report the information.
B) Create a script to scrape the web server log. Export the IP address request metrics to the Cloud Monitoring API.
- Reasoning: While this option could work, it involves additional complexity, such as writing and maintaining a script, parsing web server logs, and exporting metrics to the Cloud Monitoring API. This introduces unnecessary operational overhead compared to simply using Cloud Logging and logs-based metrics, which is already integrated with Cloud Monitoring.
- Rejected: This option introduces extra work (scripting and log parsing) and complexity, which can be avoided using the m...
Author: Zain · Last updated Jul 10, 2026
Your organization is using Helm to package containerized applications. Your applications reference both public and private charts. Your security team flagged that using a public Helm repository as a dependency is a risk. You want to ...
Let's evaluate each option for managing both public and private Helm charts while ensuring security, access control, and integration with VPC Service Controls:
A) Store public and private charts in OCI format by using Artifact Registry.
- Reasoning: Artifact Registry supports storing Helm charts in OCI (Open Container Initiative) format, and it integrates with Google Cloud's native access control (IAM) and VPC Service Controls. By using Artifact Registry, you can store both public and private charts securely, and access them through Helm with full control over permissions, including access to charts from both within and outside your VPC.
- Selected Option: This option is ideal as it ensures secure storage of both public and private charts, integrates with Google Cloud's IAM and VPC Service Controls, and reduces the risk posed by using external public repositories. It also allows managing charts uniformly with appropriate security features.
B) Store public and private charts by using GitHub Enterprise with Google Workspace as the identity provider.
- Reasoning: Using GitHub Enterprise to store Helm charts is feasible, and integrating with Google Workspace for identity management can help secure access. However, this solution does not fully integrate with the native Google Cloud security features such as VPC Service Controls or IAM, and it would require additional steps to manage the connection between GitHub and Helm.
- Rejected: While this option leverages identity management with Google Workspace, it doesn’t leverage Google Cloud's native security mechanisms like VPC Service Controls or IAM for access control. Additionally, it doesn’t provide the same level of control and integration as Artifact Registry.
C) Store public and private charts by using Git repository. Configure Cloud Build to synchronize contents of the repository into a Cloud Storage bucket. Connect Helm to the bucket by using https://[...
Author: Ava · Last updated Jul 10, 2026
You use Terraform to manage an application deployed to a Google Cloud environment. The application runs on instances deployed by a managed instance group. The Terraform code is deployed by using a CI/CD pipeline. When you change the machine type on the instance template used by the managed instance group, the pipeline fails at the terraform apply stage with the following ...
Let's analyze each option to determine the best approach for updating the instance template and minimizing disruption to the application and the number of pipeline runs:
A) Delete the managed instance group, and recreate it after updating the instance template.
- Reasoning: Deleting and recreating the managed instance group would cause a significant disruption to the application, as it would terminate all the instances in the group and create new ones. This approach would lead to downtime for the application, which is undesirable in a production environment.
- Rejected: This approach creates unnecessary downtime and is not optimal for minimizing disruption to the application.
B) Add a new instance template, update the managed instance group to use the new instance template, and delete the old instance template.
- Reasoning: This option involves creating a new instance template, which would result in minimal disruption because you can update the managed instance group to use the new template without affecting the running instances. The new template can be used for future instances, and the old template can be removed once all instances are updated. This method ensures that the application continues running without downtime.
- Selected Option: This approach minimizes disruption to the application by allowing the new template to be rolled out gradually (as instances are updated), and avoids a complete deletion and recreation of the managed instance group.
C) Remove the managed instance group from the Terraform state file, update the instance template, and reimport the managed instance group.
- Reasoning: Removing the managed instance group from the Terraform state fi...
Author: Matthew · Last updated Jul 10, 2026
Your company operates in a highly regulated domain that requires you to store all organization logs for seven years. You want to minimize logging infrastructure complexity by using managed services. You need to avoid any futu...
Let's evaluate each option based on the following key factors:
- Simplicity: The goal is to minimize infrastructure complexity and use managed services.
- Retention: The company needs to retain logs for seven years.
- Security: The solution should avoid any future loss of log capture or stored logs due to misconfiguration or human error.
- Scalability: The solution should scale effectively across the organization.
- Consistency: Logs should be reliably stored across all projects without the risk of missing data.
Option A: Use Cloud Logging to configure an aggregated sink at the organization level to export all logs into a BigQuery dataset.
- Pros:
- Centralized logging: Logs are stored in a BigQuery dataset, and an aggregated sink at the organization level ensures centralized control.
- Scalable and managed: BigQuery is a fully managed service with robust querying and retention capabilities.
- Easy querying and analysis: Logs in BigQuery are easier to query, and you can perform detailed analysis.
- Cons:
- Retention management: BigQuery does not have native retention management that is as simple as configuring a retention policy in Cloud Storage. You would need to implement additional management to ensure that logs are retained for seven years.
- Potential human error: Without a native retention policy, there could be potential for accidental deletion of logs or mismanagement.
Option B: Use Cloud Logging to configure an aggregated sink at the organization level to export all logs into Cloud Storage with a seven-year retention policy and Bucket Lock.
- Pros:
- Easy retention management: Cloud Storage allows for setting up a retention policy with Bucket Lock to ensure data is preserved for seven years and cannot be deleted or modified.
- Simplicity: Cloud Storage is a simpler and more straightforward option for log storage with a defined retention period, ensuring logs are protected from accidental deletion.
- Cons:
- Querying limitations: Logs in Cloud Storage are not as easily queryable as in BigQuery. While Cloud Storage is great for archiving, analyzing logs could be more cumbersome.
- Limited analy...
Author: Sara · Last updated Jul 10, 2026
You are building the CI/CD pipeline for an application deployed to Google Kubernetes Engine (GKE). The application is deployed by using a Kubernetes Deployment, Service, and Ingress. The application team asked you to deploy the application by us...
Let's analyze each option in detail with the goal of implementing a blue/green deployment methodology and enabling rollback actions when necessary.
Option A: Run the kubectl rollout undo command.
- Pros:
- Direct rollback: The `kubectl rollout undo` command allows you to roll back to a previous revision of a deployment, effectively reverting changes made during the most recent rollout.
- Automated rollback: This method automatically restores the deployment to a previous working state, minimizing the chance for human error during the rollback process.
- Version control: Kubernetes keeps track of deployment revisions, so you can easily undo changes without worrying about manually managing versions.
- Cons:
- Requires a valid deployment revision history: If there is no previous revision available (e.g., if the deployment has not yet been successfully rolled out before), this command won't work as intended.
- Not specific to blue/green: While this option works for a standard deployment, blue/green deployments might require more specific handling of traffic switching between two environments.
Option B: Delete the new container image, and delete the running Pods.
- Pros:
- Immediate effect: Deleting the running pods ensures the newly deployed version stops running immediately.
- Cons:
- No rollback: Simply deleting the pods doesn't revert to the old version of the application. The deployment is still technically in a broken state, as Kubernetes will try to spin up new pods based on the current deployment configuration, which could still be pointing to the wrong container image.
- Manual intervention: This is a very manual approach that doesn't take full advantage of Kubernetes' managed deployment features, making it prone to errors or longer downtime.
Option C: Update the Kubernetes Service to point to the previous Kubernetes Deployment.
- Pros:
- Blue/green methodology: This approach directly ties into the blue/green deployment strategy. In a blue/green deployment, you have two...
Author: Max · Last updated Jul 10, 2026
You are building and running client applications in Cloud Run and Cloud Functions. Your client requires that all logs must be available for one year so that the client can import the logs into ...
Let's evaluate each option carefully based on the following key factors:
- Minimal code changes: The solution should minimize changes to existing code.
- Retention for one year: Logs must be retained for a full year, making it important to consider how to store and manage logs with that retention period in mind.
- Ease of access for the client: The solution should ensure the client can easily retrieve the logs without complicating the process.
- Infrastructure complexity: The solution should avoid creating unnecessary infrastructure or requiring complex configurations.
Option A: Update all images in Cloud Run and all functions in Cloud Functions to send logs to both Cloud Logging and the client's logging service. Ensure that all the ports required to send logs are open in the VPC firewall.
- Pros:
- Logs are directly sent to both Cloud Logging and the client's logging service, ensuring that the client has immediate access.
- Client doesn’t need to access another service or mechanism for logs.
- Cons:
- Code changes required: You need to update all Cloud Run and Cloud Function applications to send logs to an external service. This adds code changes, and as the client's request is to minimize changes, this is not optimal.
- Security complexity: Opening the necessary ports in the VPC firewall for log forwarding introduces additional security considerations and potential misconfigurations.
- No retention management: There's no automatic handling of log retention for one year, so this solution doesn't address the retention requirement explicitly.
Option B: Create a Pub/Sub topic, subscription, and logging sink. Configure the logging sink to send all logs into the topic. Give your client access to the topic to retrieve the logs.
- Pros:
- Logs are sent to a Pub/Sub topic, allowing the client to access them via subscription.
- Pub/Sub provides a scalable and managed service for sending logs in real-time.
- Cons:
- Client complexity: The client must manage Pub/Sub subscriptions and retrieve logs in a specific format. This adds complexity on the client's side and doesn’t directly give them access to logs in a simple manner.
- Retention management: Pub/Sub doesn’t provide native log retention for a year. Additional setup or storage solutions are required for the logs to be kept for a full year.
- Minimal code change: It ...
Author: Elijah · Last updated Jul 10, 2026
You are building and running client applications in Cloud Run and Cloud Functions. Your client requires that all logs must be available for one year so that the client can import the logs into ...
The key requirement in this scenario is ensuring that logs from Cloud Run and Cloud Functions are available for one year so that the client can import them into their logging service. You must also minimize the amount of code change required, making the solution as simple and automated as possible.
Let’s evaluate the options based on these requirements:
Option A: Deploy Falco or Twistlock on GKE to monitor for vulnerabilities on your running Pods.
- Falco and Twistlock are security tools used to monitor for vulnerabilities and intrusions on Kubernetes environments, specifically for GKE (Google Kubernetes Engine).
- While this provides security monitoring, it does not address the requirement for log retention or the need to store logs for one year.
- Conclusion: This option does not meet the core requirement, as it’s focused on security rather than log management.
Option B: Configure Identity and Access Management (IAM) policies to create a least-privilege model on your GKE clusters.
- IAM policies help manage access control to resources but are unrelated to log retention.
- The requirement is to ensure logs are available for a year, and IAM policies do not address the issue of log storage.
- Conclusion: While IAM policies are important for securing resources, they do not directly help with the log retention or logging service integration required here.
Option C: Use Binary Authorization to attest images during your CI/CD pipeline.
- Binary Authorization is a security feature that ensures only trusted container images are deployed in your GKE or Cloud Run environments.
- Although this adds security to the CI/CD pipeline, it is not related to the log retention requirement or storing logs for one year.
- Conclusion: This is a security-focused solution, and it does not help with the core requirement related to log retention.
Option D: Enable Container Analysis in Artifact Re...
Author: CrystalWolfX · Last updated Jul 10, 2026
You have an application that runs in Google Kubernetes Engine (GKE). The application consists of several microservices that are deployed to GKE by using Deployments and Services. One of the microservices is experiencing an issue where a Pod returns 403 errors after the Pod has been running for more than five hours. Your development team is working on a solution, but the issue will not be resolved for a month....
Let's evaluate the given options based on the following key factors:
- Google-recommended practices: Solutions that align with Kubernetes best practices for ensuring reliable and continuous operations.
- Efficiency: The goal is to minimize complexity and follow a straightforward approach.
- Minimal steps: You want the fewest steps to ensure continued operations while the issue is being resolved.
- Issue at hand: The issue occurs after a Pod has been running for five hours, resulting in 403 errors.
Option A: Create a cron job to terminate any Pods that have been running for more than five hours.
- Pros:
- Automates the termination of Pods that have been running for more than five hours, potentially avoiding the 403 errors.
- Can help ensure that Pods are replaced regularly to prevent issues caused by long-running Pods.
- Cons:
- Not a direct fix: This is more of a workaround than a true solution. Terminating the Pods will not address the root cause of the 403 errors.
- Complexity: Creating and managing a cron job to monitor and terminate Pods adds additional overhead.
- Unnecessary termination: It is not efficient to terminate Pods based on runtime without addressing the underlying issue. This could lead to unnecessary restarts of Pods, impacting the application’s stability and performance.
Option B: Add a HTTP liveness probe to the microservice's deployment.
- Pros:
- Google-recommended practice: Liveness probes are a Kubernetes best practice for ensuring that unhealthy Pods are restarted automatically.
- Fixes the root cause: If the Pod becomes unhealthy (e.g., due to the 403 errors), the liveness probe will automatically restart the Pod, ensuring continued operation.
- Efficient: Liveness probes are built-in, minimal configuration, and directly address the health of the Pod.
- Cons:
- May not address the root cause of 403 errors: The issue could be related to something external to the Pod (e.g., authorization issues). If the...
Author: SolarFalcon11 · Last updated Jul 10, 2026
You want to share a Cloud Monitoring custom dashboard with a partner team. What should you do?
When sharing a custom dashboard in Cloud Monitoring with a partner team, we need to consider the most efficient and accessible option that aligns with the technical needs of the partner team. Here's an analysis of each option:
A) Provide the partner team with the dashboard URL to enable the partner team to create a copy of the dashboard.
- Pros: This is the most straightforward method. The partner team can easily access the dashboard through the URL and create a copy of the dashboard, preserving all configurations and metrics. This option is also real-time and dynamic, meaning any updates to the original dashboard are reflected in the partner's copy.
- Cons: This may require the partner team to have the right permissions to access the dashboard.
- Scenario: Best used when the partner team has the required permissions in Cloud Monitoring and needs a direct replica of the dashboard with real-time updates.
B) Export the metrics to BigQuery. Use Looker Studio to create a dashboard, and share the dashboard with the partner team.
- Pros: This method allows for a custom, more flexible visualization of the metrics, especially if the partner team needs specific, advanced reports or custom visualizations beyond what Cloud Monitoring offers. Looker Studio integrates well with BigQuery, providing powerful reporting capabilities.
- Cons: This requires additional steps and configuration (exporting data to BigQuery, setting up Looker Studio). It's also more complex and may not reflect the real-time changes that are available in Cloud Monitoring directly.
- Scenario: Best used if the partner team requires advanced reporting features or if the data needs to be used in a separate too...
Author: Maya2022 · Last updated Jul 10, 2026
You are building an application that runs on Cloud Run. The application needs to access a third-party API by using an API key. You need to determine a secure way to store and use the API key ...
To securely store and use an API key in a Cloud Run application, we need to consider best practices for managing sensitive data. Let's analyze the options one by one:
A) Save the API key in Secret Manager as a secret. Reference the secret as an environment variable in the Cloud Run application.
- Reasoning: Secret Manager is designed to securely store sensitive information like API keys, passwords, or certificates. You can store the API key in Secret Manager and reference it as an environment variable, ensuring that the key is not hard-coded in your application code. The environment variable is securely injected at runtime and can be accessed by the application code.
- Pros: It provides centralized secret management, automatic auditing, and access control. It's integrated well with Cloud Run, making it easy to manage.
- Cons: None significant in the context of Cloud Run.
- Use case: Best option for securely storing API keys in Cloud Run, ensuring ease of integration and security.
B) Save the API key in Secret Manager as a secret key. Mount the secret key under the /sys/api_key directory, and decrypt the key in the Cloud Run application.
- Reasoning: This option involves mounting a secret from Secret Manager as a file in the application’s file system and manually decrypting it. Cloud Run does support mounting secrets as files, but manually decrypting them adds complexity and risks mistakes.
- Pros: It uses Secret Manager, which is secure.
- Cons: Manual decryption is error-prone and unnecessary. It complicates the setup and doesn’t offer any significant benefits over using environment variables.
- Use case: ...
Author: Amira99 · Last updated Jul 10, 2026
You are currently planning how to display Cloud Monitoring metrics for your organization's Google Cloud projects. Your organization has three folders and six projects:
You want to configure Cloud Monitoring dashboards to only display metrics from the projects within one folder. You need to ensure that the da...
First Scenario: Storing and Using API Key in Cloud Run Application
The application requires a secure method to store and use an API key for accessing a third-party API. Google recommends secure practices to avoid storing sensitive data in plain text.
A) Save the API key in Secret Manager as a secret. Reference the secret as an environment variable in the Cloud Run application.
- Pros: Secret Manager is designed for securely storing and managing sensitive information, like API keys. Cloud Run can easily reference these secrets as environment variables. This method ensures that the API key is not exposed in the application code and is retrieved securely during runtime. This is the most straightforward and secure option in line with Google-recommended practices.
- Cons: None significant, as it follows best practices for secret management in Google Cloud.
- Scenario: Best used for secure and straightforward management of secrets in Cloud Run, especially when you need automatic and easy secret retrieval.
B) Save the API key in Secret Manager as a secret key. Mount the secret key under the /sys/api_key directory, and decrypt the key in the Cloud Run application.
- Pros: Secret Manager can securely store the API key, and mounting it can ensure secure access.
- Cons: Mounting the secret as a file and manually decrypting it adds unnecessary complexity. Cloud Run’s native environment variable integration with Secret Manager provides a more straightforward and secure solution. This option introduces complexity and potential risks in handling decryption manually.
- Scenario: Could be used if there's a very specific need to access secrets as files rather than environment variables, but it's less efficient and secure.
C) Save the API key in Cloud Key Management Service (Cloud KMS) as a key. Reference the key as an environment variable in the Cloud Run application.
- Pros: Cloud KMS is used for encryption, which is essential for managing cryptographic keys, but it is not meant for storing sensitive information directly like API keys.
- Cons: Cloud KMS is intended for managing encryption keys and not for storing API keys directly. This adds complexity and does not align with the intended use case.
- Scenario: Best for encryption/decryption tasks but not for storing API keys. Not recommended for this scenario.
D) Encrypt the API key by using Cloud Key Management Service (Cloud KMS), and pass the key to Cloud Run as an environment variable. Decrypt and use the key in Cloud Run.
- Pros: Cloud KMS can securely encrypt data, and the key can be passed to Cloud Run for decryption at runtime.
- Cons: While encryption is secure, this option adds unnecessary steps. Cloud Secret Manager is a simpler and more appropriate solution for securely storing and accessing API keys directly without needing encryption and decryption steps. It also introduces more complexity and potential points of failure.
- Scenario: This could be used if the API key needed to be encrypted manually before use, but it's more complex than necessary for this use case.
Conclus...
Author: Aria · Last updated Jul 10, 2026
Your company's security team needs to have read-only access to Data Access audit logs in the _Required bucket. You want to provide your security team with the necessary permissions following th...
When providing read-only access to the Data Access audit logs in the _Required bucket for your security team, the goal is to adhere to the principle of least privilege and follow Google-recommended practices to ensure secure and efficient access management.
A) Assign the roles/logging.viewer role to each member of the security team.
- Pros: The `roles/logging.viewer` role provides read-only access to the logs, which is what the security team requires.
- Cons: Assigning roles to each individual member manually can lead to administrative overhead, especially if team members change frequently or if there are many members. It’s also less scalable than using a group for access management.
- Scenario: Suitable for small teams where managing individual roles isn’t a problem, but less efficient for larger or dynamic teams.
B) Assign the roles/logging.viewer role to a group with all the security team members.
- Pros: This option is more efficient than assigning roles individually because you can assign the role to a group, making it easier to manage access as team members come and go. The `roles/logging.viewer` role provides the necessary read-only access to audit logs.
- Cons: The group must be properly managed, and the access should only be granted to relevant members. However, the benefits of using a group outweigh the cons in this case.
- Scenario: Best used when managing access for a team that may change over time or for larger teams, as it simplifies role assignment and management.
C) Assign the roles/logging.privateLogViewer role to each member of the security team.
- Pros: The `roles/logging.privateLogViewer...
Author: Siddharth · Last updated Jul 10, 2026
Your team is building a service that performs compute-heavy processing on batches of data. The data is processed faster based on the speed and number of CPUs on the machine. These batches of data vary in size and may arrive at any time from multiple third-party sources. You need to ensure that third parties are able to up...
In this scenario, you need a solution that allows secure, efficient, and scalable data processing while minimizing costs and ensuring third parties can upload data securely. The key requirements are:
- Secure uploads: Third parties must be able to upload data securely.
- Scalability: Data processing should scale based on the size and arrival rate of data.
- Cost efficiency: You want to minimize costs while processing data quickly.
Let's break down each option and see how it aligns with the requirements.
A) Provide a secure file transfer protocol (SFTP) server on a Compute Engine instance so that third parties can upload batches of data, and provide appropriate credentials to the server. Create a Cloud Function with a `google.storage.object.finalize` Cloud Storage trigger. Write code so that the function can scale up a Compute Engine autoscaling managed instance group using an image pre-loaded with the data processing software that terminates the instances when processing completes.
- Pros: This option provides secure file transfer through SFTP, which could be a familiar method for third parties to upload data. Using Cloud Functions and autoscaling Compute Engine instances ensures scalability for processing. Autoscaling helps handle varying data sizes and load.
- Cons: Using Compute Engine instances for processing, even with autoscaling, could be more expensive compared to serverless or containerized solutions. Managing an SFTP server adds complexity and maintenance overhead. Also, triggering an autoscaling group and managing the processing software can increase the operational overhead.
- Scenario: Suitable for use cases where SFTP is necessary, and Compute Engine instances are preferred, but may incur higher costs and maintenance effort compared to other options.
B) Provide a Cloud Storage bucket so that third parties can upload batches of data, and provide appropriate Identity and Access Management (IAM) access to the bucket. Use a standard Google Kubernetes Engine (GKE) cluster and maintain two services: one that processes the batches of data, and one that monitors Cloud Storage for new batches of data. Stop the processing service when there are no batches of data to process.
- Pros: Cloud Storage provides secure and easy data uploading. GKE can scale well and handle various batch sizes efficiently. Kubernetes provides a flexible environment to manage workloads.
- Cons: GKE requires more setup and management, including the need to maintain services and monitor the batch upload process. It can also be more costly in terms of infrastructure management and operational overhead compared to more serverless solutions like Cloud Functions.
- Scenario: Suitable for teams already familiar with Kubernetes and requiring a flexible, scalable infrastructure, but may be more complex and costly for this specific use case.
C) Provide a Cloud Storage bucket so that third parties can upload batches of data, and provide appropriat...
Author: Ella · Last updated Jul 10, 2026
You are reviewing your deployment pipeline in Google Cloud Deploy. You must reduce toil in the pipeline, and you want to minimize the amount of time it takes to...
To reduce toil in the deployment pipeline and minimize deployment time, you should focus on automating repetitive steps, reducing manual intervention, and improving efficiency. Let’s review each option in detail:
A) Create a trigger to notify the required team to complete the next step when manual intervention is required.
- Reasoning: This option can help with reducing manual oversight. Instead of waiting for the team to notice that intervention is required, you automatically notify them to complete the necessary step. This reduces delays but still leaves manual steps in place.
- Reject: This doesn't directly reduce toil or deployment time. It still requires manual intervention, and notifying the team doesn't remove the need for them to act.
B) Divide the automation steps into smaller tasks.
- Reasoning: Breaking automation into smaller, manageable tasks helps in troubleshooting, enhances reusability, and can also allow parallel execution. However, if the tasks are too small, it might introduce overhead, so finding the right balance is crucial.
- Reject: While this could make the pipeline easier to manage, it doesn't directly reduce the time of end-to-end deployment unless optimized for parallelism. It also introduces the possibility of bottlenecks when steps need to be run sequentially.
C) Use a script to automate the creation of the deployment pipeline in Google Cloud Deploy.
- Reasoni...
Author: Rahul · Last updated Jul 10, 2026
You work for a global organization and are running a monolithic application on Compute Engine. You need to select the machine type for the application to use that optimizes CPU utilization by using the fewest number of steps. You want to use historical system metrics to iden...
To optimize CPU utilization while ensuring you are using the fewest number of steps in a Google-recommended way, let’s examine each option:
A) Use the Recommender API and apply the suggested recommendations.
- Reasoning: Google Cloud's Recommender API provides automated recommendations for optimizing resource utilization based on historical data. The Recommender analyzes historical metrics such as CPU usage, memory, and disk IO to suggest the best machine type for your workloads. This approach minimizes guesswork and follows Google’s best practices for resource allocation.
- Select: This option directly leverages the cloud’s capabilities to provide a recommendation based on actual usage, reducing manual effort and ensuring you’re following Google’s guidelines for optimization.
- Why it’s selected: This approach uses automated insights based on historical system metrics, which directly addresses the need to optimize CPU utilization with the fewest steps.
B) Create an Agent Policy to automatically install Ops Agent in all VMs.
- Reasoning: The Ops Agent collects metrics and logs for your VMs, but its role is more about monitoring and logging rather than recommending machine types. While it can provide valuable data, this option doesn’t directly help with selecting the optimal machine type...
Author: Aarav · Last updated Jul 10, 2026
You deployed an application into a large Standard Google Kubernetes Engine (GKE) cluster. The application is stateless and multiple pods run at the same time. Your application receives inconsistent traffic. You need to ensure that the user experience remains consiste...
To ensure that your application handles inconsistent traffic effectively while optimizing resource usage in a large Standard Google Kubernetes Engine (GKE) cluster, it’s crucial to scale the application dynamically based on load. Let's evaluate each option:
A) Configure a cron job to scale the deployment on a schedule
- Reasoning: A cron job in Kubernetes is typically used for running scheduled tasks at fixed intervals (like backups or periodic jobs). While it can scale the deployment, it does so on a fixed schedule, which is not well-suited for handling inconsistent, dynamic traffic patterns.
- Reject: This approach doesn’t react to traffic fluctuations dynamically, which is a key requirement for applications with inconsistent traffic.
B) Configure a Horizontal Pod Autoscaler
- Reasoning: A Horizontal Pod Autoscaler (HPA) adjusts the number of pods based on observed CPU utilization, memory usage, or custom metrics. Since your application is stateless and traffic is inconsistent, the HPA allows the number of pods to scale up when traffic spikes and scale down when traffic decreases. This ensures that the application responds to changing traffic volumes and optimizes resource usage efficiently.
- Select: This option is ideal for scaling based on traffic variability, which directly addresses your requirement for consistent user experience and op...
Author: Arjun · Last updated Jul 10, 2026
You need to deploy a new service to production. The service needs to automatically scale using a managed instance group and should be deployed across multiple regions. The service needs a large number...
To deploy a new service to production that automatically scales using a managed instance group (MIG) across multiple regions and requires a large number of resources for each instance, you need to consider factors such as resource availability, capacity planning, and scaling. Let’s evaluate the options:
A) Monitor results of Cloud Trace to determine the optimal sizing
- Reasoning: Cloud Trace helps with monitoring and analyzing the latency of your application by tracking request traces. While it provides insights into performance bottlenecks and latency issues, it doesn’t directly help with capacity planning or selecting the optimal machine type for scaling instances.
- Reject: This option focuses on tracing and performance optimization rather than helping with the upfront capacity planning or ensuring sufficient resources for your large-scale instances. It's not the best tool for pre-deployment resource planning.
B) Use the n2-highcpu-96 machine type in the configuration of the managed instance group
- Reasoning: The n2-highcpu-96 machine type offers 96 vCPUs and is optimized for workloads that need high CPU but may not require significant memory. This machine type could be beneficial for resource-heavy services, especially if your application requires significant CPU capacity. However, this only covers the machine type configuration and does not address the need for scaling across multiple regions or ensuring capacity availability.
- Reject: While selecting an appropriate machine type is important, it is not the complete solution to ensuring optimal capacity, especially when you need to scale across multiple regions. You also need to consider resource availabil...
Author: Abigail · Last updated Jul 10, 2026
You are analyzing Java applications in production. All applications have Cloud Profiler and Cloud Trace installed and configured by default. You want to determine which...
To determine which Java applications in production need performance tuning, you should focus on identifying inefficiencies in resource usage and application behavior, particularly in terms of latency, CPU, and memory utilization. Let’s analyze the options:
A) Examine the wall-clock time and the CPU time of the application. If the difference is substantial, increase the CPU resource allocation.
- Reasoning: Wall-clock time represents the total elapsed time, while CPU time represents the amount of time the CPU is actively processing instructions for the application. If the difference between these two is substantial, it suggests that the application might be waiting on I/O operations, such as network or disk access, and increasing CPU allocation wouldn't necessarily improve performance.
- Reject: Simply increasing CPU resources when the application is spending time waiting on I/O (not CPU-bound) would not lead to better performance. This doesn’t address the root cause of the issue.
B) Examine the wall-clock time and the CPU time of the application. If the difference is substantial, increase the memory resource allocation.
- Reasoning: A substantial difference between wall-clock time and CPU time could indicate that the application is memory-bound, experiencing frequent garbage collection, or encountering memory bottlenecks. However, increasing memory allocation might help only if the application is indeed constrained by available memory, but it doesn't directly address the underlying cause, especially if I/O operations are the problem.
- Reject: Increasing memory might help with performance if the issue is related to memory consumption, but it won't resolve latency issues or optimize CPU-bound workloads. This is not always the best step for performance tuning without further investigation.
C) Examine the wall-clock time and the CPU time of the application. If the difference is substantial, increase the local disk storage allocation.
- Reasoning: Like the other options that suggest resource allocation changes, increasing disk storage would be beneficial only...
Author: Henry · Last updated Jul 10, 2026
Your organization stores all application logs from multiple Google Cloud projects in a central Cloud Logging project. Your security team wants to enforce a rule that each project team can only view their respective logs and only the operations team can view all the logs. ...
To solve this issue, we need a solution that satisfies two main objectives:
1. Project teams should only have access to their own logs.
2. The operations team should have access to all logs across projects.
Option Analysis:
A) Grant each project team access to the project _Default view in the central logging project. Grant logging viewer access to the operations team in the central logging project.
- Pros: Easy to implement as it uses the default views in Cloud Logging.
- Cons: This approach grants each project team access to their logs in the default view. However, the operations team will only have "Viewer" access to the central project, meaning they could view logs, but they might not have full control over access or other privileges.
- Rejection Reason: Does not specifically isolate access between project teams, as they all access the default view. The operation team will have limited control and may not have full access to all logs. There's no strong enforcement of access control at the level of each project's logs, which is a security concern.
B) Create Identity and Access Management (IAM) roles for each project team and restrict access to the _Default log view in their individual Google Cloud project. Grant viewer access to the operations team in the central logging project.
- Pros: Custom IAM roles can be used to enforce strict access control. Project teams will have access only to their own logs, as IAM roles can be tailored precisely to what they need.
- Cons: While this offers good isolation, it doesn't account for an efficient way for the operations team to access all logs. IAM policies can become complex to manage when dealing with many projects.
- Rejection Reason: This solution becomes cumbersome and complex in large environments because IAM roles are tied to individual projects, making it harder to centrally manage and scale permissions.
C) Create log views for each project team and only show each project team their applicati...
Author: GlowingTiger · Last updated Jul 10, 2026
Your company uses Jenkins running on Google Cloud VM instances for CI/CD. You need to extend the functionality to use infrastructure as code automation by using Terraform. You must ensure that the Terraform Jenkins instance is authorized...
To securely and efficiently allow Jenkins to manage Google Cloud resources using Terraform while following Google-recommended practices, we need to ensure proper authorization and access control for Terraform to interact with Google Cloud.
Option Analysis:
A) Confirm that the Jenkins VM instance has an attached service account with the appropriate Identity and Access Management (IAM) permissions.
- Pros: This is the most Google-recommended approach. Attaching a service account with the necessary IAM roles to the VM instance provides secure and manageable access to Google Cloud resources. The service account will have the appropriate permissions assigned, such as roles for creating resources or interacting with Cloud APIs.
- Cons: None significant, as long as the IAM permissions are correctly configured. The service account provides the VM with seamless access to resources without needing to manage secrets.
- Selected Reasoning: This option is aligned with Google's best practices because it avoids managing credentials directly and leverages the security model of IAM and service accounts. It provides a more secure, scalable, and manageable approach to authorization for Terraform running on Jenkins.
B) Use the Terraform module so that Secret Manager can retrieve credentials.
- Pros: Using Secret Manager to retrieve credentials adds security by keeping sensitive credentials in a secure location.
- Cons: While using Secret Manager improves security, it's not the most efficient or Google-recommended method for managing service account credentials in this context. Google Cloud’s native recommendation is to use service accounts attached directly to VM instances or workloads, which simplifies access management and auditing.
- Rejection Reason: Although secure, this adds unnecessary complexity and is less efficient than attaching a service account directly to the Jenkins VM. Additionally, it requires handling secrets explicitly, which ca...
Author: Nia · Last updated Jul 10, 2026
You encounter a large number of outages in the production systems you support. You receive alerts for all the outages, the alerts are due to unhealthy systems that are automatically restarted within a minute. You want to set up a process that wou...
To address the issue of staff burnout caused by a large number of alerts in production systems, it’s important to implement a solution that follows Site Reliability Engineering (SRE) practices. The goal is to reduce unnecessary alert fatigue while ensuring systems remain reliable and meet service level objectives (SLOs).
Option Analysis:
A) Eliminate alerts that are not actionable
- Pros: By eliminating non-actionable alerts, you can reduce the noise and focus only on critical issues that require intervention. This would directly reduce burnout, as engineers would only need to respond to events that have a significant impact.
- Cons: Requires a review of the existing alerting strategy to ensure that only actionable alerts are being generated, and it may involve tuning or modifying monitoring thresholds.
- Selected Reasoning: This option aligns perfectly with SRE practices by ensuring alerts are meaningful and relevant. It focuses on reducing unnecessary responses to issues that can be automatically handled by the system (such as restarts). It helps in minimizing alert fatigue and burnout, which is essential for long-term reliability and staff well-being.
B) Redefine the related SLO so that the error budget is not exhausted
- Pros: This approach focuses on adjusting SLOs to align with the system's actual performance, allowing more tolerance for failures without triggering excessive alerts. It could help manage expectations for availability or reliability.
- Cons: This solution doesn’t directly address the cause of alert fatigue; redefining SLOs might be useful in some contexts but doesn't solve the problem of too many alerts being triggered in the first place. If SLOs are set too loosely, it might lead to undetected performance degradation.
- Rejection Reason: While redefining SLOs could help manage errors within acceptable limits, it doesn’t necessarily reduce alert fatigue. The goal should be to ensure meaningful alerts, not just adjusting metrics to accommodate frequent failures.
C) Distribute the alerts to engineers in differ...
Author: Evelyn · Last updated Jul 10, 2026
As part of your company's initiative to shift left on security, the InfoSec team is asking all teams to implement guard rails on all the Google Kubernetes Engine (GKE) clusters to only allow the deployment of trusted and approved images. You n...
To fulfill the InfoSec team's goal of shifting left on security for Google Kubernetes Engine (GKE) clusters, we need a solution that ensures only trusted and approved container images are deployed. Shifting left on security emphasizes catching security issues early in the development and deployment stages, rather than reacting after deployment. This typically involves measures such as image scanning, enforcing security policies at the CI/CD level, and ensuring secure configurations.
Option Analysis:
A) Enable Container Analysis in Artifact Registry, and check for common vulnerabilities and exposures (CVEs) in your container images
- Pros: This option enables automatic scanning of container images stored in Artifact Registry for vulnerabilities (e.g., CVEs), which helps identify insecure or outdated images before deployment.
- Cons: While this is a useful tool for vulnerability scanning, it focuses mainly on detecting vulnerabilities in images rather than controlling which images are allowed to be deployed in the first place. It is an important part of security but doesn’t directly ensure that only trusted and approved images are deployed.
- Rejection Reason: This approach alone doesn’t enforce policies for trusted or approved images during the deployment process. It focuses on scanning images post-upload, which doesn't directly meet the goal of preventing unapproved images from being deployed in the first place.
B) Use Binary Authorization to attest images during your CI/CD pipeline
- Pros: Binary Authorization allows you to enforce policies that ensure only trusted and approved images can be deployed on your GKE clusters. It integrates into the CI/CD pipeline and requires images to be attested (signed) as trusted before they are deployed. This aligns directly with the InfoSec team's goal of shifting security left, as the policy enforcement happens early in the deployment pipeline.
- Cons: This may require setup and integration into your existing CI/CD pipeline, but it is an industry-best practice for securing containerized environments. It can add some overhead but provides strong enforcement.
- Selected Reasoning: This option directly addresses the requirement to prevent the deployment of unapprov...
Author: Nia · Last updated Jul 10, 2026
Your company operates in a highly regulated domain. Your security team requires that only trusted container images can be deployed to Google Kubernetes Engine (GKE). You need to implement a solution that meets the...
To meet the security team’s requirement of ensuring only trusted container images can be deployed to Google Kubernetes Engine (GKE), while also minimizing management overhead, we need a solution that provides robust security with minimal ongoing administrative work. This requires both security enforcement at the point of deployment and ease of maintenance.
Option Analysis:
A) Configure Binary Authorization in your GKE clusters to enforce deploy-time security policies
- Pros: Binary Authorization is a Google Cloud-native security solution that ensures only trusted images are deployed to GKE. It can enforce policies such as image signing and approval before deployment. This solution integrates well with GKE and is highly automated, making it easier to enforce security policies at the deployment stage with minimal manual intervention.
- Cons: There may be some initial setup required to integrate image signing and approval mechanisms into your CI/CD pipeline, but once set up, it requires minimal management.
- Selected Reasoning: This is the most suitable solution because it directly enforces trusted image deployments without requiring additional custom code or complex configuration. It meets security compliance needs and reduces operational overhead by automating the process of image validation during deployment.
B) Grant the roles/artifactregistry.writer role to the Cloud Build service account. Confirm that no employee has Artifact Registry write permission
- Pros: This option helps in controlling who has the ability to push images to the Artifact Registry, ensuring that only authorized entities can upload images.
- Cons: While it helps in controlling permissions around image creation, it doesn’t directly prevent the deployment of unapproved images to GKE. It’s more focused on controlling who can push images, rather than ensuring that only trusted images are deployed.
- Rejection Reason: This approach does not directly address the requirement to ensure only trusted images are deployed in GKE clusters. It focuses on image uploading control but doesn't enforce security policies at the deployment stage. It also doesn’t automate the v...
Author: Samuel · Last updated Jul 10, 2026
Your CTO has asked you to implement a postmortem policy on every incident for internal use. You want to define what a good postmortem is to ensure that the po...
When defining a good postmortem policy for internal use, we must consider a few key factors:
- Transparency: The policy should promote open communication and ensure clarity about the causes of incidents.
- Actionable Insights: The postmortem should focus on identifying how to prevent the issue in the future.
- Accountability: It should identify roles, responsibilities, and ownership without blaming individuals.
- Learning Culture: Encourage an environment where everyone learns from incidents and mistakes.
Analysis of Options:
A) Ensure that all postmortems include what caused the incident, identify the person or team responsible for causing the incident, and how to prevent a future occurrence of the incident.
- Why this is good: It emphasizes the critical factors—cause, responsibility, and future prevention.
- Why not the best: Naming the person or team responsible could lead to blame, which is counterproductive to fostering a learning culture. Instead, the focus should be on systems and processes, not individuals.
B) Ensure that all postmortems include what caused the incident, how the incident could have been worse, and how to prevent a future occurrence of the incident.
- Why this is good: This option addresses cause, prevention, and risk awareness.
- Why not the best: Speculating on "how the incident could have been worse" may be unnecessary and detracts from focusing on actionable insights and practical solutions. The focus should be on the actual event and prevention strategies.
C) Ensure that all postmortems include the severity of the incident, how to prevent a future occurrence of the incident, and what caused the incident without naming internal system co...
Author: Rahul · Last updated Jul 10, 2026
You are developing reusable infrastructure as code modules. Each module contains integration tests that launch the module in a test project. You are using GitHub for source control. You need to continuously test your feature branch and ensure that all code is tested b...
When developing reusable infrastructure as code (IaC) modules, the main goal is to ensure that integration tests are consistently executed to validate that new changes do not break existing functionality. Given the context of using GitHub for source control, we need an automated process for testing before accepting changes. Let’s break down the options:
Analysis of Options:
A) Use a Jenkins server for CI/CD pipelines. Periodically run all tests in the feature branch.
- Why this is good: Jenkins is a powerful and highly customizable tool for CI/CD pipelines, capable of automating test runs, deployments, and more.
- Why not the best: The option of "periodically running all tests" is not optimal in this context. It doesn't provide immediate feedback, and waiting for periodic runs could result in delays. Continuous integration demands quick and automated testing on every change, especially before merging pull requests, not just periodically.
B) Ask the pull request reviewers to run the integration tests before approving the code.
- Why this is good: Encourages testing before code approval, ensuring that changes are validated by reviewers.
- Why not the best: This is manual and introduces human error. Relying on reviewers to run tests could lead to inconsistent results, missed tests, and delays. Automation is essential for ensuring that tests run consistently every time.
C) Use Cloud Build to run the tests. Trigger all tests to run after a pul...
Author: Lucas · Last updated Jul 10, 2026
Your company processes IoT data at scale by using Pub/Sub, App Engine standard environment, and an application written in Go. You noticed that the performance inconsistently degrades at peak load. You could not reproduce this issue on your workstation. You need to continuously monitor the application in ...
To address performance degradation in your production IoT application, you need a solution that allows you to continuously monitor and identify slow paths without adding significant overhead or complexity. Let's analyze the options in light of these requirements.
Analysis of Options:
A) Use Cloud Monitoring to assess the App Engine CPU utilization metric.
- Why this is good: Cloud Monitoring can provide valuable insights into resource utilization (like CPU usage) and overall system health.
- Why not the best: While CPU utilization metrics provide a high-level view of performance, they do not help you pinpoint specific slow paths or bottlenecks in your application code. Monitoring CPU utilization alone won’t give you the granularity needed to identify performance issues in the code itself, such as slow database queries or inefficient functions.
B) Install a continuous profiling tool into Compute Engine. Configure the application to send profiling data to the tool.
- Why this is good: Continuous profiling could provide valuable insights into performance bottlenecks by monitoring CPU and memory usage over time.
- Why not the best: Since your application runs on App Engine, not Compute Engine, this solution isn’t directly applicable. Additionally, using a separate profiling tool would introduce extra management overhead and complexity, especially when the goal is to minimize overhead.
C) Periodically run the `go tool pprof` command against the application instance. Analyze the results by using flame graphs.
...
Author: Vivaan · Last updated Jul 10, 2026
Your company runs services by using Google Kubernetes Engine (GKE). The GKE dusters in the development environment run applications with verbose logging enabled. Developers view logs by using the kubectl logs command and do not use Cloud Logging. Applications do not have a uniform logging structure defined....
To address the goal of minimizing costs associated with application logging while still collecting GKE operational logs, we need to consider a solution that effectively reduces unnecessary logging without losing important operational data. Let's analyze the options:
Analysis of Options:
A) Run the `gcloud container clusters update --logging=3DSYSTEM` command for the development cluster.
- Why this is good: This option would enable logging for system-level logs in the GKE cluster (such as cluster management and infrastructure events).
- Why not the best: This option only configures system-level logging and does not address the verbose application logs that are generating excessive costs. Additionally, enabling verbose application logging (especially without a structured logging format) could still lead to high costs.
B) Run the `gcloud container clusters update --logging=3DWORKLOAD` command for the development cluster.
- Why this is good: This would configure logging specifically for workloads in the development environment, ensuring that logs related to workloads are collected.
- Why not the best: This option still does not address the issue of minimizing the volume and verbosity of application logs, which is the main concern here. Verbose logging at the application level can still lead to unnecessary log storage and cost, especially since applications have no uniform logging structure.
C) Run the `gcloud logging sinks update _Default --disabled` command in the project associated with the development environment.
- Why this is go...
Author: Layla · Last updated Jul 10, 2026
You have deployed a fleet of Compute Engine instances in Google Cloud. You need to ensure that monitoring metrics and logs for the instances are visible in Cloud Logging and Cloud Monitoring by your company's operations and cyber security teams. You need to grant the required roles for the Compute Engine...
To ensure that monitoring metrics and logs for the Compute Engine instances are visible in Cloud Logging and Cloud Monitoring, you need to provide the necessary permissions to the Compute Engine service account while adhering to the principle of least privilege. The roles granted should be sufficient to collect and write logs and metrics without granting excessive permissions.
Key Considerations:
- Cloud Logging and Cloud Monitoring permissions are required for the service account to send logs and metrics.
- Principle of least privilege means granting only the necessary permissions for the tasks at hand, avoiding overly broad permissions that could lead to security risks.
Analysis of Options:
A) Grant the logging.logWriter and monitoring.metricWriter roles to the Compute Engine service accounts.
- Why this is good:
- `logging.logWriter` allows the service account to write logs to Cloud Logging, which is necessary for the instances to send logs.
- `monitoring.metricWriter` allows the service account to write metrics to Cloud Monitoring, which is needed for monitoring the instances.
- Why this is the best: This option grants exactly what is required to allow the service account to send logs and metrics, adhering to the principle of least privilege. These roles do not grant excessive permissions like administrative roles, and are specifically designed for logging and metrics writing.
B) Grant the logging.admin and monitoring.editor roles to the Compute Engine service accounts.
- Why this is not ideal:
- `logging.admin` grants broader permissions than necessary, including the ability ...
Author: Noah · Last updated Jul 10, 2026
You are the Site Reliability Engineer responsible for managing your company's data services and products. You regularly navigate operational challenges, such as unpredictable data volume and high cost, with your company's data ingestion processes. You recently learned that a new data ingestion product will be developed in ...
In this scenario, the goal is to provide operational input to ensure the new data ingestion product performs well in real-world conditions and is efficient from an operational perspective. Let's evaluate each option:
A) Deploy the prototype product in a test environment, run a load test, and share the results with the product development team.
- Pros: Running load tests can help identify performance bottlenecks early, which is crucial when managing unpredictable data volume. Sharing results with the product development team allows them to address issues before production deployment.
- Cons: Testing at this stage is only focused on load handling. It might miss broader operational concerns like monitoring, logging, error handling, or other system dependencies that can only be understood in staging or production environments.
- Best Use Case: Useful for testing system scalability and identifying immediate performance issues but not comprehensive for early feedback on overall operational concerns.
B) When the initial product version passes the quality assurance phase and compliance assessments, deploy the product to a staging environment. Share error logs and performance metrics with the product development team.
- Pros: Staging environments simulate production more closely, and by sharing error logs and metrics, you give valuable feedback on how the system handles real-like conditions.
- Cons: While staging is important, it might still not fully represent real-world production traffic. Additionally, it comes too late in the product lifecy...
Author: Sam · Last updated Jul 10, 2026
You are investigating issues in your production application that runs on Google Kubernetes Engine (GKE). You determined that the source of the issue is a recently updated container image, although the exact change in code was not identified. The deployment is currently pointing to the l...
In this scenario, the goal is to revert to a previously functioning version of the container in your Google Kubernetes Engine (GKE) deployment. Let's evaluate each option:
A) Create a new tag called stable that points to the previously working container, and change the deployment to point to the new tag.
- Pros: This is a viable solution as it allows you to assign a meaningful tag (like "stable") to the working version of the container and make it clear which version should be used. The new tag can be used for future references.
- Cons: While it works, creating a new tag is not the most direct way to revert to a previously working version. The deployment is still dependent on a tag, which can change over time (like the "latest" tag) and might lead to confusion in the future.
- Best Use Case: Suitable if you need to keep the container image management clean and clear, but not the most precise and direct solution for identifying the exact version you want to revert to.
B) Alter the deployment to point to the sha256 digest of the previously working container.
- Pros: This option is the most precise and reliable because it directly references a specific container image by its sha256 digest. This ensures that the exact container that worked previously will be deployed, with no ambiguity or future changes.
- Cons: This requires knowledge of the sha256 digest of the working container. While it's highly reliable, it might be cumbersome to retrieve and manage, particularly if you're not familiar with working directly wit...
Author: Noah Williams · Last updated Jul 10, 2026
You need to create a Cloud Monitoring SLO for a service that will be published soon. You want to verify that requests to the service will be addressed in fewer than 300 ms at least 90% of the time per calenda...
To create a Cloud Monitoring SLO for the service based on your requirement that requests are addressed in fewer than 300 ms at least 90% of the time per calendar month, we need to focus on the following factors:
- Latency: Since you are concerned with how fast the service responds to requests (i.e., under 300 ms), the SLO should be based on a latency metric.
- Request-based vs. Window-based Evaluation: The difference between these two methods lies in how the evaluation is performed:
- Request-based evaluation counts individual requests and calculates the percentage of requests that meet the SLO criteria. This is typically used when you want to measure the success of individual requests.
- Window-based evaluation measures service performance over a time window (like a specific duration) and checks if the service meets the SLO during that time period. This method is typically useful for availability metrics, but not ideal when tracking individual request latency.
Let's evaluate the options:
A) Select a latency metric for a request-based method of evaluation.
- Pros: This option is the most aligned with your requirement, as you want to track how many requests meet the condition of being under 300 ms. A request-based evaluation works well because it calculates the percentage of requests that meet this latency threshold, ensuring that at least 90% of requests are served in under 300 ms.
- Cons: None. This is the right approach since you're tracking individual request performance (latency).
B) Select a latency metric for a window-based method of eval...
Author: James · Last updated Jul 10, 2026
You have an application that runs on Cloud Run. You want to use live production traffic to test a new version of the application, while you let the quality assurance team perform manual testing. You want to limit the potential impact of any issues while testing the new version, and you must...
To deploy the new version of the application while ensuring minimal impact on live production traffic, you need to:
- Test the new version using live traffic but limit the potential impact by not directing all traffic to the new version.
- Have the ability to roll back easily if any issues arise.
- Allow the quality assurance (QA) team to perform manual testing on the new version.
Let's evaluate each option:
A) Deploy the application as a new Cloud Run service.
- Pros: Deploying as a new service would completely isolate the new version from the existing one. This makes it easy to roll back or remove the new version if issues occur.
- Cons: This option might not use production traffic for testing since the new service would be entirely separate, meaning it would not be as effective for live traffic testing. Also, managing separate services adds complexity if the goal is to use live traffic from the same service for testing.
- Best Use Case: Useful when you want complete isolation and do not want to mix old and new versions in the same service but does not match the requirement to test with live production traffic.
B) Deploy a new Cloud Run revision with a tag and use the --no-traffic option.
- Pros: Deploying a new revision with the `--no-traffic` option ensures that the new version does not immediately affect live traffic. This allows the QA team to test it manually and validate it without impacting users.
- Cons: While this prevents traffic from being directed to the new revision, it doesn't allow the new version to be tested with live traffic or enable a smooth, gradual release if necessary.
- Best Use Case: Good for testing internally without any exposure to live traffic but not the best if you want some traffic to go to the new version during testing.
C) Deploy a new Cloud Run revision without a tag and use the --no-traffic option.
- Pros: Using the `--no-traffic` option ensures that the new revision is not serving traffic. This would allow internal testing without impacting live traffic.
- Cons: The lack of a tag makes it harder to manage versions, ...
Author: Zara1234 · Last updated Jul 10, 2026
You recently noticed that one of your services has exceeded the error budget for the current rolling window period. Your company's product team is about to launch a new feature. You w...
In this situation, the goal is to ensure that the service's reliability standards are maintained according to Site Reliability Engineering (SRE) principles, while balancing the impact of a new feature launch.
Let's evaluate each option:
A) Notify the team about the lack of error budget and ensure that all their tests are successful so the launch will not further risk the error budget.
- Pros: This option ensures that testing is thorough, which could help prevent issues during the launch. It proactively addresses potential risks.
- Cons: While testing is important, merely ensuring tests are successful doesn't address the core issue: the service has already exceeded its error budget. This approach doesn't solve the problem of an already exceeded error budget, and could lead to further risk if the launch goes ahead.
- Best Use Case: This could be useful if the error budget was close to being exceeded, but since it's already exceeded, simply testing won't resolve the issue effectively.
B) Notify the team that their error budget is used up. Negotiate with the team for a launch freeze or tolerate a slightly worse user experience.
- Pros: This is a very practical approach under SRE principles. It acknowledges the importance of protecting the error budget and suggests either delaying the launch or accepting a slightly worse user experience, which aligns with SRE's focus on balancing reliability and feature delivery.
- Cons: This might cause delays, but it is essential to ensure that reliability does not take a hit due to new features. It keeps the integrity of the error budget intact, protecting the system’s long-term health.
- Best Use Case: Ideal when the error budget is already exceeded, and the priority is to ensure the system remains stable. It ensures the product team understands ...
Author: Maya · Last updated Jul 10, 2026
You need to introduce postmortems into your organization. You want to ensure that the postmortem process is w...
When introducing postmortems into an organization, it’s crucial to ensure that the process is embraced and contributes to the overall improvement. Two key actions should be taken to foster this acceptance:
C) Encourage your senior leadership to acknowledge and participate in postmortems.
Reason: Senior leadership's engagement in the postmortem process sets a strong tone for the rest of the organization. When leaders model a proactive, open attitude toward learning from mistakes, employees are more likely to embrace postmortems as valuable rather than punitive. Leadership involvement also shows the organization's commitment to continuous improvement. This will encourage a culture of transparency and reflection.
D) Ensure that writing effective postmortems is a rewarded and celebrated practice.
Reason: Encouraging the creation of effective postmortems and rewarding them helps establish this activity as a recognized and positive practice. By celebrating thoughtful, constructive postmortems, employees are incentivized to engage in this practice and improve their skills in delivering actionable insights. It fosters a positive feedback loop where people understand the tangible value of contributing to this process.
Why other options are rejected:
- A) Encourage new employees to conduct postmortems to team through practice.
Reason for rejection: While it’s helpful for new employees to learn about p...
Author: Noah · Last updated Jul 10, 2026
You need to enforce several constraint templates across your Google Kubernetes Engine (GKE) clusters. The constraints include policy parameters, such as restricting the Kubernetes API. You must ensure that the policy parameters ...
To enforce policy constraints across your Google Kubernetes Engine (GKE) clusters and ensure that changes in the GitHub repository are automatically applied, the best approach is to use Anthos Config Management. Here's why:
C) Configure Anthos Config Management with the GitHub repository. When there is a change in the repository, use Anthos Config Management to apply the change.
Reason for selection:
Anthos Config Management is specifically designed to manage configuration and policy across Kubernetes clusters. It allows you to store configurations in a Git repository (like GitHub) and automatically sync them with your GKE clusters. Anthos Config Management supports GitOps workflows, meaning that whenever changes are made in the GitHub repository, those changes can be automatically pushed and applied to the clusters. This solution is built to manage Kubernetes resources, including policy constraints, and provides a consistent way of ensuring that configurations and policies are enforced across multiple clusters. It integrates well with GKE, and is the most appropriate tool for managing Kubernetes policies across a large infrastructure.
Why other options are rejected:
- A) Set up a GitHub action to trigger Cloud Build when there is a parameter change. In Cloud Build, run a gcloud CLI command to apply the change.
Reason for rejection: While this option could work, it is more manual and does not provide the native Kubernetes configuration management features that Anthos Config...
Author: Stella · Last updated Jul 10, 2026
You are the Operations Lead for an ongoing incident with one of your services. The service usually runs at around 70% capacity. You notice that one node is returning 5xx errors for all requests. There has also been a noticeable increase in support cases from customers. You need to remove the offending node from the load balancer pool so that you can iso...
In this scenario, the most effective and Google-recommended approach to handle the situation and minimize user impact would be to follow the principles of gradual and safe scaling, while ensuring that traffic is managed correctly across the remaining healthy nodes.
Selected option: B) 1. Communicate your intent to the incident team. 2. Add a new node to the pool, and wait for the new node to report as healthy. 3. When traffic is being served on the new node, drain traffic from the unhealthy node, and remove the old node from service.
Reason for selection:
- Scalability and Resilience: This option follows the practice of adding a new node to ensure that the traffic load can be balanced out more evenly before removing the faulty node. It helps ensure that there is no sudden capacity loss, reducing the risk of overloading the remaining healthy nodes. By waiting for the new node to become healthy first, you are ensuring that traffic can continue to flow smoothly while the problematic node is isolated.
- Risk Mitigation: Adding a new node before removing the unhealthy one prevents overloading the existing nodes. The new node acts as a buffer to handle the increased load temporarily, preventing further impact on users and maintaining service reliability.
- Communication: The incident team is informed of the actions being taken, ensuring that all parties are aligned and can monitor the situation closely.
Why other options are rejected:
- A) 1. Communicate your intent to the incident team. 2. Perform a load analysis to determine if the remaining nodes can handle the increase in traffic offloaded from the removed node, and scale appropriately. 3. When any new nodes report healthy, drain traffic from the unhealthy node, and remove the unhealthy node from service.
Reason for rejection: While this approach starts with good communication and analysis, performing...
Author: Henry · Last updated Jul 10, 2026
You are configuring your CI/CD pipeline natively on Google Cloud. You want builds in a pre-production Google Kubernetes Engine (GKE) environment to be automatically load-tested before being promoted to the production GKE environment. You need to ensure that only builds that have passed this test are deploy...
In this scenario, you are aiming to ensure that only builds that pass the load test are deployed to the production environment using Google Cloud's Binary Authorization. Binary Authorization ensures that only trusted images are deployed by verifying attestation signatures on container images. The goal is to follow Google-recommended practices for a secure, scalable, and automated pipeline.
Selected option: C) Create an attestation for the builds that pass the load test by using a private key stored in Cloud Key Management Service (Cloud KMS) authenticated through Workload Identity.
Reason for selection:
- Google-recommended best practice: Using Workload Identity for authentication is the recommended approach in Google Cloud for securely managing service-to-service access without needing to manage service account keys manually. Workload Identity enables the use of Kubernetes service accounts with Google Cloud identities, making it a more secure and scalable option compared to traditional key management.
- Seamless integration with GKE and KMS: This option allows for a more secure and automated attestation process. By leveraging Cloud KMS, you store the private key securely, and the attestation can be done in a way that is fully automated within the CI/CD pipeline, reducing manual intervention and human error.
- Security and compliance: The private key is not exposed or stored in less secure locations like Kubernetes Secrets, and authentication through Workload Identity provides enhanced security by associating Kubernetes workloads with Google Cloud identities.
Why other options are rejected:
- A) Create an attestation for the builds that pass the load test by requir...
