Cheat sheet & self-check

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

1. Q1. Why use OIDC federation from CI instead of storing AWS access keys as secrets?

   1. AIt's faster
   2. BNo long-lived keys to leak; credentials are short-lived and the role trusts only specific repos, branches or environments
   3. CKeys don't work in CI
   4. DIt's free
   Show answer

   B. The CI provider issues a signed token per job; AWS exchanges it for temporary credentials if the trust conditions match.

   From lesson 08 · CI/CD for the stack

2. Q2. Why separate the plan role from the apply role?

   1. AFor speed
   2. BPull requests (including from less-trusted branches) only get read-only access; only the protected main-branch job can change infrastructure
   3. CAWS requires it
   4. DTo save money
   Show answer

   B. A malicious or buggy PR shouldn't be able to modify production just by running a plan job.

   From lesson 08 · CI/CD for the stack

3. Q3. What should apply use?

   1. AA fresh plan made at apply time
   2. BThe saved plan file that was reviewed, so what's applied is exactly what was approved
   3. Cterraform apply -auto-approve on every branch
   4. DThe console
   Show answer

   B. Applying a saved plan prevents surprises when something changed between review and apply.

   From lesson 08 · CI/CD for the stack

4. Q4. Why split an upgrade into several pull requests (control plane, add-ons, nodes)?

   1. AGit requires it
   2. BEach step is small, reviewable and verifiable before the next, and a failure has an obvious scope
   3. CIt's faster overall
   4. DTerraform can't do it in one apply
   Show answer

   B. One giant apply mixes concerns and makes a failure hard to reason about. Small steps with checks between them are safer and easier to roll forward.

   From lesson 09 · Upgrades with Terraform

5. Q5. The control-plane version bump shows 'must be replaced' in the plan. What do you do?

   1. AApply anyway
   2. BStop: something else in the change forces replacement (a renamed resource, a changed immutable attribute, a module major bump). Find it before continuing
   3. CRun terraform refresh
   4. DDestroy manually first
   Show answer

   B. A Kubernetes version bump is an in-place update. Replacement means an unrelated change slipped into the plan.

   From lesson 09 · Upgrades with Terraform

6. Q6. How do Karpenter-managed nodes pick up a new AMI after the upgrade?

   1. AThey never do
   2. BKarpenter detects drift from the EC2NodeClass AMI selection (e.g. an alias for the latest AL2023 AMI for the cluster version) and replaces nodes within disruption budgets
   3. CTerraform replaces them
   4. DOnly after a reboot
   Show answer

   B. Drift detection rolls Karpenter nodes automatically, respecting PDBs and NodePool disruption budgets.

   From lesson 09 · Upgrades with Terraform

7. Q7. You moved a node group resource into a module. How do you avoid Terraform destroying and recreating it?

   1. AApply and hope
   2. BAdd a moved block from the old address to the new one (or terraform state mv), then plan shows no destroy
   3. CDelete it from state
   4. DUse -target
   Show answer

   B. Addresses changed, not the resource. A moved block tells Terraform it's the same object, and it's reviewable in code.

   From lesson 10 · Drift, import, moved & safe destroy

8. Q8. Someone scaled a node group's max_size in the console. What does a scheduled drift check do?

   1. ANothing
   2. Bplan -detailed-exitcode returns 2; the job alerts, and the team either reverts the console change or codifies it
   3. CIt fixes it silently
   4. DIt destroys the node group
   Show answer

   B. Drift detection surfaces out-of-band changes so they're decided on deliberately instead of being overwritten or forgotten.

   From lesson 10 · Drift, import, moved & safe destroy

9. Q9. terraform destroy of the network layer fails with 'DependencyViolation' on a subnet. Most likely cause?

   1. AA Terraform bug
   2. BSomething created outside Terraform (an ALB from an Ingress, a Karpenter node, a leftover ENI) still lives in the subnet
   3. CWrong region
   4. DMissing tags
   Show answer

   B. In-cluster controllers create AWS resources Terraform doesn't track. Remove them before destroying the cluster and network layers.

   From lesson 10 · Drift, import, moved & safe destroy

10. Q10. 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 11 · Playbook: creating the cluster

11. Q11. 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 11 · Playbook: creating the cluster

12. Q12. 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 11 · Playbook: creating the cluster

13. Q13. 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 12 · Playbook: day-2 operations

14. Q14. 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 12 · Playbook: day-2 operations

15. Q15. 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 12 · Playbook: day-2 operations

16. Q16. 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 13 · Challenges on this stack

17. Q17. 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 13 · Challenges on this stack

18. Q18. 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 13 · Challenges on this stack

19. Q19. 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 14 · Recovery playbook

20. Q20. 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 14 · Recovery playbook

21. Q21. `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 14 · Recovery playbook

22. Q22. 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 15 · Simulator: practise for $0

23. Q23. 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 15 · Simulator: practise for $0

24. Q24. 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 15 · Simulator: practise for $0

25. Q25. What makes a platform 'hand-over ready'?

    1. AIt runs
    2. BAnother team can operate it from documentation: runbooks, SLOs, access model, upgrade and DR procedures, with evidence they work
    3. CIt uses the newest versions
    4. DIt has no alerts
    Show answer

    B. Operability is part of the deliverable. If only the builder can run it, it isn't finished.

    From lesson 16 · Capstone: the whole platform from an empty account