Troubleshooting — Workloads and Networking — CKA practice questions

Which `kubectl describe pod` section is MOST useful when a pod was admitted but never reached Running?

1. The Events list at the bottom, which records scheduling and kubelet messages
2. The Labels and Annotations block, which shows the controller that owns it
3. The Tolerations block, which enumerates every taint the node currently carries
4. The QoS Class line, which determines the order of container startup on the node

Answer: A — The Events list at the bottom, which records scheduling and kubelet messages

A) Correct — events are the chronological record of what the scheduler and kubelet tried and why it failed, and they are the fastest route from symptom to cause. C) is a genuine section but it lists the pod's own tolerations, not the node's taints, so it cannot by itself explain a failure. B) helps identify ownership, useful context but not causal evidence. D) misstates QoS class, which influences eviction priority, not startup order.

Pod fails: 'CreateContainerConfigError'. Common cause?

1. The claim the pod mounts has not been bound to any volume
2. The liveness probe failed before the container was ready
3. The registry rejected the pull request for the image
4. A referenced ConfigMap or Secret key does not exist

Answer: D — A referenced ConfigMap or Secret key does not exist

D is right: the kubelet raises this when it cannot assemble the container configuration, typically because envFrom, configMapKeyRef or secretKeyRef points at an object or key that is missing. A surfaces as FailedMount, C as ImagePullBackOff, and B needs a container that already started, so each names a different failure mode.

A pod is Pending and its events show `0/6 nodes are available: 4 Insufficient cpu, 2 node(s) had untolerated taint`. What does this output mean?

1. The scheduler evaluated every node and none satisfied the pod's requirements
2. Six nodes are NotReady, so the scheduler deferred the decision until they recover
3. The pod exceeded a ResourceQuota, and the namespace must be expanded first
4. The image could not be pulled on four nodes and is blocked by taints on two

Answer: A — The scheduler evaluated every node and none satisfied the pod's requirements

A) Correct — the message is the scheduler's per-node tally of filter failures: four rejected on CPU requests, two on taints, so the pod stays Pending until requests shrink, a toleration is added, or capacity appears. B) misreads the count, which is nodes considered, not nodes unhealthy. C) would be rejected at admission with a quota error and the pod would not exist to be scheduled. D) imports an image-pull problem, which happens only after binding and produces ImagePullBackOff, not FailedScheduling.

Quick way to dump all problematic pods cluster-wide?

1. kubectl get pods -A --field-selector=status.phase!=Running
2. kubectl get errors -A, which lists failing objects by kind
3. kubectl describe all -A and read the events at the bottom
4. kubectl logs all -A, which streams every container's output

Answer: A — kubectl get pods -A --field-selector=status.phase!=Running

A is right: field selectors filter on built-in fields, so excluding Running and Succeeded across all namespaces surfaces the unhealthy pods, though CrashLoopBackOff pods still report Running, so check restartCount too. B and D name resources kubectl does not have. C floods the terminal without filtering.

Which command lists cluster events in time order?

1. kubectl history events, which replays the audit log of every API request made to the cluster
2. kubectl get events --sort-by=.lastTimestamp, optionally with -A and --watch for live output
3. kubectl describe node <node>, which shows conditions and events for that one object only
4. kubectl trace cluster, which streams scheduling and image-pull decisions as they happen
5. journalctl -u kubelet on a node, which shows node-local logs rather than API-level events

Answer: B — kubectl get events --sort-by=.lastTimestamp, optionally with -A and --watch for live output

B is the answer: events are API objects, so kubectl get events with --sort-by=.lastTimestamp orders them, -A crosses namespaces and --watch tails them; kubectl events is the newer equivalent. They expire after about an hour by default, so read them early. A and D are not kubectl subcommands. C tempts and is genuinely useful, but it is scoped to a single object. E is the right tool for kubelet failures, not for cluster events.

A pod shows ImagePullBackOff and its events include `pull access denied ... may require authorization` for a private registry. What is the MOST appropriate fix?

1. Set imagePullPolicy to IfNotPresent so the kubelet uses a cached copy instead
2. Label the node with the registry hostname so the kubelet routes the pull correctly
3. Create a docker-registry Secret and reference it in the pod's imagePullSecrets
4. Grant the pod's ServiceAccount a Role that permits the get verb on images

Answer: C — Create a docker-registry Secret and reference it in the pod's imagePullSecrets

C) Correct — registry authentication is carried by a kubernetes.io/dockerconfigjson Secret referenced through imagePullSecrets, optionally attached to the ServiceAccount so every pod inherits it. D) is the tempting conflation of Kubernetes RBAC with registry credentials; images are not API resources. A) only helps if the image is already on the node and silently masks the problem elsewhere. B) invents a node-labelling mechanism the kubelet does not use for pulls.

You need a shell to debug a running application pod built from a distroless image with no shell binary. Which approach is MOST appropriate?

1. `kubectl exec -it <pod> -- /bin/sh`, which the kubelet injects
2. `kubectl cp` a static busybox binary into the container, then exec into it
3. `kubectl port-forward` to the pod and attach a remote debugger over the tunnel
4. `kubectl debug -it <pod> --image=busybox --target=<container>`

Answer: D — `kubectl debug -it <pod> --image=busybox --target=<container>`

D) Correct — an ephemeral debug container joins the running pod's namespaces and, with --target, shares the process namespace of the named container, giving you tooling the image lacks without rebuilding or restarting it. A) fails outright because exec can only run binaries that exist in the image; the kubelet injects nothing. B) requires a working exec path (tar) inside the container, which distroless images also lack. C) reaches a network port but provides no shell or filesystem access.

An ephemeral debug container is added with:

1. kubectl exec --debug <pod>, reusing the already running container
2. crictl exec on the node, attaching it to the same namespaces
3. kubectl run --target=<pod>, which co-schedules a second pod
4. kubectl debug -it <pod> --image=busybox --target=<container>

Answer: D — kubectl debug -it <pod> --image=busybox --target=<container>

D is right: kubectl debug uses the ephemeral containers API to inject a container with your chosen image into a running pod, and --target shares the process namespace of a named container. A is not a flag exec accepts. B works on the node but cannot add a new container to the pod. C invents a flag for run.

After a NetworkPolicy is applied selecting the `api` pods for ingress, all traffic to those pods stops, including from previously allowed clients. Which explanation is MOST accurate?

1. NetworkPolicies apply namespace-wide whatever the podSelector
2. NetworkPolicy objects always deny egress as well once any policy is created
3. The CNI plugin must be restarted before a policy's allow rules become active
4. Once selected by an ingress policy, only its rules are permitted

Answer: D — Once selected by an ingress policy, only its rules are permitted

D) Correct — selection flips the pod from default-allow to default-deny for that direction, so any client not matched by an explicit ingress rule is dropped; the fix is to add the missing from selectors. A) overstates scope: the podSelector genuinely narrows which pods are affected, and an empty selector is what makes it namespace-wide. B) wrongly couples the directions — egress is unaffected unless a policy lists it in policyTypes. C) invents an activation step; a conformant CNI enforces policies as they are created.

An application logs `Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:app:worker" cannot list resource "pods" in API group "" in the namespace "app"`. Which command BEST verifies a proposed fix?

1. `kubectl auth can-i list pods -n app --as system:serviceaccount:app:worker`
2. `kubectl describe serviceaccount worker -n app` to view its effective permissions
3. `kubectl get rolebindings -n app` and confirm one references the app namespace
4. `kubectl auth can-i --list` as yourself to compare against the failing identity

Answer: A — `kubectl auth can-i list pods -n app --as system:serviceaccount:app:worker`

A) Correct — impersonating the exact ServiceAccount with the exact verb, resource and namespace asks the authorizer the same question the application asked, so a yes is direct proof. B) is a common misreading: describing a ServiceAccount shows tokens and secrets, never the roles bound to it. C) confirms a binding exists but not that its rules cover this verb and resource. D) evaluates your own admin identity, which will succeed regardless and prove nothing.

kubectl get pods?

List pods in current namespace. -n <ns> for specific, --all-namespaces for all.

What does a pod in Pending, ImagePullBackOff, CrashLoopBackOff or Terminating tell you?

Pending: not scheduled — no matching node, insufficient resources, taints, or an unbound PVC • ImagePullBackOff: the image name, tag or registry credentials are wrong • CrashLoopBackOff: the container starts and exits repeatedly, so read the previous logs • Terminating stuck: a finalizer or an unresponsive preStop hook or graceful shutdown.