How to assess · For hiring teams
How to Assess Terraform / Infrastructure as Code Skills When Hiring
The test formats that actually work for Terraform / Infrastructure as Code, what a strong answer looks like, sample questions and a scoring rubric you can.
The short answer
Assess Terraform / Infrastructure as Code with a task, not a conversation: read and judge a plan, refactor a module, ai-scored assessment (e.g. cohesyve) or state-recovery conversation. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Reads a plan carefully and can explain every destroy, replace and in-place update before applying
- Manages state remotely with locking, and can describe what happens when state and reality diverge
- Designs modules with a small, stable interface and no hidden environment assumptions
- Uses variables, outputs and data sources so that the same code runs in every environment
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
Infrastructure as code is where a mistake is not a bug but an outage or a bill. A Terraform plan that destroys and recreates a database because someone renamed a resource, a state file that two people wrote to at once, a module that hardcodes a region — each is a failure of judgement rather than syntax, and each is invisible in a conversation about tooling. This page covers how to assess Terraform and infrastructure-as-code skill for platform and cloud roles: reading plans, managing state, designing modules, and the discipline that keeps infrastructure changes safe.
Why Terraform / Infrastructure as Code is worth testing
The tooling makes it easy to apply a change that cannot be undone. Strong practitioners treat every plan as a proposal to be read line by line; weak ones apply and hope. Testing shows which habit a candidate has, and it matters because the cost of the wrong one is measured in downtime and data.
What strong Terraform / Infrastructure as Code looks like
- Reads a plan carefully and can explain every destroy, replace and in-place update before applying
- Manages state remotely with locking, and can describe what happens when state and reality diverge
- Designs modules with a small, stable interface and no hidden environment assumptions
- Uses variables, outputs and data sources so that the same code runs in every environment
- Keeps secrets out of code and state, and knows what ends up in state anyway
- Structures repositories and workspaces so that blast radius is bounded
- Runs plans in CI, reviews them, and never applies from a laptop to production
Ways to assess Terraform / Infrastructure as Code
Read and judge a plan
Provide a Terraform plan output for a change that includes a rename causing a replace of a database, a security group opening, and a harmless tag update. Ask what they would approve, block and investigate.
Pros
Cons
Best for Any level; the subtlety of the planted change scales it.
Refactor a module
Provide a module with hardcoded values, a leaked secret and a resource that will be replaced on rename. Ask the candidate to make it reusable and safe, and explain how they would migrate existing state.
Pros
Cons
Best for Mid and senior platform engineers.
AI-scored assessment (e.g. Cohesyve)
Generate an IaC scenario from the job description — a plan review, a module design, a state-recovery question — with a rubric. Each candidate receives a different variant; reasoning is scored in writing.
Pros
Cons
Best for Screening before technical interviews.
State-recovery conversation
Describe a situation: state was lost, or someone changed a resource by hand. Ask how they recover.
Pros
Cons
Best for Senior engineers owning production infrastructure.
Cohesyve
Run a Terraform / Infrastructure as Code assessment on your next opening
Cohesyve generates a unique Terraform / Infrastructure as Code task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Plan reading
Whether they understand what a change will do.
State management
Whether state is safe and understood.
Module design
Whether infrastructure code is reusable.
Safety and workflow
Whether changes are made safely.
Sample Terraform / Infrastructure as Code questions
What does a plan line starting with `-/+` mean, and what should you do when you see it on a database?
EntryLook for Replace: destroy then create; on a database, stop and find the cause, likely a rename or immutable attribute; use moved blocks or import.
Why is remote state with locking necessary?
EntryLook for Shared source of truth, concurrent applies corrupt state, locking prevents it.
Someone changed a security group in the console. What happens on the next plan, and what do you do?
MidLook for Drift detected, plan proposes reverting; decide whether the manual change was right, then either import the change or apply the revert.
Design a module for a service that needs a queue, a role and an alarm, usable in three environments.
MidLook for Inputs for what varies, outputs for what consumers need, no hardcoded region or account, sensible defaults.
State was accidentally deleted for a production environment. Recover.
SeniorLook for Check for backups and versioning first; otherwise import resources one by one, verify with plan, and put protections in place afterwards.
Red flags
- Applies without reading the plan
- Local state for shared infrastructure
- Secrets in variables files committed to the repository
- Hardcoded regions, accounts and names inside modules
- Has never recovered from drift
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Plan judgement | 30% | Every destructive change is noticed and explained before apply. |
| State discipline | 25% | Remote, locked, understood; drift is handled. |
| Module design | 25% | Reusable, environment-agnostic, small interface. |
| Safe workflow | 20% | CI plans, reviews, bounded blast radius, protected resources. |
Mistakes hiring teams make
- Testing HCL syntax rather than plan judgement
- Not including a destructive plan — the defining risk
- Ignoring state entirely
- Accepting modules with hardcoded values because they work
- Confusing familiarity with one cloud provider for IaC skill
Roles that need Terraform / Infrastructure as Code
Common questions
Does Terraform skill transfer to other IaC tools?
The judgement — reading plans, managing state, bounding blast radius — transfers to Pulumi, CloudFormation and others. Tool syntax is learnable. Test judgement first.
What is the most important IaC question?
Show a plan with a replace on a stateful resource and ask what they do. Anyone who says "apply" is not ready for production infrastructure.
How do I assess IaC without cloud access?
Plan outputs, module code and state scenarios all work on paper. Reasoning is what you are testing; hands-on can be confirmed with finalists.
Should IaC be tested for backend developers?
Lightly, if they touch infrastructure. Reading a plan and understanding state is a reasonable expectation; module design is a platform skill.
Cohesyve · Skill assessments for hiring
Test Terraform / Infrastructure as Code before the first interview
Generate a role-specific Terraform / Infrastructure as Code assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog