Deployment strategies solve the critical problem of how to update a live application without crashing it for existing users. For the Google Professional Cloud Developer exam, you must understand the three main methods — rolling, blue/green, and canary — because they are the difference between a seamless update and a site-wide outage.
Jump to a section
A simple way to picture Configuring Deployment Strategies and Rollbacks
When a restaurant needs to renovate its kitchen, it cannot simply close for a month without losing all its customers and revenue. Instead, the head chef plans a precise approach to keep serving meals while the work happens. This directly mirrors how software deployment works.
First, the chef decides to do a 'rolling renovation'. She replaces one old stove with a new one while the other stoves stay on. If the new stove works perfectly, she replaces the second one tomorrow, and so on until the whole kitchen is upgraded. If the new stove explodes, she only lost one station, not the entire kitchen — that is a rollback.
Next, for a 'blue/green renovation', the chef secretly builds a complete second kitchen (the 'green' kitchen) in the basement. She tests it with a few trusted staff members. When it is perfect, she instantly switches service to the green kitchen. The old blue kitchen remains untouched for weeks, ready to be switched back if the green kitchen fails.
Finally, for a 'canary renovation', the chef sends out a single canary — a small bird used by miners to detect gas. If the canary survives, the air is safe. Here, she lets the new kitchen serve just one table of customers. If those customers enjoy their meal and no complaints come back, the new kitchen is safe to open for everyone. If the canary (that one table) gets sick, the chef shuts the new kitchen immediately.
Each strategy exists for one reason: to let the chef change the kitchen without ever forcing hungry customers to wait, and to give her a fast escape plan if the change goes wrong.
Deployment is the process of putting a new version of your software onto the servers where users can access it. In the early days of IT, this meant taking the entire website offline, copying files over, and hoping nothing broke. That approach is called a 'big bang deployment' and it is incredibly risky: if the new version has a bug, every single user experiences it at the same moment.
To reduce this risk, modern cloud developers use controlled deployment strategies. The three main strategies you need to know for the PCD exam are rolling, blue/green, and canary deployments. Each one allows you to manage risk by updating only part of your system at a time, and each one has a built-in rollback plan if something goes wrong.
A 'rollback' is the act of reverting to a previous stable version of your software. Think of it as an undo button for a deployment. The best rollbacks are fast, automated, and tested beforehand — you should never be figuring out how to rollback while a disaster is happening.
Let us break down each strategy.
Rolling Deployment A rolling deployment updates instances (individual copies of your application) one at a time or in small groups. Suppose you have 10 instances running version 1.0 of your app behind a load balancer (a device that distributes incoming traffic across all healthy instances). In a rolling deployment, you tell your orchestration system — like Google Kubernetes Engine (GKE) or a managed instance group — to replace one instance with version 2.0. The load balancer automatically stops sending traffic to the old instance while it updates, then re-adds it once it passes a health check (a simple test that confirms the instance is responding correctly). Then the system moves to the next instance, and so on.
The main advantage is that your application never goes completely offline. If version 2.0 crashes the first instance, the rolling deployment pauses, and you can rollback by reverting that single instance. The disadvantage is that during the update, some users see the old version and some see the new one, which can cause inconsistency.
Blue/Green Deployment Blue/green deployment keeps two identical environments running: the 'blue' environment (the current live version) and the 'green' environment (the new version). You deploy version 2.0 to the green environment and run extensive tests on it while blue still serves all live traffic. Once you are confident green works, you switch the router (the load balancer or traffic manager) so that all users hit the green environment. The blue environment remains untouched, ready to become the new green for your next update, or to serve as an instant rollback target if green fails.
The rollback here is trivially simple: just flip the traffic back to blue. The downside is cost, because you are paying for two full environments simultaneously. Blue/green is also sometimes called 'red/black' deployment in certain contexts.
Canary Deployment A canary deployment is named after the miner's canary — a bird that would die if poison gas was present, warning the miners to escape. In software, you route a small percentage of users (say 1%) to the new version while the other 99% stay on the old one. This is usually done by modifying the load balancer rules or using a service mesh (a dedicated infrastructure layer for handling service-to-service communication). You monitor metrics like error rates, latency, and user complaints. If the canary group shows no problems after a set period (maybe 10 minutes or an hour), you gradually increase the percentage until all users are on the new version. If the canary fails, you simply route all traffic back to the old version.
Canary deployments are excellent for testing real-world traffic patterns and catching subtle bugs that unit tests might miss. However, they require sophisticated traffic management and monitoring tools, which are part of Google Cloud's offerings like Cloud Load Balancing and Traffic Director.
Why these strategies matter for the exam The PCD exam expects you to understand not just what each strategy is, but when to use each one. Rolling deployments are good for simple updates with minimal risk. Blue/green deployments are best for high-stakes updates where a fast, clean rollback is critical, and you can afford the extra infrastructure cost. Canary deployments are ideal for testing risky changes — like new algorithms or database schema changes — on a small user base first.
You should also understand that rollbacks are not automatic in all cases. Rolling deployments may require manual intervention or a configured rollback policy. Blue/green rollbacks are instant as long as you keep the old environment alive. Canary rollbacks require cutting traffic back to zero for the new version, which your monitoring system should trigger automatically.
Choose the Deployment Strategy
Based on your risk tolerance, budget, and rollback speed requirements, decide between rolling, blue/green, or canary. For example, if you need instant rollback and can afford extra infrastructure, choose blue/green. If you want to test with real users gradually, choose canary. If you want minimal extra cost, choose rolling.
Configure the Deployment Environment
For each strategy, set up the necessary infrastructure. For rolling, prepare a managed instance group or GKE cluster with health checks. For blue/green, create a second identical environment. For canary, configure your load balancer or service mesh to support weighted traffic splitting. This step requires understanding Google Cloud services like Cloud Load Balancing and Traffic Director.
Define Rollback Parameters
Before deploying, specify exactly how to revert if something goes wrong. For rolling, decide which instance template to revert to. For blue/green, ensure the old environment remains accessible. For canary, set the traffic weight back to zero. Document and automate this rollback process in a script or deployment pipeline.
Execute the Deployment
Trigger the deployment through your CI/CD pipeline or directly via the Google Cloud Console. Monitor the deployment progress using Cloud Monitoring dashboards. Watch health check status, error rates, latency, and user-reported issues. In a rolling deployment, verify that each batch passes health checks before the next batch starts.
Monitor and Verify
After the deployment completes, continue monitoring for a soak period (e.g., 30 minutes to 48 hours depending on the strategy). Check that all instances are healthy and that user metrics are normal. For canary deployments, gradually increase traffic percentage while monitoring at each step. For blue/green, verify the new environment thoroughly before terminating the old one.
Handle Rollback if Necessary
If monitoring reveals issues, execute your pre-planned rollback procedure. For blue/green, switch traffic back to the old environment. For rolling, revert the instance template and restart the update. For canary, set traffic weight to zero. After rollback, investigate the root cause using Cloud Logging and fix the bug before attempting another deployment.
Imagine you are a cloud developer at an e-commerce company called ShopFast. Your team has built a new checkout flow that reduces the number of clicks from five to three. You are excited, but scared: if the new flow has a bug, you could lose thousands of pounds of revenue per minute. Your boss tells you to deploy it safely.
Here is what a real-world IT professional would do step by step.
First, you open the Google Cloud Console and navigate to the Compute Engine or GKE section where your application runs. You identify that ShopFast runs on 20 virtual machine (VM) instances behind a Cloud Load Balancer. You need to decide which deployment strategy fits the risk. Because the checkout flow directly affects revenue, you choose a canary deployment to start.
You configure the load balancer to send 2% of traffic to the new version. In Google Cloud, you might use Traffic Director or a weighted backend service to split traffic. You also set up Cloud Monitoring alerts that will page you if the error rate on the canary instances exceeds 0.5% or if checkout latency doubles.
For the next 30 minutes, you watch the dashboards. The canary performs well — no errors, and latency actually dropped. You decide to increase the canary to 10%, then 50%, watching after each step. After an hour at 100%, you confirm the new checkout flow is stable. You then terminate the old instances to save costs.
Now imagine the opposite: two minutes after the canary starts, you get an alert that the error rate just hit 5%. You immediately change the load balancer weight back to 0% for the new version. Then you investigate the logs (recorded event data) in Cloud Logging to find the bug. Your rollback was manual but fast because you had a plan.
In a different scenario, if your company requires zero downtime and you have budget for two environments, you might instead use a blue/green deployment. You would:
Deploy the new checkout flow to the 'green' environment with its own set of 20 VMs.
Run automated integration tests that simulate checkout from the green environment.
Verify that the green environment can connect to the production database correctly.
Switch the load balancer to point all traffic to green.
Keep the blue environment running for 48 hours in case you need to rollback.
After 48 hours, terminate blue to save money.
If you chose a rolling deployment for a smaller feature, you would use a managed instance group (MIG) with a rolling update configuration. You set the 'maxSurge' to 1 (meaning you can spin up one extra instance during the update) and 'maxUnavailable' to 0 (meaning you should never have fewer than 20 instances serving). The MIG automatically replaces instances one at a time, verifying health checks after each replacement. If a health check fails, the update pauses and you can manually rollback by reverting to the old instance template.
The key takeaway for IT professionals: you always plan the rollback before the deployment. You script it, test it, and make sure your team knows how to execute it. In a real incident, manual panic is the enemy — automation and pre-planned rollback strategies are your friends.
The PCD exam tests 'Configuring Deployment Strategies and Rollbacks' in two main question types: scenario-based multiple choice and technical architecture best practices. You will not be asked to write YAML, but you will need to select the correct strategy for a given set of constraints.
Here are the specific concepts the exam loves to test:
When to choose each strategy: The exam will give you constraints like 'must minimise cost, must have zero downtime, must be able to rollback instantly'. You must map those to the correct strategy. For example, 'zero downtime and instant rollback' points to blue/green if cost is not a concern, or rolling if cost is limited.
The concept of 'maxSurge' and 'maxUnavailable': These are parameters in rolling updates for managed instance groups and GKE. 'maxSurge' is the number of extra instances you can create during the update. 'maxUnavailable' is the number of instances that can be unavailable during the update. The exam expects you to understand how setting maxSurge to 0 and maxUnavailable to 1 means you take down one instance at a time, ensuring no extra cost but potentially slower updates.
Health checks: Every deployment strategy relies on health checks to determine success. The exam will test that you know a failing health check pauses the deployment.
Traffic splitting for canary: You need to know that canary deployments require a load balancer or service mesh that supports weighted routing. Google Cloud's HTTP(S) Load Balancer and Traffic Director both support this.
Rollback mechanisms: For blue/green, rollback is a traffic switch. For rolling, you revert the instance template or container image tag. For canary, you reset traffic weights to zero.
Common traps the exam sets:
Trap 1: Confusing blue/green with canary because both involve two versions running simultaneously. The difference is that in blue/green, all users see the new version after the switch; in canary, you expose only a subset to the new version.
Trap 2: Believing rolling updates are always the cheapest. If you set maxSurge to a high number, you spin up extra instances, increasing cost during the update.
Trap 3: Forgetting that rollback is not automatic. The exam will present a scenario where developers assume a rollback happens by itself. The correct answer will stress that you must configure and test the rollback separately.
Trap 4: Mixing up 'rolling' with 'recreate' (big bang). The question might describe taking all instances down at once — that is 'recreate' strategy, not rolling.
Key definitions to memorise for the exam:
Rolling deployment: Updates instances in batches, controlled by maxSurge and maxUnavailable.
Blue/green deployment: Two identical environments, switch traffic between them.
Canary deployment: Route a small percentage of traffic to new version, gradually increase.
Rollback: Reverting to a previous version using a pre-defined process.
Health check: A probe that confirms an instance is responding correctly before it receives traffic.
The exam expects you to read a scenario, identify the most important constraint (cost, speed of rollback, user impact), and match it to the correct strategy. Practise with scenario-based questions until you can eliminate two wrong answers immediately.
Rolling updates replace instances one by one or in small batches, keeping the application available throughout the process.
Blue/green deployments use two parallel environments to enable instant, zero-downtime rollbacks by switching traffic between them.
Canary deployments expose a small percentage of users to a new version first, allowing real-world testing before full rollout.
A rollback must be planned, automated, and tested before the deployment begins — never improvise a rollback during an incident.
The three main deployment strategies are rolling, blue/green, and canary; each serves a different risk and cost profile.
Health checks are the gatekeepers of any deployment — a failing health check pauses the update but does not automatically revert it.
maxSurge and maxUnavailable are critical parameters for controlling the speed and cost of rolling deployments in managed instance groups.
The PCD exam tests your ability to select the right deployment strategy based on constraints like downtime tolerance, cost, and rollback speed.
In a canary deployment, gradually increasing traffic percentage is safer than jumping from 1% to 100% in one step.
Blue/green deployments are sometimes called 'red/black' deployments in certain tools and contexts.
These come up on the exam all the time. Here's how to tell them apart.
Rolling Deployment
Updates instances one by one or in small batches
No extra infrastructure cost beyond current instances (if maxSurge is low)
Rollback requires reverting the instance template and re-running the update
Blue/Green Deployment
Maintains two complete environments simultaneously
Doubles infrastructure cost during the deployment window
Rollback is instant by switching traffic back to the old environment
Canary Deployment
Exposes a small percentage of real users to the new version gradually
Uses traffic splitting on a single load balancer
Rollback is gradual: reduce traffic weight to zero
Blue/Green Deployment
Switches all users to the new version at once after testing
Requires two separate infrastructure stacks
Rollback is instant: switch traffic to the old environment
Rolling Deployment
Replaces instances in place, not creating a parallel version
Does not support traffic splitting; users are randomly assigned to instances
Best for low-risk updates where consistency matters less
Canary Deployment
Runs both old and new versions concurrently for a subset of users
Requires a load balancer that supports weighted traffic routing
Ideal for high-risk changes needing real-world validation before full rollout
Recreate Deployment (Big Bang)
Terminates all instances at once, then spins up new ones
Causes total downtime during the deployment
Simple to implement but extremely risky for production
Rolling Deployment
Keeps some instances running during the update
Zero or minimal downtime depending on configuration
More complex but much safer for production
Automated Rollback
Triggered automatically by monitoring alerts (e.g., error rate spike)
Faster response time, reducing user impact
Requires pre-written rollback scripts and configuration
Manual Rollback
Initiated by a human after seeing an alert or user report
Slower, allowing more errors to reach users
Still requires planning, but no automation setup
maxSurge (Rolling Update)
Controls how many extra instances can be created during the update
Higher values cost more but can speed up the update
Set to 0 to avoid extra cost
maxUnavailable (Rolling Update)
Controls how many instances can be unavailable during the update
Higher values allow more instances down at once, risking capacity
Set to 0 to ensure all instances are available (but update may be slower)
Mistake
Rolling deployments are always the best choice because they are the default in most tools.
Correct
Rolling deployments are only the best choice when you want to minimise extra infrastructure cost and can tolerate a slow rollout with no instant rollback. Blue/green is better when instant rollback is critical.
This mistake happens because beginners see rolling as the simplest option and assume 'default' means 'best'. The exam tests your ability to pick the optimal strategy based on constraints.
Mistake
A canary deployment and a blue/green deployment are essentially the same thing because both run two versions at once.
Correct
They are fundamentally different. In blue/green, you switch all traffic at once after testing. In canary, you gradually shift traffic percentages, allowing real-time monitoring of a small user segment before full rollout.
The confusion arises because both strategies involve two versions. Beginners focus on the similarity (two versions) and miss the critical difference in traffic routing and rollout speed.
Mistake
Rollback in a rolling deployment happens automatically if a health check fails.
Correct
A failing health check usually pauses the rolling update, but it does not automatically revert the already-updated instances. You must manually trigger a rollback by reverting the instance template or restarting the update with the old version.
Modern tools pause on error, which feels like 'the system is handling it'. Beginners assume the system will fix itself, not realising a rollback is a separate action that must be explicitly invoked.
Mistake
You can use a canary deployment without any special load balancer configuration — just deploy the new version to a few instances.
Correct
A proper canary deployment requires a load balancer that supports traffic splitting by weight (e.g., 2% of requests to new version). Simply deploying to a few instances does not control traffic distribution; users could be randomly assigned.
This misconception comes from thinking 'deploy to a few servers = canary'. Without traffic management, the canary instances might receive no traffic at all, defeating the purpose of real-world user testing.
Mistake
Blue/green deployment doubles your infrastructure cost permanently.
Correct
Blue/green typically doubles cost only during the deployment window (often hours or days). The old environment is terminated once the new one is proven stable, so the extra cost is temporary.
Beginners hear 'two environments' and assume both run forever. In practice, you spin up green, verify, switch, then tear down blue. The cost increase is temporary and predictable.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A rolling update replaces instances one at a time, keeping the application online but potentially mixing old and new versions. A blue/green deployment keeps two full environments running and switches all traffic instantly from the old to the new.
No, rollback is not automatic by default. You must configure your monitoring system to detect failure and trigger a rollback, such as resetting traffic weights to zero. Google Cloud's Deployment Manager or Cloud Build can be set up to automate this.
Yes, a load balancer is typically required to route traffic away from instances being updated and back to them once they pass health checks. Without it, users could hit an unavailable instance during the update.
If the health check fails on the green environment, you should not switch traffic to it. The blue environment continues serving, and you investigate the green environment's issues. You can then fix and redeploy to green before attempting the switch again.
Not necessarily. A canary deployment does not require a second full environment like blue/green does. The extra cost comes from running both old and new versions simultaneously for a subset of users, but the new version's instances are often scaled down initially, so the cost difference is small.
maxSurge is the number of extra instances you allow to be created during a rolling update. For example, maxSurge = 1 means one extra instance can be spun up, allowing the update to proceed without reducing the total instance count below the target size.
You've finished Configuring Deployment Strategies and Rollbacks. Continue through the PCD study guide to build a complete picture of the exam.
Done with this chapter?