GCP PCD · Domain 4 of 4

GCP PCD Domain 4: Integrating applications with Google Cloud services

Section 4 is where application code meets Google Cloud: connecting to datastores and messaging, calling Google APIs efficiently and safely, and instrumenting code so issues can be found with Google Cloud Observability, Error Reporting and AI assistance.

Exam weight
~21%
Official objectives
3
Estimated questions estimate
10–13
Suggested study time estimate
14–18 hrs

About 12 min read Reviewed October 2026

Overview

Integrating applications with Google Cloud services is the code-level section of the exam. Subsection 4.1 covers managing connections to Cloud SQL, Firestore and Cloud Storage, reading and writing data across Google Cloud data sources, and publishing and consuming messages. Subsection 4.2 covers enabling services and calling Google APIs through Cloud Client Libraries, REST, gRPC or API Explorer, with batching, field restriction, pagination, caching, exponential backoff and service account credentials.

Subsection 4.3 covers troubleshooting: instrumenting code with metrics, logs and traces in Google Cloud Observability, resolving issues from that telemetry, managing errors in Error Reporting, correlating spans with trace IDs and using AI-assisted observability. Calling generative AI models, such as Gemini through the Gemini Enterprise Agent Platform (formerly Vertex AI), follows the same client library, quota and retry rules.

How it's tested

Expect code-adjacent scenarios: an app exhausts database connections, hits quota errors, loses messages, returns partial lists or produces logs that cannot be tied to a request. You pick the library feature, connector, retry policy or instrumentation step that fixes it with the least custom code.

  • Connection management

    You choose the Cloud SQL language connectors or Auth Proxy, pooling, and IAM database authentication to connect securely without exposing public IPs or passwords.

  • Resilient API calls

    You apply exponential backoff with jitter, pagination, field masks and batching when calling Google APIs or model endpoints.

  • Find the failing hop

    You use trace IDs, structured logs, Error Reporting and metrics to locate which service or dependency caused latency or errors.

Reasoning it through

A Cloud Run service calls three downstream services and one request in fifty is slow. Searching each service's logs separately is slow and inconclusive. Propagating trace context with OpenTelemetry and writing structured logs that include the trace field lets Cloud Trace show the slow span and Logs Explorer filter every log line for that same request, pointing directly at the slow dependency.

Objectives 3

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

4.1 Integrating applications with data and storage servicesDatastore connections, reading and writing data, and messaging.
What it means
This objective covers managing connections to Google Cloud datastores such as Cloud SQL, Firestore and Cloud Storage, reading and writing data to and from Google Cloud data sources, and writing applications that publish and consume data through messaging services.
What to understand
For Cloud SQL, use the Cloud SQL language connectors or Cloud SQL Auth Proxy for IAM-authorized, encrypted connections, keep a connection pool sized to instance limits, and prefer IAM database authentication over stored passwords where supported. Firestore clients use transactions and batched writes for consistency. Cloud Storage clients support resumable uploads for large objects and signed URLs for direct client transfers. Pub/Sub publishers can batch messages and use ordering keys; subscribers choose pull or push, must acknowledge within the deadline, and should be idempotent. Dead-letter topics capture messages that keep failing.
How it shows up
Questions present connection exhaustion, slow uploads, duplicate or out-of-order messages and ask for the client-side fix.
Common confusion
Ordering keys guarantee order only within one key and require ordering enabled on the subscription; they do not order the whole topic.
4.2 Consuming Google Cloud APIsEnabling services, API call options and efficiency, error handling and service accounts.
What it means
This objective covers enabling Google Cloud services and making API calls through Cloud Client Libraries, the REST API, gRPC or API Explorer while batching requests, restricting returned data, paginating, caching results and handling errors with exponential backoff. It also covers using service accounts to authenticate API calls.
What to understand
An API must be enabled in the project before calls succeed, otherwise you see a service-disabled error. Cloud Client Libraries are the recommended option: they handle Application Default Credentials, pagination iterators, retries for idempotent calls and gRPC transport where available. Field masks or the fields parameter reduce payloads; page tokens walk large result sets; batch endpoints cut round trips. Retry 429 and 5xx responses with exponential backoff and jitter, and do not retry permanent 4xx errors. On Google Cloud runtimes, attach a service account instead of embedding keys. Generative AI calls to Gemini models follow the same patterns.
How it shows up
Look for answers that rely on client library features and proper credentials rather than hand-built HTTP and fixed retry loops.
Common confusion
Exponential backoff applies to transient errors such as 429, 500 and 503, not to 400 or 403 responses.
4.3 Troubleshooting and observabilityInstrumentation, issue resolution, Error Reporting, trace IDs and AI-assisted observability.
What it means
This objective covers instrumenting code with metrics, logs and traces in Google Cloud Observability, identifying and resolving issues with that telemetry, managing application issues in Error Reporting, using trace IDs to correlate trace spans across services, and using AI-assisted observability.
What to understand
Google Cloud Observability includes Cloud Logging, Cloud Monitoring and Cloud Trace, and accepts OpenTelemetry instrumentation. Structured JSON logs written to stdout on Cloud Run and GKE are parsed automatically, and a logging.googleapis.com/trace field links log entries to a trace. Custom metrics can be written from code or derived from logs as log-based metrics. Error Reporting groups exceptions from logs, shows first and last seen and lets teams track resolution. Trace context headers propagate the trace ID between services so spans join into one request view. AI-assisted observability, such as Gemini Cloud Assist investigations, summarizes logs and suggests likely causes for a human to confirm.
How it shows up
Scenarios ask how to find a slow or failing hop, group repeating errors, or add telemetry with minimal code change.
Common confusion
Cloud Logging stores events and Cloud Trace stores latency spans; a log entry alone does not show end-to-end timing.

High-yield concepts

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

  • Cloud SQL connectors and Auth Proxy

    Libraries and a local proxy that open IAM-authorized, encrypted connections.

    Remember
    No need to allowlist IPs or manage SSL certificates manually.
    Tested as
    Connection management in 4.1.
    Trap
    Opening a public IP to 0.0.0.0/0 to fix connectivity.
  • Connection pooling

    Reusing a limited set of database connections across requests.

    Remember
    Size pools to instance limits, especially when serverless instances scale out.
    Tested as
    Fixes too-many-connections errors.
    Trap
    Opening a new connection per request on Cloud Run.
  • Pub/Sub acknowledgment

    Subscribers confirm processing so messages are not redelivered.

    Remember
    Ack after work succeeds; extend deadlines for long work.
    Tested as
    Messaging reliability.
    Trap
    Acking before processing, which loses messages on crash.
  • Dead-letter topics

    Topics receiving messages that exceed max delivery attempts.

    Remember
    Prevents poison messages from blocking processing.
    Tested as
    Error handling for consumers.
    Trap
    Retrying failing messages forever.
  • Ordering keys

    Pub/Sub feature ensuring in-order delivery per key.

    Remember
    Ordering must be enabled on the subscription too.
    Tested as
    Out-of-order scenarios.
    Trap
    Expecting global topic ordering.
  • Cloud Client Libraries

    Idiomatic Google-maintained libraries per language.

    Remember
    Built-in auth, retries, pagination and gRPC where available.
    Tested as
    Preferred API call option in 4.2.
    Trap
    Writing raw HTTP calls without retry or auth helpers.
  • Field masks and pagination

    Ways to limit response size and walk large results.

    Remember
    Use fields or field masks and next page tokens.
    Tested as
    Named considerations for API calls.
    Trap
    Assuming a single list call returns everything.
  • Exponential backoff with jitter

    Retries with growing, randomized delays.

    Remember
    Only for transient or rate-limit errors.
    Tested as
    Named error-handling technique.
    Trap
    Immediate tight retry loops that amplify outages.
  • Enabling APIs

    Turning on a service in a project before use.

    Remember
    Errors cite the service being disabled or not used in the project.
    Tested as
    First bullet of 4.2.
    Trap
    Granting more IAM roles to fix a disabled API error.
  • Structured logging with trace field

    JSON logs including severity and trace identifiers.

    Remember
    Lets Logs Explorer and Cloud Trace link entries to a request.
    Tested as
    Instrumentation and trace ID bullets.
    Trap
    Printing plain text that cannot be filtered by request.
  • Error Reporting

    Groups and tracks application exceptions from logs.

    Remember
    Shows counts, first seen and resolution status.
    Tested as
    Named in 4.3.
    Trap
    Building custom alerting on raw log text for every exception.
  • OpenTelemetry

    Vendor-neutral instrumentation for traces, metrics and logs.

    Remember
    Exports to Google Cloud Observability.
    Tested as
    Instrumenting code with minimal lock-in.
    Trap
    Thinking proprietary agents are the only option.
  • AI-assisted observability

    Gemini Cloud Assist and related tools that analyze telemetry.

    Remember
    Speeds investigation; findings still need verification.
    Tested as
    New 4.3 bullet.
    Trap
    Accepting an AI root-cause suggestion without checking the evidence.

Side by side

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

Google Cloud Observability signals

ConceptMeaningKey differenceCommon trap
Logs (Cloud Logging) Timestamped event records. Best for detail on what happened in one request. Using logs alone to measure latency across services.
Metrics (Cloud Monitoring) Numeric time series. Best for trends, SLO tracking and alerting. Writing a log line per request instead of a counter metric.
Traces (Cloud Trace) Spans showing request timing across services. Best for finding which hop is slow. Not propagating trace context between services.
Error Reporting Grouped exceptions from logs. Best for tracking recurring crashes and their status. Expecting it to catch errors that are never logged.

API call options

ConceptMeaningKey differenceCommon trap
Cloud Client Libraries Language-native libraries maintained by Google. Handle auth, retries, paging and transport for you. Avoiding them for convenience of raw HTTP.
REST API HTTP and JSON calls to service endpoints. Works from any language or tool; you handle auth and paging. Forgetting to send an OAuth access token.
gRPC Binary protocol over HTTP/2. Lower latency and streaming support. Assuming every API exposes gRPC.
API Explorer Browser tool to try API methods. Good for testing requests, not production use. Treating it as an integration method for apps.

Exam traps

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

  1. Public IP allowlisting for Cloud SQL

    What candidates pick
    Add the serverless service's outbound IPs to authorized networks.
    Why it looks right
    It is a familiar firewall pattern.
    Why it's wrong
    Serverless egress IPs change and public exposure adds risk; the Cloud SQL connectors or Auth Proxy authorize by IAM.

    Clue to watch for Cloud Run or GKE must reach Cloud SQL securely.

  2. IAM fix for a disabled API

    What candidates pick
    Grant the service account a broader role.
    Why it looks right
    Permission errors usually mean IAM.
    Why it's wrong
    If the error says the service is not enabled, no role will help; the API must be enabled in the project.

    Clue to watch for The error message names the API as disabled.

  3. Fixed-interval retries

    What candidates pick
    Retry every second until success.
    Why it looks right
    Simple and quick.
    Why it's wrong
    Synchronized retries overload a struggling service; exponential backoff with jitter spreads them out.

    Clue to watch for Many clients hit 429 or 503 errors at once.

  4. Logs for latency analysis

    What candidates pick
    Add timestamps to logs in every service and compare them.
    Why it looks right
    Logs are already there.
    Why it's wrong
    Manual correlation is slow and error-prone; traces with propagated IDs show cross-service timing directly.

    Clue to watch for One request in many is slow across several services.

  5. Global ordering in Pub/Sub

    What candidates pick
    Enable ordering on the topic so all messages arrive in order.
    Why it looks right
    Ordering is a Pub/Sub feature.
    Why it's wrong
    Ordering applies per ordering key, and only when the subscription enables it.

    Clue to watch for Events for each customer must be processed in sequence.

  6. Trusting AI root cause blindly

    What candidates pick
    Apply the fix suggested by AI analysis immediately.
    Why it looks right
    It is fast and often right.
    Why it's wrong
    AI-assisted observability suggests hypotheses; logs, metrics and traces should confirm the cause before changing production.

    Clue to watch for The question stresses verifying the cause.

Answer framework

Use these steps for integration and troubleshooting questions that describe code behavior or errors.

  1. Classify the problem as data connection, messaging, API consumption, or observability before comparing the answer options, since each category has its own typical fix.
  2. For datastores, prefer Google connectors, IAM authentication and pooled connections over public IPs and stored passwords.
  3. For messaging, check acknowledgment timing, idempotency, ordering keys and dead-letter topics in that order before touching publisher code.
  4. For API calls, confirm the API is enabled, then use client libraries with backoff, pagination, field limits and attached service accounts.
  5. For troubleshooting, use metrics to detect, traces to locate, logs and Error Reporting to explain, and AI assistance to speed up the review of evidence.

Practice question

A Cloud Run service lists objects in a Cloud Storage bucket with millions of files using the client library, then calls a rate-limited Google API for each object. Under load it receives many HTTP 429 responses. What should the developer do?

Choose one answer

Want more like this? The GCP PCD 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

Study this section with an editor open. Pick one language you know and write a small service that connects to Cloud SQL through the connector library, reads and writes Firestore, uploads to Cloud Storage and publishes to Pub/Sub. Add a pull subscriber with explicit acknowledgment and a dead-letter topic, then send it a message that always fails.

Then call a Google API through the client library and through REST so you can see what the library does for credentials, paging and retries. Force a quota error and watch the retry behavior. Note which status codes are safe to retry.

For the troubleshooting subsection, instrument two services with OpenTelemetry, emit structured logs with the trace field, and follow one request in Cloud Trace and Logs Explorer. Throw an exception and find it in Error Reporting. Try Gemini Cloud Assist on the same incident and compare its summary with what the telemetry shows. Finish with timed practice on Section 4 questions.

FAQ

What percentage of the exam is Integrating applications with Google Cloud services?

Domain 4, Integrating applications with Google Cloud services, is about 21% of the Professional Cloud Developer exam. That is roughly 10 to 13 questions, an editorial estimate since Google does not publish item counts by section.

Will I need to read code on the exam?

Questions are multiple choice and focus on concepts, but they may describe code behavior or show short snippets. Knowing client library behavior helps more than memorizing syntax.

Are generative AI APIs tested here?

The guide does not list a gen AI subsection. Its role description mentions generative AI APIs, so treat model calls through the Gemini Enterprise Agent Platform as another Google API that needs credentials, quotas and backoff.

What is the difference between Cloud Trace and Cloud Logging?

Cloud Trace records timing spans across services for a request, while Cloud Logging stores event records. Trace IDs in structured logs connect the two views.

Which messaging service does the guide mean?

The guide says messaging services in general, and Pub/Sub is the main Google Cloud option to know, including push and pull, acknowledgment, ordering keys and dead-letter topics.

What does AI-assisted observability mean for the exam?

Expect awareness of tools such as Gemini Cloud Assist that summarize telemetry and suggest causes, and of the need to verify those suggestions with logs, metrics and traces.

Other Cloud Computing certifications

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

Test your Domain 4 knowledge

Run Section 4 practice questions on connections, Pub/Sub, client libraries, retries and tracing to see where your integration knowledge is thin.

Keep going