Site Reliability Engineer Interview Question

How do you manage Terraform state across a team, and what do you do about drift?

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

Use remote state with locking, such as S3 plus DynamoDB or a managed backend, split into one state file per environment and blast radius, and never commit state to git since it stores secrets in plain text. For drift, run plan on a schedule and alert on any non empty diff, keep all changes flowing through CI rather than the console, and use import or removed blocks deliberately instead of hand editing state.

Why interviewers ask this

This is an operational maturity question. Interviewers want to know whether you have worked in a repository where five people apply at once, whether you understand the blast radius argument for splitting state, and whether you have a real answer for the console change that someone made during an incident. Mentioning that state contains secrets is a good credibility marker.

How to structure your answer

  • Cover remote state plus locking as the baseline.
  • Explain how you split state and why, in blast radius terms.
  • Note that state holds secrets, so encryption and access control matter.
  • Describe scheduled plans as the drift detector.
  • Give the process for legitimate emergency console changes.

Example answer

Spoken example, first person

Remote backend with locking, always, so two applies cannot race. Beyond that the big decision is how you split it. One giant state file means a plan takes fifteen minutes and every change risks everything, so I split per environment and then per blast radius: networking separate from the cluster, the cluster separate from application resources, and shared data pulled in with remote state outputs or data sources rather than a monolith. State also contains secrets in plain text, which people forget, so it lives in an encrypted bucket with tight IAM and versioning on. For drift, I run terraform plan nightly in CI and alert if the diff is non empty. That found a security group someone had widened by hand during an incident, which is exactly the case you want to catch. I do not ban console access in emergencies, but the rule is that you open a pull request the same day to codify whatever you did, and the nightly plan is what enforces it.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • How do you bring an existing resource under Terraform management safely?
  • What would you do if state and reality have diverged badly?
  • How do you handle secrets in variables and outputs?

Related site reliability engineer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot