DevOps practice

{{ summaryValue }}

{{ summaryLine }}

Google Cloud Professional Cloud DevOps Engineer · Standard exam · English

Unversioned official English guide, verified 12 September 2026. This is a dated snapshot, not a numbered provider revision. No separate exam code is published in the reviewed guide.

Unofficial and independently authored; no Google affiliation or endorsement. This 30-item curated bank is untimed and single-answer, with uniform, unweighted selection. It does not cover every blueprint topic or reproduce official difficulty. The official exam has 50–60 multiple-choice and multiple-select questions in two hours.

Official scope and preparation boundaries

Official exam information · English exam guide

There is no mandatory exam prerequisite. Google recommends at least three years of industry experience, including one year designing and managing production systems on Google Cloud. Candidate eligibility rules still apply. This practice targets the standard exam, not renewal eligibility.

  • {{ domainRow.official }} — approximately {{ domainRow.weight }}% of the official blueprint.

Those weights describe the official guide; they are not sampling quotas or score weights here. Each domain has six original scenarios, split evenly between two complexity groups. A short mixed round can omit domains. Practising these decisions does not demonstrate hands-on production or incident competence.

The two groups contain different scenarios. They are authored practice levels, not calibrated exam difficulty.
Each answer is final for that round. Choose when to reveal the correction.
Optional. Blank uses “devops-practice”. Keep the same seed to reproduce a round; changing it can still repeat familiar items. Avoid personal information: the seed and attempt travel in the share link.

{{ examSetupValidation }}

{{ Math.round(progressPercent) }}%
{{ answeredCount }} of {{ questionCount }} answered

Question {{ examCursor + 1 }} of {{ questionCount }} · {{ currentQuestion.category_label }}

{{ currentQuestion.stem }}

{{ currentQuestion.accessible_clue }}

Answer recorded. Corrections will appear at completion.

Practice review

{{ resultLead }}

Readiness review

Unofficial, curated, untimed, single-answer and unweighted practice. The official exam has 50–60 multiple-choice and multiple-select questions in two hours. These items do not reproduce exam difficulty, cover every objective, predict passing, or prove hands-on production and incident competence. English guide snapshot verified 12 September 2026; no provider numeric revision is claimed.

Start with the missed decisions below.

Perfect round on these selected items. Test a different pool and validate your reasoning hands-on.

Missed answer review

  1. {{ item.prompt }}

    Your answer: {{ item.selected_answer_label }}

    Correct answer: {{ item.correct_answer_label }}

    {{ item.explanation }}

    Next study step: {{ studyAction(item.question_id) }}

    Primary documentation · {{ item.source.version }}

Use the official preparation resources to cover unsampled objectives, practise changes in a disposable environment, and connect delivery outcomes to DORA's current delivery metrics. A new seed can still repeat items; switching complexity changes the pool.

Domain performance

Correct and missed counts in this round. “Not sampled” means no evidence for that domain, not a zero-percent score. Official weights are not applied.

{{ examChartStatus }}

{{ examChartStatus }}

Answer ledger

Question IDPromptDomainYour answerCorrect answerOutcomeExplanationSourceCopy
{{ row.question_id }}{{ row.prompt }}{{ row.category_label }}{{ row.selected_answer_label }}{{ row.correct_answer_label }}{{ row.outcome_label }}{{ row.explanation }} {{ row.source.label }} · {{ row.source.version }}
Google Associate Cloud Engineer Exam Prep Planned independent practice for deploying, securing, operating, and maintaining Google Cloud solutions under a dated exam guide.
AWS DevOps Engineer Professional Exam Prep Practise AWS DevOps Engineer Professional DOP-C02 with 36 original scenarios and explained answers to guide review of missed decisions.
CI Failure Log Analyzer Find actionable clues in a failed CI log, map them to pipeline stages, and mask common secret patterns before sharing the evidence.
Error Budget Calculator Calculate SLO error-budget use from observed traffic, compare burn and policy gates, and estimate runway before a release decision.

A release can pass its build checks and still make a checkout service slower, overwhelm a database, or reach production without the required approval. Cloud DevOps work connects the evidence from building software to the decisions that keep a running service dependable. On Google Cloud, that includes organizing projects and permissions, delivering application and infrastructure changes, investigating failures, and controlling resource costs.

Continuous integration and continuous delivery, usually shortened to CI/CD, make changes repeatable and testable. Continuous integration checks changes as they are brought together. Continuous delivery prepares tested changes for release through a controlled process, which can still require human approval. The identity of the tested software matters throughout that process. Rebuilding a branch for production does not establish that the new build is the same artifact, such as a container image, that passed staging, even when the branch name has not changed.

Site reliability engineering, or SRE, connects operational decisions to measurable service outcomes. A useful reliability discussion distinguishes the measurement, the target, and the agreement with users.

Service-level indicator (SLI)
A defined measurement of service behavior, such as the fraction of eligible requests that succeed or meet a latency limit.
Service-level objective (SLO)
The target for that indicator over a stated measurement period.
Service-level agreement (SLA)
An agreement that specifies service expectations and consequences when those expectations are not met.
Error budget
The amount of unsuccessful service behavior permitted by the SLO. Its burn rate describes how quickly that allowance is being consumed.

These distinctions affect release decisions. When an agreed error-budget policy pauses ordinary feature releases after excessive failures, passing unit tests does not cancel that policy. Urgent incident fixes and security fixes may have explicit exceptions. The policy must say which changes are allowed and who can authorize them. There is no universal rule that every service must stop all changes whenever one metric worsens.

Observability supplies the evidence needed to investigate those failures. Metrics summarize measurements over time, logs describe individual events, and traces follow work through a request's operations. Low average processor use does not prove that customers receive fast responses. Similarly, collecting logs in one place and making several projects' metrics visible in one dashboard solve different problems. Choosing the right measurement is part of the diagnosis, not an administrative step after it.

Release safety also depends on what happens under load. A canary rollout sends a limited share of traffic to a new version so its behavior can be assessed before broader exposure. Configuring a traffic percentage alone does not establish success. A service may need more instances to reduce contention, yet those instances can increase pressure on a shared database. Performance and cost decisions therefore need workload evidence and a recovery plan, rather than a blanket preference for either the smallest resource or the most automation.

DevOps Research and Assessment (DORA) measures delivery outcomes through change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. These describe software delivery throughput and instability, not whether individual requests meet a latency objective. They complement service measurements without replacing them.

The Professional Cloud DevOps Engineer certification addresses this combination of delivery and operational judgment. Google recommends at least three years of industry experience, including at least one year designing and managing production systems on Google Cloud, while listing no mandatory exam prerequisite. Candidate eligibility rules still apply. Scenario practice can reveal a misunderstood decision, but recognizing an answer does not demonstrate the ability to execute a production change, investigate an incident, or recover a service.

How to Use This Tool:

Use the untimed rounds to examine operational reasoning and then study the corrections. The bank contains 30 independently authored scenarios, with no Google affiliation or endorsement. Each question offers four choices and accepts one best answer.

  1. Choose a Domain and Scenario complexity. Operational decisions focuses on the stated operational requirement. Multi-constraint trade-offs asks for an action that respects several stated requirements. These are different question pools, not calibrated levels of official exam difficulty.
    A saved link can restore an unfinished or completed attempt. If Saved attempt unavailable appears, use Reset saved attempt and start again. Invalid data or an incompatible question-bank or guide snapshot is not silently accepted.
  2. Select the Question count. All five domains allows 5, 10, or 15 questions. A single domain allows 1 or 3. The initial setup uses all five domains, Operational decisions, and 5 questions. Changing pools replaces an unsupported count with that pool's default, which is 5 for a mixed pool and 3 for a focused pool.
  3. Choose when to see Feedback. After each answer, the default, reveals the correction immediately. At completion records each response without revealing the correction until the final review.
  4. Enter a Replay seed under Advanced when you need a repeatable round. A blank or whitespace-only seed uses devops-practice, and surrounding spaces are ignored. The limit is 128 character positions, with some emoji using two positions. Keep personal or confidential information out of the seed.
  5. Start with Start exam practice, then answer each scenario. Selecting an option records it immediately and locks it for that round, including when feedback is deferred. Use Next question to continue and View results after the final response.
    To stop early, End round and change setup clears the current attempt. It does not submit unanswered questions for a final review.
  6. Review each missed explanation and its Next study step. Use Retry missed for a new round containing only the missed items. Replay same seed repeats the round, while Try a new seed starts another seeded round without guaranteeing unfamiliar questions.

Interpreting Results:

During a round, the summary and progress bar show how many questions you have answered, not how many were correct. After completion, Practice review shows the correct count and a percentage to one decimal place. That percentage describes only the selected questions. There is no pass mark, readiness band, official scaled score, or prediction of a certification result.

Readiness review is a study review, not a readiness classification. The missed-answer entries explain the correct choice and the rejected alternatives, then suggest a specific follow-up. The Answer ledger includes every selected question, your answer, the correct answer, its outcome, explanation, and primary-documentation reference. A correct guess deserves review too.

Domain performance compares correct and missed counts, without applying official blueprint weights. Not sampled means the round provides no evidence for that domain; it is not a zero-percent result. A domain with one correct answer has much less supporting evidence than a broad set of independently reasoned decisions.

A perfect round means all selected answers were correct. It does not establish exhaustive topic coverage or production competence. Before treating improvement as learning, explain why the alternatives fail, change the content pool, and practise the relevant procedure in a disposable environment. Repeating a familiar seed after reading its corrections is useful reinforcement, not an independent readiness test.

If the domain chart cannot load, use Retry chart or read the domain counts through their CSV download. The answer ledger and completed score do not depend on a successful chart drawing.

Technical Details:

A single-answer scenario measures whether the chosen action matches the requirements and the authored answer key. It does not measure how difficult the decision was, how long it took, or whether the reader could carry it out. Equal-point scoring makes the result auditable, but it does not make a small curated sample equivalent to a professional examination.

How practice scores and progress are calculated

Each correct response earns one point. Each incorrect response earns zero, with no deduction or partial credit. The percentage uses every question in the round as its denominator.

Points=C Accuracy (%)=100×CN Progress (%)=100×AN

C is the correct count, A is the answered count, and N is the total number of questions in the current round. Unanswered questions remain in N but are not counted as incorrect. The missed count is the answered count minus the correct count. Completion requires every question to be answered.

Points range from zero to N, and completed accuracy ranges from 0% to 100%. Counts remain whole numbers. Raw accuracy and progress are unrounded. The final review displays accuracy to one decimal place; the progress bar text rounds to the nearest whole percent, with half-percent ties rounding up. For example, eight correct answers in a completed ten-question round give eight points and 80.0% accuracy. No domain or complexity multiplier changes that result.

Exam scope and question selection

The practice targets an authored snapshot of the standard English guide dated 12 September 2026. Google’s English guide is unnumbered; the author’s snapshot date does not identify a provider edition or establish that the current guide is unchanged. It does not target renewal preparation or determine candidate eligibility. The live guide can change independently of this bank, so the snapshot date must not be read as a claim of automatic alignment with the latest objectives.

Google's published standard exam has 50 to 60 multiple-choice and multiple-select questions in two hours. These practice rounds are untimed, single-answer, uniformly selected, and unweighted. The official domain shares below describe the guide, not quotas for selecting practice questions.

Domain Approximate official share Examples in the practice bank
Organization20%Resource hierarchy, managed cluster upgrades, development environments, and private build access.
CI/CD25%Tested-release promotion, secret access, production approval, canary rollouts, and model validation.
SRE18%Latency indicators, error-budget policy, burn-rate alerts, capacity protection, and incident recovery.
Observability25%Virtual-machine telemetry, log counters, query conditions, cross-project visibility, and trace correlation.
Performance and cost12%Profiling, rightsizing, interruptible batch capacity, commitments, concurrent-request limits, and log exclusions.

Each domain contributes six original scenarios, split into three Operational decisions and three Multi-constraint trade-offs. Selecting a complexity therefore creates a 15-question mixed pool or a three-question focused pool. One round never combines both complexity groups. Taking both complete mixed pools reaches the 30 authored scenarios, not every objective in the official guide.

Selection is seeded and without replacement, so an item does not repeat within a round. A mixed round of 5 or 10 questions can omit a domain because there are no domain quotas. Selecting all 15 questions includes three from each domain in that complexity group. That equal distribution still differs from the official weights.

The same pool, count, seed, and compatible question-bank content reproduce the question and option order. A different seed can still select familiar items. When the whole pool is selected, changing the seed cannot introduce additional questions. A missed-only retry uses the missed items as its new scope and its own question count; it does not revise the previous answers.

Reliability calculations behind the SRE scenarios

Request-based reliability starts by defining which events are eligible and what makes an event good. For a latency objective, the measurement must count requests meeting the specified limit; average latency alone does not establish that fraction. The measurement period and any exclusions must remain consistent when comparing results.

The good-event fraction is the number of good requests divided by the number of eligible requests.

SLI=GT

G is the good-event count and T is the eligible-event count in the same measurement period. Multiplying the fraction by 100 expresses it as a percentage. With no eligible events, this ratio is undefined rather than evidence of perfect service.

For an SLO target expressed as a fraction, the error budget is the permitted number of bad events in the compliance period.

B=(1−s)×T

B is the error budget in events, s is the SLO target, and T is the eligible-event count for that compliance period. A hypothetical 99.9% objective over 100,000 eligible requests permits 100 bad requests. This is an event allowance, not automatically a number of outage minutes.

Burn rate compares the observed bad-event fraction over an alerting interval with the fraction allowed by the SLO.

r=e1−s

r is the dimensionless burn rate and e is the observed bad-event fraction. Both e and s use fractions, not whole percentage values. For the 99.9% objective, an observed 0.5% bad-event rate gives a burn rate of 5. The error fraction is five times the long-run allowance; this does not mean five errors occurred or that five percent of the budget has been consumed.

Burn rateInterpretation
0 ≤ r < 1The observed bad-event fraction is below the SLO allowance. Zero means no observed bad events.
r = 1The observed fraction matches the allowance. Sustained for the full period, it uses the permitted budget.
r > 1Sustaining this fraction for a full compliance period would miss the SLO.

A short-interval burn rate does not, by itself, say whether the existing compliance period has already missed its objective. Alert windows, notification urgency, release pauses, and urgent-fix exceptions require an agreed policy. These formulas assume positive eligible-event counts and an SLO target below 100%; a 100% target leaves no error allowance and makes the burn-rate denominator zero. They explain service-reliability concepts, not additional outputs calculated from the practice answers.

Operational rules that change the best answer

Many scenarios turn on the scope of a control. The following distinctions explain why a plausible product choice can still fail a stated requirement.

RequirementGoverning distinction
Limit production accessIdentity and Access Management (IAM) grants inherit down the resource hierarchy. A production-folder grant reaches its descendant projects; an organization-wide grant reaches a broader set of projects. A label does not create an inheritance parent.
Release tested software with approvalCloud Deploy promotes an existing release. A production-target approval requirement gates that rollout; approval of a build is not the same decision as approval to deploy an already-created release.
Block unapproved imagesBinary Authorization enforcement evaluates admission against the configured policy and required attestations, which are signed approval records tied to an image. Reporting a running workload's violation or producing a vulnerability report does not alone impose the requested deployment block.
Centralize operational visibilityA Monitoring metrics scope makes selected projects' metrics available for monitoring without requiring copies of every measurement. A log sink routes log entries. Non-intercepting aggregation preserves the child projects' normal routing, subject to their own filters and destinations.

Capacity controls also need workload interpretation. Cloud Run can briefly exceed a configured maximum instance count, so that setting alone is not an absolute database-connection guarantee. Connection-pool bounds and overload handling remain necessary. For a single-threaded application on several virtual processors, modest average processor use can hide one saturated processor. Lower concurrency, meaning fewer simultaneous requests per instance, may encourage request-driven scaling, but the resulting latency and cost need measurement rather than an assumed improvement.

Privacy Notes:

Question selection and scoring run in the browser rather than through a remote grading service. Resuming and sharing are based on the page address, which carries enough information to restore the round, including the seed and recorded responses. That information is encoded, not encrypted.

Anyone who receives the full link can inspect or restore the attempt. The address can remain in browser history and can reach the site when the page is reloaded. Resetting clears the active attempt, not copies of previously shared links or existing history. Exported reviews also contain your answers.

Chart and document features can load additional resources over the network, and opening documentation visits an external site. Browser-based grading is therefore not a promise of fully offline operation or that no practice information can leave the device.

Worked Examples:

A feature release after the error budget is spent

Select SRE, Operational decisions, and 3 questions. Correctly choose the request-based latency indicator and the burn-rate alert, but choose to ship the ordinary feature despite the stated release pause. The completed review shows 2/3 correct and 66.7%, with the error-budget decision as the only missed item. Its correction is to defer the feature while preserving the policy's urgent incident-fix and security-fix exceptions. Retry missed creates a one-question round about that decision. A later 1/1 result describes the retry, not a new assessment of all SRE topics.

A release that passed tests but still needs a canary

Choose CI/CD, Multi-constraint trade-offs, and 3 questions to include the canary scenario. The service passed functional tests, but earlier changes caused latency problems only under production traffic. Choosing to send all traffic immediately is marked incorrect because it does not meet the limited-exposure requirement. The correction favors a Cloud Deploy canary with progressive percentages and appropriate verification. In the missed review, the study step is to define success metrics and a stop or rollback decision before exposing users. Configuring percentages without assessing errors does not satisfy that requirement. The practice evaluates this choice; it does not deploy a canary or verify a real service.

References: