LEARN. PRACTICE. GROW.Connect image, revision, and request
An image tag can change in the registry, but a Cloud Run revision retains the digest resolved at deployment. In the exercise, stable changes from A to B while production still runs A because no new selected revision exists. The ticket should identify digest and revision rather than only the tag. Then confirm which clients use the normal URL and which use tagged revision URLs. That map avoids confusing artifact functional testing with evidence that production traffic reaches it.
Rehearse the path receiving the percentage
With 90% to the old revision and 10% to the new one on the normal URL, a direct call to the new tagged URL selects that revision. It does not establish a failed 90/10 distribution. Use the appropriate URL for each test goal and record the observed revision. Small samples need not exactly match configured percentages; do not turn a small count into definitive proof. Retain representative authentication and identity so a release test does not bypass controls real clients must satisfy.
Choose the secret-version contract
A secret exposed as an environment variable is retrieved at instance startup. Using latest can make instances started at different times receive different versions. Pinning a version helps make release predictable and rotation plannable. Secrets mounted as files have different read timing that should be assessed under that contract. In either case, service identity needs applicable access. A deployer being able to read the secret does not establish that the application can start with it. Do not embed the value in the image to bypass failure.
Check rollback with fresh startup
The previous revision can be immutable while depending on a secret that has since been disabled. Already-started instances can keep responding while new ones fail. A rollback gate should include fresh startup and compatibility with available data and secret versions. If an old version was withdrawn for a valid reason, do not automatically re-enable it; deploying corrected configuration with an approved version can be preferable. If operations have uncertain outcomes, retain business identities for reconciliation before resubmitting work.
Calculate capacity without promising a hard barrier
Twelve instances with five-connection pools give a nominal estimate of sixty. A configured instance maximum can be briefly exceeded and other clients can also use the database. Do not use multiplication as a strict admission guarantee. Reserve headroom, control pools, and observe effective downstream connections. If the useful limit is sixty with ten reserved, ten five-connection instances use the remaining fifty in this model. Peaks, revision overlap, and behavior when the dependency refuses new connections still need rehearsal.
Compare revisions with correct denominators
In the same window, twelve errors in two hundred new-revision requests give 6%; eight in eight hundred old-revision requests give 1%. The aggregate is 20/1000=2% and can hide regression. Also compare request type and population so causality is not assigned from percentage alone. Search logs using relevant project, service, revision, and window. A filter pinned to the old revision excludes desired evidence. Retain enough correlation to follow an operation without logging tokens or secret values in diagnosis.
Deliver evidence that makes the decision repeatable
The release record should connect digest, revision, secret configuration, runtime identity, traffic target, and observed criteria. Define when promotion stops and who accepts recovery. A lower error rate is insufficient if critical requests stopped reaching the service. Include startup and useful-operation checks per consumer in handover. This lesson’s calculations and models are synthetic; they do not represent a real Cloud Run execution or guarantee subscription behavior without corresponding authorized rehearsal.
Rollback responds on a warm instance but fails when scaling because its pinned secret was disabled. A startup check reveals the dependency before recovery is declared.
Common pitfalls
Confusing retagging with deployment; using tagged URLs to assess global percentages; assuming simultaneous env-secret updates; treating maximum instances as an absolute connection limit.
Related topics: Cloud Run and observability · Secret management and rollback
A recoverable release needs an identified artifact, an observed path, and dependencies that also support fresh startup.
Reference: Cloud Run traffic and rollback · Standard exam guide linked 2026-09-29; edition date unconfirmed