Google Practice Questions, Discussions & Exam Topics by our Authors
Your organization uses a microservices architecture based on Google Kubernetes Engine (GKE). Recent security reviews recommend tighter controls around deployed container images to reduce potential vulnerabilities and maintain compliance. You need to implement an automated system by ...
Let's analyze each option carefully based on the key requirements:
Goal:
Enforce tighter controls on container images deployed to GKE to reduce vulnerabilities and maintain compliance.
Use managed services for automation.
Ensure only approved container images are deployed.
---
Option A:
Develop custom organization policies restricting deployments to images hosted within a specific Artifact Registry project where approved images reside.
Pros:
Limits deployments to a specific repository of approved images.
Easy to enforce a whitelist by controlling Artifact Registry permissions.
Cons:
This only restricts the location of images but doesn’t ensure images themselves are scanned or approved for vulnerabilities.
If an unscanned or vulnerable image is pushed into Artifact Registry, it could still be deployed.
Lacks automated vulnerability or compliance checks.
Scenario fit:
Useful for restricting image sources but insufficient for vulnerability or compliance enforcement alone.
---
Option B:
Enforce Binary Authorization in your GKE clusters. Integrate container image vulnerability scanning into the CI/CD pipeline and require vulnerability scan results to be used for Binary Authorization policy decisions.
Pros:
Binary Authorization is a managed service designed exactly for enforcing policies on container images before deployment.
Can enforce signatures or attestations that images have passed security scans.
Automates enforcement and blocks unapproved or vulnerable images from deploying.
CI/CD pipeline integration ensures only scanned, approved images are allowed.
Native GCP solution, reducing operational overhead.
Cons:
Requires some setup and integration with vulnerability scanning tools and CI/CD pipeline.
Slight learning curve if not already using Binary Authorization.
Scenario fit:
Best for automated, managed enforcement of app...
Author: Noah Williams · Last updated Jul 20, 2026
You support a Node.js application running on Google Kubernetes Engine (GKE) in production. The application makes several HTTP requests to dependent applications. You want to anticipate ...
To address the challenge of anticipating performance issues in dependent applications, let's analyze the options one by one based on the key factors of performance monitoring, tracing, and visibility:
Option A: Instrument all applications with Stackdriver Profiler
- Explanation: Stackdriver Profiler helps identify performance bottlenecks by continuously profiling the CPU and memory usage of your applications in production. However, while this tool helps in identifying bottlenecks within the application itself (e.g., CPU, memory issues), it does not provide direct insights into the latency or performance of dependent services that the application is calling (such as HTTP requests to other services).
- Reason for rejection: This option is not ideal for identifying dependent applications causing performance issues, as it focuses more on individual application performance rather than the inter-service communication.
Option B: Instrument all applications with Stackdriver Trace and review inter-service HTTP requests
- Explanation: Stackdriver Trace helps monitor the performance of requests as they travel across services, providing insights into latency and bottlenecks within and between services. By instrumenting HTTP requests, Stackdriver Trace can identify which dependent services are causing delays in the application's overall performance. You can see request latencies, breakdowns by services, and trace flow across different applications.
- Reason for selection: This option is ideal because it focuses directly on monitoring the performance of inter-service communication, which aligns with the need to anticipate issues in dependent applications. It allows you to quickly see where latency is being introduced in the service chain.
Option C: Use Stackdriv...
Author: Liam · Last updated Jul 10, 2026
You created a Stackdriver chart for CPU utilization in a dashboard within your workspace project. You want to share the chart with your Site Reliability Engineering
(SRE) team only. You...
Let's analyze each option based on the principle of least privilege, which means providing access to only the necessary resources required for performing tasks, and the need to share a chart specifically with the SRE team without granting excess permissions:
Option A: Share the workspace Project ID with the SRE team. Assign the SRE team the Monitoring Viewer IAM role in the workspace project
- Explanation: The Monitoring Viewer role gives read-only access to monitoring data, including Stackdriver charts and dashboards. By sharing the Project ID and granting this role, the SRE team would have broad access to all monitoring data within the workspace project. However, the goal is to limit access to just the chart, and the Monitoring Viewer role applies to all monitoring data in the project, which violates the principle of least privilege.
- Reason for rejection: This option provides broader access than necessary. It gives the SRE team more permissions than required to just view the chart, violating the least privilege principle.
Option B: Share the workspace Project ID with the SRE team. Assign the SRE team the Dashboard Viewer IAM role in the workspace project
- Explanation: The Dashboard Viewer role gives read-only access to specific dashboards, which is closer to the requirement of providing access only to the chart. However, this still grants access to all dashboards within the workspace project, not just the specific chart. This role is more limited than the Monitoring Viewer, but it's still not restrictive enough to only allow access to the specific chart.
- Reason for rejection: While this option provides more restricted access than the Monitoring Viewer, it still grants the SRE team access to all dashboards in the project, rather than just the specific char...
Author: Maya2022 · Last updated Jul 10, 2026
Your organization wants to implement Site Reliability Engineering (SRE) culture and principles. Recently, a service that you support had a limited outage. A manager on another team asks you to provide a ...
When applying Site Reliability Engineering (SRE) principles, postmortems are essential for learning from outages and preventing future incidents. The key factors in choosing the best option include transparency, accountability, and collaboration across teams for continual improvement.
Option A: Develop a postmortem that includes the root causes, resolution, lessons learned, and a prioritized list of action items. Share it with the manager only
- Explanation: This option restricts the sharing of the postmortem to only the manager. While this addresses the immediate need to provide a formal explanation, it limits transparency and collaboration. Sharing the postmortem with just one person may result in missed opportunities for cross-team learning and action.
- Reason for rejection: This approach doesn't fully embrace the SRE culture of transparency, which encourages the entire organization to learn from incidents. Restricting access to only the manager reduces the chance for other teams to act on or learn from the findings.
Option B: Develop a postmortem that includes the root causes, resolution, lessons learned, and a prioritized list of action items. Share it on the engineering organization's document portal
- Explanation: Sharing the postmortem on the organization’s document portal ensures that the information is accessible to everyone within the engineering organization. This promotes transparency and helps other teams identify potential improvements or actions they can take to prevent similar issues.
- Reason for selection: This option is best because it supports a culture of transparency, ensuring that everyone involved can learn from the incident and take action as needed. It allows for collaboration and accountability across teams, a central tenant of the SRE culture.
Option C: Develop a postmortem that includes the ro...
Author: Ethan Smith · Last updated Jul 10, 2026
You have a set of applications running on a Google Kubernetes Engine (GKE) cluster, and you are using Stackdriver Kubernetes Engine Monitoring. You are bringing a new containerized application required by your company into production. This application is written by a third party and cannot be modified or reconfigured. The applicat...
Let's evaluate each option carefully based on the key requirements: integrating application logs into Stackdriver Logging, managing a containerized application that cannot be modified or reconfigured, and adhering to the principle of simplicity and least effort in terms of operational overhead.
Option A: Use the default Stackdriver Kubernetes Engine Monitoring agent configuration
- Explanation: The default Stackdriver Kubernetes Engine Monitoring agent is typically used for collecting metrics and logs from Kubernetes cluster resources (e.g., node and pod metrics). However, it does not automatically collect application-specific logs from arbitrary locations like `/var/log/app_messages.log`. This agent is focused on general monitoring and may not be configurable to target specific log files unless enhanced by additional configurations.
- Reason for rejection: This option does not meet the need to specifically tail and collect the application logs from `/var/log/app_messages.log`, so it would not work for this particular scenario.
Option B: Deploy a Fluentd daemonset to GKE. Then create a customized input and output configuration to tail the log file in the application's pods and write to Stackdriver Logging
- Explanation: Fluentd is a robust log aggregator that is commonly used in Kubernetes environments for log collection. Deploying Fluentd as a daemonset on GKE allows you to create customized input configurations that target specific log files (such as `/var/log/app_messages.log`), and then send those logs to Stackdriver Logging. Fluentd is flexible and highly configurable, which makes it a solid solution for sending specific logs to Stackdriver.
- Reason for selection: This option is ideal because it provides flexibility to tailor the log collection process, such as specifying the location of the log file, filtering log messages, and sending them to Stackdriver Logging. It does not require changes to the application and can be done entirely through Kubernetes configurations, which is both scalable and efficient.
Option C: Install Kubernetes on Google Compute Engine (GCE) and redeploy your applications. Then customize the built-in Stackdriver Logging configuration to tail the log file in the application's pods and write to Stackd...
Author: Olivia · Last updated Jul 10, 2026
You are running an application in a virtual machine (VM) using a custom Debian image. The image has the Stackdriver Logging agent installed. The VM has the cloud-platform scope. The application is logging information via syslog. You want to use Stackdriver Logging in the Google Cloud Platform Console to visualize the ...
Let's break down each option in relation to the issue you're facing—missing syslog entries in the Stackdriver Logging (now Cloud Logging) console—and evaluate which action should be taken first.
Option A: Look for the agent's test log entry in the Logs Viewer
- Explanation: Checking for the agent's test log entry can be useful to verify whether the Stackdriver Logging agent is working correctly. However, the absence of syslog logs is not necessarily related to the agent's test logs. The agent might be working, but syslog logs may not be configured or collected correctly. This option might help verify the agent’s functionality but doesn't directly address the issue with syslog logs not showing up.
- Reason for rejection: This is a useful diagnostic step but is not the first thing you should do. The issue likely lies in the configuration or setup of syslog forwarding to Cloud Logging, which is not directly addressed by looking at the agent's test logs.
Option B: Install the most recent version of the Stackdriver agent
- Explanation: Installing the most recent version of the Stackdriver agent is a good practice to ensure you're using the latest features and bug fixes. However, the issue in question—missing syslog logs—may not be related to the version of the agent. If the agent is already installed, this action could be unnecessary and would take more time than needed.
- Reason for rejection: While keeping the agent up to date is important, the root cause of the issue is likely due to configuration (e.g., syslog forwarding), not the agent's version. Installing a new version could be beneficial later, but it's not the first step to address the issue of missing syslog logs.
Option C: Verify the VM service account access scope includes the mo...
Author: Ethan · Last updated Jul 10, 2026
You use a multiple step Cloud Build pipeline to build and deploy your application to Google Kubernetes Engine (GKE). You want to integrate with a third-party monitoring platform by performing a HTTP POST of the bui...
In this scenario, the goal is to minimize development effort while integrating with a third-party monitoring platform by sending build information via HTTP POST to a webhook. Let's analyze the options in detail:
Option A: Add logic to each Cloud Build step to HTTP POST the build information to a webhook.
- Pros: You can capture build information from individual steps and send it in real-time.
- Cons: This approach would require adding custom HTTP POST logic to every step of the pipeline. It increases complexity and could be prone to errors, making it harder to maintain. Also, adding this logic to each step increases the development effort significantly.
- Use Case: This option is not ideal for minimizing development effort in a multi-step pipeline, especially when you want to avoid repetitive custom logic in every step.
- Rejected due to high maintenance and complexity.
Option B: Add a new step at the end of the pipeline in Cloud Build to HTTP POST the build information to a webhook.
- Pros: This is a simpler approach, where a single step at the end of the pipeline handles the HTTP POST. It minimizes repetitive logic and reduces complexity.
- Cons: If the build information needs to be sent in real-time for each step, this may not work effectively. This method only sends information at the end of the pipeline, not during the individual steps.
- Use Case: This could work well if sending the build information at the end of the pipeline is sufficient for your monitoring needs. It simplifies the implementation but might not be ideal if you need real-time integration with the third-party platform.
- Accepted if sending build info after the entire pipeline completes is acceptable.
Option C: Use Stackdriver Logging to create a logs-based metric from the Cloud Build logs. Create an Alert with a Webhook notification type.
- Pros: Stackdriver Logging (now part of Google Cloud Operations suite) integrates well with GKE and Cloud Build. Creating a logs-based metric and using webhooks for alerting is a manag...
Author: BlazingPhoenix22 · Last updated Jul 10, 2026
You use Spinnaker to deploy your application and have created a canary deployment stage in the pipeline. Your application has an in-memory cache that loads objects at start time. You want to automate the comparison of t...
To automate the comparison of the canary version against the production version in Spinnaker, the key factors to consider are how the canary analysis will be done, the behavior of the application (including the in-memory cache), and what is being compared during the analysis. Let's break down each option:
Option A: Compare the canary with a new deployment of the current production version.
- Pros: This option allows you to compare the canary deployment against the most recent deployment (the "current" version) of your production environment. It would provide a real-time comparison between the canary and the live system.
- Cons: If the production version has just been deployed, the comparison may be skewed by the "cold start" effect of the new production deployment, especially considering the in-memory cache of your application, which may not yet be fully warmed up. This can introduce variability in performance that isn’t reflective of normal production behavior.
- Use Case: This could be useful for comparing the canary with a fresh deployment of the production version, but the cache warm-up effects would need to be accounted for.
- Rejected due to possible instability or cache effects in the fresh production deployment.
Option B: Compare the canary with a new deployment of the previous production version.
- Pros: This approach compares the canary with the version of the application that was deployed before the current deployment. The in-memory cache would be more stable because the "previous" production version would already be fully warmed up, making it a more consistent comparison point.
- Cons: This comparison could be useful for tracking how the canary performs against a more stable, pre-existing version, but it may not reflect the current state of the application, especially if the new deployment introduces changes to performance or behavior that are worth evaluating.
- Use Case: This is an option if you want to compare against a previous, more stable version of production, but it might not always reflect the most up-to-date state of the application.
- Rejected if you want to evaluate how the canary performs against the latest production changes.
Option C: Compare the canary with the existing deployment of the current production version.
- Pros: This option direct...
Author: Ming · Last updated Jul 10, 2026
You support a high-traffic web application and want to ensure that the home page loads in a timely manner. As a first step, you decide to implement a Service
Level Indicator (SLI) to represent home page request latency with an a...
To ensure that the home page loads in a timely manner, the Service Level Indicator (SLI) should accurately reflect the latency of the home page requests in relation to the goal of 100 ms. Let's evaluate each option to determine the best approach:
Option A: Bucketize the request latencies into ranges, and then compute the percentile at 100 ms.
- Pros: This approach allows for a more detailed breakdown of latencies across different ranges. By calculating percentiles (such as the 90th or 99th percentile), it can show how the request latency distribution behaves.
- Cons: While this approach gives useful insights into the distribution of request latencies, calculating the exact percentile at 100 ms could be challenging and not directly aligned with measuring whether individual requests meet the 100 ms target. Percentiles also measure overall latency performance, not whether requests are under the 100 ms target.
- Use Case: This option is useful if you're interested in understanding the overall latency behavior of your web application, but it does not provide a clear SLI for requests under 100 ms.
- Rejected because it's not a direct method for calculating whether the page load time meets the 100 ms threshold.
Option B: Bucketize the request latencies into ranges, and then compute the median and 90th percentiles.
- Pros: By calculating the median and 90th percentiles, this option gives you a good understanding of how most requests are performing and where the majority of traffic lies in terms of latency.
- Cons: Similar to Option A, percentiles like the median and 90th percentile do not directly reflect whether individual requests are under the 100 ms threshold. Percentiles provide an overall measure but don’t help in calculating the proportion of requests that meet the 100 ms target.
- Use Case: This is good for understanding latency trends and ensuring that the majority of requests meet performance standards, but it is not ideal for directly tracking whether specific requests are under the 100 ms threshold.
- Rejected...
Author: Kunal · Last updated Jul 10, 2026
You deploy a new release of an internal application during a weekend maintenance window when there is minimal user tragic. After the window ends, you learn that one of the new features isn't working as expected in the production environment. After an extended outage, you roll back the new release and deploy a fix.
You want to mod...
To reduce the mean time to recovery (MTTR) and avoid extended outages in the future, the key focus is on improving the reliability and speed of your release process, ensuring quick detection of issues and minimizing manual intervention. Let's break down each option:
Option A: Before merging new code, require 2 different peers to review the code changes.
- Pros: Code reviews help catch potential issues early, ensure adherence to coding standards, and share knowledge among team members. This improves code quality and reduces the likelihood of introducing bugs that could cause outages.
- Cons: While helpful, code reviews are more preventative and focus on catching issues in the development phase. However, they do not directly reduce MTTR after deployment issues occur in production.
- Use Case: This is useful for maintaining code quality, but it doesn’t directly address the issue of speeding up recovery or minimizing the impact of deployment issues once in production.
- Rejected for not addressing post-release recovery times directly.
Option B: Adopt the blue/green deployment strategy when releasing new code via a CD server.
- Pros: Blue/green deployments allow you to have two separate environments: one running the current stable version (blue) and the other running the new version (green). This enables you to switch between the two environments quickly if something goes wrong, reducing downtime during rollbacks and accelerating recovery.
- Cons: The main downside could be the additional complexity in managing multiple environments, but this is generally outweighed by the ability to recover quickly in case of failure.
- Use Case: This is a strong option to reduce MTTR, as it allows for fast rollbacks without major downtime or additional manual interventions, making it highly suitable for the scenario.
- Selected as it directly addresses recovery speed and minimizes outages.
Option C: Integrate a code linting tool to validate coding standards before any code is accepted into the repository.
- Pros: Code linting ensures adherence to coding standards, which can help maintain readability and consistency across the codebase. This can reduce some low-level bugs and improve maintainability.
- Cons: Linting tools help catch syntax and style issues but do not directly affect the functionality or performance of the application in production. They are not directly related to reducing MTTR or handling deployment issues after re...
Author: Ming88 · Last updated Jul 10, 2026
You have a pool of application servers running on Compute Engine. You need to provide a secure solution that requires the least amount of configuration and allows developers to easily access ...
Let's go over the options one by one to see which one fits best.
Option A: Deploy the Stackdriver logging agent to the application servers. Give the developers the IAM Logs Viewer role to access Stackdriver and view logs.
- Pros:
- This solution integrates directly with Stackdriver (now known as Google Cloud Operations Suite), which is purpose-built for centralized logging.
- The Stackdriver logging agent can easily collect logs from the application servers and send them to Google Cloud Logging for centralized viewing and analysis.
- Giving developers the IAM Logs Viewer role will grant them read-only access to the logs without extra configuration.
- Cons:
- This requires configuration of the Stackdriver logging agent on each application server, but it is a standard and reliable method for centralized logging in GCP.
Option B: Deploy the Stackdriver logging agent to the application servers. Give the developers the IAM Logs Private Logs Viewer role to access Stackdriver and view logs.
- Pros:
- Similar to Option A, this integrates directly with Google Cloud Logging.
- The IAM Logs Private Logs Viewer role provides more granular control, limiting the developer’s access to only specific logs or logs that are designated as private, enhancing security.
- Cons:
- The Logs Private Logs Viewer role could complicate access, depending on the specific setup, and could require extra management for log access policies. For general troubleshooting, the standard IAM Logs Viewer role (Option A) may be simpler and sufficient.
Option C: Deploy the Stackdriver monitoring agent to the application servers. Give the developers the IAM Monitoring Viewer role to access Stackdriver and view metrics.
- Pros:
- This option would be beneficial if the goal is to collect and view metrics (e.g., CPU utilization, memory usage), not ...
Author: Ming88 · Last updated Jul 10, 2026
You support the backend of a mobile phone game that runs on a Google Kubernetes Engine (GKE) cluster. The application is serving HTTP requests from users.
You need to im...
To reduce network costs in a GKE-based application serving HTTP requests, it's important to optimize network traffic routing, manage ingress and egress traffic efficiently, and minimize data transfer between regions or networks. Let's evaluate each option based on this goal:
A) Configure the VPC as a Shared VPC Host project
- Analysis: This option allows multiple projects to share a single VPC network. While this could be beneficial in terms of managing network resources across multiple projects, it does not directly impact reducing network cost for your specific use case (GKE cluster and HTTP traffic serving). Shared VPC primarily helps with organizational structure and multi-project network management rather than cost reduction.
- Rejection Reason: This is more of a networking architecture solution than a direct cost reduction approach. It's not suited for reducing network costs in the context of serving HTTP traffic.
B) Configure your network services on the Standard Tier
- Analysis: Google Cloud offers two tiers for networking services: Standard Tier and Premium Tier. The Standard Tier uses less optimal routes for traffic, often leading to higher network latency and potentially higher egress costs since it may route traffic through regions that increase costs. The Premium Tier, however, uses Google's private global network, offering lower latencies and reducing egress costs.
- Rejection Reason: The Standard Tier generally results in higher costs and less optimal performance. For a mobile game with HTTP traffic, you’d want to minimize latency and cost, which is better supported by the Premium Tier. Thus, the Standard Tier is not ideal for reducing network costs.
C) Configure your Kubernetes cluster as a Private Cluster
- Analysis: A Private Cluster res...
Author: Akash · Last updated Jul 10, 2026
You encountered a major service outage that affected all users of the service for multiple hours. After several hours of incident management, the service returned to normal, and user access was restored. You need to provide an incident summary to rele...
When dealing with a major service outage, the first priority after restoring service is to communicate effectively with stakeholders and follow best practices for incident management. Let's evaluate the options in terms of SRE (Site Reliability Engineering) recommended practices.
A) Call individual stakeholders to explain what happened
- Analysis: Calling individual stakeholders can be time-consuming and inefficient, especially if there are many stakeholders involved. While it's important to communicate with stakeholders, this method doesn't scale well and lacks transparency, as it would require one-on-one interaction, and might result in inconsistent messaging.
- Rejection Reason: This option is not effective for large-scale communication and doesn't align with SRE best practices, which emphasize clear, documented, and consistent communication for all relevant parties.
B) Develop a post-mortem to be distributed to stakeholders
- Analysis: A post-mortem is a critical component of incident response in SRE. It provides a detailed and structured overview of what happened, including the root cause, the timeline of events, how the issue was addressed, lessons learned, and actions to prevent similar incidents in the future. It’s a formal document that allows all stakeholders to have a clear, consistent understanding of the event.
- Selected Option: Developing a post-mortem is the best choice because it aligns with SRE best practices for transparency, learning, and continuous improvement. It ensures that all stakeholders receive the same information in a structured format, making it a valuable tool for reflection and future incident management.
C) Send the Incident State Document to all the stakeholders
- Analysis: An Incident State Document may contain initial details about the incident, such as a high-level overvi...
Author: William · Last updated Jul 10, 2026
You are performing a semi-annual capacity planning exercise for your flagship service. You expect a service user growth rate of 10% month-over-month over the next six months. Your service is fully containerized and runs on Google Cloud Platform (GCP), using a Google Kubernetes Engine (GKE) Standard regional cluster on three zones with cluster autoscaler enabled. You currently consume about 30% of your total deployed CPU capacity, and you require resilience against the failure of a zone. You ...
In the scenario of preparing for user growth while ensuring resilience against potential zone failures, we need to balance between scaling proactively to handle the growth and avoiding unnecessary over-provisioning that could lead to cost inefficiencies.
Let's evaluate each option:
A) Verify the maximum node pool size, enable a horizontal pod autoscaler, and then perform a load test to verify your expected resource needs
- Analysis: This approach is focused on verifying the maximum capacity and ensuring that scaling is based on actual resource usage. It also suggests using a horizontal pod autoscaler to dynamically adjust the number of pods based on demand, and performing a load test to verify expected resource needs. This method ensures that you are prepared to handle growth, both in terms of scaling and performance. However, load testing might not always simulate exactly how user growth will behave, and while the horizontal pod autoscaler is helpful, it does not address the required resilience against zone failure.
- Rejection Reason: While useful for tuning and verifying resource needs, this approach doesn't directly address the resilience required for a zone failure and might not fully ensure that you can meet the demand given the predicted growth and the goal of minimizing costs.
B) Because you are deployed on GKE and are using a cluster autoscaler, your GKE cluster will scale automatically, regardless of growth rate
- Analysis: GKE’s cluster autoscaler can automatically scale the number of nodes up and down depending on resource usage. However, the cluster autoscaler will only scale as needed based on the current resource demand—it won't proactively account for future growth unless demand exceeds current capacity. This means that while your cluster may handle growth automatically, it might not be ready in advance for the 10% month-over-month growth or resilient enough for a zone failure unless you preconfigure it properly.
- Rejection Reason: While GKE does offer autoscaling, it doesn’t automatically take into account the planned growth or ensure that your cluster can handle zone failure in advance. The autoscaler reacts to demand rather than proactively scaling for future needs.
C) Because you are at only 30% utilization, you have significant headroom and you won't need to add any additional capacity for this rate of growth
-...
Author: Isabella · Last updated Jul 10, 2026
Your application images are built and pushed to Google Container Registry (GCR). You want to build an automated pipeline that deploys the application when the image ...
To minimize development effort and automate the deployment process when an image is updated in Google Container Registry (GCR), we need an efficient way to trigger the deployment pipeline whenever a new image is available, while integrating well with GKE and GCR.
Let’s analyze each option:
A) Use Cloud Build to trigger a Spinnaker pipeline
- Analysis: Cloud Build can be used to build images and trigger workflows, and Spinnaker is a powerful tool for continuous delivery and deployment. This option could work, as Cloud Build can trigger Spinnaker pipelines automatically. However, this setup requires significant configuration and management of Spinnaker pipelines. Spinnaker is a complex tool that, while powerful, can be overkill for simpler use cases. Additionally, this setup adds complexity that could require extra development and operational effort.
- Rejection Reason: Spinnaker adds a layer of complexity that may not be necessary for your requirement of minimizing development effort.
B) Use Cloud Pub/Sub to trigger a Spinnaker pipeline
- Analysis: Cloud Pub/Sub is a messaging service that can be used to notify systems about changes. By integrating Cloud Pub/Sub with Spinnaker, you could trigger a pipeline based on messages that indicate image updates. While this solution is flexible, it again involves Spinnaker, which, as mentioned earlier, can be complex and add unnecessary overhead for simpler needs.
- Rejection Reason: This approach still uses Spinnaker, which introduces more complexity than required for a simple deployment pipeline, leading to more development effort than necessary.
C) Use a custom builder in Cloud Build to trigger Jenkins pipeline
- Analysis: Cloud Build can trigger Jenkins pipelines, but this adds another layer of complexity since you...
Author: Sophia Clark · Last updated Jul 10, 2026
Your product is currently deployed in three Google Cloud Platform (GCP) zones with your users divided between the zones. You can fail over from one zone to another, but it causes a 10-minute service disruption for the affected users. You typically experience a database failure once per quarter and can detect it within five minutes. You are cataloging the reliability risks of a new real-time chat feature for your product. You catalog the following information for each risk:
* Mean Time to Detect (MTTD) in minutes
* Mean Time to Repair (MTTR) in minutes
* Mean Time Between Failure (MTBF) in days
* User Impact Percentag...
To assess the reliability risk of the new database system, we need to consider how the Mean Time to Repair (MTTR) is affected by the new database system, particularly in terms of its failover process between zones. Since the new database system takes twice as long to fail over compared to the previous system, we can analyze the potential impact based on the following:
Key Definitions:
- MTTD (Mean Time to Detect): The time it takes to detect a failure. This is still 5 minutes based on the previous system, as it is unaffected by the failover time.
- MTTR (Mean Time to Repair): The time it takes to restore service after a failure. Since the failover time for the new database system is twice as long, the MTTR would increase. Previously, the failover caused a 10-minute disruption, so doubling this time gives an MTTR of 20 minutes.
- MTBF (Mean Time Between Failures): The frequency of failures, which remains unchanged at 90 days (since the system failure rate does not change).
- Impact: The user impact percentage is based on how many users are affected by a failure. Previously, only the users in the affected zone would experience service disruption. With the new system, since failover takes longer, the service disruption could impact a larger portion of the users during the recovery period.
Reasoning for Options:
- Option A (MTTD: 5, MTTR: 10, MTBF: 90, Impact: 33%):
- MTTR is not adjusted for the longer failover time of the new database system. This would not be accurate, as the new system takes twice as long to fail over, which should result in an MTTR of 20 minutes, not 10.
- Impact is stated as 33%, which assumes that only a third of users are impacted during a zone failure, but with the longer failover time, the service disruption might affect more users, potentially up to 50% of the user base.
- ...
Author: Zara · Last updated Jul 10, 2026
You are managing the production deployment to a set of Google Kubernetes Engine (GKE) clusters. You want to make sure only images which are successfully built by you...
To ensure that only images successfully built by your trusted CI/CD pipeline are deployed to production in Google Kubernetes Engine (GKE), the best option would be to use Binary Authorization. Here's a breakdown of the reasoning:
A) Enable Cloud Security Scanner on the clusters:
- What it does: Cloud Security Scanner scans your web applications for vulnerabilities like cross-site scripting (XSS), insecure libraries, and other issues.
- Why it's not suitable: Cloud Security Scanner is not designed to control which images can be deployed or manage CI/CD processes. It's focused on scanning for vulnerabilities in web apps and doesn’t help enforce trusted image deployments.
B) Enable Vulnerability Analysis on the Container Registry:
- What it does: Vulnerability analysis checks for known security vulnerabilities in container images stored in the Container Registry.
- Why it's not sufficient: While vulnerability analysis helps detect security flaws in images, it doesn't control or enforce which images can be deployed in the first place. It’s important for security but doesn’t directly manage trusted image deployment from a CI/CD pipeline.
C) Set up the Kubernetes Engine clusters as private clusters:
- What it does: Private clusters in GKE e...
Author: SilverBear · Last updated Jul 10, 2026
You support an e-commerce application that runs on a large Google Kubernetes Engine (GKE) cluster deployed on-premises and on Google Cloud Platform. The application consists of microservices that run in containers....
To identify containers that are using the most CPU and memory in a Google Kubernetes Engine (GKE) cluster, the best option would be A) Use Stackdriver Kubernetes Engine Monitoring. Let's break down the reasoning for each option:
A) Use Stackdriver Kubernetes Engine Monitoring:
- What it does: Stackdriver (now called Google Cloud Operations Suite) Kubernetes Engine Monitoring is a built-in tool designed for monitoring and managing the performance of Kubernetes clusters. It offers detailed insights into the health and performance of Kubernetes workloads, including CPU and memory usage per container. This is specifically built for Kubernetes environments and provides an integrated solution for monitoring without requiring complex setup.
- Why it's the best choice: This option provides an easy, direct, and managed solution for tracking container resource usage (CPU and memory) in GKE. Stackdriver Monitoring automatically collects the relevant metrics without requiring additional setup or complex configuration. It is integrated with Google Cloud services and provides real-time monitoring out of the box.
B) Use Prometheus to collect and aggregate logs per container, and then analyze the results in Grafana:
- What it does: Prometheus is an open-source monitoring system, and Grafana is a data visualization tool. Prometheus can be used to scrape metrics from GKE, including CPU and memory usage per container, and Grafana can visualize the results.
- Why it’s less optimal: Although this is a powerful and flexible solution, it requires manual configuration, setup of Prometheus and Grafana, and managing the integrations. For a straightforward use case of monitoring resource usage, it’s more complex compared to Stackdriver Kubernetes Engine Monitoring, which is fully managed and already integrated with Google Cloud.
...
Author: Rahul · Last updated Jul 10, 2026
Your company experiences bugs, outages, and slowness in its production systems. Developers use the production environment for new feature development and bug fixes. Configuration and experiments are done in the production environment, causing outages for users. Testers use the production environment for load testing, which often slows the production systems. You...
To address the issues of bugs, outages, and slowness in the production systems while enabling proper testing and feature development, the best approach is to D) Create a development environment for writing code and a test environment for configurations, experiments, and load testing. Here's a detailed breakdown of why this is the best solution and why the other options are less appropriate:
A) Create an automated testing script in production to detect failures as soon as they occur:
- What it does: This option suggests creating an automated testing script that runs within the production environment to detect failures in real-time.
- Why it’s not optimal: While automated testing is valuable, running tests directly in the production environment is risky. It could potentially add more load to production systems, interfere with live user traffic, and could even cause more disruptions if the tests fail or require significant resources. Additionally, it doesn't address the root cause of the issue: testing and development happening in production. It is a reactive measure rather than a preventative one.
B) Create a development environment with smaller server capacity and give access only to developers and testers:
- What it does: This option suggests creating a separate, smaller development environment where developers and testers can work without affecting production systems.
- Why it’s not ideal: A smaller server capacity for development is a good idea, but it doesn't fully address the issue of testing and experimenting with configurations and load testing. Limiting developers and testers to just a small development environment doesn’t solve the problem of configuration changes and load testing that often take place in production. It also doesn’t allow for comprehensive testing under realistic conditions.
C) Secure the production environment to ensure that developers can't change it and set up one controlled update per y...
Author: Aarav · Last updated Jul 10, 2026
You support an application running on App Engine. The application is used globally and accessed from various device types. You want to know the number of connections. You a...
To monitor the number of active connections for an application running on App Engine, the most appropriate metric would be A) flex/connections/current. Let's break down the reasoning for this option and the others:
A) flex/connections/current:
- What it does: This metric tracks the current number of connections to an App Engine flexible environment. It provides insights into the active connections that are directly tied to the application’s workload, which is exactly what you need to monitor how many clients are actively connected to your application at any given time.
- Why it's the best choice: The flex/connections/current metric is specifically designed for monitoring connections to App Engine flexible environment instances. It aligns directly with the requirement to know the number of connections the application is handling, especially since App Engine is used globally, and you need to monitor real-time usage.
B) tcp_ssl_proxy/new_connections:
- What it does: This metric tracks the number of new TCP/SSL connections being initiated through the TCP/SSL proxy layer, which may be part of a broader network setup.
- Why it’s not the best choice: While this metric can be useful in some scenarios, it’s more focused on the proxy layer rather than the specific App Engine instance. If you’re directly concerned with the application’s connec...
Author: Grace · Last updated Jul 10, 2026
You support an application deployed on Compute Engine. The application connects to a Cloud SQL instance to store and retrieve data. After an update to the application, users report errors showing database timeout messages. The number of concurrent active...
To identify the most probable cause of the database timeout issue after an update to your application, the most appropriate action would be C) Determine whether there is an increased number of connections to the Cloud SQL instance. Here's a detailed explanation of why this is the best choice and why the other options are less suitable:
A) Check the serial port logs of the Compute Engine instance:
- What it does: Serial port logs provide low-level information about the operating system and boot process of the Compute Engine instance.
- Why it’s not ideal: While the serial port logs can provide insight into system-level issues during startup or crashes, they do not offer information about application-level behaviors or database connectivity issues. Since the issue relates to database timeouts and not to the Compute Engine instance’s startup or basic functioning, serial port logs are unlikely to help diagnose this issue.
B) Use Stackdriver Profiler to visualize the resource utilization throughout the application:
- What it does: Stackdriver Profiler helps visualize CPU and memory usage across your application to identify performance bottlenecks.
- Why it’s not the best choice: While profiling can be useful for identifying inefficient code, high CPU usage, or memory leaks, it won’t directly help you identify issues related to database connectivity, such as database timeouts. The issue described appears to be related to how your application interacts with the Cloud SQL database, not with application resource utilization.
C) Determine whether there is an increased number of connections to the Cloud SQL instance:
- What it does: This option involves checking whether there is a sudden...
Author: Benjamin · Last updated Jul 10, 2026
Your application images are built using Cloud Build and pushed to Google Container Registry (GCR). You want to be able to specify a particular version of your application for deployment based on the...
When pushing an image to Google Container Registry (GCR), it's important to make it easy to refer to a specific version of the image corresponding to a release version in source control. This ensures that deployments can reliably reference a particular version of the application.
Let's evaluate the options:
- A) Reference the image digest in the source control tag:
- This approach uses the unique digest of the image (a SHA256 hash) to ensure exact matching between the image in the registry and the version in source control. This is a very reliable way of pinpointing an exact version, as the digest is immutable. However, this method can be cumbersome, as it requires referencing the full digest in your source control and may not provide a user-friendly versioning scheme (such as "v1.0.0" or "release-2025").
- B) Supply the source control tag as a parameter within the image name:
- This approach uses the tag from source control (e.g., a version number like "v1.0.0") as part of the image name. This is a more user-friendly approach as it directly associates the image with a release version, and it's common in containerized application deployments. However, the image may change over time, meaning the tag can point to different digests, making it less reliable in terms of guaranteeing the exact same image after subsequent builds or updates.
- C) Use Cloud Build to include the release version tag in the application image:
- This option ...
Author: Daniel · Last updated Jul 10, 2026
You are on-call for an infrastructure service that has a large number of dependent systems. You receive an alert indicating that the service is failing to serve most of its requests and all of its dependent systems with hundreds of thousands of users are affected. As part of your Site Reliability Engineering (SRE) incident management protocol, you declare yourse...
In the context of managing an incident, especially one that affects a critical infrastructure service with widespread user impact, it’s important to focus on immediate resolution, coordination, and communication to minimize damage and restore service. Let's evaluate each option:
- A) Look for ways to mitigate user impact and deploy the mitigations to production:
- This is a crucial step in incident response, but it’s not the first thing to do after assuming the role of Incident Commander (IC). While mitigation is necessary, the first priority should be to establish a structured communication and coordination framework. This includes ensuring that everyone involved in the response is aligned, so the mitigation efforts can be executed effectively. Starting with mitigation may lead to disorganized actions without proper coordination.
- B) Contact the affected service owners and update them on the status of the incident:
- While communication with affected service owners is critical, this action is best done after setting up the necessary internal coordination channels. At this point, it's more important to ensure that the incident response team can communicate clearly and coordinate actions internally before informing external stakeholders like service owners. This step would come after internal teams are aligned on the action plan.
- C) Establish a communication channel where incident responders and leads can communicate with each other:
- This is the most immed...
Author: Ming · Last updated Jul 10, 2026
You are developing a strategy for monitoring your Google Cloud Platform (GCP) projects in production using Stackdriver Workspaces. One of the requirements is to be able to quickly identify and react to production environment issues without false alerts from development and staging projects. You want to ensure that you ...
When designing a strategy for monitoring GCP projects in production using Stackdriver Workspaces, the key goals are to ensure the monitoring system adheres to the principle of least privilege, minimize false alerts from non-production environments, and provide easy access to relevant team members.
Let’s evaluate the options:
- A) Grant relevant team members read access to all GCP production projects. Create Stackdriver workspaces inside each project:
- This option violates the principle of least privilege. Granting read access to all GCP production projects for monitoring purposes would give team members access to more resources than necessary. This could lead to unnecessary exposure of sensitive resources. Also, creating separate workspaces inside each project can be cumbersome to manage and maintain, particularly when trying to consolidate monitoring across multiple projects.
- B) Grant relevant team members the Project Viewer IAM role on all GCP production projects. Create Stackdriver workspaces inside each project:
- This option still grants broader permissions than necessary by giving team members access to all production projects through the Project Viewer role. This is more restrictive than option A but still involves access to all production projects, which might not be ideal if we want to follow the principle of least privilege and avoid unnecessary exposure of resources. Additionally, managing multiple workspaces inside each project can be harder to maintain.
- C) Choose an existing GCP production project to host the monitoring workspace. Attach the production projects to this workspace. Grant relevant team members read access to the Stackdriver...
Author: RadiantJaguar56 · Last updated Jul 10, 2026
You currently store the virtual machine (VM) utilization logs in Stackdriver. You need to provide an easy-to-share interactive VM utilization dashboard that is updated in real time and contains information aggregat...
When building a solution for interactive and real-time dashboards based on VM utilization logs, there are key factors to consider: ease of setup, real-time updates, aggregation of data on a quarterly basis, and easy sharing with stakeholders. Let's evaluate each option:
- A) 1. Export VM utilization logs from Stackdriver to BigQuery. 2. Create a dashboard in Data Studio. 3. Share the dashboard with your stakeholders:
- This option is a strong candidate. BigQuery is optimized for handling large datasets and performing advanced queries, including aggregations like quarterly summaries. Data Studio allows you to easily create interactive and real-time dashboards connected to BigQuery, making it easy to share with stakeholders. This solution is simple to set up, highly scalable, and provides interactive dashboards with minimal effort.
- B) 1. Export VM utilization logs from Stackdriver to Cloud Pub/Sub. 2. From Cloud Pub/Sub, send the logs to a Security Information and Event Management (SIEM) system. 3. Build the dashboards in the SIEM system and share with your stakeholders:
- While this approach might work for more specialized security use cases, it introduces unnecessary complexity for the given requirement. SIEM systems are designed to manage security data, and using them for VM utilization logs would require additional configuration and could complicate things unnecessarily. Also, creating dashboards in SIEM systems might not provide the same level of ease and flexibility as a tool like Data Studio.
- C) 1. Export VM utilization logs from Stackdriver to BigQuery. 2. From BigQuery, export the logs to a CSV file. 3. Import the ...
Author: VenomousSerpent42 · Last updated Jul 10, 2026
You need to run a business-critical workload on a fixed set of Compute Engine instances for several months. The workload is stable with the exact amount of resources allocated to it. You want to lower...
When optimizing costs for a stable, business-critical workload with fixed resource requirements, the key goals are to minimize expenses without compromising performance or availability. Let's evaluate the available options based on those criteria:
- A) Purchase Committed Use Discounts:
- This option is well-suited for workloads with predictable and stable resource usage over a long period, like the one described in the question. Committed Use Discounts allow you to reserve resources for a specific term (e.g., 1 or 3 years) in exchange for significant cost savings compared to pay-as-you-go pricing. Since the workload is stable and the resources are fixed, this option provides a cost-effective solution without any performance trade-offs. It's the ideal choice because it provides lower costs while ensuring performance stability.
- B) Migrate the instances to a Managed Instance Group:
- Managed Instance Groups (MIGs) are designed for workloads that need to scale dynamically, automatically handling changes in load and ensuring high availability through features like autoscaling and health checks. However, in this case, the workload is stable, and the resources are fixed. Migrating to a MIG does not reduce costs directly unless autoscaling is required, which is not the case here. Additionally, MIGs may introduce more overhead and complexity than is necessary for a fixed, stable workload.
- ...
Author: Sofia · Last updated Jul 10, 2026
You are part of an organization that follows SRE practices and principles. You are taking over the management of a new service from the Development Team, and you conduct a Production Readiness Review (PRR). After the PRR analysis phase, you determine that the service cannot currently meet its ...
When managing a service after conducting a Production Readiness Review (PRR) and determining that it cannot meet its Service Level Objectives (SLOs), it's crucial to make decisions based on SRE principles to ensure that the service is reliable and can meet its operational expectations in production. Here's the evaluation of each option:
A) Adjust the SLO targets to be achievable by the service so you can bring it into production.
- Reason for rejection: Adjusting the SLO targets to be achievable may result in setting expectations too low, which can compromise the overall service reliability and performance. SLOs should reflect the true capabilities and reliability of the system. Lowering SLO targets could mislead stakeholders and result in unaddressed issues that could later affect the user experience.
- When it can be used: This could be considered as a temporary measure when there is a clear path toward improving reliability, but it shouldn't be used as the first step.
B) Notify the development team that they will have to provide production support for the service.
- Reason for rejection: While involving the development team for production support might seem like a good idea initially, it doesn't address the fundamental problem of meeting SLOs. The service's operational readiness and reliability should be handled by the SRE team, not by relying on the development team to support the service in production. This approach is not scalable or in alignment with SRE best practices.
- When it can be used: This might be necessary in some situations where the development team has better insights into specific issues, but it doesn't directly solve the problem of ensuring SLOs are met.
C) Identify recommended reliability improvem...
Author: Stella · Last updated Jul 10, 2026
You are running an experiment to see whether your users like a new feature of a web application. Shortly after deploying the feature as a canary release, you receive a spike in the number of 500 errors sent to users, and your monitoring reports sh...
In this scenario, where you're running an experiment with a canary release and are seeing negative user impacts (increased 500 errors and latency), the primary goal is to minimize the negative impact on users as quickly as possible. Let's evaluate each option:
A) Roll back the experimental canary release.
- Reason for selection: This is the most immediate action to take when user experience is directly impacted by an experimental release. A rollback would quickly halt the release, removing the source of errors and latency spikes. This approach aligns with minimizing user harm in production, especially when you're dealing with critical issues like 500 errors, which directly affect functionality.
- When it can be used: This option is ideal when the negative impact is immediate and substantial, and when the release cannot be quickly diagnosed and fixed in real-time. It prioritizes reducing harm to users first, while allowing time to investigate further.
B) Start monitoring latency, traffic, errors, and saturation.
- Reason for rejection: While monitoring is important, it's not the first step when a significant user-impacting issue is already identified. Since you already know there’s a spike in 500 errors and increased latency, adding more monitoring wouldn't immediately address the impact. You need to act to mitigate the problem first (e.g., rollback) before you gather more data.
- When it can be used: This should be used after you've already mitigated the issue to understand its scope better or to investigate long-term trends, but it's not the most urgent action when facing active...
Author: Isabella · Last updated Jul 10, 2026
You are responsible for creating and modifying the Terraform templates that define your Infrastructure. Because two new engineers will also be working on the same code, you need to define a process and adopt a tool that will prevent you from overwriting eac...
To ensure that multiple engineers working on the same Terraform templates don’t overwrite each other’s code and to capture all updates efficiently, we need a solution that addresses code collaboration, version control, and preventing conflicts.
Let's evaluate the options based on this scenario:
A) Use a version control system (VCS) like Git.
- Reason for selection: Git is the most common and reliable tool for managing code collaboration. By using a VCS like Git, you can create branches, make individual contributions, and use pull requests to review and merge changes. This ensures that each engineer can work on separate branches and avoid overwriting each other’s work. Git also helps in capturing all updates in versions through commit history, making it easy to track changes over time.
- When it can be used: This is the ideal option for managing multiple contributors on Terraform code. Git can be used for local development, sharing code, and ensuring collaboration without conflicts.
B) Implement a locking mechanism in Terraform to prevent simultaneous changes.
- Reason for rejection: While Terraform does support state locking (especially when using backends like AWS S3 with DynamoDB for state locking), this is more related to ensuring that two users don't concurrently change the infrastructure in an active state rather than managing code changes in version control. This locking doesn't address code collaboration or prevent overwriting code, as Terraform itself doesn't offer a mechanism to lock code changes in the repository.
- When it can be used: State locking is important for avoiding concurrent changes to infrastructure resources in a live environment, but it doesn't solve the issue of code collaboration among developers.
C) Use Te...
Author: Krishna · Last updated Jul 10, 2026
You support a high-traffic web application with a microservice architecture. The home page of the application displays multiple widgets containing content such as the current weather, stock prices, and news headlines. The main serving thread makes a call to a dedicated microservice for each widget and then lays out the homepage for the user. The microservices occasionally fail; when that happens, the serving thread serves the homepage with some missing content. Users of the application are unhappy if this degraded mode occurs too frequently, but they wou...
In this scenario, where the application serves multiple widgets via microservices and aims to maintain an acceptable user experience despite occasional service failures, it's important to choose an SLI that effectively reflects the overall quality of the user experience in the event of degraded content.
A) A quality SLI: the ratio of non-degraded responses to total responses.
- Reason for selection: This option measures the proportion of responses where the content served is complete (non-degraded) compared to the total number of responses. Since the homepage can still be served with some missing content in case of failures, this SLI directly captures how much content is fully available and delivered, which aligns with the goal of ensuring the user experience doesn’t degrade too much. This SLI provides a clear view of the completeness of the content on the homepage, which is the main concern in this scenario.
- When it can be used: This is the most suitable SLI for the situation, as it directly measures the quality of the homepage experience, which includes ensuring users see as much content as possible, even if some widgets are missing.
B) An availability SLI: the ratio of healthy microservices to the total number of microservices.
- Reason for rejection: While availability is important, this SLI doesn’t capture the actual user experience. A microservice might be healthy, but that doesn’t guarantee it’s providing useful content. Also, a service could be healthy but still be unable to return content in a timely manner, affecting the user experience. This SLI focuses on the backend health rather than what users see on the frontend.
- When it can be used: This is useful for monitoring the overall health ...
Author: MoonlitPantherX · Last updated Jul 10, 2026
You support a multi-region web service running on Google Kubernetes Engine (GKE) behind a Global HTTP/S Cloud Load Balancer (CLB). For legacy reasons, user requests first go through a third-party Content Delivery Network (CDN), which then routes traffic to the CLB. You have already implemented an availability
Service Level Indicator (SLI) at the CLB level. However, you want to increase c...
To increase coverage and improve the ability to measure the impact of failures or misconfigurations in your multi-region web service, it’s important to consider multiple SLIs across different layers of the system. This ensures that any potential issues (e.g., CDN failure, load balancer misconfiguration, or networking issues) can be detected early and appropriately addressed.
Let’s evaluate each option based on the goal of improving monitoring for global failures:
A) Your application servers' logs.
- Reason for rejection: While application server logs provide valuable information for debugging and understanding issues in the application, they are reactive rather than proactive. Logs are helpful after an incident occurs, but they don’t give you real-time visibility into whether global issues, such as CDN failures or misconfigurations in the CLB, are affecting users in real-time.
- When it can be used: Application logs are essential for post-incident analysis and understanding root causes, but they aren’t the best option for proactively monitoring service availability or catching global issues.
B) Instrumentation coded directly in the client.
- Reason for rejection: While client-side instrumentation can provide valuable insights into the user's experience (e.g., page load times, successful requests), it doesn’t capture issues that are outside of the client’s environment, such as failures at the CDN or the global load balancer level. It could also miss global infrastructure problems if they don't directly impact the client-side experience in a noticeable way.
- When it can be used: Client-side instrumentation is useful for measuring the user experience and detecting issues on the client side, but it doesn’t help in identifying global infrastructure problems.
C) Metrics exported from the application servers.
- Reason for rejection: Metrics from the application servers can provide insights into the health and performance of the application itself. However, they might not capture network-level issues or failures earlier in the request path, such as a CDN failure or a load balancer misconfi...
Author: GlowingTiger · Last updated Jul 10, 2026
Your team is designing a new application for deployment into Google Kubernetes Engine (GKE). You need to set up monitoring to collect and aggregate various application-level metrics in a centralized location. You want to use Google Cloud P...
To decide which monitoring solution is optimal, we need to assess each option based on the ease of implementation, integration with GKE and Google Cloud services, and whether it minimizes the amount of setup and management work.
Option A: Publish various metrics from the application directly to the Stackdriver Monitoring API, and then observe these custom metrics in Stackdriver.
- Advantages:
- Direct integration with Stackdriver Monitoring.
- You can publish custom application metrics easily.
- Offers flexibility and control over which metrics are collected.
- Disadvantages:
- This approach requires manual implementation of the monitoring code in the application, including API integration.
- You would need to define each metric, handle the formatting, and ensure that the application reliably sends data to Stackdriver.
- This solution could be more complex to maintain as you need to manage your custom metrics over time.
Option B: Install the Cloud Pub/Sub client libraries, push various metrics from the application to various topics, and then observe the aggregated metrics in Stackdriver.
- Advantages:
- Pub/Sub is useful for distributing data, and it can handle various types of metrics.
- Allows decoupling the application from the monitoring system by using a publish-subscribe model.
- Disadvantages:
- This option adds complexity by introducing Pub/Sub, which is unnecessary if your goal is to simplify the monitoring setup.
- Would require you to implement logic for pushing metrics to Pub/Sub topics and then setting up another system to process and aggregate the metrics into Stackdriver.
- Not a straightforward way of getting metrics directly into Stackdriver, which leads to more overhead.
Option C: Install the OpenTelemetry client libraries in the application, configure Stackdriver as the export destination for the metrics, and then observe the application's metrics in Stackdriver.
- Advantages:
...
Author: VenomousSerpent42 · Last updated Jul 10, 2026
You support a production service that runs on a single Compute Engine instance. You regularly need to spend time on recreating the service by deleting the crashing instance and creating a new instance based on the relevant image. You want to reduce the time s...
To determine the best solution for reducing the manual effort involved in managing the production service while adhering to Site Reliability Engineering (SRE) principles, we need to evaluate the options based on automation, reliability, and efficiency.
Option A: File a bug with the development team so they can find the root cause of the crashing instance.
- Advantages:
- Addressing the root cause of the issue is a valid long-term strategy.
- Disadvantages:
- This solution is reactive, and it doesn't reduce the immediate operational burden.
- It doesn’t provide an automated recovery or prevent the issue from affecting the service in the short term.
- SRE principles emphasize automation and minimizing manual intervention, and this approach doesn’t solve the operational issue quickly.
Option B: Create a Managed Instance Group with a single instance and use health checks to determine the system status.
- Advantages:
- Managed Instance Groups (MIGs) automatically replace unhealthy instances using health checks, ensuring high availability and reducing manual effort.
- With health checks, if the instance crashes or becomes unhealthy, a new instance will be automatically created, reducing downtime.
- This approach is aligned with SRE principles by automating recovery and scaling.
- Disadvantages:
- MIGs are typically used to manage multiple instances, but they can still be used for a single instance scenario.
- Although it's a simple solution, it may still require setting up health checks and configuring the instance group, but the benefit of automation makes it worth the effort.
Option C: Add a Load Balancer in front of the Compute Engine instance and use health checks to determine the system status.
- Advantages:
- Load balancers can help distribute traffic, and health checks allow...
Author: Amira99 · Last updated Jul 10, 2026
Your application artifacts are being built and deployed via a CI/CD pipeline. You want the CI/CD pipeline to securely access application secrets. You also want to more...
When choosing the best solution to securely manage and access application secrets in a CI/CD pipeline, we need to prioritize security, ease of secret rotation, reduced human error, and automation. Let’s evaluate each option based on these factors.
Option A: Prompt developers for secrets at build time. Instruct developers to not store secrets at rest.
- Advantages:
- Secrets are not stored at rest, reducing the risk of secret exposure.
- Disadvantages:
- This approach introduces manual intervention, making it less reliable and prone to human error.
- It creates friction in the CI/CD pipeline since developers would need to be prompted for secrets every time a build occurs.
- It doesn’t offer a convenient way to rotate secrets automatically in case of a breach.
- This is not scalable and increases the complexity of automation.
Option B: Store secrets in a separate configuration file on Git. Provide select developers with access to the configuration file.
- Advantages:
- Centralized storage of secrets, making them easier to manage.
- Disadvantages:
- Storing secrets in Git, even in a separate configuration file, is risky as Git repositories could be exposed or mishandled.
- This doesn't align with best practices for managing secrets, as it doesn't offer automatic key rotation or restrict access effectively.
- There is no easy way to rotate secrets automatically, which is essential for maintaining security.
Option C: Store secrets in Cloud Storage encrypted with a key from Cloud KMS. Provide the CI/CD pipeline with access to Cloud KMS via IAM.
- Advantages:
- Cloud KMS (Key Management Service) allows for encryption and decryption of secrets securely, with full control over who can access and manage them.
- Cloud Storage can hold the secrets in a secure, encrypted form, r...
Author: William · Last updated Jul 10, 2026
Your company follows Site Reliability Engineering practices. You are the person in charge of Communications for a large, ongoing incident affecting your customer-facing applications. There is still no estimated time for a resolution of the outage. You are receiving emails from internal stakeholders who want updates on the outage, as well as emai...
When managing communication during an ongoing incident, especially one affecting customer-facing applications, it's crucial to maintain transparency, timeliness, and efficiency in your communication efforts. The selected approach should help streamline the process and reduce confusion or frustration, while adhering to Site Reliability Engineering (SRE) best practices.
Option A: Focus on responding to internal stakeholders at least every 30 minutes. Commit to the "next update" times.
- Advantages:
- Aiming for frequent updates with internal stakeholders is good to keep the internal team informed.
- Setting a fixed “next update” time can provide predictability.
- Disadvantages:
- Excessive focus on internal updates can create bottlenecks and divert resources away from customer communication.
- This approach could lead to inefficient use of time during an incident. When an incident is still ongoing and there is no resolution, constantly updating stakeholders internally could take time away from managing the situation and responding to customer concerns.
- Customer-facing updates may be neglected, as you're prioritizing internal emails.
Option B: Provide periodic updates to all stakeholders in a timely manner. Commit to a "next update" time in all communications.
- Advantages:
- Clear, timely, and transparent communication with both internal stakeholders and customers is key during an outage.
- Committing to a "next update" time ensures that all parties know when to expect the next communication, helping to manage expectations.
- Provides an efficient way to manage updates, as all stakeholders are informed at once. You don’t need to answer the same questions repeatedly.
- Helps in maintaining accountability and transparency with customers and internal teams, which aligns with SRE practices.
- Disadvantages:
- Requires a balance between providing updates to both internal teams and customers. This could become overwhelming if not properly structured or automated.
- However, this can be mitigated by sending the same update to all parties at scheduled intervals.
Option C: Delegate the responding to internal stakeholder emails to another member of the Incident ...
Author: Ethan · Last updated Jul 10, 2026
Your team uses Cloud Build for all CI/CD pipelines. You want to use the kubectl builder for Cloud Build to deploy new images to Google Kubernetes Engine
(GKE). You need to a...
When using Cloud Build with kubectl to deploy images to Google Kubernetes Engine (GKE), the focus is on authentication to ensure that Cloud Build can securely interact with the Kubernetes cluster while minimizing manual configuration and effort. Let's evaluate each option based on security, effort minimization, and best practices for CI/CD pipelines.
Option A: Assign the Container Developer role to the Cloud Build service account.
- Advantages:
- Assigning the `Container Developer` role directly to the Cloud Build service account gives it the necessary permissions to interact with GKE.
- Simple and effective approach without requiring additional setup.
- Disadvantages:
- If your Cloud Build service account is used across different projects or contexts, this approach might grant excessive permissions. This could go against the principle of least privilege.
- No flexibility to use more specific or custom roles based on your needs.
Option B: Specify the Container Developer role for Cloud Build in the cloudbuild.yaml file.
- Advantages:
- This would allow you to define the permissions as part of the build process.
- Helps in ensuring that the correct role is applied during each execution.
- Disadvantages:
- The Cloud Build configuration file (`cloudbuild.yaml`) is used to define steps in the CI/CD pipeline, not roles or IAM policies.
- You cannot assign IAM roles directly in the `cloudbuild.yaml` file; roles must be assigned through the IAM console or other administrative tools, not through build configuration files.
- This approach would lead to an incorrect configuration, as roles cannot be defined in this context.
Option C: Create a new service account with the Container Developer role and use it to run Cloud Build.
- Advantage...
Author: Krishna · Last updated Jul 10, 2026
You support an application that stores product information in cached memory. For every cache miss, an entry is logged in Stackdriver Logging. You want to vis...
Let's break down the options to determine the best solution:
Option A: Link Stackdriver Logging as a source in Google Data Studio. Filter the logs on the cache misses.
- Scenario: Google Data Studio is used for creating visualizations and reports. You could link Stackdriver Logging to Data Studio and create visualizations, filtering logs for cache misses.
- Reasoning: While this option could work for creating visualizations, it is not optimized for continuous monitoring or time-series data. The integration with Google Data Studio would require manual setup for data extraction and may not provide the necessary real-time or detailed insights needed for monitoring cache misses effectively.
- Rejection: Google Data Studio is best for static reports and not for continuous time-based monitoring of events.
Option B: Configure Stackdriver Profiler to identify and visualize when the cache misses occur based on the logs.
- Scenario: Stackdriver Profiler is used to profile applications and visualize their performance, focusing on CPU usage, memory allocation, and other performance metrics.
- Reasoning: Profiler is designed for performance optimization and resource usage, not for logging or visualizing specific events like cache misses. It does not have the functionality to directly track log entries such as cache misses from Stackdriver Logging.
- Rejection: Profiler is not designed to handle logging events or cache miss tracking, so it is not suitable for this scenario.
Option C: Create a logs-based metric in Stackdriver Logging and a dashboard for that metric in Stackdriver Monitoring.
- Scenario: Stackdriver Logging allows you to create logs-based metrics, which can be use...
Author: Andrew · 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 (MIG) and should be deployed over multiple regions. The service needs a large numbe...
Let's analyze each of the options to determine the best approach:
Option A: Use the n1-highcpu-96 machine type in the configuration of the MIG.
- Scenario: The n1-highcpu-96 machine type is a specific instance type with 96 vCPUs and a high CPU-to-memory ratio.
- Reasoning: While this machine type may provide a large number of resources, it’s not ideal for automatically scaling or ensuring proper capacity management. The requirement of using a large number of resources for each instance means you may end up with a resource that is too large for some instances and not well suited to scaling dynamically. Additionally, it doesn’t address the need for capacity planning across multiple regions.
- Rejection: Using a specific machine type limits flexibility and doesn’t directly address the scaling or regional distribution requirements, nor does it consider the quota limits in multiple regions.
Option B: Monitor results of Stackdriver Trace to determine the required amount of resources.
- Scenario: Stackdriver Trace is a tool for monitoring the performance and latency of your application. It helps analyze latency between services and trace request flow, but it doesn’t provide direct insight into capacity requirements or the number of resources needed per instance.
- Reasoning: Stackdriver Trace can help you monitor performance but is not suitable for estimating or determining the amount of resources required for your instances. It's more useful for identifying bottlenecks or latency issues rather than planning capacity for scaling instances.
- Rejection: This option is not relevant for planning resource allocation or scaling across regions. Stackdriver Trace focuses on performance rather than capacity planning.
Option C: Validate that the resource requirements are within the available quota limits of each region.
...
Author: Emma Brown · Last updated Jul 10, 2026
You are running an application on Compute Engine and collecting logs through Stackdriver. You discover that some personally identifiable information (PII) is leaking into certain log entry fields. All PII entries begin with the text userinfo. You want to capture these log e...
Let's analyze the options one by one to identify the best approach for securely handling PII in Stackdriver logs:
Option A: Create a basic log filter matching userinfo, and then configure a log export in the Stackdriver console with Cloud Storage as a sink.
- Scenario: This option involves creating a basic log filter for "userinfo" and exporting matching logs to Cloud Storage.
- Reasoning: While this approach captures logs containing "userinfo" and exports them to a secure location (Cloud Storage), it doesn’t address the need to prevent these logs from leaking into Stackdriver Logging in the first place. The logs are still ingested by Stackdriver, and they only get exported later.
- Rejection: This does not fully prevent the leak of PII into Stackdriver Logging. It only addresses post-ingestion handling.
Option B: Use a Fluentd filter plugin with the Stackdriver Agent to remove log entries containing userinfo, and then copy the entries to a Cloud Storage bucket.
- Scenario: This option uses a Fluentd filter plugin to remove logs containing "userinfo" before they are ingested into Stackdriver, then it copies those filtered logs to Cloud Storage.
- Reasoning: This approach helps prevent PII from being ingested into Stackdriver in the first place, but it doesn't provide a mechanism to capture the filtered logs securely. There is no explicit logging of PII that is removed, so this option doesn't allow you to review the logs later. It only removes them from the logs in Stackdriver.
- Rejection: This solution doesn't allow for capturing the logs containing PII for later review, as it simply removes them.
Option C: Create an advanced log filter matching userinfo, configure a log export in the Stackdriver console with Cloud Storage as a sink, and then configure a log exclusion with userinfo as a filt...
Author: VenomousSerpent42 · Last updated Jul 10, 2026
You have a CI/CD pipeline that uses Cloud Build to build new Docker images and push them to Docker Hub. You use Git for code versioning. After making a change in the Cloud Build YAML configuration, you notice that no new artifacts are being built by the ...
Let's break down each option and evaluate its effectiveness in resolving the issue:
Option A: Disable the CI pipeline and revert to manually building and pushing the artifacts.
- Scenario: This option suggests stopping the CI pipeline and manually building and pushing the artifacts.
- Reasoning: This approach does not follow Site Reliability Engineering (SRE) practices, as it does not focus on resolving the root cause of the issue. Manually reverting to building and pushing artifacts is a temporary workaround, not a long-term solution. Additionally, it adds manual intervention, which increases the risk of human error and reduces automation in the CI/CD pipeline.
- Rejection: SRE practices emphasize automation, resilience, and resolving underlying issues rather than manual intervention.
Option B: Change the CI pipeline to push the artifacts to Container Registry instead of Docker Hub.
- Scenario: This option suggests changing the destination from Docker Hub to Google Cloud's Container Registry.
- Reasoning: While using Container Registry might offer some benefits (e.g., better integration with Google Cloud), the root issue here is related to Cloud Build not triggering new builds, not the destination of the artifacts. Changing the destination without addressing the underlying issue in the Cloud Build configuration is unlikely to resolve the problem. The issue is likely to persist even if the destination is switched.
- Rejection: Changing the artifact destination doesn't solve the issue with the pipeline's functionality. The root cause of the problem (why no new builds are triggered) remains unaddressed.
Option C: Upload the configuration YAML file to Cloud Storage and use Error Reporting to identify and fix the issue.
- Scenario: This option suggests ...
Author: Kunal · Last updated Jul 10, 2026
Your company follows Site Reliability Engineering principles. You are writing a postmortem for an incident, triggered by a software change, that severely affected users. You want ...
Let’s break down the options to determine the best approach in preventing severe incidents from happening in the future:
Option A: Identify engineers responsible for the incident and escalate to their senior management.
- Scenario: This option suggests identifying the engineers responsible for the incident and escalating the issue to their senior management.
- Reasoning: Focusing on blaming specific individuals does not align with Site Reliability Engineering (SRE) principles, which emphasize collaboration, learning, and improving systems rather than assigning blame. This approach would be counterproductive and could foster a blame culture, which may stifle open communication and hinder learning from the incident. SRE practices focus on root cause analysis and system improvements, not on individual blame.
- Rejection: This approach does not foster the learning culture needed for continuous improvement, which is a core tenet of SRE.
Option B: Ensure that test cases that catch errors of this type are run successfully before new software releases.
- Scenario: This option involves making sure test cases are in place that catch errors similar to the one that caused the incident.
- Reasoning: This option aligns with SRE principles, as it emphasizes improving the development process to prevent future incidents. By improving test coverage and ensuring that errors are caught during testing, you can reduce the likelihood of severe incidents affecting users. This preventative measure focuses on automation and quality, which are key aspects of reliability and resilience.
- Selected: This approach is proactive, addressing the root cause by ensuring the issue is caught before it impacts users. It aligns with best practices in SRE to prevent incidents before they happen.
Option C: Follow up with the employees who reviewed the changes and prescribe practices they should follow in the future.
- Scenario: This option in...
Author: Amira · Last updated Jul 10, 2026
You support a high-traffic web application that runs on Google Cloud Platform (GCP). You need to measure application reliability from a user perspective without m...
To measure application reliability from a user perspective without making engineering changes to the application, let's evaluate each option in the context of reliability measurement and the requirement to avoid engineering changes.
Option Analysis:
1. A) Review current application metrics and add new ones as needed.
- Rejection Reason: This involves modifying the application or system configuration to capture additional metrics. Since the goal is to avoid making engineering changes, this option doesn't align with the requirement.
- Scenario: This would be more applicable if you had the flexibility to modify the code or infrastructure but isn’t ideal for the current objective of not making changes.
2. B) Modify the code to capture additional information for user interaction.
- Rejection Reason: This involves modifying the application code to capture more detailed data about user interactions. Since the objective is to measure reliability without engineering changes, this option is not suitable.
- Scenario: This would apply if you could change the application code to gather more data, but here we are avoiding those changes.
3. C) Analyze the web proxy logs only and capture response time of each request.
- Rejection Reason: While web proxy logs can provide useful insights, focusing on response times alone will not give a comprehensive view of user experience. Response time alone doesn’t necessarily indicate reliability from a user perspective because it doesn't account for factors like user frustration or success rate.
- Scenario: Useful when you only need raw network performance metrics, but not ideal for capturing the full user experie...
Author: CrystalWolfX · Last updated Jul 10, 2026
You manage an application that is writing logs to Stackdriver Logging. You need to give some team members t...
To give team members the ability to export logs from Stackdriver Logging, we need to provide the appropriate permissions to manage log sinks and access to export logs.
Option Analysis:
1. A) Grant the team members the IAM role of logging.configWriter on Cloud IAM.
- Rejection Reason: The `logging.configWriter` role allows users to manage the configuration of logging, including creating and managing log sinks. However, this role is broader and may allow more access than necessary, including managing the logging configuration. It doesn't specifically focus on exporting logs, which is the primary requirement.
- Scenario: This role might be useful in environments where more configuration management is required, but it's not the most appropriate for controlling only export permissions.
2. B) Configure Access Context Manager to allow only these members to export logs.
- Rejection Reason: Access Context Manager is designed for managing security policies based on context (like IP address, device type), rather than directly managing specific permissions like log export. It’s not the most straightforward tool to control export permissions for logs in Stackdriver Logging.
- Scenario: This would be relevant in highly restricted environments where specific contextual access is needed, but it is not designed for the granularity needed to allow log exports.
3. C) Create and grant a custom IAM role with the permi...
Author: Scarlett · Last updated Jul 10, 2026
Your application services run in Google Kubernetes Engine (GKE). You want to make sure that only images from your centrally-managed Google Container
Registry (GCR) image registry in the altostrat-images pro...
To ensure that only images from your centrally-managed Google Container Registry (GCR) in the `altostrat-images` project can be deployed to the GKE cluster, while minimizing development time, we should focus on an automated approach that minimizes the chances for human error and ensures security at scale.
Option Analysis:
1. A) Create a custom builder for Cloud Build that will only push images to gcr.io/altostrat-images.
- Rejection Reason: This approach focuses on ensuring that Cloud Build only pushes images to the desired GCR registry. While this can control where images are pushed, it doesn't address the deployment phase directly or restrict which images can be deployed to GKE. This solution is more focused on the build process, not deployment.
- Scenario: This would be useful for controlling image creation and storage but does not address the deployment restriction, which is the core requirement here.
2. B) Use a Binary Authorization policy that includes the whitelist name pattern gcr.io/altostrat-images/.
- Selection Reason: Binary Authorization is a Google Cloud service that allows you to define policies on which container images can be deployed to your GKE cluster based on attributes like the image registry, the image's signature, and other criteria. By creating a whitelist for `gcr.io/altostrat-images/`, you can ensure that only images from this registry are allowed to be deployed. This approach provides a centralized and automated way to enforce image security and control. It also integrates seamlessly with GKE without requiring manual intervention or changes to the deployment pipeline.
- Scenario: Ideal for enforcing security policies that ensure only trusted images from specific regist...
Author: Ravi Patel · Last updated Jul 10, 2026
Your team has recently deployed an NGINX-based application into Google Kubernetes Engine (GKE) and has exposed it to the public via an HTTP Google Cloud
Load Balancer (GCLB) ingress. You want to scale the deployment of th...
To scale the frontend application in Google Kubernetes Engine (GKE) effectively using a Service Level Indicator (SLI), we need to monitor performance metrics that will enable autoscaling decisions based on actual traffic patterns and application load. Let's analyze each option in detail to determine the best approach:
Option Analysis:
1. A) Configure the horizontal pod autoscaler to use the average response time from the Liveness and Readiness probes.
- Rejection Reason: Liveness and Readiness probes are used to determine the health of the pods but do not directly provide performance metrics related to traffic or load (e.g., response time or request rate). These probes are more focused on ensuring that the pods are functioning and ready to serve traffic rather than providing meaningful metrics for scaling based on load.
- Scenario: This option could help in ensuring pods are healthy but is not suitable for scaling based on user traffic or load metrics, which is critical for this situation.
2. B) Configure the vertical pod autoscaler in GKE and enable the cluster autoscaler to scale the cluster as pods expand.
- Rejection Reason: The vertical pod autoscaler adjusts the CPU and memory requests and limits of pods, while the cluster autoscaler scales the number of nodes in the cluster. However, neither of these approaches directly scales based on user traffic or the specific SLI you want to use for scaling (like request counts or load). Scaling the cluster based on the number of pods alone won't optimize the application’s frontend scaling in response to real-time traffic.
- Scenario: This option is more relevant for managing resources at the node level and does not provide the desired SLI-based autoscaling mechanism for the application layer.
3. C) Install the Stackdriver custom metrics adapter and configure a horizontal pod autoscaler to use the number of requests provid...
Author: Michael · Last updated Jul 10, 2026
Your company follows Site Reliability Engineering practices. You are the Incident Commander for a new, customer-impacting incident. You need to immediately assign two incident management roles to ass...
In a Site Reliability Engineering (SRE) environment, effective incident management is crucial for minimizing downtime and ensuring that the response is organized and efficient. The Incident Commander (IC) typically oversees the incident, but they need assistance with roles that focus on both the technical aspects of the incident and communication with both internal stakeholders and external customers.
Option Analysis:
1. A) Operations Lead
- Rejection Reason: The Operations Lead is responsible for the day-to-day operations of systems and infrastructure. While this role can help with ongoing system maintenance and recovery, it does not focus specifically on the incident response process itself. It is not a primary incident management role that would directly help the Incident Commander in managing a customer-impacting incident.
- Scenario: Useful in long-term operational oversight, but doesn't fit the immediate need for scaling response efforts in a high-stakes incident.
2. B) Engineering Lead
- Selection Reason: The Engineering Lead is critical to any incident response, particularly in a customer-impacting scenario. This role ensures that technical resources are focused on diagnosing and resolving the issue, and provides technical expertise and guidance to help troubleshoot and mitigate the problem. The Engineering Lead can drive the engineering team's efforts and escalate technical issues that need resolution, which is crucial for a swift response.
- Scenario: This role is essential for ensuring that the incident is addressed with the necessary technical expertise, especially in complex or high-priority incidents.
3. C) Communications Lead
- Selection Reason: The Communications Lead plays a crucial role in managing internal communications during an incident. This includes updating stakeholders, leadership, and possibly other teams. Effective communication helps ensure that everyone involved has up-to-date information about the incident’s status and any immediate actions being taken. The Communications Lead ensures that the incident response is well-documented and...
Author: Victoria · Last updated Jul 10, 2026
You support an application running on GCP and want to configure SMS notifications to your team for the most critical alerts in Stackdriver Monitoring. You have already identifi...
Let's analyze each option in detail based on key factors such as simplicity, directness, and relevance to Stackdriver (now known as Google Cloud Monitoring) configurations:
Option A: Download and configure a third-party integration between Stackdriver Monitoring and an SMS gateway. Ensure that your team members add their SMS/phone numbers to the external tool.
- Pros: This option allows the use of an external SMS gateway, which could be flexible and customizable.
- Cons: The main issue is that it's external and adds complexity. It requires downloading, configuring, and maintaining third-party software and an additional service. Also, your team needs to add their phone numbers manually to this tool, which can be a hassle.
- Use Case: This might be useful in more complex systems or when integrating with a third-party system already in place.
Option B: Select the Webhook notifications option for each alerting policy, and configure it to use a third-party integration tool. Ensure that your team members add their SMS/phone numbers to the external tool.
- Pros: Webhooks can integrate with external systems, providing flexibility for advanced setups.
- Cons: It involves setting up and maintaining a third-party tool, similar to Option A, and it doesn't directly offer SMS notifications. Webhooks are typically used for more complex workflows (e.g., sending data to custom systems or triggering events in applications).
- Use Case: This can be used when you have a custom notification system or advanced integration needs, but it's over-complicated if you're only looking for ...
Author: Joseph · Last updated Jul 10, 2026
You are managing an application that exposes an HTTP endpoint without using a load balancer. The latency of the HTTP responses is important for the user experience. You want to understand what HTTP latencie...
To properly monitor the HTTP latencies experienced by all of your users, you need to create a custom metric that can capture latency data and then visualize it effectively in Stackdriver Monitoring (Google Cloud Operations Suite).
Let’s analyze each option based on your goal:
Option A: Create a metric with a metricKind set to DELTA and a valueType set to DOUBLE. In Stackdriver's Metrics Explorer, use a Stacked Bar graph to visualize the metric.
- MetricKind: DELTA is used for metrics that track the change over time (i.e., the difference between the value at two points in time). It is typically used for counters (e.g., the number of HTTP requests).
- ValueType: DOUBLE is appropriate for numerical data such as latency values in milliseconds.
- Graph: A Stacked Bar graph is generally used for visualizing the distribution of different metrics or categories. This doesn’t fit well for visualizing latency data over time, where a continuous trend is needed.
Option B: Create a metric with a metricKind set to CUMULATIVE and a valueType set to DOUBLE. In Stackdriver's Metrics Explorer, use a Line graph to visualize the metric.
- MetricKind: CUMULATIVE is suitable for metrics where the value increases over time, like counters that track total request counts. This could also work for latency if you're interested in tracking the cumulative sum of latencies over time.
- ValueType: DOUBLE works here for latency measurements.
- Graph: A Line graph is a good choice for visualizing trends over time, such as latency variations, making it ideal for this scenario.
- Conclusion: This option makes sense for tracking the cumulative latency of requests over time, which can be helpful to understand the overall impact of latency across the application.
Option C: Create a metric with a metricKind set to GAUGE and a valueType set to DISTRIBUTION. In Stackdriver's Metrics Explorer, use a ...
Author: Sophia Clark · Last updated Jul 10, 2026
Your team is designing a new application for deployment both inside and outside Google Cloud Platform (GCP). You need to collect detailed metrics such as system resource utilization. You want to use centralized GCP services w...
Let's analyze each option to determine the most efficient and suitable approach for collecting detailed metrics like system resource utilization, while leveraging GCP's centralized services:
Option A: Import the Stackdriver Profiler package, and configure it to relay function timing data to Stackdriver for further analysis.
- Pros: Stackdriver Profiler is great for collecting detailed performance data, including profiling the performance of application functions, and it's well-integrated with GCP.
- Cons: This option is focused on profiling function-level performance (such as CPU usage and memory consumption of functions) rather than system resource utilization (e.g., CPU, memory, disk I/O). It's more about fine-grained code-level performance and may not capture the broader system resource metrics you need.
- Use Case: Ideal for optimizing individual functions and improving performance at the code level but not suitable for broad system resource utilization metrics.
Option B: Import the Stackdriver Debugger package, and configure the application to emit debug messages with timing information.
- Pros: Stackdriver Debugger helps in analyzing the behavior of live applications by providing insights into variable values and stack traces without interrupting the application.
- Cons: This is intended for debugging and inspecting code, rather than collecting system resource utilization metrics like CPU or memory. It’s not suitable for your goal of collecting metrics related to system resources.
- Use Case: This is helpful for debugging specific issues in live applications but not for gathering system-wide performance or resource metrics.
Option C: Instrument the code using a timing library, and publish the metrics via a health check endpoint that is scraped by Stackdriver.
- Pros: This option involves adding custom code to publish metrics, and you can control exa...
Author: Liam123 · Last updated Jul 10, 2026
You need to reduce the cost of virtual machines (VM) for your organization. After reviewing different options, you decide to leverage preemptible V...
Let’s break down the options based on the suitability of preemptible VMs, which are cost-effective but can be terminated by Google Cloud at any time, making them ideal for workloads that are fault-tolerant and can handle interruptions.
Option A: A scalable in-memory caching system
- Pros: An in-memory caching system can generally tolerate node termination because cache data can be reloaded or rebuilt without significant long-term impact. Preemptible VMs could be ideal for this scenario if the system is designed to be fault-tolerant.
- Cons: In-memory caches usually require low-latency, highly available infrastructure, and preemptible VMs could introduce instability if the workload is disrupted too often.
- Use Case: This could be a suitable use case for preemptible VMs if the system can gracefully handle VM termination and quickly recover by reloading data or rebuilding caches.
Option B: The organization's public-facing website
- Pros: Websites typically need high availability and reliability, especially for public-facing services. Preemptible VMs are not suitable for this kind of use case due to their unpredictability—Google Cloud may terminate them at any time.
- Cons: Public-facing websites require consistent uptime, and preemptible VMs would lead to service outages or poor user experience due to sudden VM termination.
- Use Case: This is not an appropriate use case for preemptible VMs because reliability and availability are key for public-facing services.
Option C: A distributed, eventually consistent NoSQL database cluster with sufficient quorum
- Pros: Eventually consistent systems can h...
