PS Product SecurityKnowledge Base

Terraform Mock Interview Pack

Terraform Mock Interview Pack Figure: Terraform security interview map.

Intro: This pack tests whether the candidate can talk about Terraform as part of a secure delivery system, not just as HCL syntax. The scenarios focus on state, plans, provider trust, and pipeline privilege.

What this page includes

  • five Terraform security scenarios with detailed solutions
  • emphasis on state sensitivity, plan control, dependency trust, and CI role design
  • reviewer cues for distinguishing mature infrastructure reasoning from tool memorization

Working assumptions

  • a strong candidate knows that many Terraform failures are caused by workflow and trust design around the tool, not only by the resource definitions themselves

Task 1 - Secrets placed directly in configuration and local state

Scenario

A team stores sensitive values directly in Terraform variables and runs Terraform locally with the default backend. The state file is committed to a shared internal repository by mistake.

Prompt

Explain the risk and outline immediate and long-term fixes.

Reveal the worked answer

Step-by-step solution

  1. Treat state and any saved plans as sensitive artifacts.
  2. Remove the leaked state from normal distribution paths and begin secret rotation.
  3. Move to a remote backend with appropriate access control and locking support.
  4. Redesign how secrets enter the workflow so they are not embedded directly in configuration when avoidable.
  5. Add repository and pipeline controls to prevent recurrence.

Explanation

Terraform state and plan files can contain sensitive data. The problem is not only the visible .tf code. The real risk is the surrounding artifact trail that captures resolved values and infrastructure details.

Common mistakes

  • masking terminal output but ignoring saved plan files;
  • rotating only one secret while leaving the workflow unchanged;
  • assuming internal-only repositories are a sufficient secret boundary.

Task 2 - Saved plan not used in apply stage

Scenario

The CI pipeline runs terraform plan in one job but later runs terraform apply without applying the reviewed saved plan. The apply job recomputes changes against a new state of the world.

Prompt

Why is this risky, and what would you change?

Reveal the worked answer

Step-by-step solution

  1. Explain the difference between reviewing a plan and recomputing one later.
  2. Save the reviewed plan artifact when the workflow requires a two-step review and apply process.
  3. Apply the saved plan rather than recalculating a new one in the deployment stage.
  4. Protect the integrity and sensitivity of the plan artifact.
  5. Tie approval, artifact retention, and apply permissions to the same controlled path.

Detailed explanation

A reviewed plan has value only if the apply step actually uses that reviewed artifact. Otherwise the organization approves one set of changes and executes another. That creates both change-control and security problems.

Common mistakes

  • saying “the code did not change, so it is fine”;
  • forgetting that plan files themselves are sensitive artifacts;
  • skipping integrity controls on the saved plan file.

Task 3 - .terraform.lock.hcl is ignored in version control

Scenario

Teams pin provider versions loosely in code but do not commit the dependency lock file. Different runners resolve different provider versions over time.

Prompt

Assess the risk and propose a better dependency model.

Reveal the worked answer

Step-by-step solution

  1. Explain that provider resolution drift undermines reproducibility and review.
  2. Commit the lock file and review changes to it through normal code review.
  3. Upgrade provider selections deliberately instead of implicitly.
  4. Make provider and module source choices visible in the pipeline and review process.
  5. Separate intentional upgrade work from unrelated infrastructure changes.

Why it matters

Terraform dependency trust is not only about version constraints in .tf files. The lock file records the concrete provider selection and checksum material that support reproducible installs.

Common mistakes

  • assuming version constraints alone guarantee identical installs;
  • letting terraform init -upgrade happen casually in shared pipelines;
  • reviewing HCL changes without noticing lock file drift.

Task 4 - State backend has no locking and force-unlock is common

Scenario

The organization uses a backend pattern that does not reliably protect against concurrent writers. Teams often reach for force-unlock when jobs appear stuck.

Prompt

How would you analyze and remediate this?

Reveal the worked answer

Step-by-step solution

  1. Explain why state locking protects correctness and reduces corruption risk.
  2. Identify whether the backend actually supports locking and whether the workflow relies on it correctly.
  3. Reduce concurrent-writer patterns in the pipeline design.
  4. Treat force-unlock as an exceptional recovery action, not a normal operator tool.
  5. Document ownership and troubleshooting steps so engineers do not solve process flaws with risky manual shortcuts.

Common mistakes

  • treating force-unlock as harmless housekeeping;
  • blaming Terraform alone when the backend or workflow design is the root problem;
  • allowing many independent jobs to target the same state path casually.

Task 5 - CI deploy role can read, write, and administer too much

Scenario

The Terraform CI role has broad permissions across multiple AWS accounts because “least privilege took too long.” The same role is reused across many workspaces and environments.

Prompt

What is the blast radius, and how would you redesign the model?

Reveal the worked answer

Step-by-step solution

  1. Explain that the CI role is part of the infrastructure control plane and should be treated like privileged automation.
  2. Split roles by environment, trust boundary, or portfolio instead of using one universal role.
  3. Narrow permissions to the services and actions the workspace actually manages.
  4. Add guardrails such as permissions boundaries or reviewable role catalogs where appropriate.
  5. Align plan, approval, and apply authority so one low-trust workflow cannot mutate broad infrastructure.

Interviewer notes

Strong candidates connect Terraform pipeline trust to cloud IAM design rather than treating Terraform as separate from AWS identity architecture.