60 free Google Professional Cloud DevOps Engineer practice questions from the CertStash pack of 239, each with the correct answer and a full explanation. The rule is the same for every exam: ten free on the product page, 60 free here, all 239 in the pack, and each step includes the one before it.
Get all 239 questions (US$39) · Download the first 10 as a PDF
Question 1
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 which dependent applications might cause performance issues. What should you do?
Show answer and explanation
Correct answer: B. Instrument all applications with Stackdriver Trace and review inter-service HTTP requests.
Stackdriver Trace is a distributed tracing system that records how long each request spends in every service it touches. When all applications are instrumented, the outbound HTTP calls from the Node.js application show up as spans inside a trace, so you can review the latency of each inter-service request and see which dependent applications contribute the most delay. Trace also produces latency reports and can flag changes in latency over time, which lets you spot a degrading dependency before it becomes an outage. This gives cross-service visibility with standard instrumentation rather than hand-built measurement code.
Why the other options are wrong
- A. Stackdriver Profiler samples CPU and heap usage inside a single application to find expensive code paths; it does not measure the latency of HTTP calls between services.
- C. Stackdriver Debugger captures snapshots of variables and call stacks in running code; it is a debugging aid, not a way to measure dependency latency.
- D. Custom logging of timings requires code changes and manual log analysis, and it rebuilds poorly what Stackdriver Trace already provides for inter-service requests.
Question 2
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 want to ensure you follow the principle of LEAST privilege. What should you do?
Show answer and explanation
Correct answer: C. Click "Share chart by URL" and provide the URL to the SRE team. Assign the SRE team the Monitoring Viewer IAM role in the workspace project.
The "Share chart by URL" option produces a link that opens exactly the chart in question, so the SRE team is pointed at that one chart rather than being handed a whole project to browse. To render the chart, the viewer must be able to read the underlying metric data. Monitoring Viewer (roles/monitoring.viewer) is the read-only Monitoring role that includes monitoring.timeSeries.list, so it lets the team see the CPU utilization data without any ability to change dashboards, alerting policies or other configuration. A chart link combined with the read-only Monitoring Viewer role is the narrowest grant that still lets the team see the chart.
Why the other options are wrong
- A. Handing over the project ID only tells the team where to look; it does not direct them to the specific chart that needs to be shared.
- B. Sharing the project ID does not point the team at the chart, and the dashboard configuration viewer role cannot read the time series data the chart plots.
- D. The dashboard configuration viewer role only grants read access to dashboard definitions, without monitoring.timeSeries.list, so the shared chart could not display its CPU data.
Question 3
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 formal explanation of what happened so they can action remediations. What should you do?
Show answer and explanation
Correct answer: 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.
SRE practice calls for a blameless postmortem: a written record of what happened, its root causes, how it was resolved, what was learned, and a prioritized set of action items to prevent recurrence. The focus is on systems and processes, not on individuals, so people can describe events honestly without fear of punishment. Google's SRE guidance also stresses sharing postmortems as widely as possible, because other teams can learn from the incident and spot similar risks in their own services. Publishing it on the engineering organization's document portal satisfies the manager's request while also building a shared culture of learning.
Why the other options are wrong
- A. The content is appropriate, but sharing it with one manager only limits organizational learning, which SRE postmortem culture explicitly tries to spread.
- C. Listing responsible people and assigning actions per person turns the postmortem into a blame exercise, and restricting it to one manager also limits learning.
- D. Wide sharing is good, but naming responsible individuals breaks the blameless principle and discourages honest reporting in future incidents.
Question 4
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 application writes its log information to /var/log/app_messages.log, and you want to send these log entries to Stackdriver Logging. What should you do?
Show answer and explanation
Correct answer: D. Write a script to tail the log file within the pod and write entries to standard output. Run the script as a sidecar container with the application's pod. Configure a shared volume between the containers to allow the script to have read access to /var/log in the application container.
The Stackdriver Kubernetes Engine Monitoring logging agent collects what containers write to standard output and standard error, so a log written only to a file inside the container is not picked up by default. Because the third-party application cannot be modified, the practical fix is the Kubernetes streaming sidecar pattern: mount a shared volume at /var/log in both containers, and run a small sidecar that tails /var/log/app_messages.log and writes each line to its own standard output. The existing GKE logging agent then ships those lines to Stackdriver Logging with no change to the application and no new cluster-wide logging stack.
Why the other options are wrong
- A. The default agent configuration reads container standard output and standard error, not arbitrary files inside a container, so these entries would never reach Stackdriver Logging.
- B. A separate Fluentd daemonset runs at node level and duplicates the managed agent, adding significant configuration while still lacking straightforward access to a file inside the application container.
- C. Rebuilding the platform as self-managed Kubernetes on Compute Engine is a large, costly migration for what is a per-pod logging problem.
Question 5
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 logs. You notice that syslog is not showing up in the "All logs" dropdown list of the Logs Viewer. What is the first thing you should do?
Show answer and explanation
Correct answer: D. SSH to the VM and execute the following commands on your VM: ps ax | grep fluentd.
The Stackdriver Logging agent is built on Fluentd, and on the VM it runs as the google-fluentd process that reads syslog and sends entries to the Logging API. When a log that should be collected does not appear at all, the first check is whether that process is running. Connecting to the VM over SSH and running ps ax | grep fluentd answers this immediately. The instance already has the cloud-platform scope, which covers writing logs, so a stopped or crashed agent is the most likely cause. Only once the process is confirmed running does it make sense to look at agent configuration, versions or test entries.
Why the other options are wrong
- A. The test log entry is written when the agent starts successfully, so looking for it does not show whether the agent is running right now.
- B. Reinstalling or upgrading the agent is a later remedy; first confirm whether the existing agent process is running at all.
- C. The cloud-platform scope already covers all Google Cloud APIs, and monitoring.write relates to Monitoring metrics rather than writing syslog entries to Logging.
Question 6
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 an HTTP POST of the build information to a webhook. You want to minimize the development effort. What should you do?
Show answer and explanation
Correct answer: B. Add a new step at the end of the pipeline in Cloud Build to HTTP POST the build information to a webhook.
A Cloud Build pipeline is a sequence of steps, and each step runs a container image with whatever command you specify. Adding one final step that runs a small HTTP client such as curl lets you POST exactly the build information the monitoring platform expects, using built-in substitutions such as $BUILD_ID, $PROJECT_ID and $COMMIT_SHA. Because steps run in order by default, a final step runs only after the build and deploy steps have succeeded. This change is a few lines in the existing build config and needs no extra services, subscriptions or code, which keeps development effort to a minimum.
Why the other options are wrong
- A. Adding HTTP logic to every step duplicates the same work across the pipeline and sends many partial updates instead of one report of the build.
- C. A logs-based metric only produces counts or distributions, and an alert webhook sends incident notifications about the metric rather than the build information itself.
- D. By default, a push subscription delivers each build status change wrapped in the Pub/Sub JSON envelope with base64-encoded data, and even with payload unwrapping it carries Cloud Build's own message format, so the webhook does not receive the payload it expects without extra adaptation.
Question 7
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 the canary version against the production version. How should you configure the canary analysis?
Show answer and explanation
Correct answer: A. Compare the canary with a new deployment of the current production version.
Automated canary analysis compares metrics from the canary against a baseline, and the comparison is only fair if the two differ in nothing but the code being tested. An existing production deployment has been running for a long time, so its in-memory cache is already warm and its behavior reflects that long uptime, while the new canary starts cold and loads objects at startup. Deploying a fresh copy of the current production version at the same time as the canary gives a baseline with the same startup and cache state, so any metric difference can be attributed to the new release rather than to process age.
Why the other options are wrong
- B. The previous production version is not what the canary replaces, so differences would mix in older changes and fail to isolate the new release.
- C. The long-running production deployment has a warm cache and different runtime state, so it would bias the comparison against the freshly started canary.
- D. A sliding average of past versions does not represent the current release being replaced and does not control for the canary's cold-cache startup.
Question 8
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 acceptable page load time set to 100 ms. What is the Google-recommended way of calculating this SLI?
Show answer and explanation
Correct answer: C. Count the number of home page requests that load in under 100 ms, and then divide by the total number of home page requests.
Google's SRE guidance recommends expressing an SLI as the ratio of good events to valid events, giving a value between 0 and 100 percent. For a home page latency SLI with a 100 ms threshold, a good event is a home page request that loads in under 100 ms and a valid event is any home page request. Dividing the first count by the second gives the proportion of home page loads that met the target, which is easy to compare against an SLO and to turn into an error budget. Keeping the numerator and denominator scoped to the same request type keeps the indicator meaningful.
Why the other options are wrong
- A. Computing a percentile at the threshold is not the recommended good-over-valid ratio and is harder to tie directly to an SLO target.
- B. The median and 90th percentile describe the latency distribution but say nothing directly about how many requests met the 100 ms threshold.
- D. Dividing by all web application requests mixes in traffic that is not home page traffic, so the ratio no longer measures home page latency.
Question 9
You deploy a new release of an internal application during a weekend maintenance window when there is minimal user traffic. 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 modify your release process to reduce the mean time to recovery so you can avoid extended outages in the future. What should you do? (Choose two.)
Show answer and explanation
Correct answer: B, E. Adopt the blue/green deployment strategy when releasing new code via a CD server; Configure a CI server. Add a suite of unit tests to your code and have your CI server run them on commit and verify any changes.
Mean time to recovery shrinks when a bad release can be detected quickly and undone or fixed quickly. A blue/green deployment through a CD server keeps the previous version running in a parallel environment, so recovery is a traffic switch back to the known good environment rather than a lengthy redeployment. A CI server that runs a unit test suite on every commit gives fast, automated verification of changes, so a fix can be validated and shipped through the pipeline quickly and with confidence. Together they turn an extended outage into a short, controlled recovery.
Why the other options are wrong
- A. Requiring two peer reviewers may catch some defects earlier, but it slows changes and does nothing to speed recovery once a problem reaches production.
- C. Linting enforces coding standards and style; it is not a recovery mechanism and does not shorten the time to restore service.
- D. Tests run manually on developers' local machines are inconsistent and unenforced, and they do not provide a faster path to recover in production.
Question 10
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 application logs for troubleshooting. How would you implement the solution on GCP?
Show answer and explanation
Correct answer: A. Deploy the Stackdriver logging agent to the application servers. Give the developers the IAM Logs Viewer role to access Stackdriver and view logs.
Installing the Stackdriver logging agent on the Compute Engine servers sends application logs to Stackdriver Logging, where developers can search and filter them in one place without any custom shipping scripts. Granting the Logs Viewer role (roles/logging.viewer) gives read access to those logs and is the narrowest predefined role that meets the need, which keeps the solution secure. It is also the least configuration: an agent install plus one IAM binding, with no buckets, cron jobs or custom tooling to maintain.
Why the other options are wrong
- B. Private Logs Viewer includes everything in Logs Viewer plus access to Data Access audit logs, granting more permissions than developers need and violating least privilege.
- C. The monitoring agent and Monitoring Viewer role cover metrics, not application log contents, so developers still could not read the logs.
- D. A gsutil cron upload requires custom scripting and maintenance, introduces delay, and gives developers raw files instead of searchable logs.
What people say about the full Professional Cloud DevOps Engineer pack 5.0 from 2
This is my best choice. Thank you for the dump Google Cloud Certified - Professional Cloud DevOps Engineer Exam
Your Google Cloud Certified - Professional Cloud DevOps Engineer Exam dumps are still valid.
Question 11
You support a popular mobile game application deployed on Google Kubernetes Engine (GKE) across several Google Cloud regions. Each region has multiple Kubernetes clusters. You receive a report that none of the users in a specific region can connect to the application. You want to resolve the incident while following Site Reliability Engineering practices. What should you do first?
Show answer and explanation
Correct answer: A. Reroute the user traffic from the affected region to other regions that don't report issues.
SRE incident response puts mitigation ahead of diagnosis: the first goal is to stop users from being affected. Because the application runs in several healthy regions, rerouting traffic away from the failing region to regions that are not reporting issues restores service for the affected users quickly. Once users can connect again, the team can investigate the failing region's clusters through monitoring and logs without time pressure, find the root cause, and return traffic when the region is healthy.
Why the other options are wrong
- B. Checking CPU and memory metrics is a diagnostic step that leaves users unable to connect while you investigate.
- C. Adding a larger node pool assumes a resource shortage that has not been confirmed and does not quickly restore connectivity.
- D. Inspecting logs helps find the root cause, but it should follow mitigating the user impact, not precede it.
Question 12
You need to build a CI/CD pipeline for a containerized application in Google Cloud. Your development team uses a central Git repository for trunk-based development. You want to run all your tests in the pipeline for any new versions of the application to improve the quality. What should you do?
Show answer and explanation
Correct answer: D. 1. Trigger Cloud Build to run unit tests when the code is pushed. If all unit tests are successful, build and push the application container to a central registry. 2. Trigger Cloud Build to deploy the container to a testing environment, and run integration tests and acceptance tests. 3. If all tests are successful, the pipeline deploys the application to the production environment and runs smoke tests.
In a trunk-based workflow every push to the central repository should trigger an automated pipeline. Cloud Build runs the unit tests first, and only if they pass does it build the container and push it to a central registry, so a single immutable artifact moves through every stage. That same artifact is deployed to a testing environment where integration and acceptance tests run, and only after all tests pass is it promoted to production, followed by smoke tests that confirm the release is healthy. Every test runs in the pipeline, and all functional tests pass before production.
Why the other options are wrong
- A. Unit tests depend on developer-side Git hooks rather than the pipeline, and acceptance tests run only after code is already in production.
- B. Unit tests and the build happen on developer machines, and rebuilding the container for production means the deployed artifact is not the one that was tested.
- C. Acceptance tests run only after deployment to production, so defects they would catch already affect users.
Question 13
You are building the CI/CD pipeline for an application deployed to Google Kubernetes Engine (GKE). The application is deployed by using a Kubernetes Deployment, Service, and Ingress. The application team asked you to deploy the application by using the blue/green deployment methodology. You need to implement the rollback actions. What should you do?
Show answer and explanation
Correct answer: C. Update the Kubernetes Service to point to the previous Kubernetes Deployment.
In a blue/green deployment the old and new versions run as separate Deployments, and the Service selector decides which one receives traffic through the Ingress. To roll back, you update the Service selector so it points to the previous Deployment again. The switch is immediate, the old version is already running and warmed up, and the new Deployment can be kept for investigation or removed later. This is the defining advantage of blue/green: rollback is a traffic switch rather than a redeployment.
Why the other options are wrong
- A. Rollout undo reverts a single Deployment to an earlier revision, which is a rolling-update rollback rather than switching between blue and green Deployments.
- B. Deleting the image and Pods does not route traffic to the old version, and the Deployment would just try to recreate the Pods.
- D. Scaling the new Deployment to zero leaves the Service pointing at no Pods, causing an outage instead of a rollback.
Question 14
Your application's performance in Google Cloud has degraded since the last release. You suspect that downstream dependencies might be causing some requests to take longer to complete. You need to investigate the issue with your application to determine the cause. What should you do?
Show answer and explanation
Correct answer: D. Configure Cloud Trace in your application.
Cloud Trace is a distributed tracing system that records how long each request takes and breaks it into spans for each call the application makes, including calls to downstream services. By instrumenting the application and comparing traces from before and after the release, you can see exactly which dependency is adding latency to slow requests. Cloud Trace also produces latency reports that highlight changes over time. This directly tests the suspicion that downstream dependencies are responsible for the degraded performance.
Why the other options are wrong
- A. Error Reporting groups and counts application errors and crashes; it does not measure how long downstream calls take.
- B. Managed Service for Prometheus collects metrics that can show overall latency rising, but it does not follow individual requests across downstream calls.
- C. Cloud Profiler shows CPU and memory use by function inside the code, not the time requests spend waiting on downstream services.
Question 15
Your organization recently adopted a container-based workflow for application development. Your team develops numerous applications that are deployed continuously through an automated build pipeline to the production environment. A recent security audit alerted your team that the code pushed to production could contain vulnerabilities and that the existing tooling around virtual machine (VM) vulnerabilities no longer applies to the containerized environment. You need to ensure the security and patch level of all code running through the pipeline. What should you do?
Show answer and explanation
Correct answer: A. Set up Container Analysis to scan and report Common Vulnerabilities and Exposures.
Container Analysis provides vulnerability scanning for container images stored in Google Cloud registries. When images are pushed, it scans their operating system packages and supported language packages against known Common Vulnerabilities and Exposures (CVEs) and records the findings as metadata attached to each image. Because every image produced by the automated pipeline is scanned, the team gets consistent visibility into the security and patch level of all code heading to production, and the results can be used to block or fix vulnerable images. This replaces VM-oriented vulnerability tooling with a service designed for container artifacts.
Why the other options are wrong
- B. Containers that update themselves at release time become unpredictable and are never inspected, so vulnerabilities are neither detected nor reported.
- C. Placing VM vulnerability software inside each container bloats the images and still does not scan the built images systematically in the pipeline.
- D. Static analysis of Dockerfiles checks build instructions but does not inspect the packages present in the resulting image for known CVEs.
Question 16
Your organization recently adopted a container-based workflow for application development. Your team develops numerous applications that are deployed continuously through an automated build pipeline to a Kubernetes cluster in the production environment. The security auditor is concerned that developers or operators could circumvent automated testing and push code changes to production without approval. What should you do to enforce approvals?
Show answer and explanation
Correct answer: D. Enable binary authorization inside the Kubernetes cluster and configure the build pipeline as an attestor.
Binary Authorization is a Google Cloud service that enforces deploy-time policy on GKE clusters. When the policy requires attestations, the cluster admits only container images that a trusted attestor has signed. Configuring the automated build pipeline as the attestor means it creates an attestation only after an image has passed testing and the required approval. Any image pushed by a developer or operator outside that pipeline has no valid attestation, so the cluster rejects it at deployment time and the approval process cannot be bypassed.
Why the other options are wrong
- A. Protected branches govern merges into the repository, but someone could still build an image elsewhere and deploy it directly to the cluster.
- B. A generic admission controller would need custom logic to decide which origins are approved and gives no verifiable proof that an image passed testing and approval.
- C. RBAC limits who can act on the cluster, but an authorized user could still deploy an untested, unapproved image.
Question 17
You use Cloud Build to build your application. You want to reduce the build time while minimizing cost and development effort. What should you do?
Show answer and explanation
Correct answer: A. Use Cloud Storage to cache intermediate artifacts.
Cloud Build's own guidance on speeding up builds recommends reusing results from earlier builds by caching directories in Cloud Storage. A build step copies the cached artifacts, such as downloaded dependencies or compiled outputs, from a bucket at the start of the build, and a later step copies the updated results back. Subsequent builds skip work that has already been done, so they finish sooner and use fewer build minutes. The change is only a pair of copy steps in the existing build config and Cloud Storage costs little, which meets the cost and effort constraints.
Why the other options are wrong
- B. Jenkins agents are separate infrastructure that must be set up, run and paid for, which raises both cost and effort.
- C. Splitting work into more steps does not remove any of it, and each extra step starts its own container.
- D. Larger build machine types cost more per build minute, so they cut time by spending more instead of avoiding repeated work.
Question 18
You support a trading application written in Python and hosted on App Engine flexible environment. You want to customize the error information being sent to Stackdriver Error Reporting. What should you do?
Show answer and explanation
Correct answer: D. Use the Stackdriver Error Reporting API to write errors from your application to ReportedErrorEvent, and then generate log entries with properly formatted error messages in Stackdriver Logging.
Error Reporting accepts errors in two documented ways: log entries that contain a stack trace or a ReportedErrorEvent payload, or calls to the Error Reporting API report method with a ReportedErrorEvent request body. A ReportedErrorEvent lets the application decide exactly what is reported: the message, eventTime, serviceContext with service and version, and context fields such as httpRequest, user and reportLocation. When the API is used, Error Reporting writes matching log entries to Logging, so the customized errors appear both in Error Reporting and in the logs. Building these events directly is how the trading application controls the error information.
Why the other options are wrong
- A. Moving the application to a Compute Engine VM changes the hosting platform without customizing any of the error information that is reported.
- B. Moving the application to Google Kubernetes Engine changes the hosting platform without customizing any of the error information that is reported.
- C. Installing the library in the current environment does not by itself customize any error information; the stem requires controlling the error fields, which ReportedErrorEvent provides.
Question 19
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 Percentage The chat feature requires a new database system that takes twice as long to successfully fail over between zones. You want to account for the risk of the new database failing in one zone. What would be the values for the risk of database failover with the new system?
Show answer and explanation
Correct answer: B. MTTD: 5 MTTR: 20 MTBF: 90 Impact: 33%
Each value follows from the scenario. Detection does not change, so MTTD stays at 5 minutes. The current zone failover causes a 10-minute disruption, and the new database takes twice as long to fail over, so MTTR becomes 20 minutes. Database failures happen about once per quarter, giving an MTBF of roughly 90 days. Users are divided among three zones, so a failure in one zone affects about one third of them, or 33%. These are the inputs needed to estimate the expected minutes of user impact this risk will cost against the error budget.
Why the other options are wrong
- A. An MTTR of 10 minutes reflects the existing failover time and ignores that the new database takes twice as long to fail over.
- C. This keeps the old 10-minute repair time and overstates impact, since one of three zones affects about a third of users, not half.
- D. The 20-minute MTTR is right, but 50% impact does not match a single zone failing when users are split across three zones.
Question 20
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 need to redesign the environment to reduce the number of bugs and outages in production and to enable testers to load test new features. What should you do?
Show answer and explanation
Correct answer: D. Create a development environment for writing code and a test environment for configurations, experiments, and load testing.
Outages and slowness occur because development, configuration changes, experiments and load tests all run against production. Separating these activities fixes the cause: a development environment where developers write code and fix bugs, and a test environment where configurations and experiments can be tried and testers can run load tests without affecting real users. Changes are validated in these environments before being promoted, so fewer bugs reach production, and production capacity is reserved for customers. This is the standard dev, test and prod separation that supports safe, frequent releases.
Why the other options are wrong
- A. Automated tests in production only detect failures after users are hit; they do not stop development and load testing from disrupting production.
- B. A single small development environment cannot host realistic load tests and does not separate configuration experiments from coding work.
- C. Locking production and allowing one update per year halts delivery of features and fixes, and gives testers nowhere to load test.
Question 21
You have an application that runs in Google Kubernetes Engine (GKE). The application consists of several microservices that are deployed to GKE by using Deployments and Services. One of the microservices is experiencing an issue where a Pod returns 403 errors after the Pod has been running for more than five hours. Your development team is working on a solution, but the issue will not be resolved for a month. You need to ensure continued operations until the microservice is fixed. You want to follow Google-recommended practices and use the fewest number of steps. What should you do?
Show answer and explanation
Correct answer: B. Add an HTTP liveness probe to the microservice's deployment.
A liveness probe lets the kubelet check whether a container is still healthy and restart it when the check fails. An HTTP probe treats any status code from 200 to 399 as success, so once the Pod starts returning 403 errors the probe fails and the container is restarted automatically, restoring normal behavior. This is a single change to the Deployment's Pod template, uses built-in Kubernetes self-healing as recommended, and keeps the microservice running reliably until the development team ships a fix.
Why the other options are wrong
- A. A custom cron job that kills Pods by age is extra tooling to maintain and restarts healthy Pods as well as failing ones.
- C. Manually watching and terminating Pods is toil and depends on someone acting quickly every time.
- D. An alert only notifies you of the problem; it does not keep the service working without manual action.
Question 22
You are creating a CI/CD pipeline to perform Terraform deployments of Google Cloud resources. Your CI/CD tooling is running in Google Kubernetes Engine (GKE) and uses an ephemeral Pod for each pipeline run. You must ensure that the pipelines that run in the Pods have the appropriate Identity and Access Management (IAM) permissions to perform the Terraform deployments. You want to follow Google-recommended practices for identity management. What should you do? (Choose two.)
Show answer and explanation
Correct answer: A, C. Create a new Kubernetes service account, and assign the service account to the Pods. Use Workload Identity to authenticate as the Google service account; Create a new Google service account, and assign the appropriate IAM permissions.
Google recommends keyless authentication for workloads on Google Kubernetes Engine. A dedicated Google service account is created and granted only the IAM roles that the Terraform deployments need. A Kubernetes service account is then assigned to the pipeline Pods and linked to the Google service account through Workload Identity, so each ephemeral Pod automatically receives short-lived credentials for that identity. No long-lived keys are created, stored or rotated, and the permissions apply only to the pipeline Pods rather than to everything on the node.
Why the other options are wrong
- B. Exported JSON keys are long-lived credentials that can leak; storing one in a Kubernetes secret is the practice Workload Identity is designed to replace.
- D. Keeping a JSON key in the CI/CD tool's secret store still relies on a long-lived exported key that must be protected and rotated.
- E. Granting roles to the node's service account gives those permissions to every Pod on those nodes, violating least privilege.
Question 23
Your team deploys applications to three Google Kubernetes Engine (GKE) environments: development, staging, and production. You use GitHub repositories as your source of truth. You need to ensure that the three environments are consistent. You want to follow Google-recommended practices to enforce and install network policies and a logging DaemonSet on all the GKE clusters in those environments. What should you do?
Show answer and explanation
Correct answer: C. Use Cloud Build to render and deploy the network policies and the DaemonSet. Set up Config Sync to sync the configurations for the three environments.
Config Sync is Google's GitOps service for keeping Kubernetes configuration consistent across clusters. It syncs configs and policies, such as NetworkPolicies and DaemonSets, from a Git repository to every enrolled cluster and continuously reconciles each cluster back to the repository, correcting drift automatically. Cloud Build can render the network policies and the logging DaemonSet manifests for each environment, and Config Sync then applies and maintains them on the development, staging and production clusters. The GitHub repositories remain the authoritative definition and all three environments stay aligned.
Why the other options are wrong
- A. Cloud Deploy rolls releases through a promotion sequence and does not continuously reconcile clusters, and Cloud Monitoring has no built-in comparison against a Git repository.
- B. Policy Controller only accepts or rejects resources against constraints, and Monitoring plus Cloud Functions for drift correction is custom work Config Sync already does.
- D. Policy Controller audits and enforces constraints as guardrails; it cannot install the DaemonSet or keep configurations synced across environments.
Question 24
Your company is using HTTPS requests to trigger a public Cloud Run-hosted service accessible at the https://booking-engine-abcdef.a.run.app URL. You need to give developers the ability to test the latest revisions of the service before the service is exposed to customers. What should you do?
Show answer and explanation
Correct answer: A. Run the gcloud run deploy booking-engine --no-traffic --tag dev command. Use the https://dev---booking-engine-abcdef.a.run.app URL for testing.
Deploying with the no-traffic flag creates a new revision without sending any production traffic to it, so customers keep using the current revision. Adding a tag gives that revision its own dedicated URL, formed by prefixing the tag and three hyphens to the service URL, here https://dev---booking-engine-abcdef.a.run.app. Developers can test the latest revision at that address, and when it is ready, traffic can be migrated to it. This is the documented Cloud Run pattern for testing a revision before exposing it to users.
Why the other options are wrong
- B. Sending all traffic to the latest revision exposes it to customers immediately, which is exactly what must be avoided.
- C. An identity token authenticates requests to the main URL, but that URL still serves the production revision to everyone, so the new revision is not isolated.
- D. The invoker role controls who may call the service; it does not create a separate URL for an untested revision, and that private URL format does not exist.
Question 25
You support a service that recently had an outage. The outage was caused by a new release that exhausted the service memory resources. You rolled back the release successfully to mitigate the impact on users. You are now in charge of the postmortem for the outage. You want to follow Site Reliability Engineering practices when developing the postmortem. What should you do?
Show answer and explanation
Correct answer: B. Focus on identifying the contributing causes of the incident rather than the individual responsible for the cause.
Site Reliability Engineering postmortems are blameless: they assume everyone acted with good intentions based on the information they had, and they look for the contributing causes in systems and processes. For a release that exhausted memory, that means asking why testing, load validation, resource limits or release checks did not catch the problem, and producing action items that fix those gaps. Because people are not punished for honest mistakes, engineers share full details, which yields a more accurate analysis and makes a repeat of the outage less likely.
Why the other options are wrong
- A. A postmortem exists to prevent recurrence; ignoring the causes in favor of feature work leaves the same failure free to happen again.
- C. Hunting for who approved and pushed the release turns the review into a search for someone to blame, which discourages candor.
- D. Barring the engineer who wrote the commit is punitive and ignores the systemic gaps that let a faulty change reach production.
Question 26
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 relevant stakeholders following the Site Reliability Engineering recommended practices. What should you do first?
Show answer and explanation
Correct answer: B. Develop a postmortem to be distributed to stakeholders.
Once service is restored, SRE practice is to write a postmortem: a formal, blameless account of the impact, timeline, root causes, resolution, lessons learned and action items. It is the recommended vehicle for summarizing a significant incident to stakeholders because it gives everyone the same accurate, reviewed record and commits the organization to concrete follow-up work. An outage that affected all users for several hours clearly meets the usual criteria for writing one. Developing the postmortem first ensures that later communication is consistent and based on analysis rather than recollection.
Why the other options are wrong
- A. Individual phone calls produce inconsistent, undocumented accounts and do not capture root causes or follow-up actions.
- C. The incident state document is a working record used during the response; it is not the reviewed analysis stakeholders should receive.
- D. Singling out one engineer for an apology assigns blame, which contradicts the blameless culture SRE postmortems depend on.
Question 27
You have an application running in Google Kubernetes Engine. The application invokes multiple services per request but responds too slowly. You need to identify which downstream service or services are causing the delay. What should you do?
Show answer and explanation
Correct answer: D. Use a distributed tracing framework such as OpenTelemetry or Stackdriver Trace.
Distributed tracing follows a single request as it passes through every service it calls. Each call is recorded as a span with its start time and duration, and the spans are linked into one trace, so you can see how much of the total response time each downstream service contributes. Instrumenting the services with OpenTelemetry and viewing the traces in Stackdriver Trace shows latency per request and per service, which directly identifies the service or services causing the delay, without building custom analysis infrastructure.
Why the other options are wrong
- A. VPC flow logs record network flows between endpoints, not how long each service takes to process its part of a request.
- B. Liveness and readiness probes tell Kubernetes whether containers are running and ready for traffic; they do not measure per-request latency across services.
- C. Building a Dataflow pipeline requires significant custom work, and aggregate metrics cannot follow an individual request across services the way traces do.
Question 28
You are working with a government agency that requires you to archive application logs for seven years. You need to configure Stackdriver to export and store the logs while minimizing costs of storage. What should you do?
Show answer and explanation
Correct answer: D. Create a sink in Stackdriver, name it, create a bucket on Cloud Storage for storing archived logs, and then select the bucket as the log export destination.
A Stackdriver Logging sink routes matching log entries to a supported destination without writing any code. Creating a sink, creating a Cloud Storage bucket for archived logs, and choosing that bucket as the destination exports the logs automatically to object storage, which is the lowest-cost place to keep data for years. The bucket can use a cold storage class or lifecycle rules to reduce costs further, and a retention policy can enforce the seven-year requirement. This uses built-in features rather than custom applications or messaging services.
Why the other options are wrong
- A. Changing the application to write logs straight to a bucket requires custom development and bypasses Stackdriver's collection and routing.
- B. A custom App Engine application adds code to build and run, and BigQuery storage costs more than Cloud Storage for long-term archives.
- C. Pub/Sub is a messaging service that holds messages only briefly; it is not a permanent store for seven years of logs.
Question 29
You are managing an application that runs in Compute Engine. The application uses a custom HTTP server to expose an API that is accessed by other applications through an internal TCP/UDP load balancer. A firewall rule allows access to the API port from 0.0.0.0/0. You need to configure Cloud Logging to log each IP address that accesses the API by using the fewest number of steps. What should you do first?
Show answer and explanation
Correct answer: C. Enable logging on the firewall rule.
Firewall Rules Logging records a log entry in Cloud Logging for each connection that a rule allows or denies, including the source and destination IP addresses and ports. An internal passthrough TCP/UDP load balancer preserves the client's source IP address, so the existing rule that allows the API port already sees every caller. Turning on logging for that one rule is a single setting and immediately captures the IP address of each client reaching the API, with no agent installation or application change. That makes it the fewest-step first action.
Why the other options are wrong
- A. Packet Mirroring clones full packet traffic to a collector for deep inspection; it does not write caller IP addresses to Cloud Logging and needs extra infrastructure.
- B. The Ops Agent collects system and application logs, but the custom HTTP server would also need configuration to log client IPs, adding steps.
- D. VPC Flow Logs sample traffic for the whole subnet, so they may miss connections and capture far more than the API traffic.
Question 30
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 the costs for this workload without any performance implications. What should you do?
Show answer and explanation
Correct answer: A. Purchase Committed Use Discounts.
Committed use discounts lower Compute Engine prices in exchange for committing to a set amount of vCPU and memory for a one-year or three-year term. They are a billing change only: the instances keep the same machine resources and run exactly as before, so there is no performance impact. A stable, business-critical workload on a fixed set of instances with a known, exact resource footprint is the use case these discounts are designed for, and none of the other choices reduce cost without adding risk.
Why the other options are wrong
- B. A managed instance group adds autoscaling and autohealing, but on its own it does not lower the price of a fixed set of instances.
- C. Preemptible VMs are cheaper but can be stopped at any time and run at most 24 hours, which is unacceptable for a business-critical workload.
- D. An unmanaged instance group is only a grouping for load balancing and management; it does not change what the instances cost.
Question 31
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 show increased latency. You want to quickly minimize the negative impact on users. What should you do first?
Show answer and explanation
Correct answer: A. Roll back the experimental canary release.
The spike in 500 errors and latency appeared right after the canary went out, so the canary is the clear suspect, and SRE practice puts mitigation ahead of diagnosis. Rolling back the experimental canary release removes the faulty change and quickly restores the previous, known good behavior for the affected users. Limiting the blast radius in this way is the whole purpose of a canary. Once users are protected, the team can investigate the errors calmly and record what happened for the postmortem.
Why the other options are wrong
- B. Monitoring of the golden signals is already reporting the problem; starting it now adds nothing to stop users seeing errors.
- C. Recording postmortem data matters, but it does not reduce user impact and should not come before mitigation.
- D. Root cause analysis while users are still failing prolongs the impact; rolling back first stops the harm, then investigation can follow.
Question 32
You support a service with a well-defined Service Level Objective (SLO). Over the previous 6 months, your service has consistently met its SLO and customer satisfaction has been consistently high. Most of your service's operations tasks are automated and few repetitive tasks occur frequently. You want to optimize the balance between reliability and deployment velocity while following site reliability engineering best practices. What should you do? (Choose two.)
Show answer and explanation
Correct answer: B, C. Increase the service's deployment velocity and/or risk; Shift engineering time to other services that need more reliability.
A service that consistently meets its SLO, keeps customers happy and has little toil is leaving error budget unspent. Site Reliability Engineering practice is to use that budget: increasing deployment velocity or accepting riskier changes delivers more value to users while the SLO still protects them. Because this service needs little reliability work, engineering time can also be shifted to other services that are struggling to meet their objectives, where the same effort produces a much larger reliability gain. Together these steps rebalance effort toward where it matters most.
Why the other options are wrong
- A. Customer satisfaction is already high at the current SLO, so a stricter target adds cost and slows releases without a business reason.
- D. Prioritizing reliability over features is the response to an exhausted error budget, not to a service that comfortably meets its SLO.
- E. Reworking SLIs for coverage changes measurement only; it does not shift the balance between deployment velocity and reliability.
Question 33
Your organization has a containerized web application that runs on-premises. As part of the migration plan to Google Cloud, you need to select a deployment strategy and platform that meets the following acceptance criteria: 1. The platform must be able to direct traffic from Android devices to an Android-specific microservice. 2. The platform must allow for arbitrary percentage-based traffic splitting. 3. The deployment strategy must allow for continuous testing of multiple versions of any microservice. What should you do?
Show answer and explanation
Correct answer: D. Deploy the canary release to Google Kubernetes Engine with Anthos Service Mesh. Use traffic splitting to direct 10% of user traffic to the new version based on the user-agent header configured in the virtual service.
Anthos Service Mesh on Google Kubernetes Engine uses Istio traffic management, where a virtual service can match requests on HTTP headers and split traffic by arbitrary weights between versions. A match on the user-agent header sends Android devices to the Android-specific microservice, weighted routes send a chosen percentage such as 10% to a canary, and multiple versions of any microservice can run side by side for continuous testing. This single platform meets all three acceptance criteria for the containerized application.
Why the other options are wrong
- A. Cloud Run splits traffic by percentage between revisions and exposes tagged URLs, but it does not route requests to a service based on the user-agent header.
- B. App Engine splitting by IP address or cookie cannot identify Android devices, so it fails the device-specific routing requirement.
- C. Moving a containerized application onto Compute Engine VMs adds operational burden, and this option routes only by percentage without user-agent matching for Android traffic.
Question 34
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 are using Stackdriver Monitoring for App Engine. What metric should you use?
Show answer and explanation
Correct answer: A. flex/connections/current
Stackdriver Monitoring exposes App Engine flexible environment metrics under the appengine.googleapis.com prefix, and flex/connections/current reports the number of current active connections for an App Engine flexible environment version. Because it is measured at the version level, it captures connections from users worldwide on every device type without needing to add up individual instances. It is therefore the direct way to answer how many connections the application currently has.
Why the other options are wrong
- B. tcp_ssl_proxy/new_connections belongs to TCP and SSL proxy load balancer monitoring and counts newly opened connections, not current App Engine connections.
- C. tcp_ssl_proxy/open_connections is a load balancer metric for TCP and SSL proxies, not a metric reported for App Engine applications.
- D. flex/instance/connections/current reports connections per instance, so it gives a per-instance breakdown rather than the application's overall connection count.
Question 35
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 making any engineering changes to it. What should you do? (Choose two.)
Show answer and explanation
Correct answer: D, E. Create new synthetic clients to simulate a user journey using the application; Use current and historic Request Logs to trace customer interaction with the application.
Both measurements work from outside the application, so no engineering changes are required. Synthetic clients that simulate a user journey exercise the application the way a real user would, step by step, and report whether each step succeeds and how long it takes. Current and historic request logs already record the outcome of every real user request, such as status codes and latency, so analyzing them shows how reliable the service has been from the users' point of view over time. Together they give a forward-looking probe and a record of actual user experience.
Why the other options are wrong
- A. Adding new application metrics requires instrumenting the code, which is an engineering change the stem rules out.
- B. Modifying the code to capture user interactions is explicitly an engineering change.
- C. Using only proxy response times captures latency alone and ignores errors and other failures, so it gives an incomplete view of reliability.
Question 36
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 number of resources for each instance and you need to plan for capacity. What should you do?
Show answer and explanation
Correct answer: C. Validate that the resource requirements are within the available quota limits of each region.
Compute Engine enforces quotas such as CPUs, GPUs, persistent disk and IP addresses per region, and a managed instance group cannot create instances once a regional quota is used up. A service with large instances that must autoscale across several regions therefore has to be planned against the quota available in each target region. Before deployment, compare the expected peak instance count multiplied by the per-instance resource needs with every region's quota limits, and request increases where needed. Without this check, autoscaling can fail in a region exactly when demand peaks.
Why the other options are wrong
- A. Choosing a specific large machine type sets instance size but does not confirm that each region has enough quota for the MIG to scale.
- B. Stackdriver Trace records request latency across services; it does not show the regional resource capacity available to the MIG.
- D. Deploying to a single region contradicts the multi-region requirement and concentrates all capacity and risk in one location.
Question 37
Your organization is using Helm to package containerized applications. Your applications reference both public and private charts. Your security team flagged that using a public Helm repository as a dependency is a risk. You want to manage all charts uniformly, with native access control and VPC Service Controls. What should you do?
Show answer and explanation
Correct answer: A. Store public and private charts in OCI format by using Artifact Registry.
Artifact Registry can store Helm 3 charts as OCI artifacts in Docker-format repositories, so public charts can be copied in alongside private ones and every chart is managed in the same way. Access is controlled with IAM roles on the repository, and Artifact Registry is supported by VPC Service Controls, which limits data exfiltration. Helm clients pull and push charts with standard OCI commands. This removes the dependency on public chart repositories while meeting the requirements for native access control and VPC Service Controls.
Why the other options are wrong
- B. GitHub Enterprise is not a Google Cloud service, so it cannot be protected by VPC Service Controls or Google Cloud IAM.
- C. Syncing a Git repository into a Cloud Storage bucket adds a custom pipeline to maintain and does not provide native chart management.
- D. Running a self-managed chart server on GKE adds operational overhead and lacks the native IAM access control of a managed repository.
Question 38
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 pipeline. You need to resolve the issue following Site Reliability Engineering practices. What should you do?
Show answer and explanation
Correct answer: D. Run a Git compare between the previous and current Cloud Build configuration files to find and fix the bug.
The pipeline stopped producing artifacts right after a change to the Cloud Build YAML configuration, so that change is the most likely cause. SRE troubleshooting starts by asking what changed, and because the configuration is under Git version control, a Git diff between the previous and current versions shows exactly which lines were modified. That narrows the investigation to a small set of edits, making it quick to spot and correct the bug, and the fix can be committed through the same reviewed workflow.
Why the other options are wrong
- A. Disabling the pipeline and building by hand replaces automation with manual toil and does not identify or fix the configuration bug.
- B. Switching the registry changes a second variable without addressing the edit that broke the build.
- C. Error Reporting groups errors from running applications; it does not analyze YAML files stored in Cloud Storage.
Question 39
You support a large service with a well-defined Service Level Objective (SLO). The development team deploys new releases of the service multiple times a week. If a major incident causes the service to miss its SLO, you want the development team to shift its focus from working on features to improving service reliability. What should you do before a major incident occurs?
Show answer and explanation
Correct answer: A. Develop an appropriate error budget policy in cooperation with all service stakeholders.
An error budget policy states in advance what happens when the service consumes its error budget, for example pausing feature releases and dedicating engineering time to reliability work until the service is back within its SLO. Developing it together with all stakeholders, including product and development teams, means everyone has already agreed to the consequences before an incident occurs. When a major incident causes the SLO to be missed, the policy applies automatically, so the shift from features to reliability happens without fresh negotiation under pressure.
Why the other options are wrong
- B. Always putting reliability ahead of features ignores the error budget concept, which balances the two based on actual SLO performance.
- C. Limiting release frequency is an arbitrary rule that slows delivery and does not tie the team's focus to SLO performance.
- D. A pipeline plugin can block releases, but it does not redirect the development team's work toward reliability or reflect a stakeholder agreement.
Question 40
You are implementing a CI/CD pipeline for your application in your company's multi-cloud environment. Your application is deployed by using custom Compute Engine images and the equivalent in other cloud providers. You need to implement a solution that will enable you to build and deploy the images to your current environment and is adaptable to future changes. Which solution stack should you use?
Show answer and explanation
Correct answer: A. Cloud Build with Packer
Packer is an open source tool that builds machine images from a single template and supports many platforms, including Compute Engine and the image formats of other cloud providers. Running Packer as a build step in Cloud Build gives a managed, serverless CI/CD pipeline that can produce custom Compute Engine images today and other providers' images from the same definitions. Because new builders can be added to the Packer template as the environment changes, the stack stays adaptable to future platforms without redesigning the pipeline.
Why the other options are wrong
- B. Google Cloud Deploy delivers releases to GKE, Cloud Run and similar targets; it does not build or deploy virtual machine images across clouds.
- C. GKE runs containers, and Google Cloud Deploy targets Google Cloud runtimes, so neither builds custom VM images for multiple cloud providers.
- D. kpt manages Kubernetes configuration packages; it does not build machine images for Compute Engine or other clouds.
Question 41
You built a serverless application by using Cloud Run and deployed the application to your production environment. You want to identify the resource utilization of the application for cost optimization. What should you do?
Show answer and explanation
Correct answer: C. Use Cloud Monitoring to monitor the container CPU and memory utilization of the application.
Cloud Run automatically sends built-in metrics to Cloud Monitoring, including container CPU utilization, container memory utilization, instance counts and billable instance time. These metrics show how much of the allocated CPU and memory the service uses, which is exactly the information needed to right-size the CPU and memory settings and concurrency for cost optimization. No agent or code change is required, because the metrics are collected for every Cloud Run service by default.
Why the other options are wrong
- A. Cloud Trace measures request latency across services; it does not report container CPU or memory utilization.
- B. The Ops Agent is installed on Compute Engine VMs and cannot run on Cloud Run, and Profiler analyzes code hotspots rather than service utilization.
- D. Logs-based metrics are derived from log entries, which do not contain container utilization data, so they add work without providing the needed metrics.
Question 42
You recently deployed your application in Google Kubernetes Engine (GKE) and now need to release a new version of the application. You need the ability to instantly roll back to the previous version of the application in case there are issues with the new version. Which deployment model should you use?
Show answer and explanation
Correct answer: D. Perform a blue/green deployment, and test your new application after the deployment is complete.
A blue/green deployment runs the new version alongside the existing version as a complete, separate environment. In Google Kubernetes Engine this is typically two Deployments, with a Service whose selector points to one of them. After the new version is deployed and tested, traffic is switched to it, and the previous version stays running. If problems appear, switching the selector back sends all traffic to the old version immediately, without redeploying anything, which provides the instant rollback the release requires.
Why the other options are wrong
- A. A rolling update replaces Pods incrementally, so rolling back means another gradual rollout rather than an instant switch.
- B. A/B testing compares how user groups respond to variants for business decisions; it is not a mechanism for instant rollback.
- C. A canary limits exposure by sending a small share of traffic to the new version, but it is designed for gradual rollout rather than an instant full switch.
Question 43
A third-party application needs to have a service account key to work properly. When you try to export the key from your cloud project, you receive an error: "The organization policy constraint iam.disableServiceAccountKeyCreation is enforced." You need to make the third-party application work while following Google-recommended security practices. What should you do?
Show answer and explanation
Correct answer: D. Add a rule to set the iam.disableServiceAccountKeyCreation policy to off in your project, and create a key.
Organization policies are inherited down the resource hierarchy, and a lower level can override an inherited boolean constraint when it is allowed. Setting iam.disableServiceAccountKeyCreation to not enforced only in the project that hosts the third-party integration creates the narrowest possible exception: key creation becomes possible where it is truly required, while every other project in the organization stays protected. After that, a key can be created for a dedicated service account and given to the application. This follows the principle of least privilege and keeps the organization-wide security control in place.
Why the other options are wrong
- A. There is no default service account key to enable, and downloading keys for default service accounts, which often hold broad roles, is poor security practice.
- B. Removing the constraint at the organization level allows key creation in every project, which weakens security far beyond what one application needs.
- C. Relaxing the policy at the folder affects every project in that folder, and there is no default key to download.
Question 44
You manage an application that is writing logs to Stackdriver Logging. You need to give some team members the ability to export logs. What should you do?
Show answer and explanation
Correct answer: A. Grant the team members the IAM role of logging.configWriter on Cloud IAM.
Exporting logs in Stackdriver Logging is done by creating sinks that route log entries to destinations such as Cloud Storage, BigQuery or Pub/Sub. The Logs Configuration Writer role (roles/logging.configWriter) grants permission to create, update and delete sinks, along with related logging configuration such as logs-based metrics. Granting this predefined role through Cloud IAM to the selected team members gives them exactly the ability to set up log exports, without granting broader administrative rights over the project.
Why the other options are wrong
- B. Access Context Manager defines access levels for perimeters and context-aware access; it does not grant permission to create log sinks.
- C. Permissions to list and get sinks only allow viewing existing exports, not creating new ones.
- D. Organization policies apply constraints to resources and do not grant permissions to particular users.
Question 45
You are building and running client applications in Cloud Run and Cloud Functions. Your client requires that all logs must be available for one year so that the client can import the logs into their logging service. You MUST minimize required code changes. What should you do?
Show answer and explanation
Correct answer: D. Create a logs bucket and logging sink. Set the retention on the logs bucket to 365 days. Configure the logging sink to send logs to the bucket. Give your client access to the bucket to retrieve the logs.
Cloud Run and Cloud Functions already send their logs to Cloud Logging automatically, so no code changes are needed to capture them. Creating a user-defined log bucket with a retention period of 365 days and a sink that routes the logs into it keeps every entry for a full year. Granting the client access to the bucket lets the client read and export the logs into its own logging service whenever needed. The solution uses managed Cloud Logging features only and meets the requirement to minimize code changes.
Why the other options are wrong
- A. Updating every image and function to ship logs to a second destination requires code changes across all services, which the requirement prohibits.
- B. Pub/Sub keeps unacknowledged messages for at most a limited number of days, so it cannot hold logs available for one year.
- C. Writing logs to a file in a storage bucket requires changing every service, and VPC firewall rules do not control access to Cloud Storage.
Question 46
Your company has a Google Cloud resource hierarchy with folders for production, test, and development. Your cyber security team needs to review your company's Google Cloud security posture to accelerate security issue identification and resolution. You need to centralize the logs generated by Google Cloud services from all projects only inside your production folder to allow for alerting and near real-time analysis. What should you do?
Show answer and explanation
Correct answer: D. Create an aggregated log sink associated with the production folder that uses a Cloud Logging bucket as the destination.
An aggregated sink created on the production folder, with child resources included, captures log entries from every project in that folder, including projects added later, and nothing from the test or development folders. Routing those entries to a central Cloud Logging bucket keeps them inside Cloud Logging, where the security team can query them in near real time with Logs Explorer or Log Analytics and create log-based alerts. This centralizes production logs for security review without building or operating any extra processing pipeline.
Why the other options are wrong
- A. Workflows orchestrates service calls and plays no part in log routing; it cannot gather logs from only the production folder's projects.
- B. A Cloud Monitoring scoping project centralizes metrics and dashboards across projects, but it does not route or centralize log entries.
- C. Pub/Sub only delivers log entries to subscribers, so analysis and alerting would need an additional system to be built and operated.
Question 47
You support a stateless web-based API that is deployed on a single Compute Engine instance in the europe-west2-a zone. The Service Level Indicator (SLI) for service availability is below the specified Service Level Objective (SLO). A postmortem has revealed that requests to the API regularly time out. The timeouts are due to the API having a high number of requests and running out of memory. You want to improve service availability. What should you do?
Show answer and explanation
Correct answer: C. Set up additional service instances in other zones and load balance the traffic between all instances
The postmortem shows that one instance cannot handle the request volume and runs out of memory, which causes the timeouts. Because the API is stateless, any instance can serve any request, so the service can scale out. Running additional instances in other zones behind a load balancer spreads the traffic so that no single instance is overloaded, which addresses the memory exhaustion, and it also removes the single-zone, single-instance point of failure. Both effects raise the availability SLI back toward the SLO.
Why the other options are wrong
- A. Lowering the SLO to match current performance hides the reliability problem instead of fixing it for users.
- B. A larger machine adds memory but still leaves one instance in one zone as a single point of failure, with capacity bounded by that machine.
- D. Failover instances sit idle while the primary still handles all traffic, so it keeps running out of memory under load.
Question 48
You are running a real-time gaming application on Compute Engine that has a production and testing environment. Each environment has their own Virtual Private Cloud (VPC) network. The application frontend and backend servers are located on different subnets in the environment's VPC. You suspect there is a malicious process communicating intermittently in your production frontend servers. You want to ensure that network traffic is captured for analysis. What should you do?
Show answer and explanation
Correct answer: B. Enable VPC Flow Logs on the production VPC network frontend and backend subnets only with a sample volume scale of 1.0.
VPC Flow Logs are enabled per subnet and record network flows to and from the VM instances in that subnet. The suspicious process is on the production frontend servers, so enabling flow logs on the production frontend and backend subnets captures the traffic of interest, including any flows between the tiers. The sample rate controls the fraction of generated log entries that are kept: 1.0 keeps all of them, while 0.5 discards half. Because the malicious communication is intermittent, keeping every record gives the best chance of capturing it for analysis.
Why the other options are wrong
- A. A sample rate of 0.5 discards half of the flow log entries, which could miss intermittent malicious traffic.
- C. The testing network is not where the suspicious activity is, and a 0.5 sample rate could drop the very flows you need.
- D. Enabling logs in testing first only delays capturing production traffic, and testing logs add cost without helping this investigation.
Question 49
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. You want to identify containers that are using the most CPU and memory. What should you do?
Show answer and explanation
Correct answer: A. Use Stackdriver Kubernetes Engine Monitoring.
Stackdriver Kubernetes Engine Monitoring collects system metrics for clusters, nodes, pods and containers out of the box, including CPU and memory usage per container. Its Kubernetes dashboards let you browse by infrastructure, workload or service and sort to find the heaviest resource consumers. It supports GKE clusters on Google Cloud and GKE On-Prem clusters, so one tool covers both halves of this deployment. No custom instrumentation or separate analytics pipeline is required to answer which containers use the most CPU and memory.
Why the other options are wrong
- B. Prometheus collects metrics rather than logs, and running it with Grafana adds a self-managed stack when built-in container metrics already exist.
- C. Custom metrics and groups require extra development and duplicate the CPU and memory metrics already collected automatically.
- D. Application logs do not normally contain CPU and memory figures, so exporting them to BigQuery would not reliably reveal resource consumption.
Question 50
You support a user-facing web application. When analyzing the application's error budget over the previous six months, you notice that the application has never consumed more than 5% of its error budget in any given time window. You hold a Service Level Objective (SLO) review with business stakeholders and confirm that the SLO is set appropriately. You want your application's SLO to more closely reflect its observed reliability. What steps can you take to further that goal while balancing velocity, reliability, and business needs? (Choose two.)
Show answer and explanation
Correct answer: B, E. Have more frequent or potentially risky application releases; Announce planned downtime to consume more error budget, and ensure that users are not depending on a tighter SLO.
Stakeholders have confirmed that the SLO is correct, so the aim is to bring observed reliability down toward the target rather than move the target. Unused error budget is room for risk: shipping releases more often, or accepting riskier changes, turns that spare budget into faster feature delivery while staying within the SLO. Announced planned downtime deliberately consumes some budget and reminds users that the service is only as reliable as its SLO, which prevents them from building dependencies on reliability the business never committed to providing.
Why the other options are wrong
- A. Adding serving capacity raises reliability and cost further, widening the gap between observed reliability and the agreed SLO.
- C. The SLO review confirmed the current target is right for the business, so tightening it would contradict that decision and reduce release velocity.
- D. Measuring additional SLIs adds observability but does nothing to bring observed reliability closer to the agreed SLO.
Question 51
You are responsible for the reliability of a high-volume enterprise application. A large number of users report that an important subset of the application's functionality, a data-intensive reporting feature, is consistently failing with an HTTP 500 error. When you investigate your application's dashboards, you notice a strong correlation between the failures and a metric that represents the size of an internal queue used for generating reports. You trace the failures to a reporting backend that is experiencing high I/O wait times. You quickly fix the issue by resizing the backend's persistent disk (PD). Now you need to create an availability Service Level Indicator (SLI) for the report generation feature. How would you define it?
Show answer and explanation
Correct answer: B. As the proportion of report generation requests that result in a successful response
An availability SLI should measure what users experience, and the clearest form is a ratio of good events to valid events. Defining it as the proportion of report generation requests that return a successful response captures exactly the failures users reported, the HTTP 500 errors, regardless of what caused them. Queue size, I/O wait and disk throughput were useful for diagnosing this particular incident, but they are internal signals: future failures may have different causes, and these metrics can look abnormal while users are still served correctly.
Why the other options are wrong
- A. I/O wait time is an internal resource metric tied to one past cause, not a direct measure of whether users receive reports.
- C. Queue size correlated with this incident but is an internal signal that may not reflect user-facing success in other failure modes.
- D. Disk throughput capacity describes backend infrastructure, not whether report requests succeed for users.
Question 52
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 easily rotate secrets in case of a security breach. What should you do?
Show answer and explanation
Correct answer: 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.
Keeping secrets in a Cloud Storage bucket and encrypting them with a Cloud KMS key separates the secrets from the code and the build artifacts. Access is governed by IAM, so the pipeline's service account can be granted permission to read the encrypted objects and to decrypt with the key, while everyone else is denied. Because the secrets live in one central location rather than inside repositories or developers' heads, rotating a compromised secret means writing a new encrypted value to the bucket, and the next pipeline run picks it up without any code changes.
Why the other options are wrong
- A. Prompting developers at build time breaks automation, exposes secrets to people, and gives no central place to rotate them after a breach.
- B. A configuration file in Git spreads plaintext secrets to every clone and its history, and rotation requires new commits while old values remain recoverable.
- D. Encrypted secrets in a repository still require commits to rotate, and keeping the decryption key in another repository puts key material in version control.
Question 53
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 latencies all of your users are experiencing. You use Stackdriver Monitoring. What should you do?
Show answer and explanation
Correct answer: C. In your application, create a metric with a metricKind set to GAUGE and a valueType set to DISTRIBUTION. In Stackdriver's Metrics Explorer, use a Heatmap graph to visualize the metric.
To understand the latencies all users experience, you need the full spread of values, not a single average. A metric with a DISTRIBUTION value type stores a histogram of observations in buckets for each point, along with count, mean and sum of squared deviation, so percentiles and outliers remain visible. Written with the GAUGE metric kind, each point describes the latencies measured in that interval. Metrics Explorer's Heatmap chart is designed for distribution metrics and shows how latency values are spread across buckets over time, revealing both typical and tail latency.
Why the other options are wrong
- A. A DOUBLE value records one number per point, losing the spread of latencies, and a stacked bar chart cannot show per-user latency distribution.
- B. A single cumulative DOUBLE value reduces latency to one running number, so a line chart cannot reveal how latency varies across users.
- D. METRIC_KIND_UNSPECIFIED is not a usable metric kind, and a single INT64 value cannot represent the distribution of latencies.
Question 54
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 is updated while minimizing the development effort. What should you do?
Show answer and explanation
Correct answer: B. Use Cloud Pub/Sub to trigger a Spinnaker pipeline.
Container Registry publishes a message to a Pub/Sub topic named gcr whenever an image is pushed or tagged, once that topic exists in the project. Spinnaker has built-in support for Pub/Sub triggers, so a pipeline can subscribe to those messages and start a deployment as soon as a new image arrives. Google's continuous delivery architecture with Spinnaker on GKE uses exactly this pattern: images are pushed to the registry and a Pub/Sub subscription notifies Spinnaker to deploy. All of the pieces are existing features that only need configuration, so no custom triggering code has to be written.
Why the other options are wrong
- A. Cloud Build builds and pushes images; using it to call Spinnaker needs extra trigger logic and does not react to image updates in the registry by itself.
- C. A custom Cloud Build builder that calls Jenkins requires writing and maintaining the builder and running Jenkins, which adds development effort.
- D. A custom deployment service on GKE means writing, running and maintaining your own deployment software instead of using Spinnaker's existing Pub/Sub trigger.
Question 55
You are using Terraform to manage infrastructure as code within a CI/CD pipeline. You notice that multiple copies of the entire infrastructure stack exist in your Google Cloud project, and a new copy is created each time a change to the existing infrastructure is made. You need to optimize your cloud spend by ensuring that only a single instance of your infrastructure stack exists at a time. You want to follow Google-recommended practices. What should you do?
Show answer and explanation
Correct answer: B. Confirm that the pipeline is storing and retrieving the terraform.tfstate file from Cloud Storage with the Terraform gcs backend.
Terraform uses its state file to map configuration to the real resources it manages. If each pipeline run starts with no state, Terraform sees nothing deployed and creates a full new copy of the stack every time. Google recommends storing state remotely in a Cloud Storage bucket through the gcs backend, which persists state between runs, supports state locking to prevent concurrent changes, and can use object versioning for recovery. With shared remote state, each run updates the existing stack instead of duplicating it.
Why the other options are wrong
- A. Deleting old stacks with another pipeline treats the symptom while each run still creates a duplicate stack, wasting resources and adding risk.
- C. State files can contain sensitive data and should not be kept in source control, which also offers no state locking to prevent concurrent runs.
- D. Destroying everything before each apply causes downtime and data loss, and it ignores the missing state that is causing the duplication.
Question 56
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 assist you in an effective incident response. What roles should you assign? (Choose two.)
Show answer and explanation
Correct answer: A, C. Operations Lead; Communications Lead
Google's SRE incident management model separates responsibilities so the Incident Commander can coordinate instead of doing everything. The Operations Lead works with the Incident Commander on the response by running the operational team that makes changes to the system to mitigate and fix the problem. The Communications Lead is the public face of the response, issuing periodic updates to stakeholders and keeping the incident document accurate. Assigning these two roles immediately covers both the technical work and stakeholder communication from the start of a customer-impacting incident.
Why the other options are wrong
- B. Engineering Lead is not one of the incident roles defined in the SRE model; hands-on technical work is coordinated by the Operations Lead.
- D. Customer Impact Assessor is not a defined incident role; understanding impact is part of the work handled within the existing roles.
- E. External customer messaging is part of the Communications Lead's responsibility, so a separate external communications role is not one of the core assignments.
Question 57
Your team of Infrastructure DevOps Engineers is growing, and you are starting to use Terraform to manage infrastructure. You need a way to implement code versioning and to share code with other team members. What should you do?
Show answer and explanation
Correct answer: A. Store the Terraform code in a version-control system. Establish procedures for pushing new versions and merging with the master.
Terraform configuration is code, so it belongs in a version-control system such as Git. A repository records every change with its author and history, lets several engineers work in parallel on branches, and supports review before changes are merged into the main line. Agreeing on procedures for pushing new versions and merging gives the growing team a consistent workflow, makes infrastructure changes auditable, and allows any earlier version to be restored. This is the standard foundation for infrastructure as code and for later automating Terraform runs in a CI/CD pipeline.
Why the other options are wrong
- B. A network share with a folder per release has no change history, branching or merging, and asking people to avoid each other's files does not scale as the team grows.
- C. Object versioning keeps copies of files, but a bucket offers no branching, merging or review workflow for a team editing the same code.
- D. Drive syncing and file naming conventions do not provide real version control, merge handling or code review, and simultaneous edits can easily conflict.
Question 58
You are configuring connectivity across Google Kubernetes Engine (GKE) clusters in different VPCs. You notice that the nodes in Cluster A are unable to access the nodes in Cluster B. You suspect that the workload access issue is due to the network configuration. You need to troubleshoot the issue but do not have execute access to workloads and nodes. You want to identify the layer at which the network connectivity is broken. What should you do?
Show answer and explanation
Correct answer: B. Use Network Intelligence Center to perform a Connectivity Test from Cluster A to Cluster B.
A Connectivity Test is a configuration analysis tool: it takes a source and destination, such as nodes in Cluster A and Cluster B, and simulates the packet path through the VPC configuration. It evaluates routes, firewall rules, VPC peering or VPN, and other network settings, then reports whether the packet would be delivered and identifies the step where it would be dropped. Because it works from configuration rather than from inside workloads, it needs no execute access to nodes or Pods, and it pinpoints the layer where connectivity is broken.
Why the other options are wrong
- A. Installing a toolbox container on a node requires the node access you do not have, and checking routes alone may miss firewall or peering problems.
- C. Running traceroute from a debug container requires execute access to workloads, which is not available.
- D. VPC Flow Logs record sampled traffic flows, but they do not explain which configuration layer is blocking the traffic.
Question 59
You support a web application that runs on App Engine and uses Cloud SQL and Cloud Storage for data storage. After a short spike in website traffic, you notice a big increase in latency for all user requests, increase in CPU use, and the number of processes running the application. Initial troubleshooting reveals: After the initial spike in traffic, load levels returned to normal but users still experience high latency. Requests for content from the Cloud SQL database and images from Cloud Storage show the same high latency. No changes were made to the website around the time the latency increased. There is no increase in the number of errors to the users. You expect another spike in website traffic in the coming days and want to make sure users don't experience latency. What should you do?
Show answer and explanation
Correct answer: D. Modify the App Engine configuration to have additional idle instances.
Requests for both Cloud SQL data and Cloud Storage images show the same latency, no code changed, and errors did not rise, so the storage services are not the bottleneck: the problem lies in how the App Engine tier handled the traffic spike. When load jumps suddenly, App Engine must start new instances, and requests wait while instances start and warm up. Configuring additional idle instances keeps warm instances ready to receive traffic immediately, so the next spike is absorbed without users waiting on new instances, protecting response times during the expected surge.
Why the other options are wrong
- A. Multi-Regional storage changes data location and redundancy, but the same latency appears for database requests too, so Cloud Storage is not the cause.
- B. Cloud SQL high availability adds a standby for failover; it does not improve latency, and image requests from Cloud Storage are equally slow.
- C. Migrating to Compute Engine is a large effort that adds operational work and does not by itself provide ready capacity for traffic spikes.
Question 60
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 coverage in case of a potential load balancer misconfiguration, CDN failure, or other global networking catastrophe. Where should you measure this new SLI? (Choose two.)
Show answer and explanation
Correct answer: B, E. Instrumentation coded directly in the client; A synthetic client that periodically sends simulated user requests.
A failure in the third-party CDN, a load balancer misconfiguration or a global network problem can stop requests before they ever reach the CLB, so a CLB-level SLI never sees them. The SLI must therefore be measured from the user side of the whole path. Instrumentation coded directly in the client records the success or failure of real user requests as users experience them, covering every hop including the CDN. A synthetic client that periodically sends simulated user requests through the public entry point gives a steady, controlled signal that detects the same end-to-end failures even when real traffic is low.
Why the other options are wrong
- A. Application server logs only record requests that reach the servers, so requests lost at the CDN or load balancer never appear in them.
- C. Server-exported metrics also describe only traffic that arrives at the backends and are blind to failures upstream of the CLB.
- D. GKE health checks probe the backends from inside Google Cloud and say nothing about whether users can reach the service through the CDN.
That was 60 of 239.
The full Google Professional Cloud DevOps Engineer pack has all 239 questions, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.
Not ready yet? Get the first 119 free as one PDF by email. Get the Half Pack →