Google Cloud Professional Cloud DevOps Engineer Practice Exam

What the Google Cloud Professional Cloud DevOps Engineer exam covers

• Bootstrapping and maintaining a Google Cloud organization142 questions
• Building and implementing CI/CD pipelines289 questions
• Applying site reliability engineering practices101 questions
• Implementing observability practices and troubleshooting issues107 questions
• Optimizing performance and cost82 questions

Free Google Cloud Professional Cloud DevOps Engineer sample questions

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

1. Question 1Applying site reliability engineering practices

   In SRE, what is an error budget?

   • AThe maximum share of compute capacity a service is permitted to reserve for peak load
   • BThe rolling estimate of monthly cloud spend that finance approves 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 to meet response targets
   ✓ Correct answer: C

   An error budget is defined as 1 minus the SLO target - for example, a 99.9% availability SLO yields a 0.1% error budget. This budget quantifies how much downtime or degradation a team is allowed to 'spend' over a rolling window. When the budget is plentiful, teams can ship features aggressively; when it runs low, reliability work takes priority. This mechanism aligns dev and ops incentives by making reliability a shared, measurable resource.

   Why the other options are wrong

   • AAn error budget measures permitted unreliability against the SLO, not a reservation of compute capacity.
   • BAn error budget tracks reliability headroom, not an approved financial spending limit.
   • DOn-call staffing is an operational decision unrelated to the reliability budget derived from the SLO.
2. Question 2Applying site reliability engineering practices

   Product pressure is pushing for a 99.999% availability SLO on an internal tool that users tolerate brief outages on. Engineering warns the cost to achieve five-nines is enormous. What is the correct SRE rationale for the target?

   • AAlways target 99.999% availability because higher reliability is unconditionally better for users
   • BSet the SLO to the lowest level that keeps users happy, since each added nine sharply raises costCorrect
   • CMatch the SLO to the reliability of the most dependable external dependency in the stack
   • DRemove the SLO altogether on the grounds that internal tools do not require one
   ✓ Correct answer: B

   SRE philosophy holds that SLOs should reflect actual user happiness - not marketing aspirations or engineering pride. Going from 99.9% to 99.99% availability cuts allowable downtime from ~8.7 hours to ~52 minutes per year, requiring substantially more redundancy, faster incident response, and engineering investment. For an internal tool where users tolerate brief outages, a 99.9% or even 99.5% SLO may fully satisfy users at a fraction of the five-nines cost. The correct approach is to measure or survey user tolerance and set the SLO just above that threshold.

   Why the other options are wrong

   • AChasing five-nines when users tolerate brief outages wastes cost and effort for no user benefit.
   • CCopying a dependency's reliability ignores actual user tolerance and can force needless expense.
   • DEven internal tools benefit from an SLO to guide reliability decisions; removing it forfeits that signal.
3. Question 3Applying site reliability engineering practices

   A bad Cloud Run revision is causing elevated 5xx errors in production. What is the fastest safe recovery action?

   • ALower the DNS TTL and wait for caches to expire
   • BDelete the entire Cloud Run service and recreate it from scratch
   • CShift 100% of traffic back to the last known-good revision that is still retainedCorrect
   • DIncrease the instance memory limit and hope errors stop
   ✓ Correct answer: C

   Cloud Run retains all deployed revisions, and traffic splitting is controlled declaratively - redirecting 100% of traffic to a previous known-good revision is an instant, low-risk operation that can be performed via the console, gcloud CLI, or a YAML update, immediately stopping user impact from the bad revision without deleting any resources or requiring a new build.

   Why the other options are wrong

   • ALowering the DNS TTL and waiting for caches to expire is a slow, indirect approach - DNS propagation can still take minutes even with a low TTL, and DNS does not control which Cloud Run revision serves traffic; traffic splitting is configured at the service level, not at DNS.
   • BDeleting the entire Cloud Run service and recreating it from scratch is destructive and slow - it removes all revision history and configuration, takes significantly longer than a traffic split update, and risks configuration errors during recreation.
   • DIncreasing the instance memory limit without understanding the root cause is speculative and will not resolve a code-level bug causing 5xx errors - it delays recovery while still serving bad traffic, and the assumption that memory is the issue may be entirely wrong.
4. Question 4Applying site reliability engineering practicesSelect all that apply

   You are integrating a new event-driven pipeline and need reliable handling of messages that repeatedly fail processing. Which TWO Pub/Sub features address this? (Choose TWO)

   • ADisable acknowledgements so messages never expire
   • BSet an appropriate acknowledgement deadline and use exponential backoff retry policyCorrect
   • CDelete the subscription whenever a message fails
   • DConfigure a dead-letter topic for messages exceeding max delivery attemptsCorrect
   ✓ Correct answer: B, D

   Reliable Pub/Sub message processing requires two complementary features for failure handling. First, setting an appropriate acknowledgement deadline gives the subscriber enough time to process the message, and configuring an exponential backoff retry policy avoids hammering a struggling downstream service on consecutive retries. Second, a dead-letter topic (also called a dead-letter queue) captures messages that have exceeded the maximum delivery attempt count so they can be inspected, reprocessed, or alerted on without blocking the rest of the queue.

   Why the other options are wrong

   • ADisabling acknowledgements so messages never expire would cause the subscription to accumulate messages indefinitely - Pub/Sub requires acknowledgements to determine when a message has been successfully processed and to remove it from delivery.
   • CDeleting the subscription whenever a message fails would lose all unprocessed messages in the subscription and require recreating the subscriber setup - it does not handle individual failing messages gracefully.
5. Question 5Bootstrapping and maintaining a Google Cloud organization

   Which organization-level guardrail enforces that resources can only be created in approved regions?

   • AA VPC firewall egress rule restricting traffic to the region subnets
   • BA project-level IAM deny binding applied to every user in the project
   • CThe Resource Location Restriction organization policy constraintCorrect
   • DA Cloud DNS managed zone scoped to the approved deployment regions
   ✓ Correct answer: C

   The Resource Location Restriction organization policy constraint (gcp.resourceLocations) lets you specify the allowed locations, and Google Cloud then refuses to create resources in any region or multi-region outside that list. Because it is an organization policy, it is inherited down the resource hierarchy and enforced at creation time across projects. IAM deny bindings control who may act, a Cloud DNS zone resolves names, and a firewall egress rule filters traffic, so none of them constrain where resources may be provisioned.

   Why the other options are wrong

   • AA firewall egress rule filters network traffic and does not limit the locations where resources can be created.
   • BAn IAM deny binding controls who can act, not where resources may be created, so it does not enforce region restrictions.
   • DA DNS managed zone handles name resolution and cannot restrict the regions in which resources are provisioned.
6. Question 6Building and implementing CI/CD pipelines

   A CI/CD architecture review flags that the same container image rebuilt in staging is rebuilt again for production, risking subtle differences. The team wants to guarantee the exact artifact tested in staging is what runs in production. Which practice ensures this?

   • ARebuild the image from source in each environment but pin the same Git tag every time, trusting that identical source always yields a byte-identical image
   • BBuild the image once, store it in Artifact Registry by immutable digest, and promote that same digest through staging and production without rebuildingCorrect
   • CUse the 'latest' tag everywhere so all environments always pull whatever the newest build happened to produce most recently in the shared repository
   • DRebuild the image in production with layer caching disabled to guarantee a completely clean build that cannot reuse anything from earlier environments
   ✓ Correct answer: B

   Building the image once and storing it in Artifact Registry by its immutable content digest lets the pipeline promote that exact same digest from staging into production, guaranteeing the bytes that were tested are the bytes that run. Rebuilding from the same Git tag can still diverge because base images, dependencies, or build tooling change between runs, the mutable 'latest' tag can point at different images over time, and any rebuild in production, cached or not, produces a fresh artifact that was never validated in staging.

   Why the other options are wrong

   • ARebuilding from the same tag can still differ due to base images, dependencies, or build tooling, so it does not guarantee the identical artifact.
   • CThe 'latest' tag is mutable and can point to different images over time, so environments may not run the exact artifact that was tested.
   • DRebuilding in production, cache disabled or not, still produces a new artifact that was never tested in staging.
7. Question 7Building and implementing CI/CD pipelines

   A build pipeline needs to authenticate from an on-premises Jenkins server to Google Cloud without storing a service account key on the Jenkins host. The Jenkins server can obtain OIDC tokens from your corporate identity provider. Which Google Cloud feature should you configure?

   • AWorkload Identity Federation with a workload identity pool and provider that trusts the corporate OIDC identity providerCorrect
   • BA shared API key embedded in the Jenkins global configuration so all build jobs can authenticate to Google Cloud without a key file
   • CA Cloud KMS key that the Jenkins server uses to sign each build artifact, which Google Cloud then accepts as proof of identity
   • DA downloaded service account key securely copied to the Jenkins host over SSH and referenced by every build job that authenticates
   ✓ Correct answer: A

   Workload Identity Federation with a workload identity pool and provider that trusts the corporate OIDC identity provider lets the on-prem Jenkins server present its OIDC token and receive short-lived Google Cloud credentials, so no service account key ever lives on the host. A downloaded key is exactly the exported credential the requirement forbids, a shared API key does not authenticate an IAM principal and is an insecure long-lived secret, and a Cloud KMS signing key signs data but does not federate the Jenkins identity into a service account.

   Why the other options are wrong

   • BAPI keys do not authenticate a principal for IAM-scoped access and embedding a shared key on the host is an insecure long-lived credential, not keyless federation.
   • CA Cloud KMS signing key signs data but does not federate the Jenkins server's OIDC identity into a Google Cloud service account for access.
   • DA downloaded service account key is exactly the exported credential on the host that the requirement forbids, regardless of how it is copied over.
8. Question 8Building and implementing CI/CD pipelines

   Your pipeline deploys to prod with a canary, but stakeholders complain that even healthy rollouts take over an hour because each canary phase waits a long fixed time. You want to keep safety but reduce total rollout time for healthy releases. Which adjustment best balances speed and safety?

   • AIncrease the fixed wait on every canary phase to be extra safe, accepting that healthy rollouts will take even longer than they do today to complete
   • BDrive phase advancement with metric-based verification (advance as soon as the SLI is confirmed healthy over a sufficient sample) instead of long fixed waits, so healthy releases progress quickly while unhealthy ones still fail and roll backCorrect
   • CDisable the rollback automation so that the canary phases never pause for verification and the rollout advances without interruption to completion
   • DRemove all canary phases entirely and deploy straight to 100% of traffic so that healthy releases finish immediately with no phased waiting period, accepting that a bad release would reach every user at once
   ✓ Correct answer: B

   Long fixed wait times in canary phases add latency to every rollout regardless of whether the release is healthy. Replacing fixed waits with metric-based verification - where Cloud Deploy's verification job queries Cloud Monitoring SLIs and advances the rollout as soon as a statistically sufficient healthy window is confirmed - allows healthy releases to complete far faster. Unhealthy releases still trigger rollback because the verification fails. This adaptive approach preserves safety while eliminating unnecessary delay.

   Why the other options are wrong

   • AIncreasing fixed waits makes healthy rollouts even slower, which is the opposite of the goal of reducing total rollout time while keeping safety.
   • CDisabling rollback automation removes the safety net so bad releases are no longer caught, sacrificing safety rather than balancing it with speed.
   • DRemoving all phases and going straight to 100% eliminates the canary safety entirely, exposing every user to a bad release with no gradual validation.
9. Question 9Applying site reliability engineering practices

   An API serves user-facing search requests. The team wants a latency SLI that reflects what users actually experience rather than being skewed by a few outliers. Which SLI formulation is most appropriate?

   • AThe proportion of valid requests served faster than a threshold (e.g., the percentage of requests under 300 ms)Correct
   • BThe arithmetic mean response time computed across all requests served in the measurement window
   • CThe single maximum response time observed among all requests during the measurement window
   • DThe total count of requests successfully served across the entire measurement window
   ✓ Correct answer: A

   A threshold-based latency SLI - the percentage of requests completing within a set time limit such as 300 ms - is the recommended approach in Google SRE practice because it is a ratio of good events to total events and is not distorted by outliers. The arithmetic mean is heavily skewed by a small number of very slow requests, hiding the true majority experience. Maximum response time captures only the single worst case and is extremely noisy. Total request count provides throughput information but says nothing about latency at all.

   Why the other options are wrong

   • BA mean hides tail behavior; a few very slow or very fast requests skew the average so it does not reflect what most users actually experience.
   • CThe maximum reflects a single worst-case outlier and is highly volatile, so it is a poor SLI for typical user-perceived latency.
   • DA request count measures throughput, not latency, so it says nothing about how fast users' searches were served.
10. Question 10Building and implementing CI/CD pipelines

    You need an Artifact Registry repository that transparently caches and serves packages from a public upstream (e.g., Docker Hub) so builds avoid rate limits and gain a single internal pull endpoint. Which repository mode should you configure?

    • AA remote repository configured with the public registry as its upstream sourceCorrect
    • BA virtual repository aggregating only your private standard repositories
    • CA Cloud Storage bucket fronted by a Cloud CDN origin
    • DA standard repository into which you manually re-push every upstream image
    ✓ Correct answer: A

    Remote repositories act as a pull-through cache: the first request fetches from the configured upstream (such as Docker Hub) and caches it, and subsequent pulls are served from Artifact Registry, mitigating upstream rate limits and giving you one internal endpoint. Virtual repositories aggregate multiple upstream/standard/remote repos behind a single URL but do not themselves proxy an external registry without an underlying remote repo. Standard repositories only hold artifacts you push yourself, and a CDN-fronted bucket is not an artifact registry and lacks package semantics.

    Why the other options are wrong

    • BVirtual repositories aggregate repositories behind one endpoint but rely on a remote repository to actually proxy an external upstream.
    • CA bucket plus CDN serves objects, not package/registry protocols, so clients cannot pull container images by tag from it.
    • DManually re-pushing every upstream image is exactly the toil a remote (pull-through) repository eliminates.

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
• Google Cloud Professional Cloud Security Engineer practice examRelated
• Google Cloud Professional Cloud Network Engineer practice examRelated
• Associate Google Workspace Administrator practice examRelated

Google Cloud Professional Cloud DevOps Engineer practice exam FAQ