Text preview & study summary

Kubernetes CKAD - Certified Kubernetes Application Developer - Application Design Workloads Config Observability

A free sample of 5 questions from this quiz, shown in full with answer choices and explanations. No interactivity — everything is visible on this page for study and review.

Want to test your knowledge? Launch the Interactive Exam Simulator

Question 1

A developer needs to run a DaemonSet that deploys a log collection agent on every node, including control plane nodes. By default, the DaemonSet pods are NOT being scheduled on control plane nodes. What is the cause and solution?

Answer choices

  • A. DaemonSets don't support control plane nodes — use a StatefulSet instead

  • B. Control plane nodes have a taint `node-role.kubernetes.io/control-plane:NoSchedule` — add a toleration for this taint in the DaemonSet's pod spec (Correct)

  • C. Increase the DaemonSet's `maxUnavailable` to include control plane nodes

  • D. Label the control plane nodes with `daemonset: enabled` and add a `nodeSelector` to the DaemonSet

Explanation

Control plane nodes typically have the taint `node-role.kubernetes.io/control-plane:NoSchedule` (and/or `node-role.kubernetes.io/master:NoSchedule` in older versions). This prevents regular pods from being scheduled there. To deploy DaemonSet pods on control plane nodes, add a toleration in the pod spec:

```yaml

tolerations:

- key: node-role.kubernetes.io/control-plane

operator: Exists

effect: NoSchedule

```

DaemonSets fully support control plane nodes once the toleration is added.

Question 2

An application needs to gracefully handle shutdown signals. When a pod is deleted, Kubernetes sends `SIGTERM` to the container. The application needs 20 seconds to finish processing in-flight requests before terminating. How should this be configured?

Answer choices

  • A. Set `spec.terminationGracePeriodSeconds: 20` in the pod spec — Kubernetes will wait up to 20 seconds after SIGTERM before sending SIGKILL (Correct)

  • B. Add a `lifecycle.preStop` hook that sleeps for 20 seconds — the application doesn't need any changes

  • C. Set `spec.activeDeadlineSeconds: 20` — this controls the shutdown window

  • D. Configure `readinessProbe.failureThreshold: 20` to delay pod removal

Explanation

`terminationGracePeriodSeconds` (default: 30 seconds) defines how long Kubernetes waits after sending SIGTERM before force-killing with SIGKILL. Setting it to 20 gives the application 20 seconds to complete graceful shutdown. Option B (preStop hook sleep) is actually a valid complementary technique to ensure the pod is removed from service endpoints before shutdown, but the application itself needs to handle SIGTERM. `activeDeadlineSeconds` limits total pod running time, not shutdown time.

Question 3

A developer needs to run a data processing job that downloads a file, processes it, and exits. The job must retry up to 4 times if it fails. Which Kubernetes resource and configuration is correct?

Answer choices

  • A. Deployment with `restartPolicy: Always` and `replicas: 4`

  • B. Job with `backoffLimit: 4` and `restartPolicy: OnFailure` (Correct)

  • C. CronJob with `successfulJobsHistoryLimit: 4`

  • D. StatefulSet with `podManagementPolicy: Parallel`

Explanation

A Kubernetes Job with `backoffLimit: 4` allows up to 4 retries before marking the job as failed. The `restartPolicy: OnFailure` or `Never` is required for Jobs (not `Always`, which is used for Deployments). This is the correct pattern for batch/one-off processing tasks.

Question 4

A developer needs to ensure a specific container in a pod runs as a non-root user (UID 1000) and cannot escalate privileges. Which security configuration is correct?

```yaml

containers:

- name: app

image: myapp:v1

securityContext:

???

```

Answer choices

  • A. `runAsUser: 1000` and `allowPrivilegeEscalation: false` (Correct)

  • B. `user: 1000` and `privileged: false`

  • C. `uid: 1000` and `noEscalation: true`

  • D. `runAsNonRoot: true` — this automatically sets UID to 1000

Explanation

The correct container-level `securityContext` fields are `runAsUser: 1000` (sets the UID) and `allowPrivilegeEscalation: false` (prevents the process from gaining more privileges than its parent). Option D is incorrect — `runAsNonRoot: true` verifies that the container does not run as UID 0, but does NOT set a specific UID. The image must already have a non-root USER defined. Options B and C use non-existent field names.

Question 5

You need to build a multi-container pod where an init container downloads configuration files before the main application container starts. The init container should run `wget -O /config/app.conf http://config-server/app.conf`. Which pod spec structure is correct?

Answer choices

  • A. List both containers under `spec.containers[]` and use `depends_on`

  • B. Define the wget container under `spec.initContainers[]` with a shared `emptyDir` volume mounted at `/config` in both containers (Correct)

  • C. Use a sidecar container with `lifecycle.postStart` hook to run the wget command

  • D. Use a ConfigMap populated by a CronJob to pre-load the configuration

Explanation

Init containers are defined under `spec.initContainers[]` and run to completion before any containers in `spec.containers[]` start. Sharing an `emptyDir` volume between the init container (writing to `/config`) and the main container (reading from `/config`) is the standard pattern. There is no `depends_on` in Kubernetes pod specs.