Text preview & study summary

Kubernetes CKA - Certified Kubernetes Administrator - Cluster Architecture Workloads Networking Storage Security

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 Kubernetes administrator is troubleshooting a node that shows `NotReady` status in `kubectl get nodes`. Which components should the administrator investigate first, and what commands are most useful?

Answer choices

  • A. Check the kube-apiserver logs since all node issues originate there

  • B. SSH to the affected node and investigate the `kubelet` service status (`systemctl status kubelet`), check kubelet logs (`journalctl -u kubelet`), and verify container runtime (containerd/Docker) is running (Correct)

  • C. Restart the entire cluster to resolve node status issues

  • D. Delete and recreate the node object with `kubectl delete node` and re-join the cluster

Explanation

A `NotReady` node typically indicates kubelet failure or container runtime issues. Investigation steps: (1) Kubelet status: `systemctl status kubelet` — check if kubelet is running (should be `active (running)`). (2) Kubelet logs: `journalctl -u kubelet -n 50 --no-pager` — look for errors (certificate issues, container runtime connection failures, resource exhaustion). (3) Container runtime: `systemctl status containerd` (or `dockerd`) — if containerd is not running, kubelet cannot manage pods. (4) System resources: `df -h` (disk full), `free -m` (memory), `top` (CPU). (5) Network connectivity: Verify node can reach the API server. (6) CNI: Check network plugin pods if connectivity issues. The API server itself doesn't control node readiness — it receives reports from kubelet.

Question 2

A CKA administrator needs to configure a CronJob that runs a batch job every day at 3 AM UTC, using the `batch-processor` container image. The job should run to completion and not be retried on failure. How is this configured?

Answer choices

  • A. Create a scheduled Deployment with a startup time annotation

  • B. Create a CronJob with `schedule: "0 3 * * *"`, `image: batch-processor`, and `spec.jobTemplate.spec.backoffLimit: 0` (Correct)

  • C. Create a DaemonSet with a time-based trigger

  • D. Create a Kubernetes Timer object pointing to the Job manifest

Explanation

Kubernetes CronJob configuration: ```yaml apiVersion: batch/v1; kind: CronJob; metadata: {name: batch-job}; spec: schedule: "0 3 * * *"; jobTemplate: spec: template: spec: containers: [{name: processor, image: batch-processor}]; restartPolicy: Never; backoffLimit: 0```. Key settings: (1) `schedule` — standard cron format (`minute hour day-of-month month day-of-week`). `0 3 * * *` = 3:00 AM UTC daily. (2) `backoffLimit: 0` — no retries on failure (default is 6). (3) `restartPolicy` — must be `Never` or `OnFailure` for Jobs (not `Always`). (4) `concurrencyPolicy`: `Allow` (default), `Forbid` (don't start new if previous running), `Replace` (cancel previous, start new). (5) `successfulJobsHistoryLimit/failedJobsHistoryLimit` — control how many completed/failed Jobs to retain. CronJobs create Job objects at each scheduled time.

Question 3

A CKA administrator needs to configure a static pod on a worker node. Static pods are managed directly by kubelet without the Kubernetes API server. What is the configuration mechanism?

Answer choices

  • A. Create the Pod manifest in the `/etc/kubernetes/manifests/` directory on the target node; kubelet automatically creates and manages the Pod (Correct)

  • B. Use `kubectl create pod --static=true` with the node name

  • C. Configure the Pod in a DaemonSet with `nodeSelector` targeting the specific node

  • D. Use `kubectl apply --node=worker-1` to schedule a Pod on a specific node

Explanation

Static Pods are defined by placing manifest YAML files in a specific directory on the node (default: `/etc/kubernetes/manifests/`). The kubelet on that node watches this directory and automatically creates, restarts, and manages the Pods defined there. Key properties: (1) Managed by kubelet — not by the API server (no ReplicaSet, Deployment, or controllers). (2) Mirror pods — the API server creates read-only "mirror pod" objects visible via `kubectl get pods`, but you cannot modify them via kubectl. (3) Use case — control plane components (kube-apiserver, kube-controller-manager, kube-scheduler, etcd) in kubeadm clusters are static pods. (4) Configuration path — defined in kubelet config: `staticPodPath: /etc/kubernetes/manifests`. To delete a static pod, remove the manifest file from the directory.

Question 4

A Kubernetes administrator needs to debug a failing application. The Pod is running but the application inside is not responding. They need to execute a command inside the running container. Which kubectl command provides an interactive shell?

Answer choices

  • A. `kubectl attach <pod-name>` — attaches to the container's stdin/stdout

  • B. `kubectl exec -it <pod-name> -- /bin/bash` (or `/bin/sh` if bash is not available) — starts an interactive shell in the running container (Correct)

  • C. `kubectl ssh <pod-name>` — provides SSH access to the container

  • D. `kubectl debug <pod-name>` — always provides a bash shell for debugging

Explanation

`kubectl exec` runs a command inside a running container: (1) Interactive shell: `kubectl exec -it <pod-name> -c <container-name> -- /bin/bash`. Flags: `-i` (pass stdin to container), `-t` (allocate pseudo-TTY for interactive use). `-c` specifies the container name (required for multi-container Pods). (2) Single command: `kubectl exec <pod-name> -- ls /app`. (3) Non-bash containers (distroless, scratch): Use `kubectl debug` to attach an ephemeral debug container: `kubectl debug -it <pod-name> --image=busybox --target=<container-name>`. (4) Alternative for no-exec containers: `kubectl cp <pod-name>:/path/to/file ./local-file` copies files without exec. `kubectl attach` connects to stdout but is less useful for interactive debugging. `kubectl ssh` is not a valid kubectl command.

Question 5

A Kubernetes administrator needs to configure a Pod to run as a non-root user (UID 1000) and prevent privilege escalation. Which Pod specification section controls these security settings?

Answer choices

  • A. The `metadata.annotations` section with security annotations

  • B. The `spec.securityContext` (Pod-level) and `spec.containers[].securityContext` (container-level) sections (Correct)

  • C. The `spec.nodeSelector` section with security labels

  • D. The RBAC ClusterRole assigned to the Pod's ServiceAccount

Explanation

Kubernetes security contexts control security settings for Pods and containers: (1) Pod-level `spec.securityContext` — applies to all containers: `runAsUser: 1000` (UID), `runAsGroup: 3000` (GID), `fsGroup: 2000` (volume ownership), `runAsNonRoot: true` (block UID 0). (2) Container-level `spec.containers[].securityContext` — per-container overrides: `allowPrivilegeEscalation: false` (prevents setuid/capabilities escalation), `privileged: false` (prevents privileged container), `readOnlyRootFilesystem: true` (immutable container filesystem), `capabilities: {drop: [ALL], add: [NET_BIND_SERVICE]}` (Linux capabilities). Best practice: set `runAsNonRoot: true` and `allowPrivilegeEscalation: false` for all production containers. PodSecurityAdmission (PSA) can enforce these policies cluster-wide using `restricted`, `baseline`, or `privileged` standards. RBAC controls API access, not container execution context.