Scenario practice questions

Match each troubleshooting scenario to its likely cause.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Insufficient resources or unschedulable Node

Application crashes repeatedly

Missing or incorrect Endpoint selector labels

Kubelet not reporting or network issue

Invalid image name or registry authentication failure

Question 2easymultiple choice

Given the exhibit, a pod in the same namespace tries to reach my-service on port 80. What is the most likely outcome?

Exhibit

Refer to the exhibit.

$ kubectl get svc my-service -o yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  clusterIP: 10.96.0.1
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: my-app
  type: ClusterIP
status:
  loadBalancer: {}

$ kubectl get endpoints my-service
NAME         ENDPOINTS          AGE
my-service   192.168.1.10:8080  5m

Trap 1: The connection succeeds but reaches the pod on port 80.

The targetPort is 8080, not 80.

Trap 2: The connection fails because the endpoints list is empty.

The endpoints list is not empty; it contains one endpoint.

Trap 3: The connection is randomly dropped due to missing port…

The port specification is present and correct.

A
The connection succeeds but reaches the pod on port 80.
Why wrong: The targetPort is 8080, not 80.
B
The connection fails because the endpoints list is empty.
Why wrong: The endpoints list is not empty; it contains one endpoint.
C
The connection is randomly dropped due to missing port specification.
Why wrong: The port specification is present and correct.
D
The connection succeeds and reaches the pod on port 8080.
The service is correctly configured with endpoints mapping port 80 to targetPort 8080.

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

There is no such flag.

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

This shows the certificate data but does not decode expiration.

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

This checks the admin.conf certificate, but the user may not be using admin.conf.

A
kubeadm upgrade plan --certificate-expiration
Why wrong: There is no such flag.
B
kubectl config view --raw | grep client-certificate
Why wrong: This shows the certificate data but does not decode expiration.
C
openssl x509 -in /etc/kubernetes/admin.conf -text -noout
Why wrong: This checks the admin.conf certificate, but the user may not be using admin.conf.
D
kubeadm certs check-expiration
This command displays expiration dates for all certificates managed by kubeadm.

Question 4hardmultiple choice

An administrator runs 'kubectl run nginx --image=nginx --port=80' and then 'kubectl expose pod nginx --port=80 --type=NodePort'. Later, they run 'kubectl get svc nginx' and see that the NodePort is set to 0. What is the most likely reason?

Trap 1: The pod was not ready when the service was created, so NodePort…

NodePort is assigned immediately regardless of pod readiness.

Trap 2: The nodePort field was explicitly set to 0 in the service YAML, but…

Setting nodePort to 0 is not allowed; it must be within the range.

Trap 3: The pod was created by a Deployment, so its labels do not match the…

Even if labels mismatch, the NodePort should still be assigned.

A
The pod was not ready when the service was created, so NodePort assignment was delayed.
Why wrong: NodePort is assigned immediately regardless of pod readiness.
B
The nodePort field was explicitly set to 0 in the service YAML, but the administrator used a flag that was ignored.
Why wrong: Setting nodePort to 0 is not allowed; it must be within the range.
C
The cluster has a mutating webhook that converted the service type to ClusterIP because NodePort is disabled.
A cluster-level policy may disallow NodePort services, causing the type to be overridden.
D
The pod was created by a Deployment, so its labels do not match the service selector.
Why wrong: Even if labels mismatch, the NodePort should still be assigned.

Read the full NAT/PAT explanation →

Question 5mediummultiple choice

A cluster administrator creates a PersistentVolume with the following YAML:

apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv

A user creates a PersistentVolumeClaim requesting 500Mi with access mode ReadWriteOnce and no storage class. The PVC remains in Pending state. What is the most likely cause?

Trap 1: The PV's reclaim policy is Retain, so it is in Released state and…

A newly created PV with Retain policy is in Available state and can be bound. It transitions to Released only after the bound PVC is deleted.

Trap 2: The hostPath path /data/pv does not exist on any node in the…

The existence of the hostPath directory does not affect PVC binding; it affects pod scheduling when the volume is mounted.

Trap 3: The PVC requests 500Mi, but the PV has 1Gi capacity, which is…

A PV's capacity must be greater than or equal to the PVC's request. 1Gi >= 500Mi, so it is a valid match.

A
The PV's reclaim policy is Retain, so it is in Released state and cannot be bound to a new PVC.
Why wrong: A newly created PV with Retain policy is in Available state and can be bound. It transitions to Released only after the bound PVC is deleted.
B
The cluster has a default StorageClass defined, causing the PVC to attempt dynamic provisioning instead of binding to this static PV.
When a default StorageClass exists, a PVC without a storageClassName will use that class for dynamic provisioning, ignoring static PVs without a matching class.
C
The hostPath path /data/pv does not exist on any node in the cluster.
Why wrong: The existence of the hostPath directory does not affect PVC binding; it affects pod scheduling when the volume is mounted.
D
The PVC requests 500Mi, but the PV has 1Gi capacity, which is larger than requested, so the PVC cannot bind to it.
Why wrong: A PV's capacity must be greater than or equal to the PVC's request. 1Gi >= 500Mi, so it is a valid match.

Read the full NAT/PAT explanation →

Question 6hardmultiple choice

You are debugging a CrashLoopBackOff. The pod YAML includes the following container spec:

```yaml containers: - name: app image: myapp:1.0 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 3 ```

The application starts successfully but crashes after about 10 seconds. What is the most likely cause?

Trap 1: The container image myapp:1.0 does not exist

If the image did not exist, the pod would be in ImagePullBackOff, not CrashLoopBackOff.

Trap 2: The liveness probe is too aggressive, causing the container to be…

The initialDelaySeconds of 3 and periodSeconds of 3 are typical; the app starts successfully, so the probe likely passes.

Trap 3: The pod is running out of memory

Memory exhaustion would cause OOMKilled, not a liveness probe failure.

A
The container image myapp:1.0 does not exist
Why wrong: If the image did not exist, the pod would be in ImagePullBackOff, not CrashLoopBackOff.
B
The application's health endpoint /healthz is not responding with HTTP 200
If the health endpoint does not return a success status, the liveness probe fails and kills the container, causing a restart.
C
The liveness probe is too aggressive, causing the container to be killed before it fully initializes
Why wrong: The initialDelaySeconds of 3 and periodSeconds of 3 are typical; the app starts successfully, so the probe likely passes.
D
The pod is running out of memory
Why wrong: Memory exhaustion would cause OOMKilled, not a liveness probe failure.