Overview
This section is about the groundwork that every later pipeline, SLO and dashboard depends on. You design an organization's folders and projects, connect networks with Shared VPC, VPC Network Peering or Private Service Connect, centralize logs and metrics across projects, and govern access with IAM, organization policies and service accounts while respecting data residency rules.
It then moves into how infrastructure is managed and delivered: Terraform, Infrastructure Manager, Config Connector, Helm and GitOps; a CI/CD stack built on Cloud Build, Cloud Deploy and Artifact Registry with third-party tools such as Jenkins and Argo CD; staging and production environments managed as GKE fleets; and secure developer workspaces on Cloud Workstations and Cloud Shell with Gemini Code Assist, Gemini Cloud Assist and Gemini CLI. Google has announced no retirement for this exam as of October 2026.
How it's tested
Section 1 questions read like platform-team design reviews. A scenario gives you an organization size, a governance or compliance constraint and a delivery goal, then asks which structure, tool or policy meets it with the least ongoing toil. Managed Google services usually beat custom scripts unless the scenario names a reason.
-
Where does the control belong?
You pick the hierarchy level (organization, folder, project) for an IAM binding, organization policy constraint or log sink so it covers exactly the intended scope.
-
Pick the IaC or delivery tool
You choose between Terraform, Infrastructure Manager, Config Connector, Helm, Cloud Build and Cloud Deploy based on who owns the resources and how changes are reviewed.
-
Environment isolation
You decide how staging, production and short-lived preview environments are separated and kept consistent, often using projects, fleets and Config Sync.
A company wants every new team project to send audit logs to a security project and block external IPs on VMs. Creating sinks and policies per project would miss future projects. An aggregated sink at the folder or organization level with include-children, plus the organization policy constraint that restricts external IPs set on the parent folder, applies automatically to every project created later.
Objectives 5
Official objectives from the Google Cloud outline, in outline order.
1.1 Designing the overall resource hierarchy for an organizationFolders and projects, shared networking, cross-project observability, IAM, service accounts and data residency.
- What it means
- This covers organizing resources by application, team or environment using folders and projects; connecting networks with Shared VPC, VPC Network Peering or Private Service Connect; monitoring and logging across many projects; applying IAM roles and organization policies; managing service accounts; and meeting data residency requirements.
- What to understand
- IAM bindings and organization policies set on a folder flow down to every project under it. Shared VPC lets a host project own subnets that service projects use, which centralizes network control. Peering joins two VPCs without transitive routing, while Private Service Connect exposes a service privately through an endpoint. A metrics scope lets one project view metrics from many, and aggregated sinks route logs from a whole folder. Resource location restrictions enforce data residency.
- How it shows up
- Expect a multi-team scenario where you choose the folder layout, network model or policy level with the least per-project setup.
- Common confusion
- VPC Network Peering is not transitive; reaching a third network through a peered VPC needs a different design.
1.2 Managing infrastructureInfrastructure as code, Google blueprints and automation scripting.
- What it means
- This covers managing infrastructure with code and managed services such as Infrastructure Manager, Cloud Foundation Toolkit, Config Connector, GitOps workflows, Terraform and Helm, following Google-recommended practices and blueprints when making changes, and automating routine tasks with Python or Go scripts.
- What to understand
- Terraform describes resources declaratively and tracks them in state, which should live in a remote, locked backend such as a Cloud Storage bucket. Infrastructure Manager runs Terraform as a managed Google service. Config Connector lets teams manage Google Cloud resources as Kubernetes objects, which suits GKE-centric shops using GitOps. Cloud Foundation Toolkit provides tested blueprints. Changes should flow through pull requests and plan review, not console edits.
- How it shows up
- Questions ask which IaC approach fits a team's existing tooling and how to stop drift caused by manual changes.
- Common confusion
- Helm packages Kubernetes applications; it does not provision VPCs, projects or other Google Cloud infrastructure.
1.3 Designing a CI/CD architecture stack in Google Cloud, hybrid, and multi-cloud environmentsCloud Build, Cloud Deploy, Artifact Registry, third-party tools and CI/CD security.
- What it means
- This covers using Cloud Build for continuous integration, Cloud Deploy for continuous delivery with Kustomize and Skaffold, configuring Artifact Registry, combining Google tools with third-party options such as Git, Jenkins, Argo CD, Packer and kpt, and securing the CI/CD tooling itself.
- What to understand
- Cloud Build runs build steps in containers and produces artifacts. Cloud Deploy manages a delivery pipeline of ordered targets and promotes releases between them, using Skaffold to render and apply manifests and Kustomize for per-environment overlays. Artifact Registry stores container images and language packages with regional or multi-regional repositories and remote or virtual repositories. Private pools give Cloud Build access to private networks. Build service accounts should hold only the roles each stage needs.
- How it shows up
- A scenario names an existing tool such as Jenkins or Argo CD and asks how to integrate or replace it with minimal disruption.
- Common confusion
- Cloud Build is CI and can deploy, but Cloud Deploy is the service for managed promotion, approvals and rollback across targets.
1.4 Managing multiple environments (e.g., staging, production)Ephemeral environments, configuration and policy, GKE fleets and safe upgrades.
- What it means
- This covers creating and tearing down ephemeral environments, keeping configuration and policy consistent across environments, managing many GKE clusters as fleets, and patching and upgrading clusters and nodes safely and securely.
- What to understand
- Separate projects per environment give clean IAM and billing boundaries. Ephemeral environments for pull requests should be created by automation and deleted automatically to control cost. Fleets group GKE clusters so features like Config Sync and Policy Controller apply consistent configuration and guardrails. Release channels, maintenance windows, exclusions and surge upgrades control how GKE versions roll out with minimal disruption.
- How it shows up
- Expect a question about keeping dozens of clusters consistent or upgrading production without downtime.
- Common confusion
- A release channel picks the version cadence; a maintenance window controls when upgrades may run.
1.5 Enabling secure cloud development environmentsCloud Workstations, Cloud Shell, custom images and Gemini assistants.
- What it means
- This covers configuring and managing Cloud Workstations and Cloud Shell, bootstrapping developer environments with custom container images, IDEs and the Cloud SDK, and using AI assistants such as Gemini Code Assist, Gemini Cloud Assist and Gemini CLI for development and operations work.
- What to understand
- Cloud Workstations runs managed development environments inside your VPC, defined by workstation configurations that reference a container image, so source code stays off laptops and access follows IAM. Custom images preload tools and settings so every developer starts the same way. Cloud Shell offers a quick authenticated terminal but is not meant for long-running or customized team setups. Gemini Code Assist helps write code, while Gemini Cloud Assist helps operate and troubleshoot Google Cloud resources.
- How it shows up
- A security or onboarding requirement is described, and you choose Cloud Workstations, a custom image or the right Gemini tool.
- Common confusion
- Gemini Code Assist targets code in the IDE; Gemini Cloud Assist targets cloud resources and operations.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Folder-level inheritance
IAM bindings and organization policies set on a folder apply to all child projects.
- Remember
- Set shared controls high, exceptions low.
- Tested as
- Governance and scaling scenarios.
- Trap
- Repeating bindings in every project.
-
Shared VPC
A host project owns the network; service projects attach and use its subnets.
- Remember
- Network admins keep control centrally.
- Tested as
- Multi-team networking questions.
- Trap
- Choosing peering when central control is needed.
-
VPC Network Peering
Private connectivity between two VPC networks.
- Remember
- Peering does not chain to a third network.
- Tested as
- Connectivity design questions.
- Trap
- Assuming transitive routing.
-
Private Service Connect
Consumes a producer service privately through an endpoint in your VPC.
- Remember
- Exposes a service, not a whole network.
- Tested as
- Private access to managed or partner services.
- Trap
- Confusing it with peering.
-
Aggregated log sink
A sink on a folder or organization that collects logs from all children.
- Remember
- Enable include-children so new projects are covered.
- Tested as
- Central audit and security logging.
- Trap
- Creating one sink per project.
-
Metrics scope
Lets a scoping project view metrics from many monitored projects.
- Remember
- One place for cross-project dashboards and alerts.
- Tested as
- Multi-project monitoring.
- Trap
- Copying dashboards into every project.
-
Terraform remote state
Terraform state stored in a shared backend with locking.
- Remember
- Use a Cloud Storage backend, never local state for teams.
- Tested as
- IaC collaboration questions.
- Trap
- Committing state files to Git.
-
Config Connector
Manages Google Cloud resources through Kubernetes custom resources.
- Remember
- Fits GitOps teams already running GKE.
- Tested as
- IaC tool selection.
- Trap
- Thinking it replaces Helm for apps.
-
Cloud Deploy
Managed continuous delivery that promotes releases through ordered targets.
- Remember
- Supports approvals, rollbacks and canary deployments.
- Tested as
- CD architecture and promotion.
- Trap
- Using Cloud Build alone for multi-stage promotion.
-
Artifact Registry
Stores container images and packages in standard, remote or virtual repositories.
- Remember
- Replaces Container Registry.
- Tested as
- Artifact management and caching.
- Trap
- Using a public registry directly in production builds.
-
GKE fleets
Logical groups of clusters managed together.
- Remember
- Enable Config Sync and Policy Controller fleet-wide.
- Tested as
- Multi-cluster consistency.
- Trap
- Configuring each cluster by hand.
-
Cloud Workstations
Managed, VPC-hosted developer environments built from container images.
- Remember
- Keeps source code off local devices.
- Tested as
- Secure development scenarios.
- Trap
- Choosing Cloud Shell for persistent team environments.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Connecting networks across projects
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Shared VPC | One host project's VPC used by service projects in the same organization. | Central network ownership with delegated workloads. | It needs an organization; it cannot span unrelated orgs. |
| VPC Network Peering | Direct private routing between two separate VPCs. | Each side keeps its own administration. | Routes do not pass through to a third peered network. |
| Private Service Connect | A private endpoint that reaches a specific published service. | Service-level access rather than network-level. | It does not give broad subnet-to-subnet reachability. |
Infrastructure as code options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Terraform | Declarative IaC with state across many providers. | Broadest coverage, including hybrid and multi-cloud. | State must be stored remotely and locked. |
| Infrastructure Manager | Google-managed service that runs Terraform deployments. | Removes the need to run your own Terraform runners. | It still uses Terraform configurations, not a new language. |
| Config Connector | Kubernetes custom resources that create Google Cloud resources. | Kubernetes-native and GitOps friendly. | It requires a cluster to host the controller. |
| Helm | Package manager for Kubernetes application manifests. | Templating and versioning of in-cluster apps. | It does not create Google Cloud infrastructure. |
Developer environment choices
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Cloud Workstations | Managed, customizable workstations in your VPC. | Team-wide images, private network access and IAM control. | It needs a cluster and configuration set up first. |
| Cloud Shell | Temporary browser terminal with the Cloud SDK preinstalled. | Instant and free for quick tasks. | Its home disk is small and sessions time out. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Per-project log sinks
- What candidates pick
- Create a log sink in each existing project.
- Why it looks right
- It works for the projects that exist today.
- Why it's wrong
- New projects would be missed and the setup creates toil; an aggregated sink at the folder or organization covers them automatically.
Clue to watch for The scenario says new projects are created frequently.
-
Peering as a hub
- What candidates pick
- Peer every spoke to a hub VPC to reach on-premises or other spokes.
- Why it looks right
- Peering is simple and private.
- Why it's wrong
- Peering is not transitive, so spokes cannot reach each other or routes behind the hub through it.
Clue to watch for Traffic must travel through one network to reach another.
-
Cloud Build for promotion
- What candidates pick
- Write Cloud Build steps that deploy to staging, then production.
- Why it looks right
- Cloud Build can run kubectl and gcloud.
- Why it's wrong
- Cloud Deploy provides managed promotion, approvals, rollback and audit history across targets without custom scripting.
Clue to watch for Requirements mention approvals, promotion or rollback between environments.
-
Basic roles for builds
- What candidates pick
- Give the build service account Editor.
- Why it looks right
- It makes every deployment step succeed.
- Why it's wrong
- Editor violates least privilege and widens the blast radius if the pipeline is compromised.
Clue to watch for Any mention of securing CI/CD tooling.
-
Manual cluster configuration
- What candidates pick
- Apply the same manifests to each GKE cluster by hand or with scripts.
- Why it looks right
- Familiar kubectl workflow.
- Why it's wrong
- Fleets with Config Sync and Policy Controller keep many clusters consistent and detect drift with less effort.
Clue to watch for Dozens of clusters, consistency or policy guardrails.
-
Cloud Shell for regulated code
- What candidates pick
- Have developers work in Cloud Shell to avoid local copies.
- Why it looks right
- Cloud Shell is managed and authenticated.
- Why it's wrong
- Cloud Workstations offers VPC placement, custom images and admin controls that suit regulated or team-wide development.
Clue to watch for Requirements for private network access or standard images.
Answer framework
Use these steps when a Section 1 scenario asks how to structure or govern a Google Cloud estate.
- Find the scope of the requirement: one project, a team, an environment or the whole organization, then place the control at the matching hierarchy level.
- Decide whether the need is permissions (IAM), configuration limits (organization policy) or network reachability (Shared VPC, peering, Private Service Connect).
- Choose the infrastructure-as-code tool that matches the team's existing platform, preferring managed options such as Infrastructure Manager or Config Connector.
- Map CI to Cloud Build, CD to Cloud Deploy and storage to Artifact Registry, keeping third-party tools only where the scenario requires them.
- Confirm environments are isolated, consistent and upgraded safely, using separate projects, fleets, release channels and secure developer workstations.
Practice question
Want more like this? The GCP PCDOE practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with the resource hierarchy, because almost every Section 1 answer depends on scope. Build a small organization in a sandbox if you can: two folders, a few projects, a Shared VPC host project and an aggregated log sink sending to a central bucket. Then test an organization policy at the folder level and confirm that projects underneath inherit it. Write down the difference between peering, Shared VPC and Private Service Connect in your own words.
Next, deploy the same small stack twice: once with Terraform using a Cloud Storage backend, and once through Infrastructure Manager. Add a Cloud Build trigger and a two-target Cloud Deploy pipeline that pulls an image from Artifact Registry. Register two GKE clusters to a fleet and sync a namespace from Git. Finish by creating a Cloud Workstations configuration and trying Gemini Code Assist in it. Review release channels and maintenance windows last, then use timed practice questions to check that you can pick the right scope quickly.
FAQ
How much of the GCP PCDOE exam is Bootstrapping and maintaining a Google Cloud organization?
Google's exam guide weights Section 1 at about 20%. On a 50-60 question exam that suggests roughly 10 to 12 questions, though Google does not publish per-section counts.
Do I need deep networking knowledge for this section?
You need design-level networking: when to use Shared VPC, peering or Private Service Connect, and how they affect who controls subnets and firewall rules. Detailed routing and hybrid connectivity are covered more heavily in the Professional Cloud Network Engineer exam.
Is Terraform required knowledge?
The guide names Terraform alongside Infrastructure Manager, Config Connector, Helm and Cloud Foundation Toolkit. Expect to know how state, plans and modules work and when a managed option is a better fit, rather than HCL syntax details.
Why is a CI/CD architecture subsection in Section 1?
Subsection 1.3 is about designing the tool stack: which services run CI, CD and artifact storage and how they are secured. Section 2 then tests building and operating the pipelines on top of that stack.
What is new in Section 1 compared with older guides?
Subsection 1.5 on secure cloud development environments is new. It covers Cloud Workstations, Cloud Shell, custom images and Gemini Code Assist, Gemini Cloud Assist and Gemini CLI.
Is the Professional Cloud DevOps Engineer exam being retired?
As of October 2026, Google had not announced a retirement for this exam. Google revises exam guides without a published changelog, so check the official guide before booking.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
Check whether you can place controls at the right hierarchy level and pick the right IaC and delivery tools under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP PCDOE AI tutor Get any concept explained your way