Google Cloud Professional Cloud DevOps Engineer Practice Exam

What the Google Cloud Professional Cloud DevOps Engineer exam covers

• Bootstrapping and maintaining a Google Cloud organization146 questions
• Building and implementing CI/CD pipelines299 questions
• Applying site reliability engineering practices121 questions
• Implementing observability practices and troubleshooting issues126 questions
• Optimizing performance and cost84 questions

Free Google Cloud Professional Cloud DevOps Engineer practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 776.

1. Question 1Applying site reliability engineering practices

   In SRE, what is an error budget?

   • AThe upper limit on compute capacity a service may reserve so it can absorb peak traffic load spikes
   • BThe rolling estimate of monthly cloud spend that the finance team approves and reviews for a service
   • CThe allowable amount of unreliability (1 minus the SLO) that can be 'spent' before slowing feature releasesCorrect
   • DThe number of on-call engineers a rotation must staff each week to meet incident response targets
   ✓ Correct answer: C

   An error budget equals 1 minus the SLO: a 99.9% availability target leaves 0.1% tolerated unreliability. While budget remains, teams ship features quickly; once it is exhausted they freeze risky launches and prioritize reliability work. This makes reliability a shared, measurable resource for dev and ops.

   Why the other options are wrong

   • AReserving compute capacity for peak load is a capacity-planning concern, not the SLO-derived unreliability an error budget measures.
   • BAn error budget tracks reliability headroom against the SLO, not an approved monthly financial spend for the service.
   • DOn-call staffing levels are an operational rota decision, unrelated to the reliability budget derived from the SLO.
2. Question 2Building and implementing CI/CD pipelinesSelect all that apply

   A team wants faster, cheaper CI feedback without reducing release confidence. Which TWO pipeline practices help? (Choose TWO)

   • ARun the entire end-to-end suite serially on every commit before any code is allowed to merge
   • BDisable Cloud Build layer caching so every pipeline run rebuilds all dependencies from scratch
   • CRun fast unit tests on every commit and reserve slow end-to-end/integration tests for later gated stagesCorrect
   • DParallelize independent build and test steps so total wall-clock and billed time dropsCorrect
   ✓ Correct answer: C, D

   Running fast unit tests on every commit gives near-instant regression feedback, while slow end-to-end and integration suites run in a later gated stage rather than on every push. Parallelizing independent steps (lint, unit test, build) across concurrent workers cuts wall-clock time and total billed Cloud Build minutes.

   Why the other options are wrong

   • ARunning the full end-to-end suite serially on every commit is exactly the slow, costly pattern the team wants to escape; it raises both time and spend.
   • BDisabling Cloud Build layer caching forces every run to rebuild all dependencies, making the pipeline slower and more expensive, not cheaper.
3. Question 3Building and implementing CI/CD pipelines

   A Cloud Build pipeline using a single default build (no machineType set) is slow on a large monorepo. Which is the most accurate constraint and fix?

   • ADefault builds use a shared 1-vCPU/4 GB worker; set a larger machineType (e.g., E2_HIGHCPU_8) or use a private/worker pool for more resourcesCorrect
   • BBuild speed is determined solely by the size of the source repository and cannot be improved by any machineType or pool change
   • CCloud Build cannot change its worker machine size at all, so the only way to speed things up is to split the build into more steps
   • DYou must migrate entirely off Cloud Build to a self-managed third-party CI system to get any speedup on a large monorepo build
   ✓ Correct answer: A

   Cloud Build's default worker offers roughly 1 vCPU and 4 GB RAM, which throttles compile and test time on a large monorepo. Setting a higher machineType such as E2_HIGHCPU_8 or E2_HIGHCPU_32, or routing builds to a private worker pool with custom specs, gives each build more CPU and memory and directly relieves the bottleneck.

   Why the other options are wrong

   • BBuild speed is not fixed by repository size; a larger machineType or worker pool measurably improves it, so this claim is false.
   • CCloud Build can change worker size through the machineType option, so splitting into more steps is not the only lever.
   • DCloud Build supports large machine types and private worker pools, so migrating to a third-party CI system is unnecessary.
4. Question 4Applying site reliability engineering practices

   After migrating a service, you want to automatically open an incident and notify on-call when the error-budget burn rate spikes. Which configuration achieves this?

   • AA single uptime check that pages only after the endpoint has been fully unreachable for several minutes straight
   • BAn SLO with multi-window burn-rate alerting policies in Cloud Monitoring wired to a notification channelCorrect
   • CA log-based counter metric that tallies error responses for the monthly reliability report but never pages anyone
   • DA Cloud Deploy approval gate that requires a human sign-off before promoting the next release to production
   ✓ Correct answer: B

   Service Level Objectives (SLOs) define reliability targets (e.g., 99.5% availability), and burn-rate alerts measure how quickly the error budget is being consumed. Multi-window burn-rate alerts detect spikes faster than traditional threshold-based alerts by comparing fast and slow burn rates (e.g., 5-minute vs 1-hour windows)-if the 5-minute burn rate is high while the 1-hour is normal, a spike has just started. These alerts can automatically trigger incidents via notification channels (Slack, PagerDuty, etc.) and integrate with incident management tools. This combination provides fast, accurate alerting for SLO violations, directly enabling automatic incident creation and on-call notification when reliability degrades.

   Why the other options are wrong

   • AAn uptime check only detects a fully down endpoint and does not measure error-budget burn rate to open an incident proactively.
   • CA counter metric feeds a report but does not evaluate burn rate or notify on-call, so it cannot open an incident automatically.
   • DA deploy approval gate governs release promotion and has nothing to do with alerting on error-budget burn rate.
5. Question 5Bootstrapping and maintaining a Google Cloud organization

   A microservice in project app-prod must act as another service account that has access to a BigQuery dataset, but only for specific operations, without creating any keys. Which gcloud-supported mechanism grants this?

   • ASet the target service account's email address as the value of GOOGLE_APPLICATION_CREDENTIALS so the runtime authenticates as that identity
   • BAdd the caller as an owner of the target service account's project so it inherits every permission the target service account has been granted
   • CExport a JSON key for the target service account and mount it as a Kubernetes secret so the microservice loads the key to act as that account
   • DGrant the caller the roles/iam.serviceAccountTokenCreator role on the target service account so it can generate short-lived tokens to impersonate itCorrect
   ✓ Correct answer: D

   Granting the caller roles/iam.serviceAccountTokenCreator on the target service account lets it call the IAM Credentials API to mint short-lived access or ID tokens and impersonate that account, so it inherits only the target's permissions (such as the specific BigQuery access) with no exported key. This is the keyless impersonation pattern gcloud and client libraries support natively. Making the caller a project owner grossly over-grants access, exporting a JSON key creates the long-lived credential the requirement forbids, and GOOGLE_APPLICATION_CREDENTIALS expects a key file path rather than a service account email.

   Why the other options are wrong

   • AGOOGLE_APPLICATION_CREDENTIALS expects a key file path, not a service account email, so this does not enable keyless impersonation.
   • BMaking the caller a project owner grants sweeping access far beyond impersonating one account for specific operations, violating least privilege.
   • CExporting a JSON key creates the long-lived key the requirement forbids, whereas token-creator impersonation is keyless.
6. Question 6Building and implementing CI/CD pipelines

   A team hosts code in Cloud Source Repositories and wants a Cloud Build trigger to fire on every push to the 'main' branch of a repository named 'orders-api'. Which trigger source configuration is correct?

   • AA trigger that polls Artifact Registry for new image tags every five minutes and starts a build whenever the 'orders-api' image changes
   • BA trigger with source set to the Cloud Source Repository 'orders-api' and a branch filter of '^main$'Correct
   • CA webhook trigger pointed at the deployed Cloud Run service URL so the running service notifies Cloud Build after each push to main
   • DA manual trigger that an engineer must click to run after every push to the main branch of the 'orders-api' repository
   ✓ Correct answer: B

   A Cloud Build trigger fires on source-repository events, so pointing its source at the Cloud Source Repository 'orders-api' with a branch filter regex of '^main$' starts a build on every push that lands on the main branch. Polling Artifact Registry image tags reacts to image changes rather than Git pushes, a webhook aimed at the Cloud Run service URL does not deliver repository push events to Cloud Build, and a manual trigger requires an engineer to click Run so it never fires automatically.

   Why the other options are wrong

   • ACloud Build triggers on source events, not by polling Artifact Registry image tags, so this would not fire on a Git push.
   • CA webhook must target Cloud Build's endpoint from the repository, not the Cloud Run service URL, which does not deliver push events.
   • DA manual trigger requires human action and does not fire automatically on every push to main.
7. Question 7Building and implementing CI/CD pipelines

   A stateless web service on GKE must remain fully available during deploys, and the business prefers the cheapest strategy that avoids a second full environment while still allowing in-place gradual replacement. Which strategy should you choose?

   • AA recreate strategy during a maintenance window
   • BA rolling update with a readiness probe and maxUnavailable set to 0Correct
   • CA canary requiring a separate service mesh and traffic management layer
   • DA blue/green deployment with two full clusters
   ✓ Correct answer: B

   A rolling update replaces pods incrementally in place - no duplicate environment is required, keeping costs low. Setting maxUnavailable to 0 ensures capacity is never reduced, and a readiness probe ensures traffic is only sent to healthy new pods. This combination satisfies both the availability requirement (zero-downtime) and the cost constraint (no full second environment), making it the best fit for a stateless workload on GKE.

   Why the other options are wrong

   • AA recreate strategy terminates all existing pods before starting new ones, causing downtime during the gap - this violates the full-availability requirement.
   • CA canary deployment with a service mesh and traffic management layer adds infrastructure and operational complexity beyond what is needed for simple zero-downtime in-place replacement of a stateless service.
   • DA blue/green deployment with two full clusters doubles infrastructure cost by running a complete standby environment, which directly contradicts the requirement to avoid a second full environment.
8. Question 8Building and implementing CI/CD pipelines

   A delivery flow integrates a recurring data export: a managed pipeline must read from Cloud Storage, transform records, and load them into BigQuery on a schedule, with autoscaling and no servers to manage. Which combination is most appropriate?

   • AA Dataflow pipeline (or Dataflow template) orchestrated on a schedule to read from Cloud Storage, transform, and write to BigQueryCorrect
   • BAn Apigee API proxy that transforms each record inline as a policy and forwards the transformed rows into the BigQuery destination table
   • CA single Cloud Tasks task that reads the entire Cloud Storage dataset, transforms it, and loads it into BigQuery synchronously in one request
   • DA Secret Manager rotation event that fires on schedule and triggers the read, transform, and load of the records into the BigQuery tables
   ✓ Correct answer: A

   Dataflow is Google Cloud's fully managed Apache Beam execution service, providing autoscaling, parallel processing, and no infrastructure management. Google-provided Dataflow templates (such as Cloud Storage Text to BigQuery) can be launched on a schedule via Cloud Scheduler or Workflows, making the entire ETL pipeline managed, repeatable, and serverless - directly matching all stated requirements.

   Why the other options are wrong

   • BApigee is an API management gateway, not a data-processing engine, and is not designed to read from storage and batch-load records into BigQuery.
   • CA single synchronous Cloud Tasks request cannot autoscale or reliably process a large dataset in one call, unlike a managed Dataflow pipeline.
   • DSecret Manager rotation events manage credential lifecycle and have nothing to do with scheduled data transformation and loading into BigQuery.
9. Question 9Applying site reliability engineering practices

   You want an alerting policy that pages on-call only when a 99.9% monthly availability SLO is burning its error budget fast enough to exhaust it well before the period ends, while ignoring brief blips. Which Cloud Monitoring construct should you use?

   • AAn uptime check that pings the homepage every minute and pages on any single failure
   • BA multi-window, multi-burn-rate SLO alert that combines a fast-burn condition and a slow-burn conditionCorrect
   • CA static threshold alert that fires whenever the instantaneous error rate exceeds 0.1% for one minute
   • DA metric-absence alert on the request count metric
   ✓ Correct answer: B

   Multi-window, multi-burn-rate alerting is the Cloud Monitoring approach specifically designed for SLO-based alerting. It pairs a fast-burn condition (high burn rate over a short window, e.g. 14x over 1 hour) with a slow-burn condition (moderate burn rate over a longer window, e.g. 1x over 3 days), alerting only when both windows show problematic consumption. This filters out brief blips while catching both sudden catastrophic failures and slow steady degradation, with no false positives from momentary spikes.

   Why the other options are wrong

   • AAn uptime check that pages on any single failure is extremely noisy - a single failed ping does not indicate an SLO breach and will generate many false-positive pages, violating the requirement to ignore brief blips.
   • CA static threshold alert on instantaneous error rate fires on any brief spike above 0.1% regardless of duration, generating many false positives from transient blips without considering whether the SLO budget is actually at risk.
   • DA metric-absence alert fires when a metric stops reporting data entirely (e.g., if a service stops sending metrics), not when it is burning error budget; it cannot detect latency or error-rate degradation.
10. Question 10Building and implementing CI/CD pipelines

    An integration must run a long-lived batch transformation (about 40 minutes) that is triggered by an HTTP event and then signals completion to a Pub/Sub topic. The team wants a managed, serverless compute option that runs to completion and is NOT constrained by request timeouts. Which is the BEST choice?

    • AA 2nd-gen Cloud Function triggered directly by the HTTP request, running for 40 minutes
    • BA Cloud Scheduler job that runs the transformation inline
    • CA Cloud Run service handling the HTTP request synchronously for the full 40 minutes
    • DA Cloud Run job invoked via the Admin API, publishing to Pub/Sub when finishedCorrect
    ✓ Correct answer: D

    Cloud Run jobs are designed for run-to-completion workloads rather than serving requests, so they are not bound by per-request timeout limits and can execute long batch work, then publish a completion message to Pub/Sub. A thin HTTP handler (or Eventarc/Workflows step) can start the job via the Cloud Run Admin API and return immediately, decoupling the trigger from the long-running compute. Request-serving services and functions tie the work to a request lifecycle, whereas a job has no request lifecycle to manage.

    Why the other options are wrong

    • A2nd-gen Cloud Functions support up to 60 minutes for HTTP triggers, so 40 minutes would fit, but like a Cloud Run service the work is still tied to a request lifecycle; a Cloud Run job is the better architectural fit for a batch transformation.
    • BCloud Scheduler only triggers targets on a schedule; it does not execute arbitrary long-running transformation logic itself, and the trigger here is an HTTP event rather than a schedule.
    • CA Cloud Run service does support request timeouts up to 60 minutes, so a 40-minute request would technically fit, but a synchronous request-serving model ties the work to a request lifecycle; a Cloud Run job is the purpose-built run-to-completion option for batch work.

Who this Google Cloud Professional Cloud DevOps Engineer practice exam is for

This practice set is for anyone preparing for the Google Cloud Professional Cloud DevOps Engineer exam at the advanced level - from first-time candidates building a foundation to experienced Google practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this Google Cloud Professional Cloud DevOps Engineer practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Use your readiness score to decide when you are ready to book the real Google Cloud Professional Cloud DevOps Engineer exam.

Related Google resources

• Google Cloud Professional Cloud DevOps Engineer study guideKey concepts
• Google practice examsAll Google
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• Google Cloud Professional Cloud Network Engineer practice examRelated
• Google Cloud Professional Cloud Security Engineer practice examRelated
• Google Cloud Professional Data Engineer practice examRelated

Google Cloud Professional Cloud DevOps Engineer practice exam FAQ