You want to enable your development team to deploy new features to an existing Cloud Run service in production. To minimize the risk associated with a new revision, you want to reduce the number of…

Question

Options

• AAsk your customers to retry access to your service with exponential backoff to mitigate any
• BGradually roll out the new revision and split customer traffic between the revisions to allow
• CSend all customer traffic to the new revision, and roll back to a previous revision if you witness
• DDeploy your application to a second Cloud Run service, and ask your customers to use the

• A
  12% (2)
• B
  76% (13)
• C
  6% (1)
• D
  6% (1)

Explanation

Gradual traffic splitting in Cloud Run lets you route a small percentage of live traffic to the new revision while keeping most customers on the stable version - if the new revision fails, only a fraction of users are affected, and you can instantly redirect traffic back with zero downtime. This is the Google-recommended approach for safe production rollouts.

Why the distractors fail:

• A is wrong because requiring customers to implement retry logic shifts the operational burden onto them, which the question explicitly forbids.
• C is wrong because sending all traffic to the new revision eliminates the risk-reduction benefit - a bad revision immediately affects every customer before you can react.
• D is wrong because deploying a second Cloud Run service and asking customers to change endpoints introduces customer-facing operational cost (they must update their configurations), which the question also forbids.

Memory tip: Think of traffic splitting as a dimmer switch - you ease the new revision into production gradually rather than flipping all the lights off at once (C) or making your customers rewire the room themselves (A and D).

No community discussion yet for this question.