Authoring and Refactoring Configuration: Expressions, Functions, Dynamic Blocks, Validation, and Lifecycle
Expressions first
Most questions test whether you can predict the value or the plan diff an expression produces, not whether you can write HCL from scratch. Be fluent with for expressions (list and map forms), splats, conditionals, and the safety functions try and can. can returns a boolean and is the idiomatic guard for a value that may not exist; try returns the first expression that evaluates without error. Collection and string functions appear constantly: lookup, merge, flatten, setproduct, cidrsubnet, format, templatefile, yamldecode.
Meta-arguments and blocks
Know the difference between count (index-keyed, so instances shift when a list is reordered) and for_each (key-stable, requiring a map or set with keys known at plan time). dynamic blocks take for_each, an optional iterator, and a content block; the iterator name defaults to the block label. Validation has three homes: variable validation blocks, whose condition may reference only that variable; lifecycle precondition/postcondition, which may reference other values and fail the run; and check blocks, which only emit warnings and never block an apply. Refactoring tools are moved blocks, removed blocks with lifecycle { destroy = false }, import blocks, and terraform_data for hook-style resources.
Trap
A frequent distractor is ignore_changes versus prevent_destroy. ignore_changes filters plan diffs for named attribute paths, while prevent_destroy aborts at plan time. Neither suppresses a replacement once another attribute forces one.
Rule of thumb
If a collection's identity matters, use for_each keyed by a stable name; if only ordering matters, count is fine.