Cheat sheet & self-check

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

1. Q1. What does 'declarative' mean in Terraform?

   1. AYou write the exact API calls in order
   2. BYou describe the desired end state; Terraform works out what to create, change or delete
   3. CIt runs in the cloud
   4. DIt only reads resources
   Show answer

   B. You write 'there should be a bucket named X'. Terraform compares that with reality (via state) and plans the steps.

   From lesson 01 · IaC principles & Terraform basics

2. Q2. What does terraform plan do?

   1. ACreates resources
   2. BCompares configuration, state and reality, and shows the changes apply would make, without making them
   3. CDeletes the state
   4. DFormats code
   Show answer

   B. Plan is the safety step: read it every time, especially lines that destroy or replace resources.

   From lesson 01 · IaC principles & Terraform basics

3. Q3. Why commit .terraform.lock.hcl to Git?

   1. AIt holds secrets
   2. BIt pins exact provider versions and checksums, so everyone and CI use the same provider builds
   3. CIt's the state file
   4. DTerraform requires it to be ignored
   Show answer

   B. The dependency lock file makes runs reproducible. Upgrade providers deliberately with 'terraform init -upgrade'.

   From lesson 01 · IaC principles & Terraform basics

4. Q4. You rename resource aws_s3_bucket.old to aws_s3_bucket.logs in code. Without anything else, what does plan propose?

   1. ANothing
   2. BDestroy the old bucket and create a new one
   3. CRename in AWS
   4. DAn error
   Show answer

   B. Terraform sees one address disappear and a new one appear. A moved block tells it they're the same object.

   From lesson 02 · State management

5. Q5. Why are import blocks better than running 'terraform import' by hand?

   1. AThey're faster
   2. BThey live in code: reviewed in a PR, visible in plan, repeatable across environments
   3. CThe CLI command was removed
   4. DThey don't need state
   Show answer

   B. Code-based import goes through the normal plan/review/apply workflow instead of a one-off command on someone's laptop.

   From lesson 02 · State management

6. Q6. Does marking an output 'sensitive' keep the value out of state?

   1. AYes
   2. BNo: it only hides it from CLI output; state still contains it, so protect state access
   3. COnly for passwords
   4. DOnly in remote backends
   Show answer

   B. State is plain JSON with every attribute. Encrypt it and restrict who can read it.

   From lesson 02 · State management

7. Q7. What does a validation block on a variable do?

   1. AEncrypts it
   2. BRejects invalid values at plan time with a clear error message
   3. CSets a default
   4. DHides it from output
   Show answer

   B. Catching 'environment must be dev, staging or prod' at plan time beats discovering it halfway through an apply.

   From lesson 03 · Variables, outputs & data sources

8. Q8. What's the difference between a resource and a data source?

   1. ANone
   2. BA resource is managed (created/changed/deleted) by this configuration; a data source only reads something that already exists
   3. CData sources are faster
   4. DResources can't have outputs
   Show answer

   B. Use data sources to look up AMIs, VPCs or zones managed elsewhere, without taking ownership.

   From lesson 03 · Variables, outputs & data sources

9. Q9. Why prefer for_each over count for a list of named things?

   1. AIt's faster
   2. Bfor_each keys resources by name, so removing one item doesn't shift the others' addresses and cause replacements
   3. Ccount is deprecated
   4. Dfor_each works without state
   Show answer

   B. With count, removing the first element renumbers everything after it. for_each addresses stay stable.

   From lesson 03 · Variables, outputs & data sources

10. Q10. Why pin module versions (ref=v1.4.0 or version constraints)?

    1. AIt's faster
    2. BSo a change in the module can't silently change every environment on the next plan; upgrades become deliberate
    3. CTerraform requires it
    4. DTo save disk space
    Show answer

    B. Unpinned modules follow the latest code. Pinning lets each environment adopt new versions through a reviewed change.

    From lesson 04 · Modules

11. Q11. What's a sign a module is too generic?

    1. AIt has a README
    2. BIt exposes nearly every argument of the underlying resources as variables, adding indirection without decisions
    3. CIt has outputs
    4. DIt's versioned
    Show answer

    B. Good modules encode opinions (secure defaults, naming, tagging). Thin wrappers over every argument add complexity without value.

    From lesson 04 · Modules

12. Q12. Where should provider configuration usually live?

    1. AInside every child module
    2. BIn the root module; child modules declare required providers and inherit (or receive) configured providers
    3. CIn variables
    4. DIn outputs
    Show answer

    B. Configuring providers inside reusable modules makes them hard to use with multiple regions/accounts and breaks features like count/for_each on modules.

    From lesson 04 · Modules

13. Q13. Why are provisioners considered a last resort?

    1. AThey're slow
    2. BTerraform can't know what they changed, can't plan or detect drift for it, and failures leave resources half-configured
    3. CThey're deprecated entirely
    4. DThey only work on AWS
    Show answer

    B. Provisioners run arbitrary commands outside Terraform's model. Prefer declarative mechanisms (images, cloud-init, dedicated providers).

    From lesson 05 · Provisioners & bootstrap

14. Q14. What is cloud-init?

    1. AA cloud provider
    2. BThe standard first-boot agent in cloud and VM images that applies user data: users, packages, files, commands
    3. CA Terraform provider
    4. DA Kubernetes operator
    Show answer

    B. Almost every cloud and virtualization platform (AWS, OpenStack, libvirt, VMware, bare-metal provisioning) supports cloud-init.

    From lesson 05 · Provisioners & bootstrap

15. Q15. Why bake software into images instead of installing it at boot?

    1. AImages are smaller
    2. BFaster, more reliable boots with fewer runtime dependencies (package mirrors, internet), and every node is identical
    3. Ccloud-init can't install packages
    4. DIt's required by Terraform
    Show answer

    B. Boot-time installs fail when mirrors are slow or unreachable (think air-gapped sites). Images make boots predictable.

    From lesson 05 · Provisioners & bootstrap

16. Q16. Why use a base cloud image with per-VM backing-file volumes?

    1. AIt's required by KVM
    2. BEach VM's disk only stores its own changes on top of the shared base, so VMs are created fast and use little space
    3. CIt enables encryption
    4. DCloud images can't boot otherwise
    Show answer

    B. qcow2 copy-on-write layering: one base image, thin per-VM overlays. Recreating a VM takes seconds.

    From lesson 06 · Terraform for bare metal / libvirt

17. Q17. How does a libvirt VM get its user, SSH key and hostname?

    1. AFrom Terraform state
    2. BFrom a cloud-init disk (an ISO with user data) attached to the VM at first boot
    3. CFrom DHCP
    4. DFrom the base image name
    Show answer

    B. The provider builds a small cloud-init ISO; the cloud image's cloud-init reads it on first boot.

    From lesson 06 · Terraform for bare metal / libvirt

18. Q18. What does 'terraform test' with command = plan check?

    1. ANothing
    2. BAssertions against the planned values, without creating real resources
    3. COnly formatting
    4. DProvider downloads
    Show answer

    B. Plan-mode tests are fast and free: they catch wrong names, tags or counts. Apply-mode tests create real (temporary) resources.

    From lesson 07 · Production patterns

19. Q19. Why run policy checks on the plan JSON rather than on the .tf files?

    1. AIt's the only format supported
    2. BThe plan shows the actual resolved values and actions (including deletions), after variables, modules and data sources are evaluated
    3. CHCL can't be parsed
    4. DIt's faster
    Show answer

    B. Rules like 'no S3 bucket may be public' or 'never delete an EKS cluster' are reliable only on resolved values and planned actions.

    From lesson 07 · Production patterns

20. Q20. What's the benefit of a scheduled drift-detection job?

    1. AIt speeds up applies
    2. BIt finds manual or unexpected changes early, before they surprise the next person who runs apply
    3. CIt fixes drift automatically
    4. DIt rotates credentials
    Show answer

    B. Drift found at 3 a.m. by a job beats drift found during an urgent change. Then decide: codify it or revert it.

    From lesson 07 · Production patterns