GCP PCD · Domain 3 of 4

GCP PCD Domain 3: Configuring cloud-native applications for deployment

Section 3 checks that you can ship an application onto Google's two main container platforms: deploying Cloud Run services from source and wiring their event triggers and APIs, then running containers on GKE with health checks and autoscaling.

Exam weight
~24%
Official objectives
2
Estimated questions estimate
12–14
Suggested study time estimate
14–18 hrs

About 11 min read Reviewed October 2026

Overview

Configuring cloud-native applications for deployment has two subsections, each centered on one of Google's container runtimes. Subsection 3.1 covers Cloud Run: deploying from source code, invoking services through Eventarc and Pub/Sub triggers, configuring event receivers that accept CloudEvents or push messages, and versioning, exposing and securing APIs with Apigee.

Subsection 3.2 covers GKE: deploying containerized applications with Kubernetes objects, implementing health checks through liveness, readiness and startup probes, and setting Horizontal Pod Autoscaler attributes such as replica bounds and the metrics that drive scaling. Questions mix platform behavior with configuration detail, so you need both concepts and the knobs that control them.

How it's tested

Items describe an application that fails to start, drops events, scales poorly or exposes an API insecurely after deployment. You pick the configuration change: a trigger filter, an invoker permission, a probe, an autoscaler target or an Apigee proxy. Distractors are usually settings that exist but solve a different problem.

  • Event wiring

    You connect a source such as Cloud Storage, Pub/Sub or audit logs to a Cloud Run service through Eventarc and grant the trigger identity permission to invoke it.

  • Health and readiness

    You pick liveness, readiness or startup probes to fix restarts, early traffic or slow initialization on GKE.

  • Scaling configuration

    You set HPA metrics and bounds on GKE, or concurrency and instance limits on Cloud Run, to match load without wasting resources.

Reasoning it through

A GKE service loads a large model file at startup and Kubernetes keeps restarting the pods before they finish. Raising the liveness timeout for every check would also delay detection of real hangs later. Adding a startup probe holds off liveness checks until initialization succeeds, after which a normal liveness probe catches deadlocks quickly, so the slow start and fast failure detection both work.

Objectives 2

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

3.1 Deploying applications to Cloud RunSource deployments, triggers, event receivers and API versioning and security.
What it means
This objective covers deploying applications to Cloud Run directly from source code, invoking Cloud Run services with triggers such as Eventarc and Pub/Sub, configuring event receivers for those triggers, and versioning, exposing and securing the APIs in those applications, with Apigee as the named example.
What to understand
A source deploy with gcloud run deploy --source uploads code, builds it with buildpacks or a Dockerfile in Cloud Build, stores the image in Artifact Registry and creates a new revision. Revisions are immutable, and tags plus traffic percentages control which ones serve users. Eventarc routes events from Google sources, audit logs and Pub/Sub to a service as CloudEvents over HTTP; the trigger's service account needs the Cloud Run Invoker role. Pub/Sub push subscriptions can call a service directly with an OIDC token. Receivers should return a success code quickly and be idempotent because delivery is at least once. Apigee adds versioned proxies, keys, quotas and OAuth in front of services.
How it shows up
Questions focus on which identity invokes the service, how an event reaches it, and how a new API version is released safely.
Common confusion
Allowing unauthenticated invocations is not needed for Eventarc or Pub/Sub push; grant the invoker role to their service accounts instead.
3.2 Deploying containers to GKEDeploying containerized apps, Kubernetes health checks and Horizontal Pod Autoscaler attributes.
What it means
This objective covers deploying containerized applications to GKE, implementing Kubernetes health checks to improve availability, and incorporating Horizontal Pod Autoscaler attributes such as scaling bounds and metrics.
What to understand
A Deployment manages ReplicaSets and rolling updates for stateless pods, while a Service gives them a stable address and an Ingress or Gateway exposes HTTP routes. Liveness probes restart a container that is stuck; readiness probes remove a pod from Service endpoints until it can serve; startup probes protect slow starters. HPA scales replica counts between minReplicas and maxReplicas based on CPU, memory, custom or external metrics, and needs resource requests set for utilization targets. Autopilot clusters handle node scaling, while Standard clusters use the cluster autoscaler. Workload Identity Federation for GKE lets pods call Google APIs as an IAM principal.
How it shows up
Expect a symptom such as traffic to unready pods or restart loops, then a choice among probe types or HPA settings.
Common confusion
A failed readiness probe stops traffic to the pod but does not restart it; only a failed liveness probe triggers a restart.

High-yield concepts

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

  • Cloud Run source deploy

    gcloud run deploy --source builds and deploys code in one command.

    Remember
    Uses Cloud Build and buildpacks or a Dockerfile, storing the image in Artifact Registry.
    Tested as
    First bullet of 3.1.
    Trap
    Thinking a pre-built image is mandatory for Cloud Run.

  • Revisions and tags

    Each deployment creates an immutable revision that can be tagged with its own URL.

    Remember
    Test a tagged revision with zero traffic before shifting users.
    Tested as
    Safe release scenarios.
    Trap
    Deploying a new service name for every version.

  • Eventarc triggers

    Route events from Google sources, audit logs or Pub/Sub to Cloud Run.

    Remember
    Events arrive as CloudEvents over HTTP POST.
    Tested as
    Named for triggers and receivers.
    Trap
    Forgetting to grant the trigger's service account the invoker role.

  • Pub/Sub push to Cloud Run

    Push subscription calls the service URL with each message.

    Remember
    Use an OIDC token from a service account to authenticate the push.
    Tested as
    Alternative trigger path in the guide.
    Trap
    Opening the service to allUsers so pushes succeed.

  • Idempotent receivers

    Handlers that produce the same result if an event is delivered twice.

    Remember
    At-least-once delivery means duplicates happen.
    Tested as
    Event receiver correctness.
    Trap
    Assuming exactly-once delivery by default.

  • Apigee API proxies

    Managed proxies that version, secure and throttle APIs.

    Remember
    Use base paths or revisions for versions, plus quotas and OAuth policies.
    Tested as
    Named for API versioning and security.
    Trap
    Versioning APIs by overwriting the existing backend.

  • Cloud Run concurrency

    Number of simultaneous requests one instance handles.

    Remember
    Raise it for I/O-bound apps; lower it for CPU-heavy or non-thread-safe code.
    Tested as
    Scaling questions on Cloud Run.
    Trap
    Assuming one request per instance is always required.

  • Liveness probe

    Checks whether a container is still functioning.

    Remember
    Failure restarts the container.
    Tested as
    Kubernetes health checks bullet.
    Trap
    Using it to delay traffic during warm-up.

  • Readiness probe

    Checks whether a pod can accept traffic.

    Remember
    Failure removes it from Service endpoints without a restart.
    Tested as
    Common fix for errors during rollouts.
    Trap
    Expecting it to recover hung processes.

  • Startup probe

    Gates other probes until the app has started.

    Remember
    Prevents slow starters from being killed by liveness checks.
    Tested as
    Slow initialization scenarios.
    Trap
    Setting huge liveness delays instead.

  • Horizontal Pod Autoscaler

    Adjusts pod replicas from metrics.

    Remember
    Set minReplicas, maxReplicas, target metrics and resource requests.
    Tested as
    Third bullet of 3.2.
    Trap
    Confusing HPA with the cluster autoscaler, which adds nodes.

Side by side

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

Kubernetes probe types

ConceptMeaningKey differenceCommon trap
Liveness Is the container still healthy? Failure restarts the container. Making it depend on downstream services, causing cascading restarts.
Readiness Can the pod serve traffic now? Failure removes the pod from load balancing only. Expecting it to restart broken pods.
Startup Has the app finished starting? Disables liveness and readiness checks until it succeeds. Leaving it off for apps with long initialization.

Ways to invoke a Cloud Run service

ConceptMeaningKey differenceCommon trap
Direct HTTPS Clients call the service URL. Needs IAM invoker or public access, depending on design. Making internal services public.
Eventarc Event router delivering CloudEvents. Supports many Google event sources and audit log events with filters. Missing invoker role for the trigger identity.
Pub/Sub push Subscription posts messages to the URL. Simple message-driven invocation with retries. Not acknowledging quickly, causing redelivery.
Cloud Scheduler or Cloud Tasks Timed or queued HTTP calls. Schedules or rate-controls invocations. Using Eventarc for cron-style jobs.

Scaling on Cloud Run and GKE

ConceptMeaningKey differenceCommon trap
Cloud Run autoscaling Instances scale from requests, concurrency and CPU. Configure min and max instances and concurrency. Expecting HPA objects on Cloud Run.
GKE HPA Scales pod replicas from metrics. Requires resource requests for utilization targets. Forgetting maxReplicas limits or requests.

Exam traps

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

  1. Public service for event delivery

    What candidates pick
    Allow unauthenticated invocations on the Cloud Run service.
    Why it looks right
    It instantly fixes 403 errors from the trigger.
    Why it's wrong
    It exposes the service to the internet; the proper fix is granting the invoker role to the trigger or push service account.

    Clue to watch for Eventarc or Pub/Sub deliveries fail with permission errors.

  2. Liveness for warm-up

    What candidates pick
    Increase the liveness probe initial delay to several minutes.
    Why it looks right
    It stops early restarts.
    Why it's wrong
    It also delays detection of genuine hangs after every restart; a startup probe solves warm-up cleanly.

    Clue to watch for The app takes a long, variable time to initialize.

  3. HPA to add nodes

    What candidates pick
    Raise HPA maxReplicas to fix pending pods.
    Why it looks right
    More replicas sounds like more capacity.
    Why it's wrong
    HPA scales pods, not nodes; pending pods need node capacity from Autopilot or the cluster autoscaler.

    Clue to watch for Pods are stuck in Pending with insufficient resources.

  4. New service per API version

    What candidates pick
    Deploy v2 as a separate service and email clients the new URL.
    Why it looks right
    It isolates versions.
    Why it's wrong
    It skips managed versioning, quotas and security; Apigee proxies or Cloud Run revisions with tags manage versions cleanly.

    Clue to watch for Clients need a stable, governed API with versions.

  5. Exactly-once assumption

    What candidates pick
    Write the handler to process each event once without checks.
    Why it looks right
    Most events do arrive once.
    Why it's wrong
    Eventarc and Pub/Sub can redeliver, so non-idempotent handlers create duplicates such as double charges.

    Clue to watch for The handler changes money, inventory or state.

Answer framework

Work through these checks when a deployment question describes a symptom or a release goal.

  1. Name the runtime first, Cloud Run or GKE, because the fixes, objects and terminology differ between the two platforms.
  2. For invocation problems, trace the path: event source, Eventarc trigger or push subscription, identity used, and invoker permission.
  3. For releases, use Cloud Run revisions with tags and traffic percentages, or Kubernetes rolling updates, and manage API versions through Apigee.
  4. For availability symptoms on GKE, match the probe: startup for slow boots, readiness for traffic gating, liveness for hangs.
  5. For load issues, tune Cloud Run concurrency and instance limits, or HPA metrics, replica bounds and container resource requests on GKE, then confirm with load tests.

Practice question

During a rolling update on GKE, users see errors for about thirty seconds while new pods load their caches, even though no pods restart. The deployment has only a liveness probe. What should the developer add to stop users reaching pods that are not ready?

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

Split your study evenly between Cloud Run and GKE, since each subsection is a full runtime. For Cloud Run, deploy the same small app three ways: from source, from an image in Artifact Registry, and as a second revision with a tag and zero traffic. Add an Eventarc trigger on a Cloud Storage bucket and a Pub/Sub push subscription, keep the service private, and fix the permission errors you hit.

For GKE, use an Autopilot cluster and write the Deployment, Service and HPA manifests yourself. Break things on purpose: make the app slow to start, hang it, or make it briefly unready, and observe how each probe type reacts. Generate load and watch the HPA change replica counts.

Then read the Apigee overview pages on proxies, versioning, quotas and OAuth policies. End with timed question sets that describe symptoms and ask for configuration changes, and write down which setting each wrong option actually controls.

FAQ

How much weight does Configuring cloud-native applications for deployment have?

Domain 3, Configuring cloud-native applications for deployment, is about 24% of the exam, making it the second-largest section. Plan for roughly 12 to 14 questions; that count is an editorial estimate.

Is Cloud Deploy part of this section?

The current guide does not name Cloud Deploy. It focuses on Cloud Run deployments, Eventarc and Pub/Sub triggers, Apigee, and GKE deployments with probes and autoscaling.

Do I need to write Kubernetes YAML?

You should be able to read and reason about Deployment, Service, probe and HPA definitions. Exact field syntax matters less than knowing what each setting does.

Why does Apigee appear in a deployment section?

Subsection 3.1 includes versioning, exposing and securing APIs, and Apigee is the named example. Know proxies, API products, quotas and OAuth verification at a conceptual level.

What should I know about Eventarc?

Know event sources, trigger filters, CloudEvents format, the service account used by the trigger and the invoker role it needs. Also know Pub/Sub as the transport for many triggers.

Are Cloud Run jobs in scope?

The guide focuses on services, triggers and receivers. Jobs may appear as context for batch work, but service deployment and invocation deserve most of your time.

Other Cloud Computing certifications

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

Test your Domain 3 knowledge

Try timed Section 3 questions on Cloud Run triggers, Apigee versioning, GKE probes and autoscaling to confirm you can choose the right setting quickly.

Take the GCP PCD practice test Check your GCP PCD readiness

Keep going