CKAD Practice Question 4: Blue Green Service Cutover
Certified Kubernetes Application Developer (CKAD) · Test 1 · question 4 of 10
A payments team must release version 2 of an API with an all-or-nothing cutover: no request may ever be served by a mix of v1 and v2, the switch must take effect in seconds, and rolling back must be equally immediate. Both versions can be fully deployed at the same time, and the team cannot install a service mesh or any additional ingress controller.
Which approach fits these constraints?
Show answer and explanation
Answer:
This is the standard blue/green pattern built from core Kubernetes objects. Both Deployments run concurrently with labels such as version: v1 and version: v2. The Service selects only one of them, so every request goes to a single version. Changing the selector to the other value rebuilds the EndpointSlice within seconds, and changing it back is an equally fast rollback. No extra components are required.
Option A does not meet the constraint that versions never mix. A rolling update deliberately runs old and new Pods side by side behind the same Service, and kubectl rollout undo unwinds through the same gradual process, so rollback is not instantaneous either.
Option B is a ramped or canary release. It also mixes versions in the endpoint set for the whole duration of the shift, which the stem forbids.
Option C fails the core requirement: weighted splitting by definition sends some requests to v1 and others to v2 at the same time, which is exactly the version mixing the stem forbids; it is a canary technique, not blue/green. It also would not work as specified: weight-based splitting is not part of the core Ingress API and depends on controller-specific annotations or the Gateway API, both ruled out by the stem.
Reference: Service