What's changed: Created Professional Cloud Developer Chapter 5 (Domain 4 "Integration" part 1: data/storage/messaging = Cloud SQL/Firestore/Cloud Storage connections, connection pool, Cloud SQL Auth Proxy, ADC, Pub/Sub publish/subscribe/at-least-once/dead-letter; consuming Google Cloud APIs = enabling services, client libraries/REST/gRPC, batching/restrict/pagination/caching, exponential backoff, service accounts).
5.1Integrating data, storage, and messaging
Understand managing connections to datastores (Cloud SQL, Firestore, Cloud Storage), reading/writing across data sources, publishing/consuming data with Pub/Sub, and connection security/pooling/auth (e.g., Cloud SQL Auth Proxy).
Apps deliver value by integrating with datastores and messaging, not in isolation. Managing connections securely and efficiently is key.
5.1.1Connecting to datastores
Apps connect to multiple datastores—Cloud SQL, Firestore, Cloud Storage—to read/write. Reuse connections via a connection pool to avoid excessive connections. For secure Cloud SQL connections, use the Cloud SQL Auth Proxy (IAM auth and encryption without exposing a public IP). Authenticate via Application Default Credentials (ADC) and service accounts. Map "secure Cloud SQL connection = Cloud SQL Auth Proxy" and "reuse connections = connection pool."
5.1.2Publishing and consuming via messaging
Pub/Sub is messaging that decouples publishers from subscribers. Publishers send messages to a topic; subscribers receive from a subscription (push/pull). This absorbs spikes, enables async processing, and delivers to multiple subscribers. Design for ordering, duplicates (at-least-once), and dead-letter topics. Map "loosely coupled async delivery = Pub/Sub publish/subscribe."
Common: requirement → means. E.g., "secure Cloud SQL connection without exposing a public IP" = Cloud SQL Auth Proxy; "prevent connection exhaustion" = connection pool; "decouple publisher/subscriber" = Pub/Sub; "absorb spikes, async processing" = Pub/Sub subscriptions; "park failed messages" = dead-letter topic.
Watch the mix-ups: (1) Pub/Sub is typically at-least-once—handle duplicates idempotently. (2) Without a connection pool, connection exhaustion is likely. (3) Cloud SQL Auth Proxy is the secure connection method, preferred over a direct public IP.
5.1.3Section summary
- Datastore connections via ADC + service accounts; Cloud SQL via Auth Proxy; reuse via connection pool
- Pub/Sub decouples publish/subscribe (absorb spikes, async, multiple subscribers)
- Pub/Sub is at-least-once—process idempotently; failures to dead-letter
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To connect to Cloud SQL securely with IAM auth/encryption without exposing a public IP, what do you use?
Q2. To reuse database connections and prevent exhaustion, which best fits?
Q3. To decouple publishers/subscribers and deliver messages asynchronously, which is best?
Q4. Pub/Sub is typically at-least-once. What should the subscriber design for duplicates?
Q5. To park messages that repeatedly fail processing, what do you use in Pub/Sub?
Q6. What is the basic way for an app to authenticate to Google Cloud services?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.