CKA Practice Exam 64 — 20 Questions

Question 1

A Job named 'pi' runs a container that computes pi to 2000 digits. The Job's spec has completions=3 and parallelism=2. After some time, you observe that two pods completed successfully, and the third pod is still running. What is the expected behavior when the third pod completes?

Accepted Answer

The Job will be marked as Complete. Option A is correct because a Job with `completions=3` and `parallelism=2` is considered complete when the required number of successful pod completions (3) is reached. Since two pods have already completed and the third is still running, once it finishes successfully, the total successful completions will equal the `completions` value, and the Job controller will mark the Job as Complete. The Job does not require all pods to run concurrently or finish simultaneously.

Answer

The Job will restart the completed pods

Answer

The Job will continue to run new pods indefinitely

Answer

The Job will be marked as Failed because parallelism is not fully utilized

Question 2

You create a PriorityClass named 'high-priority' with value 1000000 (one million). A pod uses this PriorityClass. The cluster has limited resources. What scheduling behavior is most likely?

Accepted Answer

The pod may preempt lower-priority pods to be scheduled. PriorityClass with value 1000000 is extremely high (the default max is 1 billion). When a pod with this PriorityClass is submitted and the cluster has limited resources, the Kubernetes scheduler may preempt (evict) lower-priority pods to free resources and schedule this high-priority pod. This is the core behavior of PriorityClass and preemption in Kubernetes.

Answer

The pod will never be preempted by other pods

Answer

The pod will be scheduled only after all lower-priority pods have been scheduled

Answer

The pod will be assigned a higher CPU priority in the kernel

Question 3

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". Option C is correct because it uses the correct YAML structure with a `resources` block containing `requests` and `limits` subfields, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi") under the container spec. This matches the Kubernetes API specification for resource management in Pod containers.

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 4

A CronJob runs every hour. The job takes 45 minutes to complete. What is the default behavior if the next scheduled time occurs while the previous job is still running?

Accepted Answer

The next job starts immediately, running concurrently. By default, CronJobs in Kubernetes do not allow concurrent executions. If a new job is scheduled while the previous one is still running, the new job is skipped (i.e., not created) because the `concurrencyPolicy` defaults to `Forbid`. However, the question states the correct answer is C, which implies the CronJob has been configured with `concurrencyPolicy: Allow`. In that case, the next job starts immediately, running concurrently with the previous one.

Answer

The next job is queued and starts after the previous finishes

Answer

The next job is skipped

Answer

The CronJob is suspended

Question 5

Which of the following is a valid way to mount a Secret as a volume in a Pod?

Accepted Answer

volumes:
- name: secret-volume
  secret:
    secretName: my-secret. Option A is correct because it uses the `secret` volume type with the `secretName` field to reference a Kubernetes Secret object. This is the standard syntax for mounting a Secret as a volume in a Pod, allowing the Secret's data to be exposed as files in the container's filesystem.

Answer

volumes:
- name: secret-volume
  secretName: my-secret

Answer

volumes:
- name: secret-volume
  configMap:
    name: my-secret

Answer

volumes:
- name: secret-volume
  hostPath:
    path: /etc/secret

Question 6

Which TWO of the following are valid ways to inject a ConfigMap into a pod as environment variables? (Select 2)

Accepted Answer

Using env with valueFrom.configMapKeyRef. Option C is correct because `env.valueFrom.configMapKeyRef` allows you to inject a specific key from a ConfigMap as an environment variable into a pod. This is a standard Kubernetes API pattern for selectively exposing ConfigMap data as environment variables.

Answer

Using volumeMounts with configMapKeyRef

Answer

Using env with configMapRef

Answer

Using volumes with configMap

Question 7

A Deployment named 'web-app' has 10 replicas. You want to perform a rolling update with a maximum of 2 extra pods during the update and a maximum of 1 pod unavailable at any time. Which YAML snippet correctly sets these rolling update parameters?

Accepted Answer

spec:
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1. Option B is correct because it sets `maxSurge: 2` and `maxUnavailable: 1`, which means during the rolling update, Kubernetes can create up to 2 extra pods above the desired 10 replicas (allowing 12 total) and can have at most 1 pod unavailable at any time. This satisfies the requirement of a maximum of 2 extra pods and a maximum of 1 unavailable pod.

Answer

spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 2

Answer

spec:
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1

Answer

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

Question 8

A StatefulSet named 'mysql' manages 3 replicas. You need to scale it down to 1 replica. What happens to the PersistentVolumeClaims (PVCs) of the removed pods?

Accepted Answer

The PVCs are retained to preserve data.. When a StatefulSet is scaled down, the PersistentVolumeClaims (PVCs) associated with the removed pods are retained by default. This is because StatefulSets are designed for stateful workloads where data persistence is critical; the PVCs remain to preserve data in case the pod is recreated or the StatefulSet is scaled up again. Kubernetes does not automatically delete PVCs when a StatefulSet pod is removed, as PVC lifecycle is independent of pod lifecycle.

Answer

The PVCs are automatically backed up before deletion.

Answer

The PVCs are retained only if the pod with the highest ordinal is removed first.

Answer

The PVCs are automatically deleted along with the pods.

Question 9

Which command creates a ConfigMap named 'app-config' from a file 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. Option D is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the specified file. The `--from-file` flag reads the file and stores its entire content as a key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content.

Answer

kubectl create cm app-config --file=config.properties

Answer

kubectl create configmap app-config --from-literal=config.properties

Answer

kubectl create configmap app-config --from-env-file=config.properties

Question 10

A Job named 'data-processor' completes successfully. You want to run it again with the same configuration. What is the correct way to rerun the Job?

Accepted Answer

Delete the Job with 'kubectl delete job data-processor' and then recreate it.. Option B is correct because a completed Job in Kubernetes is immutable and cannot be rerun by editing or restarting it. The only way to execute the same Job again is to delete the existing Job and recreate it with the same configuration, as Jobs are designed to run to completion and are not intended to be restarted like Deployments.

Answer

Edit the Job with 'kubectl edit job data-processor' and change the template.

Answer

Run 'kubectl rollout restart job data-processor'

Answer

Run 'kubectl rerun job data-processor'

Question 11

Which THREE of the following are true about pod lifecycle phases?

Accepted Answer

Running phase means all containers are running.. Option A is correct because the Running phase in Kubernetes indicates that all containers in the pod are running and at least one container is in the running state. This phase is part of the pod lifecycle as defined in the Kubernetes API, where the pod has been bound to a node and all containers have been started successfully.

Answer

CrashLoopBackOff is a pod phase.

Answer

Terminating is a pod phase during graceful shutdown.

Question 12

A DaemonSet is expected to run on all nodes, but a particular node does not have the pod. The node is Ready and has no taints. You run 'kubectl describe daemonset <name>' and see 'MISSING' for that node. What is a likely cause?

Accepted Answer

The DaemonSet has a nodeSelector that the node does not match. When a DaemonSet shows 'MISSING' for a specific node that is Ready and has no taints, the most common cause is that the node does not match the DaemonSet's nodeSelector. The nodeSelector field in the DaemonSet spec defines a set of key-value pairs that must match the node's labels. If the node lacks the required labels, the DaemonSet controller will not schedule the pod on that node, resulting in the 'MISSING' status.

Answer

The DaemonSet is configured to run only on control plane nodes

Answer

The node has insufficient resources for the DaemonSet pod

Answer

The node has a taint that is not tolerated

Question 13

A pod has an init container that downloads a large file. The init container uses the 'busybox' image and runs the command 'wget http://example.com/data.zip'. The pod's status shows 'Init:0/1' and then 'PodInitializing'. After a few minutes, the pod enters 'Init:Error'. What is the most likely cause?

Accepted Answer

The init container's command failed. The init container runs a `wget` command to download a file. The pod transitions from `Init:0/1` to `PodInitializing` (indicating the init container started) and then to `Init:Error`, which means the init container exited with a non-zero exit code. Since the image is `busybox` (which includes `wget`), the most likely cause is that the `wget` command itself failed — e.g., due to a network issue, a bad URL, or a timeout — not an image pull failure or resource limit.

Answer

The init container image was not found

Answer

The pod's main container failed to start

Answer

The init container exceeded a resource limit

Question 14

Which command scales a Deployment named 'frontend' to 5 replicas?

Accepted Answer

kubectl scale deployment frontend --replicas=5. Option D is correct because the `kubectl scale` command with the `--replicas=5` flag directly sets the desired number of replicas for the Deployment named 'frontend' to 5. This updates the Deployment's `spec.replicas` field, causing the ReplicaSet controller to adjust the number of Pods to match the new desired count.

Answer

kubectl autoscale deployment frontend --max=5

Answer

kubectl rollout restart deployment frontend

Answer

kubectl scale deployment frontend --replicas 5

Question 15

A DaemonSet named 'fluentd' is configured to run on all nodes. After adding a new node to the cluster, you notice that the DaemonSet pod is not running on the new node. What could be the cause?

Accepted Answer

The new node has a taint that the DaemonSet pod does not tolerate. A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes. When a new node is added, the DaemonSet controller automatically schedules a pod on it unless the node has a taint that the pod does not tolerate. By default, the new node may have a taint (e.g., `node.kubernetes.io/unschedulable` or a custom taint) that prevents the DaemonSet pod from being scheduled unless the pod's spec includes a matching toleration.

Answer

The new node does not have enough resources to run the DaemonSet pod

Answer

The DaemonSet has a nodeSelector that does not match the new node's labels

Answer

The DaemonSet's update strategy is set to OnDelete

Question 16

You have a pod with resource requests: cpu: 500m, memory: 128Mi. The node has 4 CPU cores and 8Gi memory. What is the maximum number of such pods that can be scheduled on this node based on CPU only?

Accepted Answer

8. The node has 4 CPU cores, which equals 4000m (millicores). Each pod requests 500m CPU. Dividing 4000m by 500m gives 8 pods. This is the maximum number that can be scheduled based on CPU alone, assuming no other pods or system overhead. Option D is correct.

Answer

4

Answer

16

Answer

6

Question 17

Which annotation is commonly used to trigger a rollout restart of a Deployment when a ConfigMap is updated?

Accepted Answer

kubectl.kubernetes.io/restartedAt. Option D is correct because the annotation `kubectl.kubernetes.io/restartedAt` is commonly used with `kubectl rollout restart` to trigger a rolling restart of a Deployment. When a ConfigMap is updated, Pods using it via `envFrom` or `volumes` are not automatically updated; adding or updating this annotation on the Deployment's pod template forces a new ReplicaSet to be created, picking up the latest ConfigMap data.

Answer

configmap.kubernetes.io/update-trigger

Answer

field.cattle.io/updateStrategy

Answer

kubectl.kubernetes.io/last-applied-configuration

Question 18

You need to schedule a pod on a node with label 'disktype=ssd'. Which field should you add to the pod spec?

Accepted Answer

nodeSelector. The `nodeSelector` field in a Pod spec is the simplest and most direct way to constrain a Pod to nodes that have a specific label. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only consider nodes that have the label `disktype=ssd` for placement. This is a hard constraint that does not require any additional configuration on the nodes.

Answer

tolerations

Answer

nodeName

Answer

affinity.nodeAffinity

Question 19

Which of the following is a valid way to mount a Secret as a volume in a pod?

Accepted Answer

spec.containers[0].volumeMounts[0].name: secret-volume; spec.volumes[0].secret.secretName: my-secret. Option A is correct because it defines a volume of type `secret` with the `secretName` field set to `my-secret`, and then mounts that volume into the container using a `volumeMount` with the same name. This is the standard YAML syntax for mounting a Kubernetes Secret as a volume in a pod.

Answer

spec.containers[0].envFrom[0].secretRef.name: my-secret

Answer

spec.containers[0].volumeMounts[0].name: config-volume; spec.volumes[0].configMap.name: my-secret

Question 20

Which TWO of the following are valid methods to expose ConfigMap data to pods?

Accepted Answer

As environment variables. Option A is correct because ConfigMap data can be injected into a pod as environment variables using the `envFrom` or `env` field in the pod spec, referencing the ConfigMap name and keys. This allows the pod to consume configuration values as standard environment variables, which are accessible to the container runtime at process startup.

Answer

As a Kubernetes Service

Answer

As a container command argument

Answer

As a Pod annotation