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.
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
| Concept | Meaning | Key difference | Common 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
| Concept | Meaning | Key difference | Common 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
- Classify the problem as data connection, messaging, API consumption, or observability before comparing the answer options, since each category has its own typical fix.
- For datastores, prefer Google connectors, IAM authentication and pooled connections over public IPs and stored passwords.
- For messaging, check acknowledgment timing, idempotency, ordering keys and dead-letter topics in that order before touching publisher code.
- For API calls, confirm the API is enabled, then use client libraries with backoff, pagination, field limits and attached service accounts.
- 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
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.
- AWS Certified Solutions Architect - Associate Study guide
- AWS Certified Cloud Practitioner Study guide
- AWS Certified SysOps Administrator - Associate Study guide
- AWS Certified Solutions Architect - Professional Study guide
- Microsoft 365 Fundamentals Study guide
- Azure Developer Associate Study guide
- Google Cloud Associate Cloud Engineer Study guide
- CompTIA Cloud+ Study guide
- Microsoft Certified: Azure Fundamentals Study guide
- AWS Certified Developer - Associate Study guide
- HashiCorp Certified: Terraform Associate Study guide
- Azure Administrator Associate Study guide
- Azure Solutions Architect Expert Study guide
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
- 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 PCD AI tutor Get any concept explained your way