GCP PCD · Domain 2 of 4

GCP PCD Domain 2: Building and testing applications

Section 2 tests the inner and outer development loop: a productive local setup with emulators and AI assistants, container builds in Cloud Build stored in Artifact Registry with provenance, and automated unit and integration tests.

Exam weight
~23%
Official objectives
3
Estimated questions estimate
11–14
Suggested study time estimate
12–16 hrs

About 12 min read Reviewed October 2026

Overview

This section follows code from a developer's laptop to a tested, signed container image. Subsection 2.1 is about the development environment: emulating services such as Pub/Sub, Firestore, Bigtable and Spanner locally through the Google Cloud CLI, working in the Google Cloud console, Cloud Shell, Cloud Workstations and Cloud Code, using Gemini Cloud Assist, and wiring IDEs to the Cloud SDK and AI tooling such as coding assistants and MCP servers.

Subsection 2.2 covers building and storing containers from source with Cloud Build and Artifact Registry and configuring build provenance that Binary Authorization can check. Subsection 2.3 covers writing unit tests with help from AI coding assistants and running automated integration tests as Cloud Build steps. It is the most AI-flavored part of the April 2026 guide.

How it's tested

Questions are practical and workflow-shaped. A team wants faster feedback, cheaper test runs, secure builds or consistent developer machines, and you choose the tool or configuration change. Wrong answers often call real cloud resources from unit tests, store images in the wrong registry, or skip provenance.

  • Local first

    You choose a gcloud emulator or Cloud Code local run so tests avoid real cloud resources, cost and shared state.

  • Build pipeline steps

    You read or design a cloudbuild.yaml with build, test, push and attestation steps in the correct order with the right service account.

  • Governed developer tooling

    You pick Cloud Workstations, Cloud Shell or IDE integrations, including AI assistants and MCP servers, that meet security and consistency requirements.

Reasoning it through

Developers' unit tests write to a shared Firestore database, so runs collide and costs climb. Mocking every call would hide query behavior. Starting the Firestore emulator with gcloud and pointing the client library at it through the emulator host environment variable gives each run an isolated, free datastore with realistic behavior, and the same setup works inside a Cloud Build step.

Objectives 3

Official objectives from the Google Cloud outline, in outline order.

2.1 Setting up your development environmentLocal emulation, console and CLI tools, Cloud Code, Cloud Workstations, Gemini Cloud Assist and IDE integrations.
What it means
This objective covers emulating Google Cloud services with the Google Cloud CLI for local development and unit testing; using the Google Cloud console, Cloud SDK, Cloud Code, Gemini Cloud Assist, Cloud Shell and Cloud Workstations; and configuring IDEs with the right integrations, such as the Cloud SDK and AI tooling like coding assistants and MCP servers.
What to understand
The gcloud emulators for Pub/Sub, Firestore, Datastore, Bigtable and Spanner run locally and are selected by environment variables, so client code stays unchanged. Cloud Code adds Kubernetes and Cloud Run support plus local runs to VS Code and JetBrains IDEs. Cloud Workstations provides managed, centrally configured development environments inside your VPC, which suits regulated teams. Cloud Shell is a free, temporary browser terminal. Gemini Cloud Assist helps operate and understand Google Cloud resources, while coding assistants such as Gemini Code Assist work in the IDE. MCP servers expose tools and data to AI agents, so their permissions need the same least-privilege care as any service account.
How it shows up
Expect scenarios asking how to test locally without touching production, or how to give contractors a secure, uniform environment.
Common confusion
Cloud Shell is a short-lived personal terminal; Cloud Workstations is a governed, persistent environment an administrator configures.
2.2 BuildingCloud Build and Artifact Registry for containers, plus build provenance.
What it means
This objective covers using Cloud Build and Artifact Registry to build containers from source code and store them, and configuring provenance in Cloud Build so that tools such as Binary Authorization can verify how and where an image was built.
What to understand
Cloud Build runs steps defined in cloudbuild.yaml, each in its own container, under a specified service account, and can be started by triggers from repository events. It can build with a Dockerfile or with buildpacks, which need no Dockerfile. Artifact Registry stores container images and language packages in regional or multi-regional repositories, supports vulnerability scanning through Artifact Analysis, and replaces the deprecated Container Registry. Cloud Build generates signed SLSA build provenance for images it pushes, and Binary Authorization policies can require that attestation before a deployment is allowed. Private pools run builds inside a peered network when builds must reach private resources.
How it shows up
Look for answers that build in Cloud Build, push to Artifact Registry, and use provenance or attestations rather than manual image checks.
Common confusion
Container Registry is deprecated; new answers should store images in Artifact Registry repositories.
2.3 TestingUnit tests with AI coding assistants and automated integration tests in Cloud Build.
What it means
This objective covers writing unit tests with the help of AI coding assistants and running automated integration tests in Cloud Build as part of the pipeline.
What to understand
AI coding assistants can generate test cases, edge cases and mocks quickly, but the developer still reviews assertions, keeps tests deterministic and makes sure generated tests check behavior rather than mirror the code. Giving an assistant good context, such as interfaces, existing tests and requirements, is the practical side of context engineering. Unit tests should run fast without network access, using emulators or fakes. Integration tests in Cloud Build can start emulators or dependent containers as steps, run against a test project, and fail the build before the image is pushed or promoted.
How it shows up
Questions ask where a test belongs in the pipeline and how to keep it isolated, repeatable and cheap.
Common confusion
AI-generated tests are a starting point; accepting them unreviewed can lock in existing bugs as expected behavior.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • gcloud emulators

    Local stand-ins for Pub/Sub, Firestore, Datastore, Bigtable and Spanner.

    Remember
    Point clients at them with emulator host environment variables; code does not change.
    Tested as
    First bullet of subsection 2.1.
    Trap
    Assuming every service has an emulator, such as BigQuery or Cloud Storage through gcloud.

  • Cloud Code

    IDE extensions for VS Code and JetBrains.

    Remember
    Supports Cloud Run and Kubernetes development, local runs and debugging.
    Tested as
    Listed among required developer tools.
    Trap
    Confusing it with Cloud Build, which runs remote builds.

  • Cloud Workstations

    Managed development environments running in your project and VPC.

    Remember
    Admins control images, network access and idle shutdown.
    Tested as
    Fits security and consistency scenarios.
    Trap
    Choosing Cloud Shell for long-lived, governed team environments.

  • Gemini Cloud Assist

    AI assistance for designing, operating and troubleshooting Google Cloud resources.

    Remember
    Works across the console and resources, not only in code.
    Tested as
    Named directly in 2.1.
    Trap
    Treating it as the same product as an in-IDE code completion assistant.

  • MCP servers

    Model Context Protocol endpoints that expose tools and data to AI assistants and agents.

    Remember
    Scope their credentials and data access tightly.
    Tested as
    New AI tooling bullet in 2.1.
    Trap
    Granting an MCP server broad project roles for convenience.

  • cloudbuild.yaml

    Build config listing ordered steps, images and options.

    Remember
    Each step runs in a container; steps can run in parallel with waitFor.
    Tested as
    Pipeline reading questions.
    Trap
    Forgetting to list images so they are not pushed and recorded.

  • Buildpacks

    Build container images from source without a Dockerfile.

    Remember
    Used by Cloud Run source deploys and available in Cloud Build.
    Tested as
    Links Section 2 builds to Section 3 source deployments.
    Trap
    Thinking a Dockerfile is always required.

  • Artifact Registry

    Regional package and container repository service.

    Remember
    Supports Docker, Maven, npm, Python and more, with IAM per repository.
    Tested as
    Storage target named in 2.2.
    Trap
    Picking the deprecated Container Registry.

  • Build provenance

    Signed metadata describing how, where and from what source an artifact was built.

    Remember
    Cloud Build can produce SLSA provenance that deploy policies check.
    Tested as
    Configuring provenance is an explicit bullet.
    Trap
    Equating provenance with a vulnerability scan.

  • Cloud Build service account

    Identity used by build steps to reach other services.

    Remember
    Use a user-specified, least-privilege account per trigger.
    Tested as
    Security-minded build questions.
    Trap
    Granting the build broad Editor permissions.

  • Integration tests as build steps

    Steps that run tests against emulators, containers or a test project.

    Remember
    A failing step stops the build before push or release.
    Tested as
    Second bullet of 2.3.
    Trap
    Running integration tests only after deploying to production.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Developer environments

ConceptMeaningKey differenceCommon trap
Cloud Shell Browser terminal with gcloud and a small persistent home directory. Free, quick, personal and temporary sessions. Using it as a team's standard governed workspace.
Cloud Workstations Managed, configurable dev environments in your VPC. Central policy, custom images and private network access. Assuming it is just a hosted IDE with no admin controls.
Local IDE with Cloud Code Developer machine plus Google Cloud extensions. Fast inner loop with emulators and local runs. Forgetting it still needs ADC credentials for real resources.

Testing layers

ConceptMeaningKey differenceCommon trap
Unit tests Small tests of functions and classes. Run in milliseconds with fakes or emulators and no network. Calling real cloud APIs from unit tests.
Integration tests Tests of components working with real or emulated services. Run as Cloud Build steps before push or promotion. Skipping them because unit coverage is high.
AI-assisted test generation Assistants propose tests from code and context. Speeds authoring; humans still verify intent. Treating generated tests as proof of correctness.

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Shared test project for unit tests

    What candidates pick
    Point unit tests at a dedicated shared Firestore database.
    Why it looks right
    It feels realistic.
    Why it's wrong
    Shared state makes runs flaky and adds cost; emulators give isolated, repeatable runs.

    Clue to watch for Tests interfere with each other or must run offline.

  2. Cloud Shell for governed teams

    What candidates pick
    Standardize on Cloud Shell for all contractors.
    Why it looks right
    It is free and preconfigured.
    Why it's wrong
    Sessions are personal and temporary, with limited admin control; Cloud Workstations is built for governed environments.

    Clue to watch for Admins must control images and network access.

  3. Scan equals provenance

    What candidates pick
    Turn on vulnerability scanning to prove where images came from.
    Why it looks right
    Both are supply chain features.
    Why it's wrong
    Scanning lists known CVEs but says nothing about the build source or builder; provenance attests to that.

    Clue to watch for A policy must prove images were built by the trusted pipeline.

  4. Broad permissions for MCP or assistants

    What candidates pick
    Give the AI tool's service account Editor so it never fails.
    Why it looks right
    It avoids permission errors.
    Why it's wrong
    Agents act on whatever they can reach; broad roles widen the blast radius of a bad suggestion or prompt injection.

    Clue to watch for The assistant can call tools against cloud resources.

  5. Tests after deployment

    What candidates pick
    Deploy to production, then run integration tests.
    Why it looks right
    It tests the real environment.
    Why it's wrong
    Defects reach users first; integration tests should gate the pipeline before release.

    Clue to watch for The team wants failures to stop the release.

Answer framework

Apply these steps when a question is about the developer workflow, build or test stage.

  1. Identify the stage involved: local inner loop, build, unit testing, integration testing, or storing and signing the artifacts that later get deployed.
  2. For local work, prefer gcloud emulators and Cloud Code so tests stay isolated, quick and free of cloud cost, and avoid touching shared projects.
  3. For team environments with security needs, choose Cloud Workstations and scope AI tooling and MCP server access tightly.
  4. For builds, use Cloud Build with a dedicated service account, push to Artifact Registry in the right region and enable provenance generation.
  5. Place integration tests as build steps that fail fast, so only verified and attested images move toward deployment.

Practice question

A security policy requires that only container images built by the company's trusted pipeline can run in production. The team already builds with Cloud Build and pushes to Artifact Registry. What should the developer configure to meet the policy with the least custom work?

Want more like this? The GCP PCD practice test has questions for every domain.

Checklist

0 of 11

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Treat this section as hands-on practice rather than reading. Install the Google Cloud CLI and Cloud Code, start the Pub/Sub and Firestore emulators, and write a few unit tests that run against them. Then open a Cloud Workstations configuration and Cloud Shell side by side and note what an administrator controls in each.

Next, write a cloudbuild.yaml from scratch: a test step, a build step, a push to Artifact Registry and an integration test step that starts an emulator. Run it with a dedicated service account and inspect the build provenance it records. Read the Binary Authorization quickstart so you can trace how an attestation is checked.

Finally, spend time with an AI coding assistant such as Gemini Code Assist. Ask it to generate tests for a small function, then deliberately find weaknesses in what it writes. Read about MCP servers and the permissions they need. Close with timed questions on Section 2 and keep a list of every tool you mixed up.

FAQ

What share of the exam does Building and testing applications cover?

Domain 2, Building and testing applications, is about 23% of the Professional Cloud Developer exam. That works out to roughly 11 to 14 questions on a typical form, an editorial estimate since Google publishes only percentages.

Will the exam test specific AI coding assistant products?

The guide refers to AI coding assistants and MCP servers generically, with Gemini Cloud Assist named in 2.1. Know how Google's assistants fit the workflow and the security considerations, not keyboard shortcuts.

Which emulators should I know?

The gcloud CLI provides emulators for Pub/Sub, Firestore, Datastore, Bigtable and Spanner. Know how to start one and how the client library is redirected to it with environment variables.

Is Container Registry still tested?

Container Registry is deprecated and the guide names Artifact Registry for storing containers. Choose Artifact Registry in any new design.

Do I need to know SLSA levels in detail?

Know that Cloud Build produces signed provenance describing the build and that Binary Authorization can enforce it. Memorizing every SLSA level is less useful than understanding what provenance proves.

How deep is the Cloud Build coverage?

Expect build configuration, triggers, service accounts, pushing images and running tests as steps. Cloud Deploy release management is not an explicit objective for this exam.

Other Cloud Computing certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 2 knowledge

Practice Section 2 questions on emulators, Cloud Build pipelines, provenance and AI-assisted testing to find which parts of the build loop need more work.

Take the GCP PCD practice test Check your GCP PCD readiness

Keep going