Cheat sheet & self-check

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

1. Q1. Why apply the stack layer by layer with verification gates?

   1. ATerraform requires it
   2. BEach layer depends on the previous one; checking it works before continuing keeps failures small, easy to diagnose and easy to roll back
   3. CIt's faster
   4. DTo use fewer states
   Show answer

   B. A broken VPC discovered after the platform layer is installed is much harder to untangle.

   From lesson 13 · Playbook: creating the cluster

2. Q2. What must you check in the plan before applying the cluster layer for the first time?

   1. ANothing, it's new
   2. BThat it only creates the expected resources in the right account/region, with the right names, versions, subnets and access entries, and nothing unexpected (like replacements in other states)
   3. COnly the cost
   4. DOnly the node count
   Show answer

   B. Plan review is the cheapest place to catch mistakes.

   From lesson 13 · Playbook: creating the cluster

3. Q3. The platform layer fails halfway (a Helm release times out). What's the safe response?

   1. ADestroy everything
   2. BStop, read the failure (events, pod logs), fix the cause, and re-run plan/apply for that layer; lower layers are unaffected
   3. CApply the next layer anyway
   4. DEdit resources by hand
   Show answer

   B. Layered states make a failed layer re-runnable without touching the others.

   From lesson 13 · Playbook: creating the cluster

4. Q4. What's the correct order for a Kubernetes minor upgrade on this stack?

   1. ANodes first, then control plane
   2. BPre-checks (deprecated APIs, add-on compatibility) → control plane → managed add-ons → nodes (node groups/Karpenter) → verify
   3. CAdd-ons first
   4. DAll at once
   Show answer

   B. The control plane may be at most a limited number of versions ahead of nodes; never behind.

   From lesson 14 · Playbook: day-2 operations

5. Q5. Why delete LoadBalancer Services/Ingresses and Karpenter NodePools before `terraform destroy`?

   1. ATo save time
   2. BThose AWS resources (load balancers, instances, ENIs, security groups) were created by in-cluster controllers, not Terraform; if the cluster goes first they're orphaned and block VPC deletion
   3. CTerraform can't delete VPCs
   4. DKarpenter requires it for licensing
   Show answer

   B. Let the creators clean up their own resources first.

   From lesson 14 · Playbook: day-2 operations

6. Q6. How should a team get access to the cluster?

   1. AShare the admin role
   2. BAn access entry for the team's IAM role with a namespace-scoped access policy (or RBAC group), added through Terraform and reviewed
   3. CEdit aws-auth by hand
   4. DGive them node SSH
   Show answer

   B. Reviewed, auditable, least-privilege access through the EKS API.

   From lesson 14 · Playbook: day-2 operations

7. Q7. How does kubectl authenticate to EKS after `aws eks update-kubeconfig`?

   1. AWith a static password
   2. BThe kubeconfig runs an exec plugin (`aws eks get-token`) that turns your current AWS credentials into a short-lived token; EKS maps your IAM identity to permissions via access entries
   3. CWith the node's SSH key
   4. DWith a certificate you must renew yearly
   Show answer

   B. No long-lived secrets in the kubeconfig; access follows your IAM session.

   From lesson 15 · The flow: laptop → cluster → kubeconfig → app

8. Q8. In the CI/CD way of working, who writes to production?

   1. AEvery engineer with kubectl
   2. BPipelines (Terraform via OIDC roles, Argo CD from the GitOps repo); humans mostly read, with break-glass for emergencies
   3. CNobody
   4. DOnly the cluster creator
   Show answer

   B. Changes become reviewed, logged and repeatable.

   From lesson 15 · The flow: laptop → cluster → kubeconfig → app

9. Q9. Why push images by digest and deploy the digest?

   1. ADigests are shorter
   2. BThe digest identifies exact bytes; tags can move, so deploying digests makes releases and rollbacks exact
   3. CECR requires it
   4. DFor faster pulls
   Show answer

   B. See CI/CD & Software Supply Chain, lesson 05.

   From lesson 15 · The flow: laptop → cluster → kubeconfig → app

10. Q10. A plan shows the EKS cluster 'must be replaced'. What do you do?

    1. AApply; it will be fine
    2. BStop: find the attribute marked 'forces replacement' (e.g. a changed name or subnet setting), revert or plan a migration; protect the cluster with prevent_destroy
    3. CDelete the state
    4. DRun apply twice
    Show answer

    B. Replacing a cluster deletes it. Plans are where you catch this.

    From lesson 16 · Challenges on this stack

11. Q11. A pod is Pending with a volume node affinity conflict after rescheduling. Why?

    1. ANot enough CPU
    2. BEBS volumes live in one AZ; the pod was scheduled (or the only capacity is) in another AZ, so the volume can't attach
    3. CThe image is missing
    4. DRBAC
    Show answer

    B. Use WaitForFirstConsumer, keep capacity in every AZ used by volumes, or use EFS for shared/multi-AZ needs.

    From lesson 16 · Challenges on this stack

12. Q12. Karpenter logs say no instance types satisfy the requirements. What's a likely cause?

    1. AKarpenter is down
    2. BNodePool requirements (arch, instance families, capacity type, zones) plus pod constraints exclude every available type, or EC2NodeClass selectors find no subnets/security groups
    3. CThe API server is slow
    4. DToo many pods
    Show answer

    B. Read the NodeClaim events and Karpenter logs; widen requirements or fix selector tags.

    From lesson 16 · Challenges on this stack

13. Q13. When is `terraform force-unlock` safe?

    1. AAlways
    2. BOnly after confirming no plan/apply is still running with that lock (e.g. a crashed pipeline), because unlocking during a real apply can corrupt state
    3. CNever
    4. DOnly on Mondays
    Show answer

    B. Check the lock info (who, when, operation) and your pipelines first.

    From lesson 17 · Recovery playbook

14. Q14. The state file was overwritten by a bad apply. What's the recovery path with a versioned S3 bucket?

    1. ARecreate everything
    2. BBack up the current state, restore the previous S3 object version of the state file, then run plan and confirm it matches reality before re-enabling pipelines
    3. CDelete the bucket
    4. DEdit the JSON by hand first
    Show answer

    B. Versioning is the reason you enabled it in lesson 02. Verify with a plan afterwards.

    From lesson 17 · Recovery playbook

15. Q15. `terraform destroy` of the network layer hangs deleting a subnet. What's the usual cause?

    1. ATerraform bug
    2. BResources created outside Terraform still use the subnet: ENIs from load balancers, Karpenter instances or the VPC CNI; find and remove them (via their controllers where possible)
    3. CToo many tags
    4. DWrong region
    Show answer

    B. Always clean up controller-created resources before destroying lower layers.

    From lesson 17 · Recovery playbook

16. Q16. What can `terraform test` with a mock AWS provider verify?

    1. AThat EKS really works
    2. BYour module's logic: counts, naming, tags, conditionals, validation rules and outputs, by planning against fake provider responses without credentials
    3. CAWS quotas
    4. DNetwork performance
    Show answer

    B. It's unit testing for Terraform code, fast and free, not an integration test.

    From lesson 18 · Simulator: practise for $0

17. Q17. Which part of this course can't be simulated faithfully offline?

    1. AWriting tfvars
    2. BAWS-managed behaviour: the EKS control plane, managed node groups, Karpenter launching EC2, the AWS Load Balancer Controller creating ALBs, IAM/Pod Identity end to end
    3. Cterraform fmt
    4. DKustomize overlays
    Show answer

    B. Use a short, budgeted real session for these, and destroy afterwards.

    From lesson 18 · Simulator: practise for $0

18. Q18. Why rehearse the platform layer on kind?

    1. Akind is EKS
    2. BMost of the platform layer is plain Kubernetes (Helm releases, namespaces, Argo CD, manifests), so you can practise the workflow and debugging for free, substituting AWS-specific pieces
    3. Ckind has ALBs
    4. DTo test IAM
    Show answer

    B. Swap ALB for an ingress controller, EBS CSI for local-path, Karpenter for fixed nodes.

    From lesson 18 · Simulator: practise for $0