Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. In EKS, who operates etcd and the API servers?

   1. AYou
   2. BAWS: the control plane is managed and runs across multiple availability zones
   3. CKarpenter
   4. DThe VPC CNI
   Show answer

   B. AWS runs, scales, patches and backs up the control plane. You own the data plane, add-ons, workloads, IAM and networking design.

   From lesson 01 · EKS architecture & mental model

2. Q2. What happens if you stay on a Kubernetes version after its standard support ends?

   1. AThe cluster is deleted
   2. BIt moves to extended support (at extra cost), and eventually gets upgraded automatically when that ends
   3. CNothing ever
   4. DNodes stop working immediately
   Show answer

   B. EKS versions have standard support, then paid extended support. Planning regular upgrades avoids both cost and forced upgrades.

   From lesson 01 · EKS architecture & mental model

3. Q3. Which data-plane option launches right-sized EC2 nodes directly for pending pods, without predefined node groups?

   1. AManaged node groups
   2. BKarpenter
   3. CFargate
   4. DSelf-managed ASGs
   Show answer

   B. Karpenter reads pending pods' requirements and provisions matching instances, then consolidates. Node groups scale predefined ASGs.

   From lesson 01 · EKS architecture & mental model

4. Q4. Why keep Terraform state in S3 rather than on a laptop?

   1. AIt's faster
   2. BShared, durable, versioned and encrypted state that the whole team and CI use, with locking to prevent concurrent applies
   3. CLaptops can't run Terraform
   4. DS3 is free
   Show answer

   B. Local state can't be shared safely and is easily lost. Remote state with locking is the basis of team workflows.

   From lesson 02 · Remote state: S3, locking, env-per-tfvars

5. Q5. What does state locking prevent?

   1. AReading state
   2. BTwo applies modifying the same state at the same time and corrupting it or racing on resources
   3. CPlans
   4. DEncryption
   Show answer

   B. The lock (an S3 lock file in newer Terraform, or a DynamoDB item in older setups) makes the second run wait or fail.

   From lesson 02 · Remote state: S3, locking, env-per-tfvars

6. Q6. What does exit code 2 from 'terraform plan -detailed-exitcode' mean?

   1. AAn error
   2. BThe plan succeeded and there are changes: something differs from the code (drift or pending changes)
   3. CNo changes
   4. DLocking failed
   Show answer

   B. Nightly jobs use it to detect drift: 0 means in sync, 2 means something changed outside (or inside) Terraform.

   From lesson 02 · Remote state: S3, locking, env-per-tfvars

7. Q7. Why can a single Terraform stack that creates EKS and installs Helm charts fail on the first plan?

   1. AHelm is incompatible
   2. BThe Kubernetes/Helm providers need the cluster endpoint and credentials, which don't exist until the cluster is created
   3. CTerraform can't use two providers
   4. DEKS blocks Helm
   Show answer

   B. Providers are configured before resources are applied. If their configuration depends on resources not yet created, planning can fail or behave unpredictably.

   From lesson 03 · The multi-provider chicken-and-egg

8. Q8. Why prefer an exec block ('aws eks get-token') over a token from the aws_eks_cluster_auth data source?

   1. AIt's shorter
   2. BThe data source's token is fetched once at plan time and expires after about 15 minutes, breaking long applies; exec fetches a fresh token when needed
   3. Cexec is required by EKS
   4. DData sources are deprecated
   Show answer

   B. Long applies (node groups, Helm charts with waits) can outlive a pre-fetched token. Exec authentication avoids that.

   From lesson 03 · The multi-provider chicken-and-egg

9. Q9. What's the most robust structure for cluster + platform components?

   1. AOne huge stack
   2. BSeparate stacks: the cluster layer first, then a platform layer that reads the cluster's outputs via remote state
   3. COnly Helm, no Terraform
   4. DOnly kubectl
   Show answer

   B. Layering removes the dependency at plan time, reduces blast radius, and lets the layers change at different speeds.

   From lesson 03 · The multi-provider chicken-and-egg

10. Q10. Pods are Pending with 'failed to assign an IP address to container', but nodes have spare CPU. Likely cause?

    1. ADNS
    2. BIP exhaustion: the node's ENI/IP limit or the subnet's free addresses have run out
    3. CRBAC
    4. DImage pulls
    Show answer

    B. With the VPC CNI every pod needs a VPC IP. Either the instance's ENI capacity or the subnet itself is exhausted.

    From lesson 04 · VPC CNI & IP planning

11. Q11. What does prefix delegation change?

    1. APods get IPv6
    2. BEach ENI slot holds a /28 prefix (16 addresses) instead of one IP, greatly increasing pods per node
    3. CPods share the node IP
    4. DIt disables security groups
    Show answer

    B. Nitro instances can attach prefixes to ENIs. Many more pods fit per node, but subnets need free, contiguous /28 blocks.

    From lesson 04 · VPC CNI & IP planning

12. Q12. Why put pods in a secondary CIDR such as 100.64.0.0/16?

    1. AIt's faster
    2. BTo give pods lots of address space without consuming the scarce, routable corporate ranges used by nodes and other systems
    3. CIt's required by EKS
    4. DTo make pods public
    Show answer

    B. The 100.64.0.0/10 range (reserved for carrier-grade NAT) is commonly used for pod subnets; pods reach other networks through the nodes' addresses.

    From lesson 04 · VPC CNI & IP planning