CKA Workloads and Scheduling Practice Test 4 — 15 Questions

Question 1

You have a DaemonSet that runs on all nodes. You need to ensure it does NOT run on a node labeled 'disk=ssd'. Which field in the DaemonSet spec should you use?

Accepted Answer

spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution with NotIn operator. `nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution` with the `NotIn` operator allows you to specify that the DaemonSet pod must not be scheduled on nodes with the label `disk=ssd`. This is the proper way to express an anti-affinity rule that excludes nodes based on a label value, ensuring the DaemonSet runs on all nodes except those with `disk=ssd`.

Answer

spec.template.spec.nodeSelector with disk: ssd

Answer

spec.template.spec.tolerations with key disk value ssd

Answer

spec.updateStrategy.rollingUpdate.maxUnavailable

Question 2

A StatefulSet 'db' has 3 replicas. You scale it down to 1. In what order are the pods deleted?

Accepted Answer

db-2, db-1, db-0. When a StatefulSet is scaled down, pods are deleted in reverse ordinal order, starting from the highest index. This ensures that the StatefulSet's ordinal and identity guarantees are maintained, as each pod has a unique, stable identity. For a StatefulSet with 3 replicas (db-0, db-1, db-2), scaling to 1 deletes db-2 first, then db-1, leaving db-0 running.

Answer

db-0, db-1, db-2

Answer

Random order

Answer

All pods are deleted simultaneously

Question 3

A Job 'backup' uses the default restartPolicy. The pod completes successfully. What is the pod's phase?

Accepted Answer

Succeeded. The default restartPolicy for a Job is 'Never'. When a Job pod completes successfully (exit code 0), Kubernetes sets the pod's phase to 'Succeeded'. This is defined in the Kubernetes API, where the pod phase reflects the lifecycle outcome of the container execution.

Answer

Running

Answer

Completed

Answer

Terminated

Question 4

A container requests 256Mi memory and has a limit of 512Mi. The container tries to allocate 600Mi. What happens?

Accepted Answer

The container is killed with OOMKilled and restarted. The container's memory limit is 512Mi, and it attempts to allocate 600Mi, which exceeds the limit. Kubernetes enforces memory limits via cgroups; when a container exceeds its memory limit, the kernel's OOM killer terminates the process, resulting in an OOMKilled status. The container will then be restarted according to its restart policy (e.g., Always).

Answer

The container is allowed to use up to 600Mi if the node has free memory

Answer

The kernel throttles the container's memory usage

Answer

The container is evicted from the node

Question 5

You apply a LimitRange that sets default CPU request to 0.5 and default CPU limit to 1. You create a pod without specifying any CPU resources. What are the effective CPU request and limit for the pod?

Accepted Answer

request: 0.5, limit: 1. When a LimitRange is applied to a namespace, it automatically injects default resource requests and limits into pods that do not specify them. In this case, the LimitRange sets default CPU request to 0.5 and default CPU limit to 1, so the pod inherits these values. This ensures the pod is subject to resource constraints even without explicit specification.

Answer

request: 0.5, limit: 0 (no limit)

Answer

request: 0, limit: 0 (no defaults applied)

Answer

request: 1, limit: 0.5

Question 6

A node has a taint 'gpu=true:NoSchedule'. A pod has a toleration 'key: gpu, operator: Exists, effect: NoSchedule'. Will the pod be scheduled on the node?

Accepted Answer

Yes, because the toleration matches the taint. A toleration with `operator: Exists` and no `value` field matches any taint that has the specified key (`gpu`) and effect (`NoSchedule`), regardless of the taint's value. The taint `gpu=true:NoSchedule` has the key `gpu` and effect `NoSchedule`, so the toleration matches it perfectly, allowing the pod to be scheduled on the node. Tolerations do not require a value when using the `Exists` operator, as it checks only for the key and effect.

Answer

Yes, only if the pod has a nodeSelector for gpu

Answer

No, because the toleration does not specify a value

Answer

No, because the node also has other taints

Question 7

What is the purpose of a PriorityClass in Kubernetes scheduling?

Accepted Answer

To assign a priority value that determines the order pods are considered by the scheduler. PriorityClass in Kubernetes assigns an integer priority value to pods, which the scheduler uses to determine the order in which pods are considered for scheduling. Higher-priority pods are scheduled before lower-priority ones, and during resource contention, lower-priority pods may be preempted to make room for higher-priority pods. This ensures critical workloads get precedence over less important ones.

Answer

To set the quality of service class for a pod

Answer

To define which nodes are eligible for pod scheduling

Answer

To control the order in which containers are started inside a pod

Question 8

Which three are valid pod phases?

Accepted Answer

Pending. Pod phases are high-level summaries of the pod's lifecycle as defined in the Kubernetes API. The valid phases are Pending, Running, Succeeded, Failed, and Unknown. Pending is correct because it indicates the pod has been accepted by the cluster but one or more containers are not yet running (e.g., waiting for image pull or scheduling).

Answer

Terminating

Answer

CrashLoopBackOff

Question 9

Which two scheduling constraints can be used to ensure a pod runs on a node that has a specific label?

Accepted Answer

requiredDuringSchedulingIgnoredDuringExecution in nodeAffinity. Both `nodeSelector` and `requiredDuringSchedulingIgnoredDuringExecution` (under `nodeAffinity`) are hard scheduling constraints in Kubernetes used to ensure a pod is only scheduled onto nodes that possess specific labels.

- `nodeSelector` is the simplest node selection constraint, requiring an exact match of key-value label pairs.
- `requiredDuringSchedulingIgnoredDuringExecution` is a hard node affinity rule that allows for more expressive label matching (using operators like In, NotIn, Exists, etc.).

In contrast, `preferredDuringSchedulingIgnoredDuringExecution` is a soft preference (not a guarantee), `tolerations` are used to allow pods to schedule on tainted nodes, and `topologySpreadConstraints` are used to distribute pods across topology domains rather than targeting a specific node label.

Answer

topologySpreadConstraints

Answer

tolerations

Answer

preferredDuringSchedulingIgnoredDuringExecution

Question 10

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. To configure a rolling update with a maximum of 2 extra pods (maxSurge: 2) and a maximum of 1 unavailable pod (maxUnavailable: 1), the deployment strategy must be set to RollingUpdate (which is the default, but explicitly defining it is best practice) with the correct rollingUpdate parameters. Option B correctly specifies these parameters under spec.strategy.rollingUpdate. Option A has the values swapped. Option C uses the 'Recreate' strategy type, which does not support rolling update parameters. Option D uses incorrect percentage values that do not match the absolute requirements.

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 11

You have a DaemonSet that should run on all nodes with a label 'disk=ssd'. Which node selector field should you use in the DaemonSet spec?

Accepted Answer

spec.nodeSelector. `spec.template.spec.nodeSelector` is the simplest and most direct way to constrain a DaemonSet (or any Pod) to run only on nodes that have a specific label, such as 'disk=ssd'. When you set `nodeSelector: { disk: ssd }` inside the Pod template spec (`spec.template.spec`), the Kubernetes scheduler ensures that Pods are placed exclusively on nodes matching that label.

Answer

spec.tolerations

Answer

spec.nodeName

Answer

spec.affinity.nodeAffinity

Question 12

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 13

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

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. The `kubectl create configmap` command with the `--from-file` flag creates a ConfigMap from the contents of a specified file. When you use `--from-file=config.properties`, Kubernetes reads the file and creates a ConfigMap with a single key named after the filename (config.properties) and the file's content as the value. This is the standard method for importing configuration data from a properties file into a ConfigMap.

Answer

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

Answer

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

Answer

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

Question 14

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.. 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 15

You define a Pod with resource requests: cpu: 250m, memory: 256Mi. The node has 2 CPUs and 4 Gi of memory. How many of these Pods can fit on the node based on CPU requests alone?

Accepted Answer

8. Each Pod requests 250m CPU (0.25 CPU). With 2 CPUs available, the node can schedule up to 2 / 0.25 = 8 Pods based on CPU requests alone. This calculation assumes no other Pods or system overhead are present, and only CPU requests are considered.

Answer

10

Answer

16

Answer

4