Tests and policy-as-code

Что отвечать

Several levels. (1) Static analysis: HCL validation, style, common mistakes with `terraform validate`, `fmt -check`, `tflint`. (2) Security and compliance, where the HCL matches policy: `checkov`, `trivy`, `tfsec`. (3) Unit tests with `terraform test` and mock providers, which checks HCL logic without a real apply. (4) Integration tests with terratest or `terraform test` against real providers in a sandbox account, which stands the infrastructure up, checks it, and tears it down. Not every project needs all of it; the more the HCL touches production, the deeper the pyramid.

Что хотят услышать

A senior should: - lay out the pyramid: many cheap static checks at the bottom, a few expensive integration tests at the top - say that a library module (shared across the org) needs unit and integration tests, while a root config for a single application is often fine with static plus security - separate "testing HCL" (expression logic, count, for_each) from "testing the infrastructure" (that AWS actually brought up what was expected) - mention that AWS tests are slow (minutes per apply), so isolate them in a separate scheduled CI job rather than every PR

Подводные камни

• ✗ Running integration tests on every PR without a sandbox account. In a week you get a bill and rate limits
• ✗ Thinking `terraform validate` is a 'test.' It is a syntax linter, not a test
• ✗ Covering 100% with static checks and skipping integration. You miss the bugs in how you interact with the provider

Follow-up

• ? What tests does a shared module used by 10 teams need?
• ? How does 'testing HCL' differ from 'testing real AWS'?
• ? Where do you draw the line: what runs in CI on every PR, what runs nightly?

Что отвечать

`terraform test` (since 1.6+) is HashiCorp's framework: run blocks are written in HCL, it can mock providers out of the box, and unit tests finish in seconds with no apply. Terratest is a Go library that runs real `terraform init/apply/destroy` under the hood, with test scenarios in Go: stand it up, check it through the AWS SDK, tear it down. Terratest is integration; the Terraform test is both unit (with mocks) and integration (without). In new code today, reach for the built-in test first; terratest stays for complex scenarios that verify through non-standard APIs.

Что хотят услышать

A senior should: - name the key differences: HCL vs Go (the test DSL), mocking out of the box vs real-apply only, speed - say that mock providers in `terraform test` (since 1.7+) let you test reference logic, count, for_each, and error handling without money or time - mention `run` blocks: each is an isolated scenario, and you can check plan-only (`command = plan`) or apply - name the choice criterion: for a new project in 2026 use `terraform test`; for legacy with terratest, leave it

Подводные камни

• ✗ Thinking the built-in test always replaces terratest. For checks through non-standard APIs (the Kafka admin API, say) Go is still handier
• ✗ Running integration tests with no TTL on the resources. A forgotten test stand can live in AWS for a month
• ✗ Not knowing how to mock in `terraform test`. It is there since 1.7+, so read the docs on the mock_provider block

Follow-up

• ? What does `mock_provider` do in `terraform test`?
• ? How does `command = plan` differ from `command = apply` in a run block?
• ? When is terratest still better than the built-in `test`?

Что отвечать

`tflint` is an HCL linter with provider knowledge: it catches deprecated arguments, a wrong instance type, references to resources that do not exist. `checkov` is a policy scanner: "the bucket is public," "RDS without encryption," "the IAM role is too broad." It runs on HCL, on a plan, or on a JSON export. `trivy` is a general scanner for containers, IaC, and secrets in code; for Terraform it is similar to checkov, plus it reports in SARIF for the GitHub Security tab. The usual pairing is tflint in pre-commit, checkov or trivy on the PR.

Что хотят услышать

A senior should: - separate a linter (structure, deprecation) from a policy scanner (security, compliance) - say that one scanner is often enough: checkov and trivy compete on coverage, so running both duplicates rules - mention that any scanner produces false positives, so you start with baseline suppressions on the existing codebase - note that `tfsec` was absorbed into trivy in 2023, so use trivy in new code

Подводные камни

• ✗ Turning on three scanners at once with no baseline. The PR fails on hundreds of warnings about existing resources, and the engineers switch them all off
• ✗ Thinking checkov will find logic bugs. No, only pattern matching against rules
• ✗ Using tflint with no `--config`. The default rules may not match your conventions

Follow-up

• ? How does trivy for IaC differ from checkov in its approach to rules?
• ? How do you introduce a scanner into a legacy project without paralysis from warnings?
• ? Where do you write custom checkov rules?

Что отвечать

OPA (Open Policy Agent) is the Rego rule language plus an execution engine. `conftest` is a CLI wrapper around OPA for checking structured files (JSON, YAML, an HCL plan export). You use it when checkov's rules are not enough or you need a corporate policy: "the Owner tag is non-empty on every S3 bucket," "IAM roles only with a specific naming scheme." You write rules in Rego and run conftest against `terraform show -json plan.tfplan`. OPA goes deeper than checkov: a full programming language for conditions, and it can reach into external data.

Что хотят услышать

A senior should: - note that Rego is declarative, with its own syntax and a learning curve - say that OPA is needed when the policy is complex or depends on corporate context (a lookup into an HR system for approvers) - mention `terraform show -json plan.tfplan | conftest test -` as the canonical pattern - name the alternative: Sentinel in Terraform Cloud/Enterprise, HashiCorp's own policy language, simpler than Rego but tied to TFC

Подводные камни

• ✗ Starting with OPA when checkov would have done. The team spends weeks on Rego instead of a first version of the policy
• ✗ Running conftest on HCL instead of the plan output. HCL does not show computed values, and it does not reflect the provider's final decisions
• ✗ Writing Rego with no tests. The rules should have their own unit tests in OPA itself

Follow-up

• ? How does Sentinel differ from OPA?
• ? What do you feed conftest: HCL or the plan JSON?
• ? How do you test a Rego rule?

Что отвечать

Bottom to top: (1) static analysis (validate, fmt, tflint), seconds, catches typos and style; (2) policy and security scanners (checkov, trivy), tens of seconds, catches unsafe patterns; (3) unit tests (`terraform test` with mocks), seconds to minutes, checks HCL logic; (4) integration tests (terratest or test with a real provider), minutes to hours, a real apply in a sandbox. It usually breaks at integration: slow, flaky, expensive. Teams either give up and keep only the lower levels (taking the risk) or run integration nightly rather than on every PR (sensible for most).

Что хотят услышать

A senior should: - build the pyramid on the "cheap at the bottom, expensive at the top" principle - note that integration tests are mandatory for shared modules and often excessive for leaf applications - say that non-determinism at integration (eventual consistency, rate limits) makes them flaky, so you need retries, backoff, and careful cleanup between runs - mention that test execution time feeds straight into a team's iteration velocity; if CI goes green an hour later, the PR cycle is broken

Подводные камни

• ✗ Assuming integration tests are needed on every PR. They are not, except for critical infrastructure
• ✗ Not cleaning up resources after integration tests. In a month the sandbox account fills with orphaned EC2 instances
• ✗ Not assigning an owner to the tests. No one fixes the flaky ones, and in six months CI is green in name only, with bugs slipping through

Follow-up

• ? Where do policy scanners sit in the pyramid?
• ? How do you keep integration tests fast?
• ? What is a flaky test, and how do you cure it in IaC?