Amazon EKS — Troubleshooting Practice Questions
Test your EKS troubleshooting knowledge with these scenario-based questions.
Question 1
A developer reports “You must be logged in to the server (Unauthorized)” when running kubectl get pods. You run aws sts get-caller-identity and confirm the IAM user is correct. What is the most likely cause?
A) The EKS cluster is down
B) The IAM user is not mapped in access entries or aws-auth ConfigMap
C) kubectl is not installed
D) The pod doesn’t exist
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | If the cluster were down, the error would be “Unable to connect to the server”, not “Unauthorized” |
| B | ✅ “Unauthorized” means AWS STS authentication succeeded but the identity has no Kubernetes RBAC mapping. It must be added to access entries or aws-auth |
| C | If kubectl weren’t installed, you’d see a command not found error, not an Unauthorized error |
| D | The Unauthorized error occurs before any resource lookup — it’s an authentication/authorization failure |
Question 2
A pod is stuck in ImagePullBackOff with the error “no basic auth credentials”. The image is in ECR in the same account. What should you check?
A) The pod’s CPU requests
B) The node IAM role has ecr:GetAuthorizationToken and ecr:BatchGetImage permissions
C) The pod’s liveness probe
D) The CoreDNS logs
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | CPU requests affect scheduling (Pending), not image pulling |
| B | ✅ ECR requires the node IAM role to have ECR permissions. “No basic auth credentials” means the node can’t authenticate to ECR |
| C | Liveness probes affect running pods, not image pulls |
| D | DNS issues would show a different error (timeout or name resolution failure) |
Question 3
A pod keeps restarting with exit code 137. What does this indicate?
A) The application has a syntax error
B) The container was OOMKilled — it exceeded its memory limit
C) The container image is corrupt
D) The liveness probe timeout is too short
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Syntax errors typically produce exit code 1 or 2 |
| B | ✅ Exit code 137 = 128 + 9 (SIGKILL). In Kubernetes, this almost always means OOMKilled. Increase the memory limit |
| C | A corrupt image would cause ImagePullBackOff, not a runtime exit code |
| D | Liveness probe failures result in SIGTERM (exit code 143), not SIGKILL (137) |
Question 4
You see pods stuck in Pending with the event: 0/3 nodes are available: 3 node(s) had untolerated taint {dedicated: gpu}. What should you do?
A) Delete the nodes
B) Add a toleration matching the taint to the pod spec
C) Increase the pod memory request
D) Restart CoreDNS
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Deleting nodes removes capacity and doesn’t resolve the taint issue |
| B | ✅ The error says nodes have a taint the pod doesn’t tolerate. Add tolerations: [{key: dedicated, value: gpu, effect: NoSchedule}] to the pod spec, or schedule on nodes without that taint |
| C | Memory requests are unrelated to taint/toleration scheduling |
| D | CoreDNS has nothing to do with pod scheduling |
Question 5
An ALB Ingress resource is created but the ADDRESS field is empty. What should you check first?
A) The pod’s readiness probe
B) Whether the AWS Load Balancer Controller is installed and running
C) The node instance type
D) The cluster Kubernetes version
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Readiness probes affect target health, not ALB creation |
| B | ✅ An empty ADDRESS means the Ingress controller hasn’t created the ALB. The AWS Load Balancer Controller must be installed, running, and have proper IAM permissions |
| C | Instance type doesn’t affect ALB creation |
| D | The Kubernetes version is unlikely to prevent ALB creation unless very old |
Question 6
Pods are stuck in ContainerCreating with the event: failed to assign an IP address to container. What is the most likely cause?
A) CoreDNS is not running
B) The VPC subnet has run out of available IP addresses
C) The container image is too large
D) The node has too many CPUs
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | CoreDNS failures cause DNS resolution issues, not IP assignment failures |
| B | ✅ The VPC CNI assigns IPs from VPC subnets. When subnets have no free IPs, pods can’t get an IP address. Enable prefix delegation or add secondary CIDR blocks |
| C | Image size affects download time, not IP assignment |
| D | CPU count is unrelated to IP address assignment |
Question 7
A node appears in kubectl get nodes with status NotReady. Which command helps you identify the root cause on the node itself?
A) kubectl logs <node-name>
B) aws ssm start-session --target <instance-id> then journalctl -u kubelet
C) kubectl delete node <node-name>
D) helm list
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | kubectl logs is for pods, not nodes |
| B | ✅ SSM Session Manager lets you access the node, and journalctl -u kubelet shows kubelet logs which explain why the node is NotReady |
| C | Deleting the node object doesn’t fix the underlying issue |
| D | helm list shows Helm releases, unrelated to node health |
Question 8
A Service has ENDPOINTS: <none> when you run kubectl get endpoints <service-name>. What is the most likely cause?
A) The Service port is wrong
B) The Service selector doesn’t match any pod labels
C) The cluster doesn’t have enough nodes
D) The VPC has no internet gateway
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | A wrong port would still show endpoints (just the wrong port). Empty endpoints means no pods matched |
| B | ✅ ENDPOINTS: <none> means the Service selector matched zero pods. Verify that the selector labels exactly match the pod labels |
| C | Node count doesn’t affect Service endpoint resolution |
| D | Internet gateway is for external traffic, not Service endpoint discovery |
Question 9
You’re debugging a pod in CrashLoopBackOff but kubectl logs <pod> shows nothing. What command should you try next?
A) kubectl logs <pod> --previous
B) kubectl get all
C) kubectl scale deployment --replicas=0
D) kubectl apply -f deployment.yaml
Show Answer
Correct Answer: A
| Option | Explanation |
|---|---|
| A | ✅ --previous shows logs from the last container instance before the crash. The current instance may crash before writing logs, so the previous instance’s logs are essential |
| B | get all lists resources but doesn’t show crash details |
| C | Scaling to 0 stops the pod but doesn’t help diagnose the crash |
| D | Re-applying the same config won’t change anything |
Question 10
A newly created EKS node group shows instances running in EC2 but no nodes appear in kubectl get nodes. What should you check?
A) Whether the nodes’ IAM role has AmazonEKSWorkerNodePolicy attached
B) Whether the pod has enough memory
C) Whether CoreDNS is running
D) Whether Horizontal Pod Autoscaler is configured
Show Answer
Correct Answer: A
| Option | Explanation |
|---|---|
| A | ✅ Nodes need the AmazonEKSWorkerNodePolicy to register with the EKS API server. Without it, the kubelet can’t authenticate and the node never joins the cluster |
| B | Pod memory is unrelated to node registration |
| C | CoreDNS runs on nodes that have already joined — it can’t prevent node registration |
| D | HPA scales pods, not nodes, and is unrelated to node joining |
