Traffic splitting is one of App Engine's signature features and shows up reliably on the Associate Cloud Engineer exam. This article covers what it is, how versions work in App Engine, the specific rule about splitting across versions and not services, and the exam patterns that test this.
It does not cover every gcloud flag, blue/green deployments outside App Engine, or canary deployments in GKE. Those are related concepts, but the exam tests App Engine traffic splitting specifically when it tests this topic.
Every time you deploy your code to App Engine, you can create a new version. Old versions stick around. They keep their own configuration, their own URL, and they can still receive traffic if you route it to them. This is unusual compared to most deployment systems, where the old version disappears when the new one ships. In App Engine, every version you have ever deployed is potentially still alive.
That is what makes traffic splitting possible. You always have somewhere to send the old traffic.
Traffic splitting lets you route a percentage of incoming requests to one version and the rest to another. You can split between any number of versions, with any percentages, as long as they add up to 100. Ninety percent to v1, ten percent to v2 is a common pattern. Fifty-fifty is another.
The Associate Cloud Engineer exam lists two main use cases. A/B testing, where you expose a new feature to a small group while most users stay on the stable version. And gradual rollouts, where you ramp the new version up slowly and roll back if something breaks.
You can split traffic from the gcloud command line:
gcloud app services set-traffic SERVICE_NAME \
--splits=v1=0.9,v2=0.1Or you can configure it in the App Engine console.
This is the detail the ACE exam tests. Traffic splitting is between different versions of an app, not across different services. App Engine has a concept of services, which are independent components within an app. Each service has its own versions. Splitting traffic happens within a service, between its versions, not from one service to another.
If you see an exam question that describes splitting traffic between two services, that is wrong. If it describes splitting between two versions of the same service, that is right.
A canary deployment is a pattern where a new version is released to a small subset of users first, watched for problems, and then ramped up if everything looks good. App Engine traffic splitting is the implementation of canary deployments on App Engine. Send one percent to v2, watch the metrics, send ten percent, watch again, eventually send all traffic.
If you see canary in an Associate Cloud Engineer exam question about App Engine, traffic splitting is the answer.
If you see a question about gradually rolling out a new version of an App Engine app, the answer is traffic splitting with --splits or the equivalent in the console. The whole answer is right there.
If you see a question about A/B testing a feature on App Engine, the answer is also traffic splitting. Send some percentage of users to the version with the new feature, leave the rest on the old one, measure what happens.
If you see a question describing a deployment that broke production and asks how to roll back quickly, traffic splitting is the answer. Move all traffic back to the previous version. The old version is still running because App Engine keeps it around. No redeploy needed.
If you see a question about splitting traffic between two services, look for the option that splits between versions instead. That is the trap.
Traffic splitting in App Engine routes a percentage of requests between versions of a service. It is how you do gradual rollouts, A/B tests, and canary deployments on App Engine. It works between versions of a service, not between services. The Associate Cloud Engineer exam tests this with phrases like gradual rollout, A/B test, canary, and rollback.
My Associate Cloud Engineer course covers App Engine versions, traffic splitting, and the deployment patterns the ACE exam tests.
