Instiq
Chapter 4 · Configuring applications for deployment·v1.0.0·Updated 6/15/2026·~13 min

What's changed: Created Professional Cloud Developer Chapter 4 (Domain 3 "Configuring for deployment": deploy to Cloud Run = source deploy/revisions/traffic splitting/Eventarc-Pub/Sub triggers/Apigee; deploy to GKE = Deployment/Service, liveness/readiness probes, Horizontal Pod Autoscaler, Cloud Run vs GKE).

4.2Deploying to GKE

Key points

Understand deploying containerized apps to GKE (Deployments, Services), Kubernetes health checks (liveness/readiness probes) for availability, scaling with the Horizontal Pod Autoscaler, and choosing between Cloud Run and GKE.

For finer control or complex orchestration, deploy to GKE (Kubernetes). Ensure availability and scalability via Kubernetes mechanisms.

4.2.1Deploying and health checks

Place containerized apps with a Deployment (declare desired Pod count) and expose them via a Service. For availability, set health checks (liveness probe = restart on failure; readiness probe = do not send traffic until ready). This prevents requests reaching Pods that are starting or unhealthy. Map "restart on failure = liveness" and "no traffic until ready = readiness."

4.2.2Scaling and choosing

To scale Pod count with load, use the Horizontal Pod Autoscaler (HPA), scaling on CPU utilization or custom metrics. Choose between Cloud Run and GKE by: "serverless, minimal ops = Cloud Run" and "fine control, complex orchestration, existing Kubernetes = GKE." Map "scale Pods by load = HPA" and "minimal ops = Cloud Run, fine control = GKE."

Exam point

Common: requirement → means. E.g., "auto-restart unhealthy Pods" = liveness probe; "no traffic until ready" = readiness probe; "scale Pods with load" = Horizontal Pod Autoscaler; "serverless minimal ops" = Cloud Run; "fine control/complex orchestration" = GKE.

Warning

Watch the mix-ups: (1) Do not confuse liveness (restart) and readiness (traffic gating). (2) HPA scales Pod count, distinct from node scaling (Cluster Autoscaler). (3) Choose Cloud Run vs GKE by ops burden and control.

Diagram of Deployment/Service, liveness (restart)/readiness (traffic gating) probes, Horizontal Pod Autoscaler, and Cloud Run vs GKE.
Control and scale

4.2.3Section summary

  • GKE: Deployment to place, Service to expose; health checks (liveness/readiness) for availability
  • Horizontal Pod Autoscaler scales Pod count with load
  • Minimal ops = Cloud Run; fine control/complex orchestration = GKE

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. To auto-restart an unhealthy Pod, what do you configure?

Q2. To avoid sending traffic to a starting Pod until it is ready, what do you configure?

Q3. To auto-scale the number of Pods with load, what do you use?

Q4. To run containers serverless with minimal ops, which is best?

Q5. For fine control, complex orchestration, or existing Kubernetes assets, which fits?

Q6. Which correctly contrasts liveness and readiness probes?

Check your understandingPractice questions for Chapter 4: Configuring applications for deployment

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.