Skip to main content

Professional Cloud DevOps Engineer

🌸 Passed: March 30, 2025


Passing Memo

Passing Memo for March 30, 2025

Got through it despite the baptism by fire of a doubleheader.

Exam Overview

  • 50 questions. Completed the first pass in about 50 minutes, reviewed for 10 minutes, and submitted.
  • I imagine I scored around 90%.

Exam Impressions

  • Most questions were either directly from the Udemy course or could be answered immediately with an understanding of SRE.
  • There might have been some shallow questions from the Architect or other exams, but most were fundamental.
  • The first half was easy, but the second half had some uncertain parts, so I can't rule out the possibility that I just happened to get past questions I knew.

Topics Covered

  • Agent Policies → Appeared about twice, and I realized I didn't understand them well.
  • Private pools
  • Cloud Build in general
  • General fundamental concepts of SRE
  • A few questions related to IAM / GKE service accounts
  • Questions about defining SRE metrics with a buffer (e.g., 50→60/100→110...).

Exam Information - March 30, 2025 → 🌸Passed🌸

Exam Name: Professional Cloud DevOps Engineer

  • Date: March 30, 2025
  • Time: 03:45 PM

Exam Day TODO (Success story from my PSE / PNE / PDE / PCA exams) ⭐️

The Day Before

  • Get a good night's sleep
    • Set up eye mask, earplugs, and pillow

On the Day

  • Wake up by 9 AM (It's important to be fully recovered from fatigue)

    • → 11 AM
  • Do a final review at a cafe

    • Feeling like going to the Doutor Odori store
      • Review incorrect answers from the Official Practice Exam
      • Review weak areas
      • Review incorrect answers from practice question sets
      • Read other important articles
  • Leave the cafe at 2:00 PM

  • Print the exam confirmation email

    • Forward the email to the app
  • Take a 10-minute nap before arriving at the venue to fully refresh my brain

    • Get enough sugar
  • Arrive at the venue by 3:00 PM (30 minutes before the test starts) and complete check-in

    • Make a conscious effort to read the options first
    • Be mindful of leaving time for review

🔥Strategy for the Exam🔥

Study Strategy:
  • Important Materials

  • Practice Questions

    • Whizlabs Free Questions: Study only the Free Test.

      • 1st pass: 2025/03/24|73%
      • 2nd pass:
    • Udemy Practice Exams

    • 1st pass:

      • Practice Test I|2025/03/23|52%
      • Practice Test 2|2025/03/27|53%
      • Practice Test 3|2025/03/25|43%
    • Review:

      • Practice Test I||
      • Practice Test 2||
      • Practice Test 3||
    • 2nd pass:

      • Practice Test I|2025/03/28|73%
      • Practice Test 2|2025/03/29|81%
      • Practice Test 3|2025/03/29|72%
    • Official Practice Exam

      • 2025/03/24|70%
        • Question 12 - Possible discrepancy between practice set and official exam answers.
      • ||
  • If I have time, read Google SRE articles


Weak Areas

Overview of private pools|Cloud Build

Private pools are a private, dedicated pool of workers that offer greater customization over the build environment, including the ability to access resources in a private network. Similar to default pools, private pools are hosted and fully managed by Cloud Build, and can scale up to or down to zero. You don't need to set up, upgrade, or scale any infrastructure. Since private pools are customer-specific resources, you can configure them in more ways.

Using a cached Docker image|Cloud Build

The easiest way to increase the speed of a Docker image build is by specifying a cached image that can be used for subsequent builds. You can specify the cached image by adding the --cache-from argument in your build config file, which will instruct Docker to build using that image as a cache source.

Caching directories with Google Cloud Storage|Cloud Build

To increase the speed of your build, you can reuse the results from a previous build. You can do this by copying the results of a previous build to a Google Cloud Storage bucket, using the results to compute, and copying the new results back to the bucket. Use this method when your builds take a long time and produce a small number of files that doesn't take long to copy to and from Google Cloud Storage.

Unlike the --cache-from that is only for Docker builds, caching with Google Cloud Storage can be used for any builder supported by Cloud Build.

Use a separate organization for experimenting|Organization

For experimental activities, use a separate organization as a sandbox environment. Using a separate organization lets you work without being constrained by the policies, configurations, and automation that you use in your production organization.

Don't use the staging organization for testing. The staging environment should have IAM policies and organization policies that are similar to your production organization. Consequently, the staging environment might have the same restrictions that are applied to your production environment. At the same time, if you relax policies to allow for testing, the purpose of the staging organization is defeated.

images|Cloud Build

The images field in the build config file specifies one or more Linux Docker images that Cloud Build will push to Artifact Registry or Container Registry. You might have a build that runs tasks without producing a Linux Docker image, but if you build images and don't push them to a registry, the images are discarded on build completion. If a specified image isn't produced at build time, the build will fail. For more information on storing images, see Storing artifacts in Artifact Registry.

artifacts|Cloud Build

The artifacts field in the build config file specifies one or more non-container artifacts to store in Cloud Storage. For more information on storing non-container artifacts, see Storing build artifacts in Cloud Storage.

Log sampling|VPC Flow Logs

  • For VMs, 50% of log entries are kept by default. You can configure this parameter from 1.0 (100%, all log entries are kept) to 0.0 (0%, no logs are kept).
  • For VLAN attachments and Cloud VPN tunnels, 100% of log entries are kept by default. You can configure this parameter from 1.0 to a value greater than 0.0.

Agent policies|Google Cloud CLI

Agent policies are created and managed by using the gcloud beta compute instances ops-agents policies command group in the Google Cloud CLI or by using the agent-policy Terraform module. Agent policies manage OS policies by using the Compute Engine VM Manager tool suite. These policies can automate the deployment and maintenance of software configurations, such as the Google Cloud Observability agents: the Ops Agent, the legacy Monitoring agent, and the legacy Logging agent.

Configuring Terraform to store state in a Cloud Storage bucket|Terraform

By default, Terraform stores state locally in a file named terraform.tfstate. This default configuration can make Terraform difficult for teams, especially when many users run Terraform at the same time and each machine has its own understanding of the current infrastructure.

To help you avoid these issues, this section shows you how to configure a remote state that points to a Cloud Storage bucket. Remote state is a feature of backends and in this tutorial is configured in a backend.tf file. For example:

IAM Conditions overview|IAM Conditions

Example date/time expression The following condition expression in a role binding allows access until midnight on January 1st, 2021:

Build VM images with Packer|Cloud Build

Packer is an open-source tool for creating identical virtual machine (VM) images for multiple platforms from a single source configuration. This page describes how to create VM images for use in Compute Engine with Packer and Cloud Build.

Triggering on Pub/Sub Messages|Spinnaker

Note that Pub/Sub and Spinnaker can be integrated.

create_before_destroy|Terraform

create_before_destroy (bool) - By default, when Terraform must change a resource argument that cannot be updated in-place due to remote API limitations, Terraform will instead destroy the existing object and then create a new replacement object with the new configured arguments.

The create_before_destroy meta-argument changes this behavior so that the replacement object is created first, and the existing object is destroyed after the replacement is created.


HTTP Status Code List
HTTP Status CodeError MessageContext/Cause
400Bad RequestThe request format is invalid (e.g., missing required parameters, invalid values).
401UnauthorizedInvalid authentication credentials or insufficient access permissions.
403ForbiddenLacking access rights, or access is denied by IAM settings.
404Not FoundThe specified resource does not exist (e.g., invalid resource ID).
409ConflictResource conflict, such as during instance creation.
429Too Many RequestsAPI request rate limit has been exceeded.
500Internal Server ErrorAn unexpected error occurred on the server side.
502Bad GatewayAn error occurred at the gateway or proxy.
503Service UnavailableThe service is down, under maintenance, or temporarily unavailable.
504Gateway TimeoutThe request timed out (e.g., after a long wait).

Developer Memo: Udemy Invalid URLs Report

Reported on 2025/03/29

Practice Test 2: Still Invalid URLs References

You oversee an application operating within Google Kubernetes Engine (GKE) and employing the blue/green deployment approach. Portions of the Kubernetes manifests are provided below: ...

Practice Test 2: The following has an incorrect answer key

Your organization aims to elevate the availability target of an application from 99.9% to 99.99% with a $2,000 investment. ...