Integrating Applications with Google Cloud Services
Credentials and authentication
Client libraries use Application Default Credentials. The lookup order is the GOOGLE_APPLICATION_CREDENTIALS file, then the gcloud user credential file, then the metadata server of the attached service account. Write code that never branches on credential source, and never ship key files in an image; on Cloud Run, GKE, and Functions the attached service account is enough. Off-GCP, use Workload Identity Federation. Some APIs need a signed request rather than a token, which is where keyless environments bite.
Messaging and events
Pub/Sub pull subscriptions are for workers that control their own flow; push subscriptions deliver to HTTPS with an OIDC token whose audience must match the receiving service, and the caller needs the invoker role. Extend ack deadlines for long processing, configure dead-letter topics, and enable message ordering on the subscription if you publish ordering keys. Eventarc delivers audit-log, Cloud Storage, and Pub/Sub events to Cloud Run or GKE with built-in retries.
Data services
Cloud SQL from a runtime connects through the Cloud SQL connectors or Auth Proxy, exposed on a Unix socket at /cloudsql/PROJECT:REGION:INSTANCE. Cloud Storage signed URLs require signBlob on the service account, because Cloud Run and Functions have no private key to sign with. Use resumable uploads for large objects and grant narrow object-level permissions.
Observability
Emit structured JSON to stdout so Cloud Logging parses severity and labels; add Cloud Trace spans and let Error Reporting group exceptions. Trap: a 403 on a Pub/Sub push endpoint is almost always an audience or invoker-role mismatch, and a signed-URL failure is almost always missing signBlob or a wrong expiration.
Rule of thumb: if a call can be retried by the client library, make the operation idempotent first.