Sample questions
Terraform Testing Policy CicdDifficulty 1
What does terraform fmt do?
- aIt applies the configuration to the target infrastructure after formatting it
- bIt rewrites configuration files into a canonical style without changing their logic.✓
- cIt validates that resource arguments reference real provider attributes
- dIt downloads and locks provider versions into a lock file
Explanation:terraform fmt is purely a style tool: it rewrites .tf files into the canonical HCL formatting (indentation, alignment, spacing) and does not touch the actual logic or check correctness. Applying, validating, and provider locking are separate commands (apply, validate, init).
Terraform Testing Policy CicdDifficulty 1
What does terraform validate primarily check?
- aWhether the target cloud account has enough quota to create the planned resources
- bWhether the resources described already exist and match the real infrastructure
- cInternal syntax and consistency of the configuration.✓
- dWhether the CI pipeline has permission to run
terraform apply
Explanation:terraform validate performs a syntax and internal-consistency check: it confirms the configuration is a valid HCL structure, required arguments are present, and referenced values resolve within the configuration. It does not talk to the cloud provider to compare against real infrastructure — that is terraform plan's job.
Terraform Testing Policy CicdDifficulty 2
A pipeline runs terraform validate without ever configuring cloud credentials, and it still succeeds. Why is this possible?
- aValidate only checks the configuration's internal structure, without authenticating against the provider API.✓
- bValidate silently skips all resources it cannot authenticate against, which is a bug some teams rely on
- cValidate always fails without credentials, so this scenario is impossible
- dValidate automatically falls back to a cached copy of the last successful plan
Explanation:Because terraform validate is a purely local/static check (types, required arguments, internal references), it does not need to reach the provider API. terraform plan and terraform apply, in contrast, need real credentials because they compare configuration against actual remote state.
Terraform Testing Policy CicdDifficulty 2
tflint is often run alongside terraform validate in a CI pipeline. What does tflint add on top of what validate already checks?
- aNothing meaningful — tflint and validate check exactly the same things, so running both is redundant
- btflint replaces the need for
terraform plan entirely, since it can simulate real infrastructure changes - ctflint applies the configuration to a sandbox account to catch runtime errors before production
- dtflint adds provider-specific best-practice and correctness checks beyond generic HCL syntax validity.✓
Explanation:terraform validate only confirms the configuration is structurally valid HCL. tflint, via its core rules plus provider-specific plugins (e.g. for AWS), additionally flags issues like deprecated syntax, unused declarations, or invalid provider-specific values that are syntactically fine but semantically wrong.
Terraform Testing Policy CicdDifficulty 1
What is the general idea behind 'policy as code' in a Terraform pipeline?
- aWriting internal documentation about infrastructure policies in a wiki, separate from the pipeline
- bExpressing organizational rules as machine-checkable rules the pipeline evaluates against a plan.✓
- cManually reviewing every plan output line by line before every apply, with no automation involved
- dReplacing
terraform validate entirely, since policy tools also check HCL syntax
Explanation:Policy as code means organizational or compliance rules are written as executable rules (e.g. with Sentinel or OPA) that a pipeline runs automatically against a plan, so violations (like a publicly-exposed resource) are caught consistently and automatically rather than relying on a human remembering to check.
Terraform Testing Policy CicdDifficulty 2
Why is it common practice to run terraform plan as part of a pull-request check, and post its output as a PR comment, before merging?
- aBecause
terraform plan modifies the real infrastructure, so it must happen before merge to save time - bBecause posting the plan is required by Terraform itself; the CLI refuses to apply otherwise
- cSo reviewers can see the infrastructure impact of a PR before approving the merge.✓
- dBecause
terraform plan is the only command capable of catching HCL syntax errors
Explanation:Posting the plan output on the PR gives reviewers visibility into the concrete infrastructure impact of a change (what will be created, changed, or destroyed) as part of the normal code review flow, catching unintended changes before they're merged and later applied.