Infrastructure as Code - Why It Matters
A team lost their entire production environment when the one engineer who understood it left the company. Nothing was written down outside his head and the consoles he'd clicked through for years. This is why interviewers ask what IaC actually matters for, not just what it is.
The answer interviewers want
Infrastructure as Code means your servers, networks, and configuration are defined in code, using tools like terraform, ansible, or CloudFormation, instead of clicking through a cloud console by hand. That code gets checked into version control, reviewed like any other change, and applied the same way every time.
The automation angle is real but it's not the point most candidates miss. IaC isn't primarily about saving time on provisioning. It's about making infrastructure knowledge explicit and shared instead of living in one person's head. When the setup is a Terraform module or an Ansible playbook sitting in a repo, anyone on the team can read it, understand it, and rebuild it. No single engineer leaving, getting sick, or going on vacation can take down your ability to reproduce or recover your environment. The code is the documentation, and it's documentation that can't go stale the way a wiki page does, because it's the thing that actually runs.
Why interviewers ask this
This question separates people who've memorized "IaC equals Terraform" from people who understand the organizational risk it solves. Interviewers want to know if you think about bus factor and operational resilience, not just tooling. It also signals whether you'd push for IaC adoption on a team that's still doing manual console changes, and whether you can justify that push in terms management cares about.
Follow-ups to expect
What happens when someone makes a manual change outside the IaC pipeline? You get drift: the code no longer reflects reality, and the next terraform apply either silently reverts someone's fix or fails in a confusing way. Part of the value of IaC collapses if people are allowed to route around it.
How do you get a team to actually use IaC instead of clicking through the console? Make code review and version control the only path to making changes, so console access becomes read-only or emergency-only in practice, and bake that into how changes get deployed.
What's the difference between provisioning tools and configuration management tools here? Terraform and CloudFormation describe and create infrastructure itself, while Ansible configures what runs on top of it. Both get versioned and reviewed the same way, for the same reason.
The common wrong answer
Most candidates answer with "it automates infrastructure setup and saves time," and stop there. That's true but it's the shallow version. It misses the actual risk IaC is defending against: a single engineer being the only one who knows how production works, and everything falling apart the day they're not available.