How would you structure Terraform for 40 services across 3 environments? What goes wrong with the obvious approaches?
What they are really testing: Whether you have felt the pain of both extremes. One giant state and a state per resource are both real failure modes, and the answer is about blast radius and plan time.
A real interview question
How would you structure Terraform for 40 services across 3 environments? What goes wrong with the obvious approaches?
What most people say
drag me
“Use one repository with a workspace per environment, which keeps everything consistent.”
Workspaces share a configuration and a backend, so environment differences get expressed as conditionals that grow unreadable, and a single state per environment still means a 40-service plan takes many minutes and one lock blocks everyone.
The follow-ups they ask next
Forty services means 40 near-identical configurations. How do you avoid the duplication?
A shared module owning the pattern, versioned, with each service passing parameters. Then a change to the pattern is one module release plus a bump, rather than 40 edits.
How do you roll out a module change to 40 services safely?
Version the module and let services adopt at their own pace, with automated pull requests for the bump. Never force everyone onto a new version at once, since a bad module release then becomes 40 simultaneous incidents.
What is genuinely wrong with reading another team remote state?
It couples you to their internal structure, so they cannot refactor without breaking you, and it usually requires read access to a state file that may contain secrets. A published output or a tagged resource you look up is a cleaner contract.
Plans still take too long. What do you do?
Target only changed directories in CI by detecting which paths a pull request touched, cache providers, and split any state that has grown too large. Plan time is a design signal that a boundary needs revisiting.
What the interviewer is listening for
- Frames state as locking, plan time and blast radius
- Names both extremes as real failure modes
- Prefers directories over workspaces for environments
- Versions shared modules for gradual adoption
What sinks the answer
- One giant state
- Workspaces for environments with no caveat
- Reads remote state casually
- No module strategy for 40 similar services
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“A state file is [the unit of locking, plan time and blast radius]. One giant state gives [slow plans, lock contention, and a mistake can destroy unrelated production]. A state per resource gives [dependency spaghetti]. So split by [blast radius and change frequency: foundational networking separate, per-service states separate], use [directories not workspaces per environment], and [prefer data sources over reading remote state].”
Keep going with infrastructure as code
Foundation
What is infrastructure as code, and why is it better than clicking in a console?
Junior
What is Terraform state, why does it exist, and what goes wrong if two people apply at the same time?
Mid
Terraform plan wants to destroy a production database that someone modified manually. What do you do?
Senior
Design a CI/CD system for 15 microservices owned by 4 teams deploying several times a day.
Senior
Design an observability stack for a system where nobody can currently answer why a request was slow.
Senior
Leadership asks you to prove the platform investment is working. What do you measure?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free