Google Cloud Platform Intermediate

Cloud SQL is Google Cloud’s fully managed relational database service, supporting MySQL, PostgreSQL, and SQL Server. Google handles patching, backups, replication, and failover, so you focus on schema and queries rather than running the engine yourself.

Key features include automated backups and point-in-time recovery, high availability (HA) via a synchronously replicated standby in a second zone, and read replicas to scale read traffic. You connect securely through the Cloud SQL Auth Proxy or with private IP over your VPC.

Cloud SQL is best for transactional (OLTP) workloads up to tens of terabytes. For very large, globally distributed relational needs with horizontal scaling, you would reach for Cloud Spanner instead. Choose the machine type and storage to match your workload, and enable HA for production.

Firestore is a fully managed, serverless document database. Data lives in documents (sets of key-value fields) organised into collections. It scales automatically, offers strong consistency, and provides real-time listeners that push changes to clients — ideal for web and mobile apps.

Firestore runs in Native mode (the modern API with real-time updates and offline support) or Datastore mode (compatible with the older Datastore API). You query by field values and build composite indexes for multi-field queries. Pricing is based on document reads, writes, deletes, and stored data.

Firestore shines for hierarchical, semi-structured data and apps needing live synchronisation. It is not designed for analytical scans over huge tables — for that you would use BigQuery or Bigtable.

Cloud Bigtable is a fully managed, wide-column NoSQL database built for massive analytical and operational workloads — think time-series data, IoT telemetry, financial ticks, and ad-tech. It delivers single-digit millisecond latency at very high throughput and scales to petabytes.

Bigtable stores rows sorted by a single row key; there are no secondary indexes or joins. Designing the row key well (to spread writes and group related reads) is the most important performance decision. It is compatible with the HBase API and integrates with Dataflow, Dataproc, and BigQuery.

Use Bigtable when you need sustained high read/write throughput on huge datasets. For small datasets or rich document queries, Firestore is simpler and cheaper.

Cloud Functions runs small, single-purpose pieces of code in response to events without you managing servers. A function can be triggered by an HTTP request, a Pub/Sub message, a Cloud Storage object change, or other event sources. You pay only for execution time and invocations.

2nd-generation Cloud Functions are built on Cloud Run and Eventarc, giving longer timeouts, larger instances, concurrency, and more event sources. Functions scale to zero when idle and scale out automatically under load.

They are ideal for glue logic: resizing an uploaded image, processing a queue message, or responding to a webhook. For long-running services or full containers, Cloud Run is the better tool.

Cloud Run runs stateless containers in a fully managed, serverless environment. You package your app as a container image, deploy it, and Cloud Run handles scaling — including scale to zero — and gives you an HTTPS endpoint automatically. You bring any language or framework that listens on a port.

Cloud Run supports concurrency (many requests per container instance), configurable CPU and memory, request and event triggers, and gradual traffic splitting between revisions for safe rollouts. Each deploy creates an immutable revision.

Choose Cloud Run when you want serverless economics with full container flexibility, more control than Cloud Functions, but without managing a Kubernetes cluster like GKE.

App Engine is Google’s original platform-as-a-service (PaaS) for running web applications without managing infrastructure. It comes in two environments: standard (fast-starting sandboxed runtimes that scale to zero) and flexible (apps run in containers on managed Compute Engine VMs, allowing custom runtimes).

You configure the app with an app.yaml file describing the runtime, scaling, and routing. App Engine supports versions and traffic splitting, and an app can have multiple services (formerly modules) that together form one application.

App Engine suits classic web apps and APIs where you want automatic scaling and minimal operations. For container-first serverless, many teams now choose Cloud Run, which shares much of the same underlying technology.

Google Kubernetes Engine (GKE) is a managed Kubernetes service. Google operates the control plane (API server, scheduler, etcd) while you run workloads on nodes grouped into node pools. GKE handles upgrades, auto-repair, and integration with Google Cloud networking and IAM.

GKE offers two modes: Standard, where you manage and pay for nodes, and Autopilot, where Google provisions and bills per-Pod resources for a hands-off experience. Features include cluster autoscaling, the horizontal Pod autoscaler, and Workload Identity for secure access to Google APIs.

Use GKE when you need full Kubernetes — complex microservices, custom controllers, or portability — and are willing to manage more than Cloud Run requires.

Artifact Registry is Google Cloud’s managed repository for container images and language packages (Maven, npm, Python, and more). It is the successor to Container Registry and offers regional repositories, fine-grained IAM, and vulnerability scanning.

You create a repository, authenticate Docker against the regional host (for example europe-north1-docker.pkg.dev), then push and pull images. GKE, Cloud Run, and Cloud Functions all pull images from Artifact Registry, and Cloud Build can push to it as part of CI/CD.

Keeping images in a regional repository close to your runtime reduces pull latency and egress, and IAM lets you grant least-privilege read or write access per repository.

Cloud Load Balancing distributes traffic across backends for availability and scale. The global external Application Load Balancer serves HTTP(S) traffic from a single anycast IP, routing users to the nearest healthy backend worldwide and supporting URL maps, SSL, and Cloud CDN.

For non-HTTP traffic there are network load balancers (TCP/UDP), which can be passthrough (preserving client IPs) or proxy-based. Backends can be managed instance groups, network endpoint groups (NEGs) for serverless or containers, and health checks remove unhealthy backends automatically.

Choose a global Application Load Balancer for worldwide web apps and a regional or network load balancer for regional or non-HTTP workloads.

A managed instance group (MIG) runs identical VM instances from an instance template. The MIG keeps the desired number of instances running, recreates failed ones (autohealing), and can span multiple zones for resilience. MIGs are the standard backend for load balancers on Compute Engine.

Autoscaling adds or removes instances based on signals such as average CPU utilisation, load-balancing capacity, or custom Cloud Monitoring metrics. You set minimum and maximum sizes and a target utilisation, and the autoscaler adjusts within those bounds.

MIGs also enable rolling updates: you change the template and roll the new version across instances gradually, with surge and unavailable limits to protect availability.

A Virtual Private Cloud (VPC) on Google Cloud is global: one VPC spans all regions, with subnets that are regional. Three patterns connect and structure networks. Shared VPC lets a host project share its network with service projects, centralising network administration while teams deploy into their own projects.

VPC Network Peering privately connects two VPCs (even across organisations) so resources communicate using internal IPs, without a gateway or VPN. Peering is non-transitive: if A peers with B and B with C, A and C are not connected.

Private Google Access lets VMs without external IPs reach Google APIs and services (like Cloud Storage) over Google’s internal network, improving security by keeping traffic off the public internet.

Cloud NAT provides managed network address translation so VMs and GKE nodes without external IPs can make outbound connections to the internet (for updates, package downloads, or APIs). It does not allow unsolicited inbound connections, which improves security by keeping instances private.

Cloud DNS is a scalable, managed Domain Name System service. You create managed zones — public zones for internet-facing names and private zones resolvable only within your VPC — and add record sets (A, AAAA, CNAME, MX, TXT). Cloud DNS offers high availability and low-latency, anycast-served resolution.

Together, Cloud NAT keeps instances private while still allowing egress, and Cloud DNS gives you authoritative name resolution for public and internal services.

Cloud CDN caches your content at Google’s globally distributed edge points of presence, serving users from a location near them. It works with the global external Application Load Balancer: you enable CDN on a backend service or backend bucket, and cacheable responses are stored at the edge.

Caching is governed by HTTP Cache-Control headers and cache modes (for example cache static content or use origin headers). Cloud CDN reduces latency for users, lowers load on your origin, and cuts egress cost. You can invalidate cached objects when content changes.

Pair Cloud CDN with a backend bucket (Cloud Storage) for static assets, or with a compute backend for dynamic apps that still have cacheable responses.

Google Cloud IAM grants members (users, groups, service accounts) roles on resources. A role is a bundle of permissions. Basic roles (Owner, Editor, Viewer) are broad and discouraged for production. Predefined roles are curated per-service (e.g. roles/storage.objectViewer) and follow least privilege. Custom roles let you assemble exactly the permissions you need when no predefined role fits.

A service account is a non-human identity used by applications and workloads. Prefer granting roles to service accounts and, on GKE, use Workload Identity to bind Kubernetes service accounts to Google service accounts, avoiding long-lived key files.

IAM policies are inherited down the resource hierarchy (organisation → folder → project → resource), so a grant at a higher level applies below it.

Secret Manager stores sensitive values — API keys, passwords, certificates — as secrets with automatically managed versions. Access is governed by IAM, every access can be audit-logged, and apps fetch secrets at runtime rather than baking them into images or code. You can pin to a specific version or use latest.

Cloud KMS (Key Management Service) manages cryptographic keys used for encryption and signing. Keys live in key rings, support rotation, and can be software-backed or HSM-backed. KMS underpins customer-managed encryption keys (CMEK), letting you control the keys that protect data in services like Cloud Storage and BigQuery.

Use Secret Manager for secrets your app reads, and KMS when you need to manage the encryption keys themselves or sign data.

The Google Cloud Operations suite (formerly Stackdriver) provides observability. Cloud Monitoring collects metrics, builds dashboards, and fires alerting policies when conditions breach thresholds, with notifications via email, PagerDuty, or Pub/Sub. Uptime checks probe endpoints from multiple locations.

Cloud Logging centralises logs from Google Cloud services and your apps. You query with the Logs Explorer, route entries with log sinks to Cloud Storage, BigQuery, or Pub/Sub, and define log-based metrics. The suite also includes Cloud Trace (latency), Cloud Profiler, and Error Reporting.

Good operations means dashboards for the golden signals (latency, traffic, errors, saturation), alerts on what users feel, and sinks that retain logs for compliance.

Pub/Sub is a fully managed, scalable messaging service for decoupling producers and consumers. Publishers send messages to a topic; subscribers receive them via a subscription. This publish-subscribe pattern lets many services react to events independently and absorb traffic spikes.

Subscriptions are pull (consumers fetch and acknowledge) or push (Pub/Sub posts to an HTTPS endpoint). Pub/Sub guarantees at-least-once delivery, so consumers should be idempotent. Features include message ordering keys, dead-letter topics for poison messages, and retention.

Use Pub/Sub for event-driven architectures, streaming ingestion into Dataflow or BigQuery, and fan-out where one event triggers many independent workflows.

Cloud Storage holds objects in buckets with a globally unique name. It offers four storage classes that trade lower storage price for higher access cost and minimum storage duration: Standard (hot, frequent access), Nearline (≈ monthly access), Coldline (≈ quarterly), and Archive (rarely accessed, long-term). All classes share the same API and millisecond access.

Object Lifecycle Management automates transitions and deletions with rules — for example, move objects to Coldline after 30 days and delete after 365. Object Versioning retains overwritten and deleted versions, and retention policies can lock objects for compliance.

Choose Standard for active data and colder classes plus lifecycle rules to cut cost for aging data without changing your application code.

Resilience depends on good backups. Persistent disk snapshots capture the state of a Compute Engine disk; they are incremental (only changed blocks after the first), stored redundantly, and can be regional or multi-regional. You can automate them with a snapshot schedule (resource policy) and create new disks from a snapshot.

Cloud SQL provides automated backups plus point-in-time recovery (PITR) using write-ahead logs, so you can restore to a specific second. Other services have their own backup mechanisms — Firestore exports, GKE Backup, and Cloud Storage versioning.

A sound strategy defines a retention period, tests restores regularly, and stores critical copies in a different region to survive a regional outage.

Infrastructure as Code (IaC) declares your infrastructure in version-controlled files instead of clicking the console. Terraform (with the Google provider) is the most widely used tool: you write HCL describing resources, run plan to preview changes, and apply to converge real infrastructure to the desired state, tracked in a state file.

Google’s native option is Cloud Deployment Manager, which uses YAML/Jinja/Python templates, though many teams now standardise on Terraform (and Infrastructure Manager, a managed Terraform service). IaC gives you repeatability, review via pull requests, and easy environment cloning.

Store state remotely (e.g. a Cloud Storage backend with locking), keep modules reusable, and never edit resources by hand once they are managed by code.

Cloud Build is Google’s managed CI/CD service. A build is defined in a cloudbuild.yaml file as a sequence of steps, each running in a container. Typical steps build a Docker image, run tests, push to Artifact Registry, and deploy to Cloud Run, GKE, or App Engine.

Builds are triggered manually, by triggers on repository events (push or pull request from GitHub, Bitbucket, or Cloud Source Repositories), or on a schedule. Builds run with a service account whose IAM roles must permit the deployments. You can store artifacts and use substitutions for variables like the commit SHA.

Cloud Build pairs naturally with IaC and Artifact Registry to form a full pipeline from commit to production deploy.