Workloads and Scheduling — CKA practice questions

Rolling back a broken Deployment?

1. kubectl delete deployment, then re-apply the previous manifest
2. kubectl rollout undo deployment/<name>, with --to-revision=N
3. kubectl edit deployment and paste the old pod template back in
4. kubectl delete pods to force the old ReplicaSet to scale up

Answer: B — kubectl rollout undo deployment/<name>, with --to-revision=N

B is right: undo re-points the Deployment at the previous ReplicaSet, or at a chosen revision listed by rollout history, keeping the object and its revisions intact. A causes an outage while the workload is gone. C works only if the old template is known exactly. D just recreates pods from the current, broken template.

Secret stored 'as-is' in etcd is:

1. AES-256 encrypted by default using a key held by the apiserver
2. Stored as a salted hash that the kubelet verifies at mount time
3. Held only in kubelet memory and never written to etcd at all
4. base64-encoded only, unless encryption at rest is configured

Answer: D — base64-encoded only, unless encryption at rest is configured

D is right: by default a Secret is merely base64-encoded in etcd, and encryption at rest requires an EncryptionConfiguration passed to the apiserver. A assumes that configuration is on by default. B confuses secrets with password storage; the value must be recoverable. C describes projected volumes on the node, not the stored object.

How do liveness and readiness probes differ?

1. They serve the same purpose; the two names are historical aliases for one health check
2. Both are used only at startup, and the kubelet stops evaluating them once pods are Ready
3. Both restart the container when they fail, differing only in their default probe timings
4. Both control Service routing, differing only in whether they use HTTP or exec probes
5. Liveness restarts a failing container; readiness removes the pod from Service endpoints

Answer: E — Liveness restarts a failing container; readiness removes the pod from Service endpoints

E is the answer: liveness answers whether the process is still healthy and the kubelet restarts the container when it fails, while readiness answers whether the pod should receive traffic and failure only removes it from the Service's endpoints. A startup probe covers slow-booting applications so liveness does not kill them early. A, B, C and D each collapse that distinction — the practical damage is using liveness where readiness belonged and getting restart loops under load.

A Job sets completions=5 and parallelism=2. What does that mean?

1. Ten pods start at once and the first five successes end the Job
2. Five pods run strictly one after another until all have exited
3. At most two pods run concurrently until five succeed in total
4. Five pods run, and two more are retried if any of them fail

Answer: C — At most two pods run concurrently until five succeed in total

C is right: completions is the number of successful pod runs required and parallelism caps how many run at once, so the controller keeps up to two in flight until five have succeeded. A multiplies the two fields, which is not how they combine. B describes parallelism=1, the default when the field is omitted. D confuses parallelism with backoffLimit, which caps retries before the Job is marked failed.

Which object is BEST for running a logging or monitoring agent on every node?

1. A Deployment with replicas set to the node count and pod anti-affinity per hostname
2. A StatefulSet, which gives ordinal names and a dedicated volume claim to each replica
3. A DaemonSet, which runs one pod per matching node and follows nodes joining or leaving
4. A Job with parallelism equal to the node count, which runs the agent once and completes
5. A CronJob that recreates the agent pods on a schedule so new nodes eventually get one

Answer: C — A DaemonSet, which runs one pod per matching node and follows nodes joining or leaving

C is the answer: a DaemonSet keeps exactly one pod on every node that matches its selector and reacts automatically when nodes join or are removed; tolerations let it run on tainted control-plane nodes. A tempts because it can approximate the layout, but the replica count is static and breaks the moment the cluster scales. B gives identity, not per-node coverage. D and E have completion semantics and leave gaps between runs.

What is the default Deployment update strategy and which fields tune it?

1. Recreate, tuned with maxUnavailable to stagger the terminating pods
2. A built-in Canary strategy driven by a stepWeight percentage field
3. A built-in BlueGreen strategy that flips the Service selector label
4. RollingUpdate, tuned with the maxSurge and maxUnavailable fields

Answer: D — RollingUpdate, tuned with the maxSurge and maxUnavailable fields

D is right: RollingUpdate is the default, with maxSurge and maxUnavailable both defaulting to 25%, so the Deployment can run slightly over the replica count while replacing pods. A names the other real strategy but attaches the wrong field - Recreate terminates every old pod before creating new ones and takes no rollout tuning. B and C name deployment patterns Kubernetes has no built-in primitive for; they are implemented with extra Services, or by add-ons such as Argo Rollouts or a service mesh.

Which required field does a StatefulSet need that a Deployment does not?

1. replicas, since a StatefulSet cannot default the number of pods
2. selector, which Deployments infer from the pod template labels
3. serviceName, naming the governing headless Service for pod DNS
4. image, which must be pinned by digest rather than by tag name

Answer: C — serviceName, naming the governing headless Service for pod DNS

C is right: spec.serviceName points at the governing headless Service that provides stable per-pod DNS names of the form <pod>.<service>.<ns>.svc.cluster.local, and the object is rejected without it. A is wrong because replicas defaults to 1 for both kinds. B is the half-right trap: selector is required, but it is required for Deployments too. D applies to neither - tags are accepted, though digests are better practice.

A ConfigMap is:

1. Storage for encrypted secrets only, with values sealed by the cluster's KMS provider
2. Non-sensitive key-value configuration injected as env vars, arguments or mounted files
3. A definition of a pod's containers, images and volumes applied through the API server
4. Networking configuration read by the CNI plugin when it wires up each pod's interface
5. Storage configuration read by the CSI driver when it provisions a volume for a claim

Answer: B — Non-sensitive key-value configuration injected as env vars, arguments or mounted files

B is the answer: a ConfigMap holds plain configuration — endpoints, feature flags, whole config files — and pods consume it through envFrom, configMapKeyRef or a mounted volume, so the same image runs in every environment. A describes what Secrets plus encryption at rest are for. C is the pod spec itself. D and E name components that read their own configuration, not ConfigMaps mounted into application pods.

Which Kubernetes object runs a task to completion rather than a long-running service?

1. Deployment, which keeps a replica count of long-running pods and rolls out updates
2. DaemonSet, which keeps one long-running agent pod on every node that matches it
3. StatefulSet, which keeps ordered, individually named long-running pods with storage
4. Job, which runs pods until the requested completions succeed, with a backoffLimit
5. A bare Pod, which is not recreated anywhere else once its node goes away for good

Answer: D — Job, which runs pods until the requested completions succeed, with a backoffLimit

D is the answer: a Job creates pods until spec.completions succeed, with parallelism for concurrency and backoffLimit bounding retries; a CronJob wraps a Job in a schedule. A, B and C all have restart-forever semantics — their pods are meant never to finish. E can run a task once, but nothing tracks completion or retries it, which is exactly what the Job controller adds.

A DaemonSet ensures:

1. One pod on every node, or on every node matching its selector, for node-level agents
2. Exactly one pod in the whole cluster, rescheduled elsewhere if its node goes away
3. A randomly chosen subset of nodes receives the pod, rebalanced as cluster load changes
4. One pod for each Service in the namespace, wired to that Service's list of endpoints
5. Only a scheduling preference; the pods themselves are still created by a Deployment

Answer: A — One pod on every node, or on every node matching its selector, for node-level agents

A is the answer: the DaemonSet controller creates a pod on each matching node and adds one automatically when a node joins, which is why log shippers, node exporters, CNI agents and kube-proxy ship this way; tolerations let it cover tainted control-plane nodes too. B is a single-replica Deployment. C is not how any controller behaves. D confuses workloads with Services. E is wrong because the DaemonSet controller creates the pods itself.

StatefulSet?

For stateful apps. Stable network identity, ordered deployment, persistent storage per pod.

Admission controllers?

Intercept API requests after auth. Validate/mutate resources before persisted.

LimitRange?

Default/min/max resources for pods/containers in namespace.

ReplicaSet purpose?

Maintains stable set of replica pods. Underlying mechanism for Deployment.