EKS Interview Questions

Summary

EKS is AWS's managed Kubernetes service. AWS runs and scales the control plane (API servers and etcd across multiple Availability Zones), patches it, and backs up etcd. You manage the worker capacity (unless you use Fargate or EKS Auto Mode), add-ons, networking design, IAM, workloads, upgrades of node versions, and everything running in the cluster.

Longer Answer

The control plane runs in an AWS-managed account and connects to your VPC through elastic network interfaces; the API endpoint can be public, private or both. You pay a per-cluster hourly fee (higher for versions in extended support) plus the compute, load balancers, storage and data transfer you use.

Shared responsibility shifts with the compute option: with self-managed nodes you own the OS and kubelet; with managed node groups AWS automates provisioning and updates you trigger; with Fargate or Auto Mode AWS manages more of the node lifecycle.

Key Points

• AWS manages the multi-AZ control plane and etcd.
• You manage nodes (unless Fargate/Auto Mode), add-ons, IAM, workloads.
• Per-cluster fee plus resources.
• Responsibility depends on compute option.

Summary

Managed node groups are EC2 Auto Scaling groups that EKS provisions and updates for you; self-managed nodes give full control of the AMI and bootstrap; Fargate runs each pod on its own AWS-managed micro-VM with no nodes to manage; Karpenter provisions right-sized EC2 instances directly from pending pods; EKS Auto Mode has AWS operate node provisioning (built on Karpenter), core add-ons and node security updates.

Longer Answer

• Managed node groups: good default; rolling updates of AMIs; limited instance flexibility per group.
• Self-managed: custom AMIs or special needs; most operational work.
• Fargate: no node management, per-pod isolation and billing; no DaemonSets, privileged pods, GPUs or EBS volumes (EFS works); slower pod start; often costlier at steady scale.
• Karpenter: fast scaling, many instance types, spot and consolidation; you operate Karpenter.
• Auto Mode: least node operations; AWS manages capacity, networking, storage and load-balancer components for you, for an extra management fee per instance.

Many clusters mix options: a small managed node group for system components and Karpenter for workloads, or Auto Mode for teams that want minimal operations.

Key Points

• Managed node groups: sensible default.
• Fargate: no nodes, with limitations.
• Karpenter: flexible, fast, cost-efficient.
• Auto Mode: AWS operates nodes and core add-ons.

Summary

The VPC CNI gives every pod a real IP address from the VPC subnet by attaching elastic network interfaces (ENIs) with secondary IPs to nodes. Pods are directly routable in the VPC, which is simple and fast, but each pod consumes a subnet IP, and each instance type supports a limited number of ENIs and IPs per ENI, which caps pods per node.

Longer Answer

IP exhaustion happens with small subnets, many small pods, or the CNI pre-allocating warm IPs. Mitigations:

• Size subnets generously (for example /19 or larger for node subnets) when creating the VPC.
• Prefix delegation: assign /28 prefixes to ENIs, greatly increasing pods per node and allocation speed.
• Custom networking with a secondary CIDR (for example from the 100.64.0.0/10 range) for pod IPs.
• Tune warm pool settings (WARM_IP_TARGET, MINIMUM_IP_TARGET).
• IPv6 clusters avoid IPv4 scarcity entirely.

Key Points

• Pods get VPC IPs via ENIs.
• Pods per node limited by ENIs/IPs.
• Prefix delegation, secondary CIDRs, IPv6.
• Plan subnet sizes early.

Summary

Both give a Kubernetes ServiceAccount an IAM role so pods get short-lived AWS credentials without static keys. IRSA (IAM Roles for Service Accounts) uses the cluster's OIDC provider and a trust policy per role referencing the cluster and ServiceAccount. EKS Pod Identity, the newer option, uses an EKS-managed agent and pod identity associations created through the EKS API, with a simpler trust policy that can be reused across clusters.

Longer Answer

Pod Identity advantages: no OIDC provider to set up per cluster, role trust policies that do not change per cluster, associations managed alongside the cluster, and session tags for attribute-based access control. IRSA remains necessary in some cases (for example self-managed Kubernetes on EC2, or pods on Fargate, which Pod Identity has not supported; check the current docs), and many existing setups use it.

Either way, avoid granting permissions to the node instance role, because every pod on the node could use them; restrict pod access to the instance metadata service (IMDSv2 with hop limit 1).

Key Points

• Both map ServiceAccounts to IAM roles.
• IRSA: OIDC provider + per-cluster trust.
• Pod Identity: EKS agent + associations, reusable trust.
• Never rely on the node role; restrict IMDS.

Summary

The AWS Load Balancer Controller watches Ingress (and Gateway API) resources to create Application Load Balancers, and Services of type LoadBalancer to create Network Load Balancers. With IP target mode, the load balancer sends traffic directly to pod IPs (possible because of the VPC CNI); instance mode routes through node ports.

Longer Answer

Practical points: IP mode avoids an extra hop and works with Fargate; use IngressGroups to share one ALB across many Ingresses (cost); terminate TLS with ACM certificates; add AWS WAF on the ALB for public apps; set the target group's deregistration delay and pod preStop hooks consistently for graceful shutdown; and use readiness gates so pods count as ready only once registered healthy in the target group.

The in-tree cloud provider can also create Classic or NLB load balancers, but the controller is the recommended, feature-rich option. EKS Auto Mode includes load-balancing management.

Key Points

• Ingress -> ALB; Service LoadBalancer -> NLB.
• IP target mode sends traffic to pods.
• Share ALBs with IngressGroups; ACM + WAF.
• Align deregistration delay, preStop and readiness gates.

Summary

Upgrade one Kubernetes minor version at a time: check for removed APIs and add-on compatibility (EKS upgrade insights help), upgrade the control plane, then the EKS add-ons (VPC CNI, CoreDNS, kube-proxy, EBS CSI), then the nodes (new AMIs for managed node groups, Karpenter drift replacement, or Auto Mode handling it). EKS offers about 14 months of standard support per version, then an optional 12 months of extended support at a higher cluster fee.

Longer Answer

Control-plane upgrades cannot be rolled back, so test in a lower environment first. Node upgrades replace instances, so workloads need multiple replicas, PodDisruptionBudgets and graceful shutdown. Some teams use blue/green clusters for major changes, shifting traffic between an old and new cluster instead of upgrading in place.

Running versions into extended support raises costs, and once extended support ends EKS upgrades the cluster automatically, so treat upgrades as a regular cadence (a few times a year).

Key Points

• One minor version at a time.
• Check removed APIs and add-ons first.
• Control plane, add-ons, nodes.
• Standard ~14 months, extended +12 at higher cost.

Summary

The Cluster Autoscaler scales existing node groups up and down; each group has fixed instance types, so you need many groups for variety. Karpenter watches unschedulable pods and launches instances that fit their combined requirements directly (choosing from many instance types, purchase options and zones), and continuously consolidates by replacing under-used nodes with cheaper or fewer ones.

Longer Answer

Karpenter concepts: NodePools (constraints such as instance families, capacity types, zones, taints, limits and disruption budgets) and EC2NodeClasses (AMI, subnets, security groups, IAM role). Benefits: faster scale-up, better bin-packing, easy spot usage with diversification, and automatic node replacement when AMIs drift.

Watch out for: disruption from consolidation (use PodDisruptionBudgets and do-not-disrupt annotations for sensitive pods), running Karpenter itself on stable capacity (a small managed node group or Fargate), and setting limits so a bug cannot launch unlimited instances.

Key Points

• CA scales node groups; Karpenter launches fitting instances.
• Consolidation lowers cost.
• NodePools and EC2NodeClasses.
• PDBs, limits, Karpenter on stable nodes.

Summary

Layer controls: IAM-based access with access entries and least-privilege RBAC; Pod Identity or IRSA for workloads (not node roles); private or restricted API endpoint; Pod Security Standards and a policy engine; NetworkPolicies (the VPC CNI supports them) or security groups for pods; encryption of secrets with KMS; image scanning and only trusted registries (ECR); audit logging; and GuardDuty EKS protection for threat detection.

Longer Answer

Node-level hardening: use EKS-optimized or Bottlerocket AMIs and keep them patched, require IMDSv2 with hop limit 1 so pods cannot steal node credentials, avoid SSH (use SSM), and run nodes in private subnets. Supply chain: scan images in ECR (enhanced scanning with Inspector), sign images, and enforce signatures at admission. Detect and respond: control-plane audit logs to CloudWatch, GuardDuty runtime monitoring, and alerts on privileged pod creation or unexpected RBAC changes.

Key Points

• IAM + RBAC least privilege.
• Workload identity; IMDSv2 hop limit 1.
• Pod security, NetworkPolicies, KMS secrets.
• Scanning, signing, audit logs, GuardDuty.

Summary

ECS is AWS's own container orchestrator: simpler, deeply integrated with AWS, no control-plane fee, and less to operate, especially with Fargate. EKS is standard Kubernetes: portable, with a huge ecosystem (Helm, operators, GitOps tools, service meshes), but more complex to run.

Longer Answer

Choose ECS when the team wants the simplest path to running containers on AWS, has no Kubernetes expertise, and does not need Kubernetes-specific tooling. Choose EKS when you need portability across clouds or on-premises, already have Kubernetes skills and tooling, rely on CNCF ecosystem components, or run complex platforms (many teams, custom controllers, GPU/ML scheduling). Cost differences come mostly from operations effort, not the EKS cluster fee.

Key Points

• ECS: simpler, AWS-native.
• EKS: portable, rich ecosystem, more complex.
• Team skills and ecosystem needs decide.
• Operational effort dominates cost.

Summary

Authentication uses IAM: kubectl sends a token derived from the caller's IAM identity. Authorisation inside Kubernetes then maps that identity to permissions. The old method mapped IAM roles to Kubernetes groups in the aws-auth ConfigMap; the newer access entries API manages these mappings through EKS itself, with optional AWS-managed access policies, and is the recommended approach.

Longer Answer

aws-auth was fragile: a typo could lock everyone out, it was edited with kubectl rather than IAM tooling, and the cluster creator had invisible admin rights. Access entries are managed through the EKS API (and IaC), can attach access policies such as AmazonEKSClusterAdminPolicy or namespace-scoped view/edit policies, and work alongside Kubernetes RBAC for fine-grained rules.

Best practices: grant access to IAM roles (assumed through SSO), not individual users; avoid permanent cluster-admin for people; use break-glass roles; and audit access with CloudTrail and the EKS audit logs.

Key Points

• IAM authentication, Kubernetes authorisation.
• aws-auth ConfigMap is legacy and fragile.
• Access entries via the EKS API.
• Roles via SSO; least privilege; audit.

Summary

Use at least two, preferably three, Availability Zones; put nodes and pods in private subnets with enough IP space for future growth (the VPC CNI uses VPC IPs for pods); use public subnets only for internet-facing load balancers and NAT gateways; tag subnets so the load balancer controller can discover them; and plan for egress costs and limits.

Longer Answer

Considerations: NAT gateway per AZ for resilience (and cost of data processing through NAT); VPC endpoints (ECR, S3, STS, CloudWatch) to keep image pulls and AWS API calls off NAT and cheaper; separate subnets or secondary CIDRs for pods if IPv4 is tight; security groups for the cluster and nodes; and private cluster endpoints or restricted public endpoint CIDRs. Changing a cluster's subnets later is constrained, so get the layout right early.

Key Points

• Multi-AZ private subnets with ample IPs.
• Public subnets for ALBs and NAT.
• VPC endpoints to cut NAT traffic.
• Plan early; changes are hard.

Summary

With infrastructure-as-code tools: Terraform or OpenTofu (commonly the community terraform-aws-modules/eks module), AWS CloudFormation or CDK, eksctl (a CLI that generates CloudFormation), or Crossplane and Cluster API from Kubernetes itself. Then install cluster add-ons and workloads with GitOps.

Longer Answer

A typical split: IaC creates the VPC, cluster, node pools or Karpenter prerequisites, IAM roles, access entries and EKS add-ons; a GitOps tool (Argo CD, Flux) bootstraps in-cluster components (ingress, cert-manager, external-secrets, monitoring) and applications. Keep cluster definitions modular so new environments are repeatable, and keep Kubernetes resources out of Terraform where possible to avoid two tools fighting over the same objects.

Key Points

• Terraform/OpenTofu, CDK/CloudFormation, eksctl.
• IaC for AWS resources; GitOps for in-cluster.
• Repeatable environments.
• Avoid managing in-cluster objects from two tools.

Deep dive: Terraform interview questions

Summary

Run nodes in several Availability Zones, run several replicas per service spread across zones (topology spread constraints), use PodDisruptionBudgets, health probes and graceful shutdown, put stateless traffic behind multi-AZ load balancers, and choose multi-AZ data stores (RDS Multi-AZ, Aurora, DynamoDB) rather than single-zone volumes.

Longer Answer

Check the weak spots: single-AZ NAT gateways, cluster add-ons with one replica (CoreDNS, ingress controllers, the load balancer controller), Karpenter or the autoscaler with no capacity in a zone, and EBS-backed StatefulSets pinned to one AZ. For regional failures, consider a second cluster in another Region with DNS failover, which is a much bigger investment.

Key Points

• Multi-AZ nodes and spread replicas.
• PDBs, probes, graceful shutdown.
• Multi-AZ data services.
• No single-AZ add-ons or NAT.

Deep dive: Kubernetes interview questions

Summary

Right-size pod requests, scale nodes with Karpenter (consolidation, many instance types), use Spot for tolerant workloads and Graviton (ARM) instances where images support them, buy Savings Plans for the steady baseline, cut NAT and cross-AZ data transfer (VPC endpoints, topology-aware routing), share load balancers, keep clusters on standard-support versions, and allocate costs per team.

Longer Answer

Hidden costs often surprise people: NAT gateway data processing for image pulls (use ECR VPC endpoints), cross-AZ traffic between chatty services, CloudWatch log ingestion, idle non-production clusters (scale them down at night), and many small clusters each paying the control-plane fee and add-on overhead. Split cost allocation data for EKS in AWS Cost and Usage Reports, or tools such as Kubecost/OpenCost, attribute spend to namespaces and teams.

Key Points

• Right-size requests; Karpenter consolidation.
• Spot, Graviton, Savings Plans.
• Cut NAT and cross-AZ transfer.
• Stay in standard support; allocate costs.

Summary

Treat clusters as replaceable: everything needed to rebuild them (IaC and GitOps repositories, container images in replicated ECR, secrets in Secrets Manager) must exist outside the cluster. Back up persistent data (database snapshots, EBS snapshots or Velero) to another Region, and practise rebuilding the cluster and restoring data within your RTO.

Longer Answer

For lower RTO, run a warm standby cluster in a second Region with GitOps keeping workloads in sync and data replicated (Aurora Global Database, DynamoDB global tables, S3 replication), then fail over with Route 53 health checks. The hard part is data, not Kubernetes objects; decide RPO per data store.

Key Points

• Rebuild from IaC + GitOps.
• Replicate images, secrets, data.
• Back up volumes and databases cross-Region.
• Warm standby for low RTO; test regularly.