CKA Workloads and Scheduling Practice Test 7 — 15 Questions

Question 1

A Pod has an init container that writes a configuration file, and the main container reads that file. The init container runs successfully, but the main container fails with 'file not found'. What is the most likely cause?

Accepted Answer

The init container wrote the file to a different volume than the one mounted in the main container.. Option B is correct. Init containers and main containers must share a volume to exchange data; otherwise, the init container's filesystem is not accessible to the main container. Option A is incorrect because init containers always run to completion before main containers start. Option C is incorrect because the main container's command is not the issue. Option D is incorrect because restarts do not affect file existence if the init container succeeded.

Answer

The main container restarted and the init container did not rerun.

Answer

The main container's command is incorrect.

Answer

The init container did not complete before the main container started.

Question 2

You have a ResourceQuota in a namespace that sets limits: pods: 10, requests.cpu: 4, requests.memory: 8Gi. You try to create a Pod with requests.cpu: 1, requests.memory: 2Gi, and no limits. The namespace currently has 8 pods using 3 CPUs and 5Gi memory in total requests. What happens?

Accepted Answer

The pod is created successfully.. Option A is correct because the ResourceQuota only enforces the total sum of requests across all pods in the namespace. Currently, the namespace has 8 pods using 3 CPUs and 5Gi memory. Adding a pod with requests.cpu: 1 and requests.memory: 2Gi would bring totals to 4 CPUs (3+1) and 7Gi memory (5+2), both within the quota limits of 4 CPUs and 8Gi. The pod does not specify limits, but ResourceQuota does not require limits unless a LimitRange enforces default limits; here, no LimitRange is mentioned, so the pod is allowed.

Answer

The pod is rejected because it exceeds the memory request quota.

Answer

The pod is rejected because it exceeds the CPU request quota.

Answer

The pod is rejected because it does not specify CPU and memory limits.

Question 3

A HorizontalPodAutoscaler (HPA) is configured for a Deployment with targetCPUUtilizationPercentage: 80. The current CPU utilization is 90%. The deployment has minReplicas: 3 and maxReplicas: 10. What will the HPA do?

Accepted Answer

It increases the number of replicas.. Option B is correct. The HPA will increase the number of replicas to bring the average CPU utilization down to 80%. Option A is incorrect because HPA does not add nodes, it adds pods. Option C is incorrect because the threshold is crossed (90% > 80%), so it will scale up. Option D is incorrect because HPA does not use pod priority.

Answer

It does nothing because the utilization is within the acceptable range.

Answer

It adds a new node to the cluster.

Answer

It decreases the number of replicas to reduce CPU usage.

Question 4

Which TWO statements are correct regarding DaemonSets?

Accepted Answer

DaemonSets are often used for cluster monitoring or logging agents.. Option D is correct because DaemonSets are designed to run a copy of a pod on every node (or a subset of nodes based on node selectors), making them ideal for cluster-wide infrastructure services such as monitoring agents (e.g., Prometheus Node Exporter), logging agents (e.g., Fluentd), and network plugins (e.g., Calico). This pattern ensures that each node has the necessary agent running without manual intervention.

Answer

DaemonSets do not support rolling updates.

Answer

DaemonSets can be scaled up and down using kubectl scale.

Answer

DaemonSets use a replica count to determine how many pods to run.

Question 5

Which THREE are valid ways to inject configuration data into a pod?

Accepted Answer

Mount a ConfigMap as a volume.. Options A, C, and D are correct. ConfigMaps can be mounted as volumes or injected as environment variables. Secrets can also be injected as environment variables. Option B is incorrect because there is no such thing as 'kubectl inject configmap'; injection is done via pod spec. Option E is incorrect because Secrets cannot be used as ConfigMap data; they are separate resources.

Answer

Use a Secret as a ConfigMap data source.

Answer

Use 'kubectl inject configmap' to inject data at runtime.

Question 6

Which TWO commands can be used to view the rollout history of a Deployment?

Accepted Answer

kubectl describe deployment my-app. Option C is correct because `kubectl describe deployment my-app` includes a 'RollingUpdateStrategy' section and a list of revision numbers under 'OldReplicaSets' and 'NewReplicaSet', which effectively shows the rollout history by displaying the current and previous ReplicaSets. Option E is correct because `kubectl rollout history deployment/my-app` is the dedicated command to list all revisions of a Deployment, showing revision numbers and change causes.

Answer

kubectl get deployment my-app -o wide

Answer

kubectl get deployment my-app -o yaml

Answer

kubectl rollout status deployment/my-app

Question 7

You have a Deployment named 'web-app' in the 'default' namespace. You run the following command: kubectl rollout history deployment web-app. The output shows: revision 1, revision 2, revision 3. You want to roll back to revision 1. Which command achieves this?

Accepted Answer

kubectl rollout undo deployment web-app --to-revision=1. Option A is correct. 'kubectl rollout undo deployment web-app --to-revision=1' rolls back to revision 1. Option B rolls back to the previous revision (2). Option C is incorrect because --revision flag does not exist. Option D uses 'rollback' which is not a valid kubectl command.

Answer

kubectl rollout undo deployment web-app --revision=1

Answer

kubectl rollback deployment web-app --to-revision=1

Answer

kubectl rollout undo deployment web-app

Question 8

You need to create a ConfigMap named 'app-config' from a file named 'config.properties' located in the current directory. Which command should you use?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. Option C is correct. The command 'kubectl create configmap app-config --from-file=config.properties' creates a ConfigMap from the file. Option A is incorrect because the syntax uses --from-literal for key-value pairs. Option B uses 'create configmap' but with wrong flag syntax. Option D is incorrect because 'apply' requires a manifest file.

Answer

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

Answer

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

Answer

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

Question 9

A StatefulSet named 'mysql' is deployed with 3 replicas. A developer reports that the pod 'mysql-0' is failing due to persistent volume issues. After fixing the underlying storage, they want to recreate 'mysql-0' while preserving its stable network identity. What is the correct approach?

Accepted Answer

Delete the pod 'mysql-0' using kubectl delete pod mysql-0, and let the StatefulSet controller recreate it. Option B is correct. Deleting a StatefulSet pod with kubectl delete pod will cause the StatefulSet controller to recreate it with the same name and identity. Option A is wrong because scaling down then up would recreate all pods and potentially lose the identity of mysql-0. Option C is wrong because you cannot recreate a pod that still exists. Option D is wrong because deleting the entire StatefulSet would delete all pods and PVCs.

Answer

Delete the StatefulSet and recreate it with the same configuration

Answer

Use kubectl replace --force on the StatefulSet to recreate the pod

Answer

Scale the StatefulSet down to 0 replicas, then scale back up to 3

Question 10

You have a DaemonSet named 'fluentd' that is intended to run on all worker nodes. After deploying, you notice that the DaemonSet pods are not running on a node that has the label 'node-type=worker'. What is the most likely reason?

Accepted Answer

The node has taints that the DaemonSet does not tolerate. Option C is correct. Taints on the node would prevent pods from being scheduled unless the pod has a matching toleration. If the DaemonSet does not have tolerations for the node's taints, the pods will not be scheduled on that node. Option A is incorrect because nodeSelector would prevent scheduling only if the node does not have the label, but the node has the label. Option B is incorrect because resource requests would cause pods to be pending, not simply not running. Option D is incorrect because DaemonSets are not affected by ReplicaSets.

Answer

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

Answer

The node has insufficient resources to run the DaemonSet pod

Answer

The DaemonSet's ReplicaSet is not managing the pods correctly

Question 11

A CronJob is configured to run every 5 minutes. After creation, no jobs are running. You inspect the CronJob and see that the 'suspend' field is set to false. The CronJob has a job history limit of 3. What could be the reason that no jobs are running?

Accepted Answer

The schedule is based on a time zone that does not match the cluster's time zone. Option A is correct. If the time zone of the cluster master node does not match the schedule time zone, the CronJob may not trigger at the expected times. Option B is incorrect because the suspend field is false, meaning it should run. Option C is incorrect because history limits do not prevent new jobs from starting. Option D is incorrect because concurrency policy does not prevent jobs from starting; it only handles overlaps.

Answer

The CronJob is suspended because 'suspend' is set to true

Answer

The concurrency policy is set to 'Forbid' and a previous job is still running

Answer

The job history limit of 3 prevents new jobs from being created

Question 12

You have a Deployment with 5 replicas. During a rolling update, you want to ensure that at most 3 pods are unavailable at any time. Which field should you set in the Deployment's strategy?

Accepted Answer

maxUnavailable: 3. Option B is correct. The 'maxUnavailable' field specifies the maximum number of pods that can be unavailable during the rolling update. Setting it to 3 means at most 3 pods can be down at once. Option A is incorrect because maxSurge specifies how many extra pods can be created above the desired count. Option C is incorrect because replicas is the desired number. Option D is incorrect because minReadySeconds affects readiness, not availability during update.

Answer

replicas: 3

Answer

minReadySeconds: 3

Answer

maxSurge: 3

Question 13

You create a Pod with an init container and a main container. The init container runs a script that writes to a shared volume. The main container reads from that volume. However, the Pod is stuck in 'Init:CrashLoopBackOff'. What is the most likely cause?

Accepted Answer

The init container's command is failing due to an error in the script. Option C is correct. If the init container is in CrashLoopBackOff, it means it is failing repeatedly. The most common cause is that the init container's command is failing (e.g., script error, missing dependencies). Option A is incorrect because resource limits on the main container do not affect init containers. Option B is incorrect because volume permissions would cause runtime issues, but the init container would still run. Option D is incorrect because init containers run sequentially; if one fails, the next does not start.

Answer

The init container is waiting for the main container to start

Answer

The main container has a resource limit that is too low

Answer

The shared volume is not mounted with the correct permissions

Question 14

You have a PriorityClass named 'high-priority' with value 1000 and 'low-priority' with value 100. A Pod with 'high-priority' is pending because no node has enough resources. Another Pod with 'low-priority' is running on a node. Will the high-priority Pod preempt the low-priority Pod?

Accepted Answer

Yes, because the high-priority Pod has a higher priority value and the scheduler will try to preempt lower-priority pods. Option B is correct. Pod preemption occurs when a higher-priority pod cannot be scheduled because of insufficient resources on nodes. The scheduler will attempt to preempt (evict) lower-priority pods to make room. Option A is incorrect because preemption is enabled by default but can be disabled. Option C is incorrect because preemption is not limited to nodes with taints. Option D is incorrect because priority values determine preemption behavior; higher value can preempt lower value.

Answer

No, because preemption only works on nodes with taints

Answer

No, because preemption is disabled by default

Answer

Yes, but only if the high-priority Pod has tolerations for the node's taints

Question 15

You are debugging a Pod that is in 'Pending' state. The output of 'kubectl describe pod' shows: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate. What does this indicate?

Accepted Answer

The pod cannot be scheduled due to a combination of insufficient CPU and untolerated taints on different nodes. Option D is correct. The message indicates two different issues: one node has insufficient CPU, and two nodes have a taint that the pod does not tolerate. So there are multiple reasons preventing scheduling. Option A is incorrect because insufficient memory is not mentioned. Option B is incorrect because only one node lacks CPU, and taints are also present. Option C is incorrect because taints are on multiple nodes, not all.

Answer

The pod requires more memory than any node can provide

Answer

All nodes have taints that the pod does not tolerate

Answer

All nodes have insufficient CPU resources for the pod