Scenario practice questions

You have a PriorityClass 'high-priority' with value 1000 and 'low-priority' with value 100. A pod A with 'high-priority' is pending because the node has no resources. A pod B with 'low-priority' is running on that node. What will happen if preemption is enabled?

Trap 1: Pod A will be scheduled only after pod B completes its work

This statement is incorrect because Kubernetes' preemption mechanism is specifically designed to prevent higher-priority pods from waiting. Instead of waiting for Pod B to naturally complete its execution and release resources, the kube-scheduler will actively identify Pod B as a candidate for eviction. This ensures that the critical Pod A, with its higher priority, gains immediate access to the necessary node resources without delay, overriding a simple FIFO scheduling approach.

Trap 2: Pod A will remain pending because preemption is not enabled by…

This option is false because preemption is a fundamental and enabled-by-default feature of the Kubernetes kube-scheduler. The scheduler continuously evaluates pending pods and, if a higher-priority pod cannot be scheduled due to resource constraints, it automatically initiates the preemption process. There is no special configuration or manual intervention required to activate this behavior, making the premise of preemption not being enabled by default incorrect.

Trap 3: The cluster administrator must manually delete pod B to allow pod A…

This option is incorrect as it fundamentally misrepresents the automated nature of Kubernetes preemption. The kube-scheduler is specifically designed to handle resource contention by identifying lower-priority pods that occupy resources needed by a higher-priority pod and then automatically triggering their eviction. Manual intervention by a cluster administrator to delete Pod B would bypass this built-in automation, which is designed for efficient and self-managing resource allocation.

A
Pod A will be scheduled only after pod B completes its work
Why it fails: This statement is incorrect because Kubernetes' preemption mechanism is specifically designed to prevent higher-priority pods from waiting. Instead of waiting for Pod B to naturally complete its execution and release resources, the kube-scheduler will actively identify Pod B as a candidate for eviction. This ensures that the critical Pod A, with its higher priority, gains immediate access to the necessary node resources without delay, overriding a simple FIFO scheduling approach.
B
Pod A will remain pending because preemption is not enabled by default
Why it fails: This option is false because preemption is a fundamental and enabled-by-default feature of the Kubernetes kube-scheduler. The scheduler continuously evaluates pending pods and, if a higher-priority pod cannot be scheduled due to resource constraints, it automatically initiates the preemption process. There is no special configuration or manual intervention required to activate this behavior, making the premise of preemption not being enabled by default incorrect.
C
The cluster administrator must manually delete pod B to allow pod A to schedule
Why it fails: This option is incorrect as it fundamentally misrepresents the automated nature of Kubernetes preemption. The kube-scheduler is specifically designed to handle resource contention by identifying lower-priority pods that occupy resources needed by a higher-priority pod and then automatically triggering their eviction. Manual intervention by a cluster administrator to delete Pod B would bypass this built-in automation, which is designed for efficient and self-managing resource allocation.
D
Pod B will be preempted (evicted) to allow pod A to be scheduled on the node
This is the correct behavior. When Pod A, possessing a higher priority, cannot find a node with sufficient available resources, the kube-scheduler will identify a node where Pod B (a lower-priority pod) is running and whose eviction would free up the necessary resources. The scheduler then initiates the preemption process, which involves evicting Pod B from that node. This action frees up the required resources, allowing Pod A to be successfully scheduled and started on the now-available node.

Question 2hardmulti select

You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)

Trap 1: Run 'kubectl get nodes' to check node status

Node status reflects the overall health of the Kubernetes node (Kubelet, CRI, and kube-proxy) but does not expose the state of pod-to-pod communication paths. A pod can be unable to reach another pod's Service even when all nodes show Ready, because the fault may lie in the Service's endpoint selector, a NetworkPolicy, or iptables/IPVS forwarding rules. Checking node status is a coarse, low-yield diagnostic that won't identify the specific break in the Service-to-pod chain.

Trap 2: Run 'kubectl logs' on the target pod to check application logs

Pod logs contain what the application writes to stdout/stderr, which reflects application-level behavior and not the underlying network forwarding or Service routing. A connectivity failure often occurs before a packet reaches the target container—for example, a NetworkPolicy drop, a Service with no endpoints, or a wrong port—so the target application may never even receive a request and thus log nothing. Logs are useful only after you have confirmed that packets can reach the pod; they cannot reveal why the Service is not routing traffic or why DNS resolution failed.

A
Run 'kubectl get nodes' to check node status
Why it fails: Node status reflects the overall health of the Kubernetes node (Kubelet, CRI, and kube-proxy) but does not expose the state of pod-to-pod communication paths. A pod can be unable to reach another pod's Service even when all nodes show Ready, because the fault may lie in the Service's endpoint selector, a NetworkPolicy, or iptables/IPVS forwarding rules. Checking node status is a coarse, low-yield diagnostic that won't identify the specific break in the Service-to-pod chain.
B
Run 'kubectl get endpoints' to verify the service has healthy endpoints
A Kubernetes Service only forwards traffic to Pod IPs listed in its Endpoints object, which are populated by the controller based on matching selectors and the readiness status of pods. If the selector matches no pods, or the pods are not Ready (e.g., failing readiness probes or CrashLoopBackOff), the Endpoints object is empty, so connections to the Service's ClusterIP are dropped or refused. Running 'kubectl get endpoints' is the quickest way to confirm whether the Service actually has healthy, Ready backends, directly exposing the most common cause of communication failure.
C
Exec into the pod and use curl to test connectivity to the service's cluster IP
Executing 'curl' from inside the pod directly to the Service's ClusterIP tests the actual network data path through kube-proxy, load-balancing rules, and the pod network, independent of DNS. If this curl fails, the problem is likely in network plumbing—such as missing iptables rules, a misconfigured NetworkPolicy, or the target pod not listening on the expected port—rather than in service name resolution. If it succeeds, you can narrow the issue to DNS or to how the application is addressing the Service, making this a precise, methodical troubleshooting step.
D
Run 'kubectl logs' on the target pod to check application logs
Why it fails: Pod logs contain what the application writes to stdout/stderr, which reflects application-level behavior and not the underlying network forwarding or Service routing. A connectivity failure often occurs before a packet reaches the target container—for example, a NetworkPolicy drop, a Service with no endpoints, or a wrong port—so the target application may never even receive a request and thus log nothing. Logs are useful only after you have confirmed that packets can reach the pod; they cannot reveal why the Service is not routing traffic or why DNS resolution failed.
E
Exec into the pod and run nslookup to verify DNS resolution of the service name
Executing 'nslookup' inside the pod queries the cluster's DNS (CoreDNS or kube-dns) and verifies that the Service's fully qualified name (e.g., myservice.namespace.svc.cluster.local) resolves to the correct ClusterIP. If resolution fails, you can inspect the pod's /etc/resolv.conf, the CoreDNS deployment, and the Service's namespace, because the name may be in a different namespace or the DNS DNS policy may be misconfigured. If resolution succeeds, you have isolated DNS as a healthy link and can focus on connectivity to the returned ClusterIP, avoiding the common pitfall of assuming a name-based request failure is always a DNS problem.

Question 3hardmultiple choice

A user reports that they can't authenticate to the cluster using a kubeconfig file. Running 'kubectl config view' shows the current context points to a user with client certificate and key. Which command checks the expiration date of the client certificate?

Trap 1: kubeadm upgrade plan --certificate-expiration

The kubeadm upgrade plan command is intended to map out the upgrade path and show available Kubernetes versions, not to inspect certificate validity. There is no --certificate-expiration flag on this subcommand, and invoking it would produce an unknown flag error. Certificate expiration details are only exposed through the separate kubeadm certs commands.

Trap 2: kubectl config view --raw | grep client-certificate

This pipeline prints the raw, base64-encoded client certificate data from the kubeconfig file, but it does not decode the file or calculate an expiration date. To extract the expiry, you would need to base64-decode the data, save it as a .crt file, and run openssl x509 separately. As a one-liner it only confirms that a certificate exists, not whether it is still valid.

Trap 3: openssl x509 -in /etc/kubernetes/admin.conf -text -noout

The /etc/kubernetes/admin.conf file is a kubeconfig YAML document, not a PEM certificate, so openssl x509 cannot read it directly; you would first need to extract the client-certificate-data field and decode it. Even then, that command only inspects the admin client certificate, which is used by the default cluster administrator, not necessarily the certificate or token of the user who is reporting the authentication failure. This makes it a poor diagnostic for a specific user's issue.

A
kubeadm upgrade plan --certificate-expiration
Why it fails: The kubeadm upgrade plan command is intended to map out the upgrade path and show available Kubernetes versions, not to inspect certificate validity. There is no --certificate-expiration flag on this subcommand, and invoking it would produce an unknown flag error. Certificate expiration details are only exposed through the separate kubeadm certs commands.
B
kubectl config view --raw | grep client-certificate
Why it fails: This pipeline prints the raw, base64-encoded client certificate data from the kubeconfig file, but it does not decode the file or calculate an expiration date. To extract the expiry, you would need to base64-decode the data, save it as a .crt file, and run openssl x509 separately. As a one-liner it only confirms that a certificate exists, not whether it is still valid.
C
openssl x509 -in /etc/kubernetes/admin.conf -text -noout
Why it fails: The /etc/kubernetes/admin.conf file is a kubeconfig YAML document, not a PEM certificate, so openssl x509 cannot read it directly; you would first need to extract the client-certificate-data field and decode it. Even then, that command only inspects the admin client certificate, which is used by the default cluster administrator, not necessarily the certificate or token of the user who is reporting the authentication failure. This makes it a poor diagnostic for a specific user's issue.
D
kubeadm certs check-expiration
This subcommand is the authoritative way to inspect the lifetimes of all certificates managed by kubeadm, including the CA, apiserver, controller-manager, scheduler, kubelet, and the client certificate embedded in admin.conf. It prints a table showing the expiration date and remaining days for each component, giving immediate insight into whether certificate expiry is causing authentication problems. For kubeadm-based clusters, this is the correct first tool for diagnosing certificate-related authentication issues.

Question 4mediummultiple choice

A CronJob is configured to run every hour. You notice that the job did not run at the scheduled time. What is the most likely reason?

Trap 1: The concurrency policy is set to 'Allow'

If the `concurrencyPolicy` is set to `Allow`, the CronJob controller permits multiple job instances to run simultaneously, even if previous jobs are still active. In this scenario, when a new scheduled time arrives, the controller would create and start a new Job object regardless of any currently running instances. Therefore, this setting would not cause a scheduled job run to be skipped, making it an incorrect reason for the observed behavior.

Trap 2: The previous job run succeeded and the CronJob is configured to not…

Kubernetes CronJobs are designed to execute Jobs on a recurring schedule, similar to a traditional Unix cron utility. Their execution is solely determined by the `schedule` field and the controller's internal timing mechanisms, not by the success or failure status of previous runs. There is no built-in configuration option or policy within CronJobs that would prevent a subsequent run based on the success of a prior job, making this statement fundamentally incorrect regarding CronJob functionality.

Trap 3: The concurrency policy is set to 'Replace'

When the `concurrencyPolicy` is configured as `Replace`, if a new job is scheduled while a previous job from the same CronJob is still running, the controller will actively terminate the existing, running job. Immediately after terminating the old job, it will then create and start the new scheduled job. This policy ensures that only the latest scheduled job runs, but it would not result in skipping a scheduled run altogether; instead, it forces a replacement.

A
The concurrency policy is set to 'Forbid' and a previous job was still running
When a CronJob's `concurrencyPolicy` is set to `Forbid`, the CronJob controller ensures that only one instance of the job runs at any given time. If the scheduled time for a new job arrives, but a previous job created by the same CronJob is still active (running or pending), the controller will simply skip the new scheduled run. This prevents resource contention or duplicate processing by ensuring strict sequential execution, directly explaining why a job might not run as scheduled.
B
The concurrency policy is set to 'Allow'
Why it fails: If the `concurrencyPolicy` is set to `Allow`, the CronJob controller permits multiple job instances to run simultaneously, even if previous jobs are still active. In this scenario, when a new scheduled time arrives, the controller would create and start a new Job object regardless of any currently running instances. Therefore, this setting would not cause a scheduled job run to be skipped, making it an incorrect reason for the observed behavior.
C
The previous job run succeeded and the CronJob is configured to not rerun after success
Why it fails: Kubernetes CronJobs are designed to execute Jobs on a recurring schedule, similar to a traditional Unix cron utility. Their execution is solely determined by the `schedule` field and the controller's internal timing mechanisms, not by the success or failure status of previous runs. There is no built-in configuration option or policy within CronJobs that would prevent a subsequent run based on the success of a prior job, making this statement fundamentally incorrect regarding CronJob functionality.
D
The concurrency policy is set to 'Replace'
Why it fails: When the `concurrencyPolicy` is configured as `Replace`, if a new job is scheduled while a previous job from the same CronJob is still running, the controller will actively terminate the existing, running job. Immediately after terminating the old job, it will then create and start the new scheduled job. This policy ensures that only the latest scheduled job runs, but it would not result in skipping a scheduled run altogether; instead, it forces a replacement.

Question 5mediummultiple choice

An administrator runs 'kubectl get pvc' and sees a PVC with status 'Lost'. What does this status indicate?

Trap 1: The PVC requested more storage than the available PV can provide

When a PersistentVolumeClaim requests a capacity larger than any available PersistentVolume can satisfy, the control plane's binder loop cannot bind them. Consequently, the PVC remains stuck in a Pending phase while it waits for a matching PV to be created or become available, rather than transitioning to a Lost state.

Trap 2: The pod using the PVC has been deleted

PersistentVolumeClaims exist independently of the Pods that consume them within the Kubernetes cluster lifecycle. Deleting a Pod that mounts a PVC will not alter the PVC's status, which typically remains Bound as long as its underlying PersistentVolume is intact and accessible.

Trap 3: The PVC's storage class does not match any available PV

If a PersistentVolumeClaim specifies a StorageClass that does not align with any existing PersistentVolume, or if dynamic provisioning fails to trigger, the PVC cannot be bound. This mismatch prevents the binding process from completing, leaving the PVC in a Pending state indefinitely instead of marking it as Lost.

A
The PVC requested more storage than the available PV can provide
Why it fails: When a PersistentVolumeClaim requests a capacity larger than any available PersistentVolume can satisfy, the control plane's binder loop cannot bind them. Consequently, the PVC remains stuck in a Pending phase while it waits for a matching PV to be created or become available, rather than transitioning to a Lost state.
B
The pod using the PVC has been deleted
Why it fails: PersistentVolumeClaims exist independently of the Pods that consume them within the Kubernetes cluster lifecycle. Deleting a Pod that mounts a PVC will not alter the PVC's status, which typically remains Bound as long as its underlying PersistentVolume is intact and accessible.
C
The PVC's storage class does not match any available PV
Why it fails: If a PersistentVolumeClaim specifies a StorageClass that does not align with any existing PersistentVolume, or if dynamic provisioning fails to trigger, the PVC cannot be bound. This mismatch prevents the binding process from completing, leaving the PVC in a Pending state indefinitely instead of marking it as Lost.
D
The PV that was bound to the PVC has been deleted or is no longer available
The Lost phase specifically indicates that a previously bound relationship has been broken because the underlying PersistentVolume was deleted from the cluster or is no longer accessible. Kubernetes updates the PVC's status to Lost to signal that the bound storage resource is missing, even though the claim object itself still exists.