CKA Practice Test 13 — 15 Questions

Question 1

Which command initializes a Kubernetes control plane node using kubeadm?

Accepted Answer

kubeadm init. `kubeadm init` is the specific command used to bootstrap and initialize a Kubernetes control plane node. It performs pre-flight checks, generates certificates, creates the static Pod manifests for core control plane components (API server, controller manager, scheduler, etcd), and configures the admin kubeconfig file. This is the standard kubeadm workflow for setting up a new cluster.

Answer

kubeadm create

Answer

kubeadm setup

Answer

kubeadm start

Question 2

A developer needs to access the Kubernetes API from a pod using a ServiceAccount. Which of the following is the recommended way to mount the ServiceAccount token into a pod?

Accepted Answer

Use a projected service account token with a mount path.. The recommended way to mount a ServiceAccount token into a pod is by using a projected service account token volume. This approach, introduced in Kubernetes 1.20, provides a time-bound, audience-scoped, and automatically rotated token that is mounted as a file at a specified mount path, enhancing security over static secrets.

Answer

Use the downward API to inject the token as an environment variable.

Answer

Set the token in the pod spec using the 'serviceAccountToken' field.

Answer

Mount the secret directly using a volume.

Question 3

A pod is in Pending state. You run 'kubectl describe pod pending-pod' and see an event: '0/3 nodes are available: 3 Insufficient memory'. However, you believe there is enough memory across the cluster. What could be the issue?

Accepted Answer

The pod's memory request is higher than any node's allocatable memory. The '0/3 nodes are available: 3 Insufficient memory' event indicates that the scheduler could not place the pod because each node lacks enough allocatable memory to satisfy the pod's memory request. Even if the cluster has plenty of total memory, the scheduler evaluates each node individually against the pod's resource requests, not the cluster-wide sum. Therefore, if the pod's memory request exceeds the allocatable memory on every node, the pod will remain Pending.

Answer

The cluster is using a resource quota that is exhausted

Answer

The pod's memory limit is set too low

Answer

The nodes have taints that the pod does not tolerate

Question 4

A Deployment named 'web-app' has 5 replicas. You want to perform a rolling update with a maximum of 3 pods unavailable during the update and a maximum of 2 extra pods above the desired count. Which YAML snippet correctly sets the rolling update strategy?

Accepted Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 3
      maxSurge: 2. The rolling update strategy specifies `maxUnavailable: 3` and `maxSurge: 2`. With 5 desired replicas, this allows up to 3 pods to be unavailable during the update (so at least 2 pods remain running) and up to 2 extra pods above the desired count (so a maximum of 7 pods total). This matches the requirement exactly.

Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 3

Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 2

Answer

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 3
      maxSurge: 3

Question 5

Which TWO of the following are valid ways to specify resource requests and limits for a container in a pod? (Select 2)

Accepted Answer

spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "1"
        memory: "1Gi". Options C and D are both correct. Option C uses the correct YAML structure with a `resources` block containing both `requests` and `limits`, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi"). Option D is also valid because Kubernetes allows specifying only `limits` without `requests`; the request defaults to the limit if omitted. Both options conform to the Kubernetes API specification for resource management in Pod containers. Options A, B, and E contain invalid syntax: A uses CPU and memory directly under the container without a resources block; B uses the singular `resource` instead of the plural `resources`; E uses invalid units ('millicores' and 'MB').

Answer

spec:
  containers:
  - name: app
    cpu: 0.5
    memory: 512Mi

Answer

spec:
  containers:
  - name: app
    resource:
      request:
        cpu: 1
        memory: 1Gi
      limit:
        cpu: 2
        memory: 2Gi

Answer

spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: "500 millicores"
        memory: "512 MB"

Question 6

Based on the exhibit, what is the most likely cause of the pod not running?

Accepted Answer

The Secret 'my-secret' does not exist in the namespace.. The pod's status indicates it is waiting for a secret to be mounted, and the error message 'secret "my-secret" not found' directly points to the missing Secret resource. Without the Secret existing in the same namespace as the pod, the volume mount fails, preventing the pod from starting.

Answer

The volume driver is not installed on node-1.

Answer

The pod has exceeded its resource limits.

Answer

The node 'node-1' is experiencing disk pressure.

Question 7

You are troubleshooting a network connectivity issue between two pods in different namespaces. The pods have the following labels: pod-a in namespace 'foo' with labels {app: web}, pod-b in namespace 'bar' with labels {app: db}. You verify that both pods have IP addresses and can ping the Kubernetes service IP. However, pod-a cannot connect to pod-b on port 5432. What should you check first?

Accepted Answer

Check if a NetworkPolicy exists that denies ingress traffic to pod-b from namespace 'foo'. Since pod-a can reach the Kubernetes service IP, the issue is likely a NetworkPolicy that denies ingress traffic from namespace 'foo' to pod-b on port 5432. NetworkPolicies can restrict cross-namespace traffic. Options A, C, and D are less likely because kube-proxy, container runtime, and DNS are not the primary suspects when connectivity to the service IP works.

Answer

Check if the kube-proxy is running on the node hosting pod-b

Answer

Check if the container runtime is Docker

Answer

Check if the DNS resolution for pod-b's service is correct

Question 8

Which component is responsible for running containers on a node?

Accepted Answer

container runtime. The container runtime is the software responsible for actually running containers on a node. It pulls container images, creates container namespaces, and manages the container lifecycle (start, stop, delete). In Kubernetes, the kubelet delegates container execution to the container runtime via the CRI (Container Runtime Interface), but the runtime itself performs the low-level operations using technologies like runc or containerd.

Answer

kubelet

Answer

kube-scheduler

Answer

kube-proxy

Question 9

You want to ensure that a pod only runs on nodes that have a GPU. Nodes with GPUs are labeled with 'gpu=true'. Which scheduling constraint should you use?

Accepted Answer

spec.nodeSelector: { gpu: "true" }. `spec.nodeSelector` is the simplest and most direct way to constrain a pod to nodes with a specific label. By setting `gpu: "true"` in the nodeSelector, the scheduler will only place the pod on nodes that have that exact label key-value pair. This is the standard Kubernetes mechanism for node-level selection based on labels.

Answer

spec.nodeName: gpu-node

Answer

spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution

Answer

spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

Question 10

Which of the following volume types is designed to store sensitive information such as passwords or tokens?

Accepted Answer

secret. The Secret volume type is specifically designed to store sensitive data such as passwords, tokens, or SSH keys. Secrets are stored in the cluster's etcd (optionally encrypted at rest) and are injected into pods as files or environment variables, with in-memory (tmpfs) mounting to avoid writing sensitive data to disk.

Answer

emptyDir

Answer

hostPath

Answer

configMap

Question 11

An admin wants to view the current context in their kubeconfig. Which command should they use?

Accepted Answer

kubectl config current-context. `kubectl config current-context` is the exact command to display the currently active context from the kubeconfig file. The context includes the cluster, namespace, and user that `kubectl` will use by default. This is a direct query of the `current-context` field in the kubeconfig YAML/JSON structure.

Answer

kubectl config get-contexts

Answer

kubectl cluster-info

Answer

kubectl config view

Question 12

Which kube-proxy mode uses iptables rules to handle service traffic?

Accepted Answer

iptables. Kube-proxy's iptables mode uses Linux iptables rules to handle service traffic. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the NAT table (specifically the PREROUTING and OUTPUT chains) to redirect traffic destined for a Service's ClusterIP to the backend Pod IPs via DNAT. This is the default mode in most Kubernetes distributions due to its reliability and moderate performance.

Answer

ipvs

Answer

nftables

Answer

userspace

Question 13

Which command is used to initialize a Kubernetes cluster using kubeadm?

Accepted Answer

kubeadm init. The correct command to initialize a Kubernetes cluster using kubeadm is `kubeadm init`. This command performs the bootstrap process by setting up the control plane components (e.g., API server, etcd, controller manager, scheduler) on the node, generating certificates, and creating the necessary configuration files in `/etc/kubernetes/`. It is the standard first step after installing kubeadm, kubelet, and a container runtime.

Answer

kubeadm create cluster

Answer

kubeadm start

Answer

kubeadm bootstrap

Question 14

Which command can you use to check the expiration date of certificates managed by kubeadm?

Accepted Answer

kubeadm certs check-expiration. The correct command is `kubeadm certs check-expiration`, which is a dedicated kubeadm subcommand that inspects all certificates managed by kubeadm and displays their expiration dates, remaining validity, and renewal status. This command reads the certificate files from `/etc/kubernetes/pki/` and parses their X.509 metadata, providing a concise summary without requiring external tools like OpenSSL.

Answer

kubectl get certificates

Answer

kubeadm certs list

Answer

kubeadm certs renew --check

Question 15

You have three pods selected by a service. One pod is in 'CrashLoopBackOff' state. How does the service's endpoints behave?

Accepted Answer

The service endpoints include only the two healthy pods. B is correct because Kubernetes services use endpoints (or endpoint slices) to track which pods are ready to receive traffic. The readiness probe determines pod readiness; a pod in CrashLoopBackOff fails its readiness probe, so it is removed from the service's endpoints. Only the two healthy pods remain in the endpoint list, ensuring traffic is routed only to healthy pods.

Answer

The service removes all endpoints to avoid partial connectivity

Answer

The service endpoints include the unhealthy pod but traffic is not routed to it

Answer

The service includes all three pods in its endpoints