What they're testing
Whether you think about disaster recovery and auditability, or just about typing fewer commands.
The short answer~30 seconds
Three reasons bigger than automation. One: infrastructure goes through code review — someone sees the security group opening port 22 to the internet BEFORE it exists. Two: it's rebuildable — lose a region and you apply into another rather than trying to recall forty console actions. Three: it has history — git blame answers "who opened this and why", which a console never can.
The long answer
What makes IaC fail in practice is drift: someone changes something by hand during an incident (reasonable), then never brings it back into code (not reasonable), and the next apply reverts their fix. The remedy is running plan on a schedule in CI and alerting on any difference — turning drift from a time bomb into a notification.
The most important operational detail is state: Terraform's state file holds everything it manages, including some sensitive values, and two concurrent applys will corrupt it. So state belongs in a remote backend with LOCKING (S3 plus DynamoDB, or Terraform Cloud), never in git. It's a near-certain follow-up, and getting it wrong signals solo use rather than team use.
What they'll ask next
?Does infrastructure need tests?
Yes, at two levels: policy checks before apply (Checkov, OPA — "no bucket may be public"), and post-apply checks that what you built actually works. A plan shows what will change; it doesn't tell you whether the change is correct.
These lose points
- Committing the state file to git. It holds sensitive values and has no locking, so two concurrent applies corrupt it.