CKAD Application Deployment Practice Question
Which THREE are valid ways to expose a canary deployment for testing? (Select three)
⚠ Common exam trap
CKAD often tests the misconception that DaemonSets or NetworkPolicies can be used for canary exposure, when in reality canary testing depends on Service selectors, Ingress annotations, or shared-label Services.
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
✓
Create a separate Service for the canary with a different selector and provide its endpoint to testers.
Option A is correct because creating a dedicated Service whose selector matches only the canary pods' labels gives testers a stable, isolated endpoint (ClusterIP/NodePort/LoadBalancer) that routes exclusively to the canary, without touching production traffic. Option B is correct because an Ingress controller such as NGINX supports canary annotations (e.g., nginx.ingress.kubernetes.io/canary: "true", canary-weight, canary-by-header, canary-by-cookie) to split or conditionally route a percentage or specific requests to the canary backend. Option E is correct because a single Service selecting both stable and canary pods via a shared common label will load-balance across all matching endpoints, which is a simple way to expose the canary alongside stable for testing (albeit without fine-grained control). Option C is not valid because a DaemonSet schedules one pod per node for node-level agents, not for canary traffic exposure. Option D is not valid because a NetworkPolicy only filters pod ingress/egress traffic; it restricts rather than exposes the canary and provides no routing mechanism to testers.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a separate Service for the canary with a different selector and provide its endpoint to testers.
Why this is correct
You can expose canary pods by creating a dedicated Service whose selector matches only the canary version label—e.g., version=canary. This Service gets its own stable ClusterIP (or LoadBalancer) and routes exclusively to canary pods, providing a direct endpoint for testers, QA teams, or automated verification pipelines. This approach is valid because it gives controlled access to the canary without mixing it into the production traffic path, but it does not automatically shift user traffic—it is for manual or targeted testing.
- ✓
Use an Ingress with traffic splitting via annotations (e.g., nginx.ingress.kubernetes.io/canary).
Why this is correct
The NGINX Ingress Controller provides canary-specific annotations such as nginx.ingress.kubernetes.io/canary: "true" and nginx.ingress.kubernetes.io/canary-weight: "10" on a second Ingress resource. This secondary Ingress routes a defined percentage of requests (or requests matching a header/cookie) to the canary Service, while the primary Ingress continues serving stable traffic. It is a valid exposure method that allows fine-grained traffic splitting without altering the stable Service's selector or creating a separate public endpoint.
- ✗
Use a DaemonSet instead of Deployment for canary.
Why it's wrong here
A DaemonSet is designed to run exactly one pod on every node, which is meant for node-level system agents, not for application deployments that need replica scaling. Canary releases require the ability to run a small, controlled number of canary replicas alongside stable ones and often to adjust those numbers dynamically; a DaemonSet cannot do this because it ties pod count to node count. Moreover, a DaemonSet itself does not expose the canary through any Service—you would still need to create a Service—so it is not a valid way to expose a canary for testing.
- ✗
Use a NetworkPolicy to restrict canary pods from receiving traffic.
Why it's wrong here
A NetworkPolicy is a Kubernetes resource that controls ingress/egress traffic to and from pods using label selectors and port rules. Applying a NetworkPolicy to restrict canary pods would block incoming connections, including traffic from the Service or testers, so it actively prevents exposure rather than enabling it. It is a security control, not a traffic-routing or service-discovery mechanism, and cannot provide an endpoint or load-balancing behavior needed to test a canary deployment.
- ✓
Use a single Service that selects both stable and canary pods based on a common label.
Why this is correct
A single Service can select both stable and canary pods by using a common label—e.g., app=myapp—while a separate label like version distinguishes the two. The Service's endpoint list then includes pods from both Deployments, and the kube-proxy load-balancer distributes traffic proportionally to the number of ready replicas in each group. This exposes the canary to all existing Service clients without any routing changes, making it a valid and simple way to start canary validation.
Visual reference
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This CKAD practice question is part of Courseiva's free CNCF 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 CKAD exam.