Amazon EKS — Production Checklist Practice Questions
Test your production readiness knowledge.
Question 1
Which EKS API server endpoint configuration is recommended for production?
A) Public access enabled, private access disabled
B) Public access disabled, private access enabled
C) Both enabled with publicAccessCidrs restricted to office/VPN IPs
D) Both disabled
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Public-only means access is internet-routable without VPC-level protection |
| B | Private-only is most secure but requires VPN/bastion for all access, which can complicate operations |
| C | ✅ Both enabled with CIDR restrictions provides secure access from corporate networks while allowing in-VPC communication. Best balance of security and operational flexibility |
| D | Both disabled is invalid — at least one endpoint must be accessible |
Question 2
A production namespace has no NetworkPolicy resources. What does this mean for pod network traffic?
A) All traffic is blocked by default
B) All traffic is allowed — pods can communicate freely across namespaces
C) Only DNS traffic is allowed
D) Traffic within the namespace is allowed, cross-namespace is blocked
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Default behavior is allow-all, not deny-all |
| B | ✅ Without any NetworkPolicy, Kubernetes allows all ingress and egress traffic. A default-deny policy must be explicitly created |
| C | DNS handling depends on NetworkPolicy configuration, not a default behavior |
| D | Kubernetes doesn’t have implicit namespace-level network isolation |
Question 3
Why should you set Pod Disruption Budgets (PDBs) on production deployments?
A) To increase pod CPU limits
B) To prevent voluntary disruptions from taking all pods offline simultaneously
C) To enable automatic scaling
D) To configure health checks
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | PDBs have nothing to do with resource limits |
| B | ✅ PDBs ensure that voluntary disruptions (node drain, cluster upgrades) cannot evict more pods than allowed, maintaining application availability |
| C | Scaling is managed by HPA/VPA/Cluster Autoscaler, not PDBs |
| D | Health checks are configured via probes, not PDBs |
Question 4
Which combination of health probes should a production pod have?
A) Liveness probe only
B) Readiness probe only
C) Liveness probe + readiness probe (+ startup probe for slow-starting apps)
D) No probes — Kubernetes handles it
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Liveness alone can restart pods but won’t remove them from Service endpoints during temporary issues |
| B | Readiness alone won’t restart deadlocked containers |
| C | ✅ Liveness detects and restarts stuck containers. Readiness controls traffic routing. Startup probes prevent premature kills for apps with long initialization |
| D | Without probes, Kubernetes has no visibility into application health |
Question 5
In a production EKS cluster, how many NAT Gateways should you deploy?
A) Zero
B) One
C) One per Availability Zone
D) One per node
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Nodes in private subnets need NAT for outbound internet access (pulling images, API calls) |
| B | A single NAT Gateway is a single point of failure — if that AZ goes down, all outbound traffic stops |
| C | ✅ One NAT Gateway per AZ ensures outbound traffic survives an AZ failure. Also avoids cross-AZ data transfer charges |
| D | NAT Gateways serve subnets, not individual nodes |
Question 6
What should you do before running terraform destroy on a production EKS cluster?
A) Run terraform apply first
B) Delete Kubernetes-created resources (ALBs, EBS volumes, Security Groups) first
C) Nothing — Terraform handles everything
D) Upgrade the cluster
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Applying before destroying doesn’t help with resource cleanup |
| B | ✅ Kubernetes-created resources (ALBs from Ingress, EBS from PVC, SGs from Services) are not in Terraform state. They create dependencies that prevent VPC/subnet deletion |
| C | Terraform only knows about resources in its state file — Kubernetes-created resources will block destruction |
| D | Upgrading before destroying is unnecessary |
Question 7
Which observability components should be deployed on a production EKS cluster?
A) Only CloudWatch Container Insights
B) Prometheus + Grafana + Fluent Bit + alerting
C) Only application logs
D) Only node metrics
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Container Insights provides basic metrics but lacks custom metrics, flexible alerting, and long-term storage |
| B | ✅ Full observability requires metrics (Prometheus + Grafana), logs (Fluent Bit to CloudWatch/OpenSearch), and alerting (PagerDuty/SNS). Custom dashboards and alerting rules are essential |
| C | Logs alone don’t show resource utilization or scaling trends |
| D | Node metrics alone miss pod-level and application-level issues |
Question 8
What is the purpose of topologySpreadConstraints in a production deployment?
A) To limit CPU usage
B) To spread pods across AZs for high availability
C) To enable autoscaling
D) To configure DNS
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | CPU is controlled by resource requests/limits, not topology constraints |
| B | ✅ topologySpreadConstraints ensures pods are distributed evenly across failure domains (AZs), so an AZ failure doesn’t take down all instances of a service |
| C | Autoscaling is managed by HPA/Karpenter/Cluster Autoscaler |
| D | DNS is managed by CoreDNS, not topology constraints |
Question 9
How often should you review IAM access to your EKS clusters?
A) Never
B) Only when there’s a security incident
C) Quarterly with documented access reviews
D) Daily
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Never reviewing access leads to accumulated stale permissions |
| B | Reactive-only reviews miss creeping privilege escalation |
| C | ✅ Quarterly reviews balance operational overhead with security hygiene. Document who has access, why, and remove stale entries |
| D | Daily reviews are excessive and impractical for most organizations |
Question 10
Which of the following is NOT a recommended practice for container images in production?
A) Enable ECR image scanning
B) Use tag immutability
C) Use the latest tag for convenience
D) Use specific version tags or image digests
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Image scanning detects vulnerabilities before deployment — recommended |
| B | Tag immutability prevents overwriting images, ensuring reproducibility — recommended |
| C | ✅ The latest tag is mutable and non-deterministic — the same tag can point to different images over time. This breaks reproducibility and makes rollbacks unreliable |
| D | Specific tags or digests ensure every deployment uses the exact intended image — recommended |
