Configuration Management and Infrastructure as Code
What this domain tests
Configuration Management and Infrastructure as Code tests declarative provisioning, idempotency, state management, drift, modules, and immutable infrastructure. Expect Terraform concepts and configuration-management tools such as Ansible.
Core rules and concepts
- Declarative IaC describes the desired end state, and the tool computes the diff. Imperative scripts describe steps and are harder to make idempotent.
- Idempotency means applying the same configuration twice yields the same result without unintended changes.
- Terraform keeps state mapping real resources to configuration. Use a remote backend with locking so concurrent runs cannot corrupt state; state may contain sensitive values, so encrypt and restrict access.
- terraform plan is the review artifact: read it for destroys and replacements, not just creates.
- Drift occurs when resources are changed outside IaC. Detect it with regular plans, then either codify the intended change or revert the console change.
- Immutable infrastructure replaces servers rather than patching them in place, reducing configuration drift.
Worked example
A terraform plan shows an EC2 instance will be replaced because someone changed its AMI in the console. Reasoning: applying immediately may cause an outage. First determine whether the console change was approved. If not, revert it or align the code; if yes, encode it, schedule a rolling replacement, and confirm the plan's replacement reason. Never accept a plan that destroys a stateful database without a migration plan.
Traps that cost marks
- Keeping state on a laptop or in Git.
- Assuming apply is safe because plan was reviewed last week; re-plan against current state.
- Using configuration management to mutate long-lived pets.
- Hard-coding secrets in variable files or module defaults.
- Ignoring force-replacement markers in a plan until production is recreated.