Traffic splitting in Cloud Run shows up often enough on the Professional Cloud Architect exam that it deserves its own write-up. The feature itself is not complicated. What matters is recognizing it as the right answer when a scenario describes gradual rollouts, canary deployments, or A/B testing, because the distractors will push you toward external load balancers, DNS tricks, or running multiple services side by side. None of those are what Cloud Run wants you to do.
A Cloud Run service can have multiple revisions. Every time you deploy a new container image or change configuration, Cloud Run creates a new revision and keeps the old ones around. The service has a routing layer in front of those revisions, and you control what percentage of incoming requests goes to each one.
The canonical setup looks like this. You have a service called my-app. Revision 1 is v1.0, your current stable version, getting 90 percent of traffic. Revision 2 is v1.1, the new version you just deployed, getting 10 percent. Incoming requests hit the routing layer, and Cloud Run distributes them according to the percentages you set.
Two things about this setup matter for the exam. First, this is one Cloud Run service, not two. The revisions are versions of the same service, not separate services. Second, the routing happens inside Cloud Run. There is no external load balancer in this picture, no DNS configuration, no API gateway making the decision.
The exam cares because traffic splitting is the supported pattern for safe deployments on Cloud Run, and Google wants you to use the platform's native capability rather than bolting on infrastructure that is not needed.
Three deployment patterns all reduce to traffic splitting between revisions. Gradual rollouts move traffic from the old version to the new version over time, often starting at a small percentage and increasing as you confirm nothing is broken. Canary deployments send a small slice of traffic to a new version specifically to catch problems before a full rollout. A/B testing sends different users to different versions to compare behavior or measure outcomes. All three are the same mechanic underneath: percentages assigned to revisions of the same service.
If a question describes any of those patterns on Cloud Run, the answer is traffic splitting between revisions. The percentages are configurable to whatever you want. You can adjust them at any time, and a rollback is just shifting traffic back to the previous revision.
The wrong answers on these questions tend to fall into a few buckets, and they are all variations of doing more work than the platform requires.
If you see any of those options paired with a correct-looking answer that says use Cloud Run's built-in traffic splitting between revisions, take the built-in option.
The recognition pattern is short. Cloud Run plus gradual rollout, canary, or A/B testing equals traffic splitting between revisions. One service, multiple revisions, percentages assigned in the routing layer, no external infrastructure required. Rollback is shifting the percentage back. That is the entire framework.
The mental picture worth carrying into the exam is the diagram of one service, the routing layer, and two revisions splitting at a percentage. If you can sketch that from memory, any traffic-splitting question the Professional Cloud Architect exam puts in front of you collapses to the same answer.
My Professional Cloud Architect course covers Cloud Run traffic splitting alongside the rest of the advanced architecture material.
