Infrastructure as Code and Configuration Management
What to know
IaC treats infrastructure definitions as versioned code. Distinguish declarative (Terraform, CloudFormation, Kubernetes manifests-describe desired end state) from imperative (scripts-describe steps). Know idempotency: applying the same configuration twice yields the same result. Understand state in Terraform (remote state, locking, drift detection), plan/apply workflow, modules for reuse, and immutable infrastructure (replace rather than mutate). For configuration management (Ansible, Chef, Puppet), know idempotent resources, inventory, roles, and convergence. Know provisioning vs. configuration as layers, and drift as divergence between declared and actual state.
Traps
A common distractor says Terraform state should be committed to Git-never; state may contain secrets and must live in a locked remote backend. Another confuses terraform plan (preview, no changes) with apply. Questions may treat mutable, hand-patched servers as acceptable; the correct posture is immutable replacement. Also watch for non-idempotent shell commands in configuration management-they break convergence on reruns.
Rule of thumb
If it isn't in version control, it doesn't exist. Review plans like code, keep environments parameterized (not copy-pasted), and treat drift as an incident signal.
Worked example
A manual console change is made to a production load balancer. The next plan shows a diff. The right response is to codify the intended change in the repository, review it, and apply through the pipeline-not to silence the diff by editing state or ignoring it. State editing hides drift; codifying resolves it.