IaC & Configuration
Infrastructure as Code (IaC) replaces hand-clicked servers and pet machines with text you commit, review, and re-run. Instead of remembering what you changed in a console, you declare the desired state in files and let a tool reconcile reality against it. Three tools dominate the interview, and each rests on a single load-bearing idea.
Terraform provisions cloud resources declaratively, but it does not read your intent from the cloud — it reconciles your configuration against a state file that is its own source of truth. Almost every Terraform trap (drift, locking, count vs for_each, imports, moved blocks) is really a state question in disguise.
Configuration management (Ansible here) drives an existing machine to a declared state, and its core property is idempotency: re-running a play must be safe and must report changed only when something actually changed. A raw shell command breaks that promise.
Helm and GitOps are often confused but solve different problems: Helm is packaging and templating, while GitOps is continuous reconciliation of a cluster against Git — which is why a manual edit gets reverted by design.
Topic map
- Terraform — declarative desired state reconciled against a state file; plan vs apply vs destroy, drift, remote backends with locking,
countvsfor_each, modules, and safe state refactors withstate mv/moved. - Config management — repeatable, version-controlled machine state; idempotency as the core property, push (Ansible) vs pull (Puppet/Chef), roles and handlers, Jinja2, Vault, and mutable config vs immutable infrastructure.
- Helm & GitOps — Helm charts, templating, and release rollback versus GitOps as Git-as-source-of-truth with Argo CD/Flux continuously reconciling and auto-healing drift.
Common traps
| Mistake | Consequence |
|---|---|
| Treating the cloud as Terraform's source of truth | You miss that plan compares config against the state file, and drift/imports stop making sense |
| Committing or hand-editing local state | State can hold secrets and is easily corrupted; two people racing an apply overwrite each other |
Using count for a set that changes in the middle | Reindexing destroys and recreates every later resource instead of touching one |
Calling a raw shell/command task idempotent | It reports changed every run and never converges — Ansible cannot see the state behind it |
| Thinking Helm and GitOps are the same layer | You conflate packaging with reconciliation and can't explain why a manual edit reverts |
"Fixing" prod with kubectl edit under GitOps | The controller reverts it by design; the only real fix is a Git commit |
Interview relevance
These topics test whether you understand where the truth lives. Terraform's truth is its state file; Ansible's is the declared end state that must converge idempotently; GitOps's is the Git repo that the controller reconciles toward. Candidates who internalise that answer drift, locking, rollback, and "why did my manual change disappear" questions cleanly, while those who don't tend to describe the happy path and stall the moment reality diverges from intent.