CKAD Application Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Add annotation 'traffic-weight: 90' to stable and 'traffic-weight: 10' to canary

  Why it's wrong here

  Adding an annotation such as 'traffic-weight: 90' to a Deployment is ineffective because annotations are arbitrary key-value metadata that Kubernetes stores for tooling and organizational purposes; they are never read by kube-proxy, the Service controller, or the endpoints controller to influence traffic routing. Even if both Deployments carry these annotations, the Service's selector will continue to include all matching pods equally, and traffic distribution will remain strictly uniform across the available endpoints, not proportional to any annotation value. To shift traffic based on metadata you would need an external controller (e.g., a service mesh like Istio, or an ingress controller with canary support) that actively interprets that metadata and manipulates routing rules.

• ✓

  selector: {app: api} and adjust the number of replicas in each Deployment to achieve the desired ratio (e.g., 9 stable, 1 canary)

  Why this is correct

  Using a single Service with the broad selector `app: api` is the correct native Kubernetes approach because it makes the Service's Endpoints object include pods from both the stable and canary Deployments simultaneously. The kube-proxy component (or the in-cluster DNS/round-robin mechanism) then picks endpoints for each new connection uniformly, so the fraction of traffic each version receives is directly proportional to the number of ready pods it contributes—for 9 stable and 1 canary pod, roughly 90% of connections go to stable and 10% to canary. This ratio can be tuned by scaling the `replicas` field in each Deployment, but you cannot get fine-grained percentages because each pod is an equal unit and there is no weighting factor beyond pod count.

• ✗

  selector: {app: api, version: stable}

  Why it's wrong here

  Setting the Service selector to `{app: api, version: stable}` will make the Service's Endpoints object contain only the Pods that carry both the `app=api` and `version=stable` labels. Because the canary Pods are labeled with `version=canary` (or any other value), they will not match this selector, so they will be excluded from the Endpoints list and will receive zero traffic from this Service. This effectively disables the canary deployment from a routing perspective; all connections will go exclusively to the stable version, which is the opposite of the intended canary rollout behavior.

• ✗

  Create two separate Services, each targeting one version, and rely on DNS weighting

  Why it's wrong here

  Creating two separate Services (one for stable, one for canary) and relying on DNS weighting does not work because Kubernetes' built-in DNS (CoreDNS/kube-dns) returns all matching clusterIPs, and the default policy is round-robin only when multiple IPs answer for the same name—but each Service has its own distinct DNS name and its own clusterIP, so no weighting is applied. Even if you gave both Services the same name (which is impossible in the same namespace) or relied on external DNS, Kubernetes itself provides no native DNS weighting mechanism to send a percentage of queries to one Service and the rest to another. A service mesh or an ingress controller with weighted routing (e.g., Istio VirtualService, Flagger) is required to implement percentage-based split across two distinct Services.

Go deeper

Related to this question