Certified Kubernetes Administrator (CKA) — All Questions

4 questions

Workloads & Scheduling

You need to ensure exactly one copy of a logging agent Pod runs on every node, including new nodes as they join. Which workload resource fits best?

  • a.Deployment
  • b.StatefulSet
  • c.DaemonSet
  • d.Job

A DaemonSet ensures a copy of a Pod runs on all (or selected) nodes and automatically adds the Pod to new nodes as they join. Deployments and StatefulSets manage a fixed or scaled replica count rather than one-per-node, and Jobs run to completion. DaemonSets are the standard choice for node-level agents such as log collectors.

Workloads & Scheduling

A node has a taint of key=value:NoSchedule. What must a Pod have to be scheduled onto that node?

  • a.A matching toleration for that taint
  • b.A nodeSelector that names the node
  • c.A higher priorityClassName
  • d.An init container that removes the taint

Taints repel Pods unless the Pod carries a matching toleration. NodeSelectors and affinity express a Pod's preference for nodes but do not overcome a NoSchedule taint. Priority affects preemption ordering, not taint tolerance, and containers cannot remove node taints.

Workloads & Scheduling

You want to perform a controlled rolling update of a Deployment and be able to undo it if the new version misbehaves. Which command reverts to the previous revision?

  • a.kubectl delete deployment then recreate it
  • b.kubectl scale deployment --replicas=0
  • c.kubectl edit deployment and change the name
  • d.kubectl rollout undo deployment/<name>

kubectl rollout undo reverts a Deployment to its previous revision using the revision history Kubernetes maintains. Scaling to zero only stops Pods, and deleting and recreating loses the managed rollout state. Rollout status and history commands complement undo for safe releases.

Workloads & Scheduling

A container specifies a CPU request of 250m and a CPU limit of 500m. What does the request value primarily influence?

  • a.The maximum CPU the container can ever burst to
  • b.How the scheduler decides which node has enough capacity for the Pod
  • c.The container's restart policy on CPU pressure
  • d.Whether the container image is pulled with high priority

The request is what the scheduler uses to find a node with enough allocatable CPU, and it guarantees that minimum share under contention. The limit (500m) caps how much CPU the container may use. Requests do not affect image pulls or restart policy directly.

Report