Courseiva

CCNA Application Deployment Questions

20 questions · Application Deployment · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

During a rolling update, you want to ensure that at most 2 pods are unavailable at any time. Which field should you set in the Deployment spec?

A.spec.strategy.type: Recreate
B.spec.replicas: 2
C.spec.strategy.rollingUpdate.maxSurge: 2
D.spec.strategy.rollingUpdate.maxUnavailable: 2
AnswerD

spec.strategy.rollingUpdate.maxUnavailable: 2 directly caps the number of pods that may be unavailable during a rolling update, ensuring that at most 2 pods are down at any given time relative to the desired replica count. The Deployment controller uses this value to decide when it can scale down old ReplicaSets and scale up new ones, keeping the available pod count at desired minus 2. This is the exact setting needed for the stated requirement of allowing at most 2 replicas to be unavailable.

Why this answer

`spec.strategy.rollingUpdate.maxUnavailable` specifies the maximum number of Pods that can be unavailable during a rolling update. Setting `maxUnavailable: 2` ensures that at most 2 Pods are unavailable at any time, allowing the update to proceed while maintaining the desired availability.

Exam trap

The trap here is confusing `maxSurge` (which controls extra Pods created above the desired count) with `maxUnavailable` (which controls Pods that can be unavailable), leading candidates to incorrectly select `maxSurge` when the question asks about limiting unavailable Pods.

How to eliminate wrong answers

Option A is wrong because `spec.strategy.type: Recreate` terminates all existing Pods before creating new ones, which would cause all Pods to be unavailable during the update, not limiting unavailability to 2. Option B is wrong because `spec.replicas: 2` sets the desired number of Pod replicas to 2, but does not control the number of unavailable Pods during a rolling update; it defines the target count, not a constraint on unavailability. Option C is wrong because `spec.strategy.rollingUpdate.maxSurge: 2` controls the maximum number of Pods that can be created above the desired replica count during an update, not the number of unavailable Pods.

Practice this question →
2
MCQeasy

A developer wants to deploy a stateless application as a set of identical pods. They need the pods to be distributed across nodes and have stable network identities. Which resource should they use?

A.Job
B.Deployment
C.DaemonSet
D.StatefulSet
AnswerD

A StatefulSet assigns each pod a stable, zero-based ordinal hostname (e.g., web-0, web-1) derived from the StatefulSet name and replica index. These identities persist across rescheduling because a replacement pod always inherits the same ordinal and, if configured, the same PersistentVolumeClaim. Combined with a headless service, each pod gets a unique DNS name, which perfectly fulfills the requirement for stable network identities in a stateless or stateful application.

Why this answer

StatefulSet is the correct resource because it provides each pod with a stable, unique network identity (e.g., pod-name-0, pod-name-1) that persists across rescheduling. While Deployment manages replicas for stateless applications, it does not assign per-pod stable hostnames. The question explicitly requires 'stable network identities' for identical pods, which is a defining feature of StatefulSet.

A Service combined with a Deployment gives a stable endpoint for the set, not per-pod identities.

Exam trap

Candidates may incorrectly choose Deployment, thinking that a Service provides stable network identities. However, a Service provides a stable endpoint for the entire set of pods, not individual pod identities. StatefulSet is needed for per-pod stable DNS names, which match the requirement for 'stable network identities' for each pod.

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch processing or one-time tasks, not for running a continuously serving stateless application with multiple identical pods. Option C is wrong because a DaemonSet ensures exactly one pod per node, which is used for node-level services (e.g., logging, monitoring) and does not distribute pods arbitrarily across nodes for scaling. Option D is wrong because a StatefulSet is intended for stateful applications requiring stable, unique network identities and persistent storage, which is unnecessary for a stateless application.

Practice this question →
3
MCQmedium

You have a Deployment named 'frontend' with 4 replicas. You want to perform a rolling update with the following constraints: the number of pods above the desired count should never exceed 1, and the number of unavailable pods should never exceed 0. Which deployment strategy configuration achieves this?

A.strategy: rollingUpdate: {maxSurge: 2, maxUnavailable: 0}
B.strategy: rollingUpdate: {maxSurge: 25%, maxUnavailable: 25%}
C.strategy: rollingUpdate: {maxSurge: 1, maxUnavailable: 0}
D.strategy: type: Recreate
AnswerC

This is the correct configuration because maxSurge: 1 caps the total number of pods at one beyond the desired 4, so at most 5 pods run during the update. Meanwhile, maxUnavailable: 0 forbids terminating any old pod until a new pod has become Ready, ensuring at least 4 pods are always available to serve traffic. Together they enforce exactly the stated constraints: no more than one extra pod and zero downtime.

Why this answer

Setting `maxSurge: 1` ensures that during a rolling update, at most one additional pod is created above the desired replica count of 4, and `maxUnavailable: 0` guarantees that no pods are taken down until the new ones are ready. This satisfies the constraints of never exceeding one extra pod and never having unavailable pods.

Exam trap

The trap here is that candidates often confuse `maxSurge` and `maxUnavailable` as percentages versus absolute values, or they mistakenly think `Recreate` can achieve zero downtime, when in fact it causes complete unavailability during the update.

How to eliminate wrong answers

Option A is wrong because `maxSurge: 2` would allow up to 2 extra pods above the desired count, violating the constraint that the number of pods above the desired count should never exceed 1. Option B is wrong because `maxUnavailable: 25%` (which equals 1 pod out of 4) would allow at least one pod to be unavailable during the update, violating the constraint that unavailable pods should never exceed 0. Option D is wrong because the `Recreate` strategy terminates all existing pods before creating new ones, causing all pods to be unavailable during the update, which directly violates the constraint of zero unavailable pods.

Practice this question →
4
MCQhard

You want to perform a canary deployment of a new version of your application. You create a Deployment named 'app-canary' with 1 replica and label 'version: canary'. The existing stable Deployment 'app-stable' has 3 replicas and label 'version: stable'. Both Deployments have the selector 'app: myapp'. You have a Service 'app-service' with selector 'app: myapp, track: stable'. How can you route traffic to the canary?

A.Use a different Service for canary with selector 'app: myapp, track: canary' and keep the original Service unchanged
B.Add label 'track: canary' to the canary pod template and set the Service selector to 'app: myapp, track: canary'
C.Modify the Service selector to 'app: myapp' and rely on the 'version' label to differentiate
D.Change the canary Deployment's selector to 'version: canary' and update the Service selector to include 'version: canary'
AnswerB

This routes traffic only to the canary pods via the Service.

Why this answer

To route traffic to the canary, the Service selector must match the canary pods' labels. The current Service selector is 'app: myapp, track: stable', but the canary pods have 'app: myapp, version: canary'. Option B correctly adds the label 'track: canary' to the canary pod template and changes the Service selector to 'app: myapp, track: canary'.

This makes the Service select only the canary pods, routing all traffic to the canary. Note: This removes the stable pods from the Service, but among the given choices, B is the only correct approach to achieve traffic to the canary.

Practice this question →
5
MCQmedium

A company wants to ensure zero-downtime deployments for a stateless web application running in Kubernetes. They have a single Deployment with 3 replicas and a Service of type LoadBalancer. Which strategy should they use to achieve this?

A.Use Recreate strategy
B.Use RollingUpdate with maxSurge=100% and maxUnavailable=100%
C.Use RollingUpdate with maxSurge=25% and maxUnavailable=0
D.Use RollingUpdate with maxSurge=0 and maxUnavailable=25%
AnswerC

With maxUnavailable=0, the rolling update guarantees that no existing pods are terminated until replacement pods have been created and reached the Ready state. The default maxSurge=25% allows the deployment to temporarily provision additional pods beyond the desired replica count, ensuring a buffer of ready pods during the transition. This combination provides zero-downtime because traffic continues to be served by the old pods until new pods are fully ready and can take over seamlessly.

Why this answer

A RollingUpdate strategy with maxSurge=25% and maxUnavailable=0 ensures that during a deployment, the desired number of replicas is always available (no downtime). maxUnavailable=0 means no old Pods are terminated until new ones are ready, and maxSurge=25% allows one extra Pod (25% of 3 replicas = 0.75, rounded up to 1) to be created before terminating old ones, maintaining capacity for zero-downtime updates.

Exam trap

The trap here is that candidates often confuse maxSurge and maxUnavailable, thinking that allowing some unavailability (e.g., maxUnavailable=25%) is acceptable for zero-downtime, but in Kubernetes, zero-downtime strictly requires maxUnavailable=0 to ensure no Pods are terminated before replacements are ready.

How to eliminate wrong answers

Option A is wrong because the Recreate strategy terminates all existing Pods before creating new ones, causing downtime during the update. Option B is wrong because maxSurge=100% and maxUnavailable=100% allows all Pods to be replaced simultaneously, which can cause a temporary loss of service if readiness probes fail or new Pods take time to become ready, violating zero-downtime requirements. Option D is wrong because maxSurge=0 and maxUnavailable=25% means no new Pods are created until old ones are terminated, reducing available capacity by 25% (1 Pod) during the update, which can cause downtime if traffic exceeds remaining capacity.

Practice this question →
6
Multi-Selectmedium

Which of the following are valid methods to perform a blue-green deployment? (Choose TWO)

Select 2 answers
A.Create two Deployments for blue and green, and update the Service selector to point to the new version
B.Create a single Deployment and update the pod labels to match the Service selector
C.Use a single Deployment and change the container image, then perform a rolling update
D.Use an Ingress resource to route traffic to different Services, each backing a different version
E.Delete the old Deployment and create a new one
AnswersA, D

Classic blue-green with Service selector.

Why this answer

Blue-green deployment in Kubernetes typically involves running two environments (blue and green) side-by-side and switching traffic from one to the other. Option A directly implements this by maintaining two separate Deployments (blue and green) and updating the Service selector to point to the new version. Option D uses an Ingress resource that can route traffic to different Services, each pointing to a different version of the application; by updating the Ingress rules, traffic can be switched from blue to green.

Option B describes a rolling update, not blue-green. Option C is a rolling update using a single Deployment and changing the container image. Option E is a delete/recreate strategy, not blue-green.

Practice this question →
7
MCQmedium

You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?

A.A new pod is created first, then the oldest pod is terminated.
B.Two old pods are terminated at a time, while new pods are created.
C.One old pod is terminated, then a new pod is created, repeating until all pods are updated.
D.All old pods are terminated simultaneously, then new pods are created.
AnswerC

With maxSurge=0, the desired replica count cannot be exceeded, and with maxUnavailable=1, at most one pod may be down during the update. This configuration forces a strictly sequential pattern: the controller first terminates an old pod, which counts as one unavailable pod, then creates a new pod to restore the replica count to the desired number. It then repeats this cycle for each remaining old replica, so one old pod is terminated, a new pod is created, and this continues until all pods are rolled over. This approach maintains availability without any temporary scaling up.

Why this answer

With `maxSurge: 0` and `maxUnavailable: 1`, the RollingUpdate strategy ensures that during the update, no extra pods beyond the desired replica count are created (surge is zero), and at most one pod can be unavailable at any time. The Deployment controller first terminates an old pod (making one unavailable), then creates a new pod to replace it, repeating this process until all pods are updated. This guarantees a controlled, sequential rollout with minimal disruption.

Exam trap

The trap is that candidates often confuse the Kubernetes rolling update parameters: `maxSurge: 0` means no extra pods can be created above the desired count, and `maxUnavailable: 1` means at most one pod can be unavailable at a time. This results in a sequential termination-then-creation process, not parallel or batch updates.

How to eliminate wrong answers

Option A is wrong because it describes a behavior where a new pod is created before terminating an old one, which would require `maxSurge: 1` or higher; with `maxSurge: 0`, no new pod can be created until an old pod is terminated. Option B is wrong because terminating two old pods at a time would violate `maxUnavailable: 1`, which limits the number of unavailable pods to one during the update. Option D is wrong because terminating all old pods simultaneously would make all pods unavailable at once, far exceeding the `maxUnavailable: 1` limit and causing a full service disruption.

Practice this question →
8
MCQhard

You are using a canary deployment strategy with Deployments and Services. You have a stable version (v1) and a canary version (v2). Both Deployments have the label 'app: myapp'. The Service selector is 'app: myapp'. How can you route a small percentage of traffic to the canary?

A.Set both Deployments to 10 replicas and use an Ingress with a canary weight annotation (e.g., canary-weight: '10')
B.Set the canary Deployment replicas to 1 and the stable to 9, and update the Service selector to include version: v2
C.Set the canary Deployment replicas to 10 and the stable to 1
D.Set the canary Deployment replicas to 1 and the stable to 9, and keep the Service selector as 'app: myapp'
AnswerD

Keeping the Service selector as 'app: myapp' while setting canary replicas to 1 and stable to 9 ensures that both Deployments' pods match the selector. The Service then performs round-robin or random load balancing across all matching endpoints, so traffic is distributed proportionally to pod counts—approximately 10% to canary and 90% to stable. This is the correct method because it uses the natural endpoint-count-based weighting of a Service without introducing label restrictions that would isolate one version.

Why this answer

The Service selector 'app: myapp' matches both Deployments, and by setting the canary to 1 replica and the stable to 9, the Service's round-robin load balancing (by default) distributes roughly 10% of traffic to the canary Pods and 90% to the stable Pods. This is a simple, native Kubernetes canary pattern that requires no additional components like Ingress controllers.

Exam trap

The trap is to overcomplicate the solution by introducing a specialized Ingress controller or modifying the Service selector, when the simplest approach is to adjust replica counts while keeping the selector unchanged.

How to eliminate wrong answers

Option A is wrong because it relies on an Ingress with a canary-weight annotation, which is specific to the NGINX Ingress Controller and not a core Kubernetes feature; the question does not specify that an Ingress controller is in use, and the scenario only mentions Deployments and Services. Option B is wrong because updating the Service selector to include 'version: v2' would cause the Service to only match Pods with that label, thus routing 100% of traffic to the canary and none to the stable version. Option C is wrong because setting the canary to 10 replicas and the stable to 1 would route approximately 91% of traffic to the canary, not a small percentage.

Practice this question →
9
MCQhard

You are using a canary deployment pattern with two Deployments: 'web-stable' (version 1) and 'web-canary' (version 2). Both have the label 'app: web'. The Service 'web-svc' selects pods with 'app: web' and 'version: stable'. How do you route traffic to the canary?

A.Add the label 'version: canary' to the canary Deployment's pod template and update the Service's selector to 'app: web, version in (stable, canary)'.
B.Use kubectl rollout canary on the stable Deployment.
C.Create a new Service with selector 'app: web, version: canary' and use an ingress to split traffic.
D.Change the Service selector to 'app: web' only (remove version label).
AnswerA

Adding the 'version: canary' label to the canary pod template and updating the Service selector to a set-based requirement (version in (stable, canary)) allows the existing Service to include both stable and canary pods in its endpoints. Kubernetes Services load-balance across all ready endpoints, so traffic is distributed proportionally to the replica counts of each Deployment. You can then carefully scale the canary Deployment up to increase its traffic share, making this a native, controlled canary strategy.

Why this answer

The Service 'web-svc' currently selects pods with 'app: web' and 'version: stable'. To route traffic to the canary pods (version 2), you need to add the label 'version: canary' to the canary Deployment's pod template so that those pods are created with that label. Then, updating the Service's selector to 'app: web, version in (stable, canary)' allows the Service to match both stable and canary pods, distributing traffic between them according to the Service's default round-robin behavior.

Exam trap

The trap here is that candidates often think they need to create a separate Service or use a special command for canary deployments, when in fact Kubernetes supports canary routing simply by updating the Service's selector to include both versions' labels, leveraging the built-in load balancing.

How to eliminate wrong answers

Option B is wrong because 'kubectl rollout canary' is not a valid kubectl command; Kubernetes does not have a built-in 'rollout canary' subcommand — canary deployments are implemented manually using multiple Deployments and Service selectors. Option C is wrong because creating a separate Service for the canary and using an ingress to split traffic is an overcomplicated approach that is not required for a simple canary pattern; the question asks how to route traffic to the canary using the existing Service, and a single Service with a combined selector is the standard method. Option D is wrong because changing the Service selector to 'app: web' only (removing the version label) would cause the Service to select all pods with 'app: web', including both stable and canary, but it would also select any other pods with that label, potentially including unintended pods; more importantly, it does not provide a controlled way to gradually shift traffic — it immediately sends traffic to all matching pods without the ability to limit the canary's exposure.

Practice this question →
10
Matchingmedium

Match each volume type to its use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Temporary storage that shares a pod's lifecycle

Mounts a file or directory from the host node

Requests durable storage from a PersistentVolume

Inject configuration data as files or env vars

Inject sensitive data as files or env vars

Why these pairings

The correct matches are: emptyDir - temporary storage, hostPath - host node directory, PVC - persistent storage, ConfigMap - configuration data. Common confusions involve mixing hostPath and PVC, or emptyDir with hostPath.

Practice this question →
11
Multi-Selecthard

A Deployment named 'api' has 6 replicas. You want to perform a rolling update with the following constraints: at most 2 pods can be unavailable during the update, and at most 1 extra pod can be created above the desired 6. Which strategy configurations achieve this? (Choose TWO)

Select 2 answers
A.strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 2
B.strategy: rollingUpdate: maxSurge: 16% maxUnavailable: 33%
C.strategy: rollingUpdate: maxSurge: 2 maxUnavailable: 2
D.strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 3
E.strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1
AnswersA, B

Absolute numbers match constraints.

Why this answer

Uses absolute numbers: maxSurge=1 and maxUnavailable=2, directly matching the constraints. Option B uses percentages: 16% of 6 = 0.96 rounded up to 1, and 33% of 6 = 1.98 rounded up to 2, so it also yields maxSurge=1 and maxUnavailable=2. Option C has maxSurge=2, exceeding the surge limit.

Option D has maxUnavailable=3, exceeding the unavailable limit. Option E has maxUnavailable=1, which is more restrictive than the allowed maximum of 2; while it technically satisfies the constraint, it is not the intended configuration. Therefore, the correct answers are A and B.

Practice this question →
12
MCQmedium

You need to perform a blue-green deployment using Deployments and Services. What is the most common approach to switch traffic from the old version (blue) to the new version (green)?

A.Update the Deployment's image field in the blue Deployment to the new version
B.Change the Service's label selector to point to the green Deployment's pod labels
C.Delete the blue Deployment and create the green Deployment
D.Scale the blue Deployment to 0 and the green Deployment to desired replicas
AnswerB

Altering the Service's label selector to match the green Deployment's pod labels is the canonical blue-green traffic switch. Because the Deployment labels are immutable to the selector only after the fact, you simply retarget the Service to the already-running and ready green pods, instantly moving all traffic without redeploying anything. This provides zero-downtime shifting and makes rollback trivial by reverting the selector to blue.

Why this answer

In a blue-green deployment, the Service acts as the traffic router by using a label selector to match pods. By updating the Service's selector to match the green Deployment's pod labels (e.g., `version: green`), traffic is instantly switched from blue pods to green pods without any downtime, as Kubernetes Services use label selectors to dynamically route traffic to matching pods.

Exam trap

The trap here is that candidates often confuse a blue-green deployment with a rolling update or scaling strategy, and mistakenly think that updating the image (Option A) or scaling (Option D) is sufficient to switch traffic, ignoring the critical role of the Service's label selector in directing traffic to the correct set of pods.

How to eliminate wrong answers

Option A is wrong because updating the image field in the blue Deployment triggers a rolling update, not a blue-green switch; this mixes old and new pods during the transition and defeats the purpose of having two separate environments. Option C is wrong because deleting the blue Deployment before creating the green one causes downtime, as there is no overlap period to validate the green deployment before cutting over. Option D is wrong because scaling blue to 0 and green to desired replicas does not automatically redirect traffic; the Service's label selector must still be updated to point to green pods, otherwise traffic continues to blue pods even if they are scaled down (and will fail if blue has 0 replicas).

Practice this question →
13
Multi-Selecthard

Which TWO statements about kubectl apply vs kubectl create are correct? (Select two)

Select 2 answers
A.Both commands support the --dry-run=client flag.
B.Both commands require a full YAML manifest file.
C.kubectl apply can update existing resources; kubectl create cannot.
D.kubectl create is the recommended way to manage production resources.
E.Both commands can only be used to create resources, not update.
.kubectl apply stores the last applied configuration in an annotation.
AnswersC

Correct. `kubectl apply` can update existing resources; `kubectl create` cannot update and will fail if the resource exists.

Why this answer

The correct options are the statement about kubectl apply storing the last applied configuration in an annotation (the first option) and option C. The annotation `kubectl.kubernetes.io/last-applied-configuration` enables declarative updates with `kubectl apply`. Option C is correct because `kubectl apply` can update existing resources declaratively, while `kubectl create` will fail if the resource already exists.

Option A is incorrect because `kubectl create` does not support `--dry-run=client`; only `kubectl apply` does. Options B, D, and E are incorrect as explained.

Exam trap

Kubernetes often tests the misconception that `kubectl apply` and `kubectl create` are interchangeable, but the trap here is that candidates confuse the imperative `create` (which cannot update) with the declarative `apply` (which can), and they may also incorrectly assume `--dry-run=client` works identically for both commands.

Practice this question →
14
Multi-Selecthard

You have a Deployment 'web-app' with 4 replicas. You want to perform a rolling update such that during the update, at most 2 pods can be unavailable and at most 5 pods can be above the desired replica count. Which TWO of the following strategy configurations achieve this?

Select 2 answers
A.maxSurge: 3, maxUnavailable: 3
B.maxSurge: 5, maxUnavailable: 0
C.maxSurge: 5, maxUnavailable: 2
D.maxSurge: '125%', maxUnavailable: '50%'
E.maxSurge: 1, maxUnavailable: 2
AnswersC, D

Correct because maxSurge: 5 allows up to 5 extra pods, and maxUnavailable: 2 allows up to 2 unavailable, matching the requirement.

Why this answer

MaxSurge: 5 and maxUnavailable: 2 means during the rolling update, up to 2 pods can be unavailable (below the desired 4) and up to 5 extra pods can be created above the desired count, allowing a total of 9 pods at peak. This satisfies the requirement that at most 2 pods are unavailable and at most 5 pods are above the desired replica count. Option D is correct because 125% of 4 equals 5, and 50% of 4 equals 2, so the effective limits are the same as option C.

Option B is incorrect because maxUnavailable: 0 prevents any pod from becoming unavailable during the update, making it impossible to delete old pods without violating the constraint. A rolling update requires some pods to become temporarily unavailable when they are terminated; with maxUnavailable=0, the update cannot proceed because no pod can be terminated. Thus, the configuration does not achieve a successful rolling update.

Options A and E are incorrect because they allow more than 2 pods unavailable (A: maxUnavailable=3) or allow only 1 extra pod (E: maxSurge=1), not the required 5.

Exam trap

The CKAD exam often tests the distinction between absolute and percentage values for maxSurge and maxUnavailable, and the trap here is that candidates may incorrectly assume percentages are always rounded down or that both values must be integers, missing that '125%' and '50%' produce the same effective limits as 5 and 2 for a 4-replica deployment.

Practice this question →
15
MCQhard

You have a Deployment 'db' that uses a ConfigMap for configuration. You want to update the ConfigMap and roll out the changes to pods without restarting them manually. Which approach should you use?

A.Delete the ConfigMap and recreate it with the same name
B.Update the ConfigMap and then update the Deployment's pod template (e.g., change an annotation) to trigger a rolling update
C.Edit the ConfigMap and run kubectl rollout restart deployment/db
D.Use kubectl replace on the ConfigMap and the pods will automatically get the new values
AnswerB

Pods will be recreated with the new ConfigMap.

Why this answer

Mounting ConfigMaps as volumes with subPath does not automatically update pods; however, using environment variables from ConfigMaps also does not update pods. The recommended approach is to use a Deployment update with a change that triggers a rollout (e.g., updating an annotation). Option B is correct.

Practice this question →
16
Multi-Selectmedium

Which TWO of the following are true about Kustomize overlays? (Select 2)

Select 2 answers
A.Overlays can only add labels, not modify existing ones.
B.Overlays are used to customize resources for different environments.
C.Overlays must be stored in the same directory as the base.
D.Overlays can patch resources defined in a base.
E.Overlays can only be used with Helm charts.
AnswersB, D

Overlays apply environment-specific patches.

Why this answer

Overlays are used to customize resources for different environments, and they can patch resources defined in bases.

Practice this question →
17
Multi-Selectmedium

Which THREE of the following are valid reasons to use an annotation in Kubernetes?

Select 3 answers
A.To enable a Service to select Pods based on the annotation value
B.To store the name of the CI/CD tool that deployed the resource
C.To record the build version or commit hash for auditing
D.To set resource limits for a container
E.To attach arbitrary non-identifying metadata to an object
AnswersB, C, E

Annotations can hold deployment tool metadata.

Why this answer

Annotations are key-value metadata used for non-identifying information. Option A is incorrect because selection of Pods by a Service is done using labels, not annotations. Option B is correct: annotations can store tooling metadata like CI/CD tool name.

Option C is correct: build versions and commit hashes are typical audit information stored in annotations. Option D is incorrect because resource limits are set in the container spec, not in annotations. Option E is correct: annotations are designed for arbitrary non-identifying metadata.

Practice this question →
18
Multi-Selecthard

You need to perform a canary deployment using a Service and two Deployments (stable and canary). Which TWO resources or configurations are typically used to route a percentage of traffic to the canary? (Select TWO)

Select 2 answers
A.Service Mesh (e.g., Istio VirtualService)
B.A single Service with multiple label selectors
C.NetworkPolicy
D.Ingress with canary annotation
E.HorizontalPodAutoscaler
AnswersA, D

Service Mesh provides fine-grained traffic splitting.

Why this answer

A Service Mesh like Istio uses a VirtualService resource to define traffic routing rules based on weights (e.g., `weight: 90` for stable and `weight: 10` for canary). This allows fine-grained, percentage-based traffic splitting between two different Kubernetes Services or subsets, which is a core requirement for canary deployments.

Exam trap

A common misconception in CKAD is that a single Service with multiple selectors can split traffic by percentage, when in fact Kubernetes Services only support label-based selection and round-robin load balancing without weighted routing.

Practice this question →
19
Multi-Selecthard

Which THREE components are essential for setting up Horizontal Pod Autoscaling (HPA) based on CPU utilization? (Select three)

Select 3 answers
A.A readiness probe on the pod
B.A Service of type LoadBalancer
C.An HPA resource targeting the Deployment
D.metrics-server installed in the cluster
E.CPU resource requests set on the container
AnswersC, D, E

The HPA defines the scaling policy.

Why this answer

HPA requires metrics-server to collect CPU metrics, CPU resource requests set on containers so HPA can calculate utilization, and the HPA resource itself targeting the Deployment. Therefore, options C, D, and E are correct.

Practice this question →
20
MCQhard

You are performing a canary deployment using two Deployments: 'app-stable' (replicas: 9) and 'app-canary' (replicas: 1), both with label 'app: myapp'. A Service selects pods with 'app: myapp' and 'version: stable'. How can you route traffic to the canary?

A.Update the canary Deployment's image to a different version.
B.Change the Service's selector to 'version: canary'.
C.Add label 'version: stable' to the canary Deployment's pod template, so both Deployments have the same label, and keep the Service selector as is.
D.Add label 'version: canary' to the canary Deployment's template and update the Service selector to 'version: stable || version: canary'.
AnswerC

Adding the label 'version: stable' to the canary Deployment's pod template ensures that its pods are selected by the existing Service selector (which is already set to 'version: stable'). The Service then load-balances across all matching pods from both Deployments, distributing traffic proportionally to their replica counts. For example, with 9 stable and 1 canary pod, the canary receives about 10% of traffic, enabling controlled rollout while both versions share the same label and the Service selector remains unchanged.

Why this answer

Adding the label 'version: stable' to the canary Deployment's pod template makes its pods match the Service's selector ('app: myapp' and 'version: stable'). This allows the Service to include both stable and canary pods, distributing traffic according to the replica ratio (9:1). The canary image can be different from stable, but the label ensures the Service routes traffic to both sets of pods.

Exam trap

The trap here is that candidates think they must change the Service's selector to include the canary, but the correct approach is to make the canary pods match the existing selector by adding the required labels, keeping the Service unchanged.

How to eliminate wrong answers

Option A is wrong because changing the canary's image does not affect the Service's selector; without matching labels, the canary pods remain unselected and receive no traffic. Option B is wrong because changing the Service's selector to 'version: canary' would exclude the stable pods, breaking the canary deployment pattern and routing all traffic to the single canary pod. Option D is wrong because Kubernetes selectors do not support logical OR operators (like '||'); selectors are based on equality or set-based matching (e.g., 'In'), and the proposed syntax is invalid, so the Service would fail to select any pods.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Application Deployment questions.

Start 20-question session