Terraform · Infrastructure as code

When should you use Terraform workspaces?

MediumworkspacesisolationenvironmentsUpdated Oct 2026
Quiz this track

Short answer

Workspaces create multiple named states from one configuration. They suit short-lived or lightly separated environments, but they are weak isolation for production because all workspaces share credentials and code.

A workspace is a named state inside the same backend and configuration. terraform workspace select switches the active one, and terraform.workspace exposes the name to expressions. All workspaces still run the same code with the same provider credentials.

hcl
resource "aws_s3_bucket" "logs" {
  bucket = "acme-logs"

  tags = {
    environment = terraform.workspace
  }
}
The workspace name is available as a value, but bucket names must still be globally unique.

Good and bad fits

  • Good: temporary review environments, per-developer sandboxes, feature testing
  • Good: identical stacks that differ only by a few inputs
  • Bad: production isolation, where a mistaken workspace selection can target prod
  • Bad: environments with different accounts, regions or compliance controls

For production, prefer a separate directory or repository per environment, backed by a separate account and state. That makes the target explicit and lets IAM, approvals and state access differ by environment. Workspaces are convenient, but convenience is not the same as a security boundary.

A common accident is running apply in the wrong workspace. Name workspaces clearly, show the workspace in CI logs, and require explicit selection for production.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1What is shared between workspaces?
  2. 2Why are workspaces a weak production boundary?
  3. 3How do you avoid applying to the wrong workspace?
  4. 4When is a directory per environment better?

Say it in the interview

Workspaces give one configuration several named states. They are useful for temporary review environments or sandboxes where the code and credentials are effectively the same. I do not use them as a production boundary, because a wrong workspace selection can hit prod and every workspace shares the same backend access. For production I prefer separate directories, accounts and state.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Terraform mock interview and get scored feedback on depth, clarity and confidence.