4.1.3. Cloud Run Operations
💡 First Principle: Operating a Cloud Run service is largely about controlling the transition between versions safely — deploying new revisions without an all-or-nothing cutover, and adjusting capacity automatically as demand changes.
Deploying a new version of a Cloud Run application creates a new revision rather than overwriting the running one, which is what makes safe rollout possible in the first place. Adjusting traffic splitting parameters lets you route a percentage of traffic to the new revision (a canary rollout) while the majority continues to the stable one, gradually shifting the split as confidence grows — and this same traffic-splitting concept applies across Cloud Run, Cloud Run functions, and GKE (via mechanisms appropriate to each). Configuring autoscaling for a Cloud Run application means setting minimum and maximum instance counts — a minimum above zero avoids cold-start latency for latency-sensitive services at the cost of paying for idle capacity, while a maximum protects against runaway scaling during a traffic spike or a misbehaving client.
⚠️ Exam Trap: A scenario emphasizing "we need to test a new version with a small percentage of real traffic before fully committing to it" is describing traffic splitting for a canary rollout, not a blue-green all-or-nothing deployment — the exam expects you to recognize percentage-based gradual rollout as its own distinct pattern.
Reflection Question: A latency-sensitive Cloud Run service is experiencing noticeable delay on its first request after periods of low traffic. Which autoscaling setting addresses that specific symptom, and what's the cost tradeoff of changing it?
