5 exercises — practise answering Terraform Platform Engineer interview questions in professional technical English.
0 / 5 completed
1 / 5
The interviewer asks: "Your Terraform state file for a production environment was accidentally corrupted. How would you recover, and how do you prevent this from happening again?" Which answer best demonstrates Terraform Platform Engineer expertise?
Option B is strongest because it uses proper state backup and versioning to recover safely, reconciles drift methodically, and fixes root causes like missing state locking and uncontrolled local applies. Option A risks Terraform destroying and recreating real production resources it can no longer track correctly, causing an outage. Option C is extremely risky and error-prone, since hand-editing state easily introduces further corruption or drift. Option D causes a full production outage and potential data loss for stateful resources like databases, which is a drastic overreaction to a recoverable problem.
2 / 5
The interviewer asks: "How do you structure Terraform code so that a change to a shared networking module does not risk accidentally breaking every environment that depends on it?" Which answer best demonstrates Terraform Platform Engineer expertise?
Option B is strongest because it isolates blast radius through per-environment state and explicit version pinning, with a progressive, validated rollout process and clear changelog communication. Option A creates a single point of failure where any mistake affects every environment simultaneously with no isolation. Option C means every environment silently picks up unreviewed changes the moment they land on main, which is exactly the uncontrolled propagation risk the question describes. Option D avoids the propagation risk but creates massive duplication and drift, making consistent updates across environments far harder to manage safely.
3 / 5
The interviewer asks: "How do you prevent a Terraform plan from being approved and applied that would destroy and recreate a production database, when that was not the developer's intent?" Which answer best demonstrates Terraform Platform Engineer expertise?
Option B is strongest because it uses lifecycle protections, automated policy-as-code detection, and explicit approval gates specifically for destructive actions, rather than relying on manual vigilance alone. Option A is exactly the failure mode described in the question — a human missed it under review pressure. Option C is not an actionable fix, just a restatement of hoping people are more careful. Option D removes the primary safety mechanism, plan review, entirely, which drastically increases risk rather than reducing it.
4 / 5
The interviewer asks: "Your organization has dozens of teams writing their own Terraform, leading to inconsistent tagging, naming, and security configurations across cloud resources. How would you address this at a platform level?" Which answer best demonstrates Terraform Platform Engineer expertise?
Option B is strongest because it makes compliance the path of least resistance through well-designed shared modules, backed by automated policy enforcement as a safety net, and treats the modules as an adopted product rather than an unenforced mandate. Option A relies purely on voluntary compliance with a document, which is exactly the kind of inconsistency the question describes already happening. Option C creates a central bottleneck that does not scale across dozens of teams and slows every team down. Option D is impractical since different teams legitimately have different infrastructure needs, and a rigid one-size-fits-all template will be worked around rather than adopted.
5 / 5
The interviewer asks: "How do you manage secrets, like database passwords or API keys, that Terraform needs to provision infrastructure without exposing them in state files or version control?" Which answer best demonstrates Terraform Platform Engineer expertise?
Option B is strongest because it sources secrets from a dedicated secrets manager at apply time, encrypts and restricts access to state since state itself can contain sensitive values, and avoids having Terraform handle raw secret values where out-of-band generation is possible. Option A commits plaintext secrets directly to version control history, which is a severe and hard-to-reverse security exposure. Option C leaves secrets in shell history and process lists, and still does not solve the state file exposure problem. Option D ignores that Terraform state itself commonly contains secret values in plaintext, which is the harder and more important part of the problem to solve.