DevOpsInterviews logo
← Infrastructure as Code & Configuration / 17
hardGitLabAtlassianNetflix

Design the CI checks for a Terraform repository. What runs at each stage, and what can each check never catch?

A green plan is evidence, not proof. Build the pyramid: lint in seconds, policy on every PR, real-cloud verification only where shared modules and money justify the burn.

Grounded in researched DevOps, SRE and platform engineering interview loops, written to a senior-engineer editorial bar, and never padded to hit a word count.

TL;DR: Layer checks by cost: format, validate and tflint within seconds; policy-as-code (conftest or Checkov) against plan JSON on every pull request; the plan itself as the reviewed artifact; and apply-and-verify tests reserved for shared modules and risky changes. Know what each layer cannot catch, because that is where the follow-up goes.

How to approach it

Structure the answer as a pyramid with runtimes and failure classes per layer, then take a position on where expensive integration tests are justified. What each tool cannot do is the useful half, because the gaps are where the untested change ships.

A strong answer

Layer one, static, seconds. terraform fmt and terraform validate catch syntax and type errors without touching a provider API. tflint plugins add rule-specific checks, such as deprecated arguments or invalid values. API access and coverage depend on the plugin and rule; do not assume it verifies live regional availability. Cache dependencies and measure runtime instead of promising a fixed fifteen-second limit.

Layer two, policy, still seconds. Convert the plan to JSON and evaluate OPA rules with conftest, or run Checkov: deny public ingress, unencrypted buckets, missing cost-allocation tags, disallowed regions. This encodes organisational law independently of author discipline, with rules reviewed like code. Exceptions exist but carry an owner and an expiry date, or the policy layer decays into noise within a quarter.

Layer three, the plan as artifact. The plan is the highest-signal cheap test: attach it to the pull request, regenerate on every new commit, bind approvals to that exact artifact. A plan proves what Terraform intends against current state; it cannot prove the change works, that quotas allow it, or that permissions propagate in time.

rendering diagram…

Layer four, real verification, selectively. Terraform native tests can use mocked providers for configuration contracts or real providers for integration tests. This partial test assumes the module defines the separate AWS encryption-configuration resource:

run "logs_bucket_encrypts" {
  command = plan

  assert {
    condition     = length(aws_s3_bucket_server_side_encryption_configuration.logs.rule) > 0
    error_message = "logs bucket must enforce SSE by default"
  }
}

Explicitly mocked native tests suit fast module contract checks. Native tests with real providers can also create billable infrastructure: a run block defaults to apply, and even command = plan may call provider APIs. Terratest-style Go tests are useful for external behavioral probes such as listener routing or DNS resolution. HashiCorp documents native test execution and cleanup. The defensible allocation: behavioural suites for published shared modules and identity-touching stacks, plan-plus-staging for leaf stacks. Budget the module suite under fifteen minutes or developers route around it.

What no layer catches is the interesting answer: cross-stack interaction effects, quota exhaustion at production scale, permission propagation latency, data-dependent behaviour. Staged promotion still catches what a complete pyramid cannot, because a sandbox holding one instance behaves differently from forty behind a quota ceiling.

What interviewers probe next

"Native tests or Terratest?" Use native mocked tests for configuration contracts and real-provider native tests for apply assertions. Add Terratest or another runner where external behavioral probes need it; cost depends on what the test executes, not its language.

"Who owns the policy rules?" The platform team owns the baseline; teams propose exceptions through PR with expiry dates. Ownership without an exception path breeds shadow infrastructure.

"Tests passed and production broke anyway. What did you miss?" Investigate ordering, propagation delay, scale, input differences and untested behavior. That gap between sandbox behaviour and production behaviour is precisely what staged promotion exists to close.

Common mistakes

Equating a passing terraform validate with tested infrastructure, which catches typos and nothing about intent.

Bolting policy checks onto main after merge, where violations surface after the damage and nobody trusts the gate.

A Terratest suite so slow it collects [skip ci] tags, leaving the expensive layer permanently decorative.

That one was free, and so are 18 answers per topic without an account. Signing in doubles that to 28, keeps your bookmarks, and tracks which topics you keep getting wrong.one Google click · no card · nothing to cancel
HOW DID IT GO?
0
UP NEXT ON YOUR JOURNEY
NOTES & DISCUSSION · 0

Nothing here yet. Say how you would answer it.