Amazon EKS — Terraform EKS Practice Questions
Test your Terraform EKS knowledge.
Question 1
What is the recommended Terraform backend for team-based EKS infrastructure management?
A) Local file backend
B) S3 bucket with DynamoDB locking
C) Git repository
D) Environment variables
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Local backends don’t support team collaboration and can’t be shared |
| B | ✅ S3 stores state remotely with versioning, and DynamoDB provides state locking to prevent concurrent modifications |
| C | Git is for code, not state files — state contains sensitive data and changes on every apply |
| D | Environment variables are for configuration, not state storage |
Question 2
Which subnet tag is required for the AWS Load Balancer Controller to auto-discover subnets for internet-facing ALBs?
A) kubernetes.io/role/internal-elb = 1
B) kubernetes.io/role/elb = 1
C) aws:eks:cluster-name = my-cluster
D) Name = public-subnet
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | internal-elb is for private/internal load balancers, not internet-facing ones |
| B | ✅ kubernetes.io/role/elb = 1 on public subnets tells the controller to use these subnets for internet-facing ALBs/NLBs |
| C | There’s no such standard tag — the cluster tag format is kubernetes.io/cluster/<name> |
| D | The Name tag is cosmetic and not used for auto-discovery |
Question 3
Why should you add lifecycle { ignore_changes = [scaling_config[0].desired_size] } to the node group resource?
A) To prevent Terraform from changing the instance type
B) To prevent Terraform from reverting changes made by Cluster Autoscaler or Karpenter
C) To disable automatic node updates
D) To prevent node group deletion
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Instance type changes are managed by a different attribute, not desired_size |
| B | ✅ Autoscalers modify desired_size outside of Terraform. Without ignore_changes, the next terraform apply would revert the autoscaler’s changes |
| C | Node updates are controlled by update_config, not ignore_changes |
| D | ignore_changes only ignores specific attributes, not deletion prevention (use prevent_destroy for that) |
Question 4
What is the purpose of the OIDC provider in an EKS Terraform configuration?
A) To enable SSH access to nodes
B) To enable IAM Roles for Service Accounts (IRSA)
C) To configure DNS for the cluster
D) To enable VPC peering
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | SSH access uses key pairs or SSM, not OIDC |
| B | ✅ The OIDC provider allows Kubernetes service accounts to assume IAM roles via sts:AssumeRoleWithWebIdentity, enabling fine-grained AWS permissions per pod |
| C | DNS is handled by CoreDNS and Route 53, not OIDC |
| D | VPC peering is a networking feature unrelated to OIDC |
Question 5
Which Terraform provider configuration uses the exec plugin for EKS authentication?
A) provider "aws" { exec { command = "kubectl" } }
B) provider "kubernetes" { exec { command = "aws" args = ["eks", "get-token", "--cluster-name", "my-cluster"] } }
C) provider "kubernetes" { token = "static-token" }
D) provider "kubernetes" { config_path = "~/.kube/config" }
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | The AWS provider doesn’t have an exec block — it uses standard AWS credentials |
| B | ✅ The Kubernetes provider uses aws eks get-token to dynamically generate short-lived authentication tokens for the EKS API server |
| C | Static tokens are insecure and not recommended for EKS |
| D | Using kubeconfig works but is less portable — the exec approach doesn’t require a pre-existing kubeconfig |
Question 6
What happens if you run terraform destroy on an EKS cluster that has manually created ALBs from Kubernetes Ingress resources?
A) Terraform cleanly destroys everything
B) Terraform may hang or fail because it can’t delete the VPC subnets that the ALBs still depend on
C) The ALBs are automatically deleted
D) Terraform skips the VPC deletion
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Terraform only manages resources it created — Kubernetes-created ALBs are not in Terraform state |
| B | ✅ ALBs create ENIs and security group rules in VPC subnets. Terraform can’t delete the VPC/subnets while these dependencies exist, causing hangs or errors |
| C | Terraform doesn’t know about these ALBs — they must be deleted via kubectl or the AWS console first |
| D | Terraform will attempt deletion and fail, it won’t automatically skip |
Question 7
In a modular Terraform project, how should the Kubernetes provider get the cluster endpoint?
A) Hard-code the endpoint URL
B) Use module.eks.cluster_endpoint output
C) Run aws eks describe-cluster manually
D) Use a local variable with a guessed value
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Hard-coding makes the configuration brittle and non-reusable |
| B | ✅ Module outputs pass the cluster endpoint dynamically, ensuring the provider always points to the correct cluster |
| C | Manual steps break automation — Terraform should be self-contained |
| D | Guessing values is unreliable and defeats the purpose of IaC |
Question 8
Which IAM policies are required for EKS managed node group instances to join the cluster?
A) AmazonEKSClusterPolicy only
B) AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, AmazonEC2ContainerRegistryReadOnly
C) AdministratorAccess
D) AmazonS3FullAccess
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | AmazonEKSClusterPolicy is for the cluster IAM role, not node roles |
| B | ✅ Nodes need: WorkerNodePolicy (kubelet API calls), CNI_Policy (VPC networking), ContainerRegistryReadOnly (pulling images from ECR) |
| C | AdministratorAccess is overly permissive and violates least privilege |
| D | S3 access is unrelated to node registration |
Question 9
What is the purpose of resolve_conflicts_on_update = "OVERWRITE" in an EKS add-on resource?
A) It deletes the add-on and recreates it
B) It overwrites any manual changes made to the add-on configuration during updates
C) It prevents any updates to the add-on
D) It creates a backup before updating
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | OVERWRITE updates in place, it doesn’t delete and recreate |
| B | ✅ If someone manually edited the add-on (e.g., via kubectl), OVERWRITE ensures Terraform’s desired state takes precedence during updates |
| C | That would be achieved by not updating the resource at all |
| D | EKS add-ons don’t have a built-in backup mechanism via this setting |
Question 10
For a production EKS environment, how many NAT Gateways should you deploy?
A) Zero — use public subnets for everything
B) One per VPC for cost savings
C) One per Availability Zone for high availability
D) One per node
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Nodes in public subnets is a security anti-pattern — production workloads belong in private subnets |
| B | A single NAT Gateway creates a single point of failure and cross-AZ data charges |
| C | ✅ One NAT Gateway per AZ ensures high availability — if one AZ goes down, other AZs still have outbound connectivity |
| D | One per node is impractical and unnecessary — NAT Gateways serve entire subnets |
