CKAD Application Deployment Practice Test 14 — 15 Questions

Question 1

You want to perform a canary deployment. You have a Deployment 'app-v1' with 10 replicas. You create a new Deployment 'app-v2' with 1 replica. Both have the label 'app: myapp'. The Service 'myapp-svc' uses selector 'app: myapp'. How do you gradually increase traffic to v2?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Gradually increase the replicas of app-v2 and decrease those of app-v1.. By increasing the number of replicas in the v2 Deployment, more pods will be available to receive traffic from the Service, as both versions share the same label.

Answer

Create a second Service for v2 and use DNS weighting.

Answer

Update the Service selector to include version labels.

Answer

Use 'kubectl set image' on the existing Deployment.

Question 2

You have a Deployment that is failing after a rollout. You want to revert to the previous revision. Which command accomplishes this?

Accepted Answer

kubectl rollout undo deployment/myapp. The command 'kubectl rollout undo deployment/myapp' reverts a Deployment to its previous revision by rolling back to the last revision in the rollout history. This is the standard and simplest way to undo a failed rollout in Kubernetes.

Answer

kubectl rollout history deployment/myapp --revision=previous

Answer

kubectl rollout resume deployment/myapp

Answer

kubectl delete deployment/myapp --cascade=orphan && kubectl apply -f old-deployment.yaml

Question 3

In a Deployment, what is the purpose of the 'maxUnavailable' field in the rolling update strategy?

Accepted Answer

The maximum number of pods that can be unavailable during the update.. In a Deployment's rolling update strategy, the 'maxUnavailable' field specifies the maximum number of Pods that can be unavailable during the update process. This ensures that the Deployment maintains a certain level of availability by controlling how many Pods can be taken down at any given time, relative to the desired replica count. It is defined as either an absolute number or a percentage of the desired Pods, and it works alongside 'maxSurge' to manage the update's pace and safety.

Answer

The maximum number of pods that can be terminated at once.

Answer

The maximum time allowed for the rollout to complete.

Answer

The maximum number of pods that can be created above the desired replicas.

Question 4

Which THREE are valid ways to expose a canary deployment for testing? (Select three)

Accepted Answer

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

Use a DaemonSet instead of Deployment for canary.

Answer

Use a NetworkPolicy to restrict canary pods from receiving traffic.

Question 5

Which TWO of the following are valid methods to perform a blue-green deployment in Kubernetes?

Accepted Answer

Create two Services, one for blue and one for green. Initially point an ingress to the blue Service. Update the ingress to point to green after validation.. Option D is correct because blue-green deployment requires two parallel environments and an atomic traffic switch: running separate blue and green Services and using an Ingress (or similar L7 router) to direct traffic to the blue Service, then updating the Ingress backend to the green Service after validation, achieves exactly that cutover without downtime. Option E is correct because two Deployments distinguished by labels (version: blue and version: green) with a Service whose selector initially matches blue, then is updated to match green once the green pods are Ready, is the canonical Kubernetes blue-green pattern using native Service selector switching. Option A is not blue-green because strategy.type: Recreate tears down the old version before starting the new one, causing downtime and providing no parallel green environment to validate. Option B is not blue-green because session affinity on a single Service with two replicas does not create two distinct blue/green versions or an atomic traffic switch. Option C is not blue-green because a RollingUpdate with maxSurge: 100% and maxUnavailable: 0% is a progressive rollout of one version, not two coexisting environments with a controlled cutover.

Answer

Use a Deployment with 'strategy.type: Recreate' and delete the old version before creating the new one.

Answer

Create a Deployment with two replicas and use a Service with session affinity to gradually shift traffic.

Answer

Use a Deployment with 'strategy.type: RollingUpdate' and set 'maxSurge: 100%' and 'maxUnavailable: 0%'.

Question 6

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?

Accepted Answer

maxSurge: 5, maxUnavailable: 2. 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.

Answer

maxSurge: 3, maxUnavailable: 3

Answer

maxSurge: 5, maxUnavailable: 0

Answer

maxSurge: 1, maxUnavailable: 2

Question 7

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

Accepted Answer

To store the name of the CI/CD tool that deployed the resource. Option B is correct because annotations are designed to hold non-identifying metadata such as tooling information, so recording the CI/CD tool that deployed a resource is a valid use. Option C is correct because annotations commonly store build versions or commit hashes for auditing and traceability, since this metadata does not need to be used for selection or scheduling. Option E is correct because the Kubernetes API explicitly defines annotations as a way to attach arbitrary non-identifying metadata to objects, which is their core purpose. Option A is not valid because Service Pod selection is performed with label selectors, not annotations, which cannot be used in selectors. Option D is not valid because container resource limits are set in the pod spec under resources.limits, not via annotations.

Answer

To enable a Service to select Pods based on the annotation value

Answer

To set resource limits for a container

Question 8

Which THREE of the following are correct statements about Helm?

Accepted Answer

Values defined in a 'values.yaml' file can be referenced in templates using '{{ .Values.key }}'.. Option A is correct because Helm's templating engine exposes the merged values from values.yaml (and overrides) under the .Values object, so a key defined there is referenced in a template as {{ .Values.key }}. Option B is correct because 'helm rollback RELEASE REVISION' reverts a named release to the specified revision number, restoring the Kubernetes resources to that prior state. Option E is correct because charts are packaged artifacts that can be pushed to and pulled from a Helm repository (an HTTP server hosting an index.yaml plus .tgz chart files), enabling sharing and versioned distribution. Option C is not correct because Helm manages applications deployed into a Kubernetes cluster, not the cluster's own lifecycle (that is the role of tools like kubeadm, kops, or Cluster API). Option D is not correct because Helm 3 uses a three-way strategic merge patch during upgrades (comparing the old manifest, the new manifest, and the live state), not a two-way merge.

Answer

Helm can be used to manage the lifecycle of a Kubernetes cluster itself.

Answer

Helm uses a two-way strategic merge patch during upgrades.

Question 9

Which THREE of the following are correct about Kustomize?

Accepted Answer

A 'kustomization.yaml' file is required in each Kustomize directory.. Options A, B, and E are correct. Option A: A kustomization.yaml file is required in each Kustomize directory to define resources, bases, and patches. Option B: The 'patches' field in kustomization.yaml allows overriding fields in resources via strategic merge patches or JSON patches. Option E: A base can be a local directory referenced via path or a remote URL (e.g., git repository). Option C is incorrect because 'kustomize build' outputs the rendered YAML to stdout; there is no 'kustomize apply' command. Option D is incorrect because Kustomize does not use templates; it uses overlays and patching without templating.

Answer

The command 'kustomize apply' deploys resources to the cluster.

Answer

Kustomize uses Helm-style templates to generate resources.

Question 10

Which THREE of the following are valid reasons to use a HorizontalPodAutoscaler (HPA) with a Deployment?

Accepted Answer

To scale replicas based on the number of incoming HTTP requests per second.. Options B, C, and E are valid uses of a HorizontalPodAutoscaler (HPA). HPA can scale based on custom metrics (e.g., HTTP requests per second) via the 'custom' or 'external' metric types, making B and C correct. Option E is correct because HPA can scale based on average CPU utilization using the 'ResourceMetric' type with 'targetAverageUtilization'. Option A is incorrect: HPA scales up when CPU exceeds the target, not down; also, the deprecated 'targetCPUUtilizationPercentage' field has been replaced by a metrics array. Option D is incorrect: HPA does not enforce resource requests; it only uses them as a basis for metric calculation.

Answer

To set a fixed 'targetCPUUtilizationPercentage' that scales down the deployment when exceeded.

Answer

To ensure that each pod has at least a certain amount of CPU resources reserved.

Question 11

Which TWO of the following are correct methods to implement a canary deployment using Kubernetes resources?

Accepted Answer

Create two Deployments (stable and canary) with a shared Service that selects both based on a common label. Initially, canary has 1 replica while stable has many. Gradually increase canary replicas.. Option C is correct because a native Kubernetes approach to canary deployment is to run two Deployments (stable and canary) that share a common label selected by a single Service; by starting the canary with 1 replica versus many stable replicas, the Service load-balances across all matching pods, so the canary receives a small fraction of traffic that grows as you scale its replicas up. Option E is correct because an Ingress controller such as NGINX Ingress supports canary traffic splitting via annotations (e.g., nginx.ingress.kubernetes.io/canary: "true" with canary-weight or canary-by-header), letting you route a defined percentage of requests to a separate canary Deployment/Service without touching the stable path. Option A is wrong because Kubernetes Deployment strategy.type only supports Recreate and RollingUpdate; there is no built-in 'Canary' strategy type. Option B is wrong because plain Kubernetes Services do not perform header-based routing; that requires an Ingress controller or service mesh, and the option as stated misattributes the capability to Services. Option D is wrong because DNS-based percentage routing is not a Kubernetes resource mechanism and DNS cannot reliably split traffic by percentage at the request level.

Answer

Use a Deployment with 'strategy.type: Canary' in the spec.

Answer

Create two Services and use a header-based routing to send specific users to canary.

Answer

Create two separate Services, one for stable and one for canary, and use DNS to route a percentage of traffic.

Question 12

Which TWO of the following are correct about the difference between 'kubectl apply' and 'kubectl create'?

Accepted Answer

'kubectl apply' can be used to update existing resources, whereas 'kubectl create' will fail if the resource already exists.. 'kubectl apply' can update existing resources, while 'kubectl create' will fail if the resource already exists. Option B is correct: 'kubectl apply' is declarative (manages desired state), whereas 'kubectl create' is imperative (directly creates). Option C is false: 'kubectl apply' can both create and update resources. Option D is false: 'kubectl apply' does not delete resources removed from the file; it only manages the resources in the file. Option E is false: 'kubectl create' can create resources from stdin, not just YAML files.

Answer

'kubectl apply' can only be used to create resources, not update them.

Answer

'kubectl apply' will delete resources if they are removed from the file.

Answer

'kubectl create' can only create resources from YAML files, not from stdin.

Question 13

You manage a Deployment named 'web' in namespace 'prod' whose pods mount a ConfigMap named 'web-config' as a volume at /etc/web. You update the ConfigMap data, but the running pods still serve the old configuration because the application only reads the mounted file at startup. You must roll out the new configuration to all pods with zero downtime and preserve the ability to roll back. What is the MOST appropriate action?

Accepted Answer

Run 'kubectl rollout restart deployment/web -n prod', which adds a restartedAt annotation to the pod template and triggers a new revision.. A rollout restart is the standard CKAD pattern for forcing pods to reload configuration that is consumed only at process start. It creates a new ReplicaSet revision by mutating the pod template annotation, so the rolling update proceeds with zero downtime and the previous ReplicaSet remains for rollback. Deleting the ConfigMap, changing the image, or manually signaling processes do not produce a clean, reversible rollout.

Answer

Edit the Deployment and change the container image tag to a new value, forcing Kubernetes to recreate all pods with the refreshed ConfigMap.

Answer

Use 'kubectl exec' into each pod and run a command to signal the application process to re-read /etc/web, then wait for the kubelet to sync the volume.

Answer

Delete the ConfigMap and recreate it with the updated data so the kubelet re-syncs the projected volume contents immediately.

Question 14

A developer needs to run a one-off batch job that processes a queue and must complete exactly once before the pod is terminated. The container image is 'registry.example.com/worker:1.4'. Which resource should be created to meet this requirement?

Accepted Answer

A Job with a pod template that sets restartPolicy to Never or OnFailure and a backoffLimit controlling retries.. A Job is purpose-built for run-to-completion workloads. Setting restartPolicy to Never or OnFailure and configuring backoffLimit gives controlled retries on failure, while a successful exit marks the Job complete without restarting the pod. Deployments restart containers indefinitely, CronJobs repeat on a schedule, and bare Pods lack controller-managed completion and rescheduling.

Answer

A CronJob with a schedule of '* * * * *' so the worker runs every minute and eventually processes the queue.

Answer

A Deployment with replicas set to 1 and a restartPolicy of Always so the worker restarts if it exits.

Answer

A bare Pod manifest with no controller, relying on the kubelet to restart the container if it fails.

Question 15

You are deploying a stateful application as a StatefulSet named 'db' with three replicas and a headless Service named 'db-headless'. The application requires each pod to have a stable network identity and its own persistent storage that survives pod rescheduling. Which combination of StatefulSet fields ensures this behavior?

Accepted Answer

Set serviceName to 'db-headless' and define volumeClaimTemplates so each pod gets a uniquely named PVC.. Stable identity and per-pod storage in a StatefulSet come from two fields working together. serviceName must point to a headless Service so each pod gets a predictable DNS name, and volumeClaimTemplates generates a distinct PVC per replica that is retained across rescheduling. Parallel pod management or a shared PVC do not satisfy both requirements simultaneously.

Answer

Set podManagementPolicy to Parallel and define volumeClaimTemplates so all pods start simultaneously with their own PVCs.

Answer

Set serviceName to a ClusterIP Service named 'db-svc' and define volumeClaimTemplates for per-pod storage.

Answer

Set serviceName to 'db-headless' and use a single shared PersistentVolumeClaim mounted by all three pods.