EX294 Coordinate rolling updates Practice Question
In OpenShift, a deployment must gradually shift traffic to new pods during a rolling update. Which default strategy achieves this?
⚠ Common exam trap
A common mix-up: candidates confuse the default OpenShift deployment strategy with advanced deployment patterns like blue-green or canary, which are not built-in defaults but require additional configuration, leading them to select those incorrect options.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
RollingUpdate
The RollingUpdate strategy is the default deployment strategy in OpenShift (and Kubernetes) that gradually replaces old pods with new ones while maintaining application availability. It achieves this by incrementally scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like maxSurge and maxUnavailable, ensuring a smooth transition of traffic to new pods.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Blue-green deployment
Why it's wrong here
Blue-green runs two full environments and switches traffic in one cutover, not gradually. It suits instant rollback with duplicated infrastructure; the RollingUpdate strategy is what increments pods in steps while keeping the old ones serving.
- ✓
RollingUpdate
Why this is correct
RollingUpdate is the Deployment strategy that replaces pods incrementally, keeping a configurable maxUnavailable and maxSurge so traffic shifts gradually to new pods while old ones terminate. This satisfies the stem's requirement for a gradual traffic shift during update, unlike Recreate, which stops all pods first.
- ✗
Canary deployment
Why it's wrong here
Canary is not a built-in OpenShift deployment strategy; it is implemented via routes or service mesh splitting. It suits controlled exposure of a subset of users, whereas the default RollingUpdate strategy natively replaces pods incrementally.
- ✗
Custom strategy
Why it's wrong here
Custom strategy requires you to define your own deployment logic, so it is not the default behaviour. It suits bespoke release orchestration; RollingUpdate is the built-in default that shifts traffic gradually as new pods pass readiness checks.
- ✗
Recreate
Why it's wrong here
Recreate terminates every existing pod before starting replacements, so traffic drops to zero during the transition rather than shifting gradually. It suits stateless development workloads where brief downtime is acceptable and no overlap between versions is needed. Rolling updates require the RollingUpdate strategy, which scales new pods up while scaling old ones down.
About these practice questions
This EX294 question is part of Courseiva's 392-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX294 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX294 exam.