What is Infrastructure Testing and Why Does It Matter?
Learn what infrastructure testing is, its static, unit, and integration layers, and why untested IaC changes are risky — DevOps interview answer.
Expected Interview Answer
Infrastructure testing is the practice of writing automated checks that verify infrastructure-as-code (Terraform, CloudFormation, Pulumi) actually provisions the resources, configurations, and network behavior it claims to, before that code reaches production.
It spans several layers: static analysis (linting and policy scanning against the raw code before anything is provisioned), unit tests that validate a module’s plan output against expected values without touching real cloud APIs, and integration tests that actually deploy real (or ephemeral) infrastructure, assert on live resource state, then tear everything down. Tools like Terratest, Kitchen-Terraform, and Terraform’s native `terraform test` framework drive the integration layer, while `tflint` and policy engines like OPA or Sentinel handle static and compliance checks. The goal is to catch a misconfigured security group, an incorrect IAM policy, or a broken module contract in a pull request, not after a change has already caused an outage or a security exposure in production. Because infrastructure changes are harder to "undo" than application code, and often touch shared, stateful resources, the cost of an untested infra change tends to be higher than an untested application bug.
- Catches misconfigurations before they reach production
- Validates module contracts so teams can safely reuse shared modules
- Provides a regression safety net for refactors of critical infrastructure
- Builds confidence to automate infra changes in CI/CD pipelines
AI Mentor Explanation
Infrastructure testing is like a ground staff crew checking pitch moisture, boundary rope tension, and sightscreen alignment before the umpires ever walk out, rather than discovering a soggy patch mid-over. A junior groundsman runs a quick static check — is the pitch marked and rolled correctly — before a senior inspector actually walks the full square and confirms bounce and carry with real deliveries. Only once both checks pass does the match official sign off on play starting. Skipping the walk-through inspection risks a dangerous pitch being discovered only when a fast bowler is already running in.
Step-by-Step Explanation
Step 1
Static analysis
Lint and scan raw IaC code (tflint, checkov) for syntax errors and obvious misconfigurations before anything is provisioned.
Step 2
Unit test the plan
Validate module logic against expected `terraform plan` output without touching real cloud APIs.
Step 3
Integration test live resources
Actually provision ephemeral infrastructure, assert on real resource state and network behavior, then destroy it.
Step 4
Gate the pipeline
Wire all three layers into CI so a pull request cannot merge until infra tests pass.
What Interviewer Expects
- Distinction between static, unit, and integration test layers for IaC
- Awareness that integration tests provision and destroy real resources
- Knowledge of at least one concrete tool (Terratest, terraform test, checkov)
- Understanding of why untested infra changes are riskier than app code bugs
Common Mistakes
- Treating `terraform plan` review alone as sufficient testing
- Never tearing down resources created by integration tests, leaking cost
- Confusing policy-as-code scanning with functional infrastructure testing
- Not testing failure/rollback paths, only the happy path
Best Answer (HR Friendly)
“Infrastructure testing means we treat our cloud configuration code the same way we treat application code — we write automated tests that check it before it goes live. We catch things like a wrongly opened security port or a broken module in a pull request, instead of finding out in production, which keeps our systems safer and our deployments faster.”
Code Example
# 1. Static analysis
tflint --recursive
checkov -d . --quiet
# 2. Unit test plan output
terraform plan -out=tfplan
terraform show -json tfplan > plan.json
# 3. Integration test (Go + Terratest)
cd test && go test -v -timeout 30m ./...Follow-up Questions
- How do you avoid leaking cloud costs from integration tests that fail mid-run?
- What is the difference between testing a Terraform plan and testing applied infrastructure?
- How would you test that a security group does not allow unintended inbound traffic?
- How do you keep infrastructure integration tests fast enough for a CI pipeline?
MCQ Practice
1. Which test layer actually provisions and then destroys real cloud resources?
Integration tests deploy real (often ephemeral) infrastructure, assert on live state, then tear it down, unlike static analysis or plan-only unit tests.
2. Why is infrastructure testing generally considered higher-stakes than application unit testing?
Infrastructure changes frequently affect shared, stateful, production-critical resources, making mistakes more costly and harder to reverse than typical app bugs.
3. What does a static analysis tool like checkov or tflint check?
Static analysis inspects the IaC source code itself for syntax issues, insecure defaults, and policy violations without provisioning anything.
Flash Cards
What is infrastructure testing? — Automated verification that IaC provisions the resources and behavior it claims to, before reaching production.
Name the three IaC test layers. — Static analysis, plan-level unit tests, and live integration tests.
What does an integration test do that a unit test does not? — It actually provisions and asserts on real (usually ephemeral) cloud resources.
Why test infrastructure code at all? — To catch misconfigurations and security exposures before they reach production, where infra mistakes are costly to undo.