In Terraform, what does a CLI workspace give you, and what actually changes when you run `terraform workspace select dev`?

## The one-sentence model A CLI workspace is a **named state file**, nothing more. One directory of `.tf` files, one backend, one set of provider credentials, and N independent states that the same configuration can be instantiated into. Switching workspaces swaps the state pointer, not the code. ## The commands ```bash terraform init # the backend must be initialized first terraform workspace list # default, dev (* marks the active one) terraform workspace new dev # creates an empty state AND selects it terraform workspace select dev # switches the active workspace terraform workspace show # prints just the active name terraform workspace delete dev # refuses while that state still has resources ``` `terraform workspace new` both creates and selects, which is why people are often surprised that their next `plan` shows every resource as new: they are planning against an empty state, not against the one they were just in. ## Where the state physically lands With the **local** backend the default workspace writes `terraform.tfstate` in the working directory, and every other workspace writes `terraform.tfstate.d/<workspace>/terraform.tfstate`. With the **S3** backend the default workspace uses the configured `key` unchanged, and non-default workspaces are prefixed: `env:/<workspace>/<key>`. The prefix is the `workspace_key_prefix` argument, whose default value is `env:`. So one bucket holds `prod/network.tfstate` for `default` and `env:/dev/prod/network.tfstate` for `dev`. Other backends have their own convention, but the principle holds: same backend configuration, different object path. ## What is shared, and why that matters later Because only the state path changes, everything else is shared across workspaces: - the backend block and therefore the bucket, table or server holding state; - the credentials the provider authenticates with; - the provider versions and modules already downloaded into `.terraform`, which is why switching does not require another `init`; - the configuration itself, so every workspace instantiates the *same* set of resources. The only legitimate way for two workspaces to differ is through **input values**: different `-var-file`s, different `TF_VAR_` environment variables, or expressions that branch on `terraform.workspace`. Terraform does not automatically load a `<workspace>.tfvars` file for you; if you want per-workspace inputs you pass them explicitly. ## The default workspace Every configuration has a workspace called `default` from the moment it is initialized. You never create it, you cannot delete it, and if you never run a workspace command you are silently working in it. That is why a fresh checkout on a CI runner — which has no local `.terraform/environment` file recording a selection — starts in `default`. ## Do not confuse it with an HCP Terraform workspace HCP Terraform (formerly Terraform Cloud) and Terraform Enterprise also call their units of work "workspaces", but those carry their own variables, run history, permissions and VCS connection. A CLI workspace carries none of that. Interviewers ask this deliberately, because candidates who have only used the SaaS product often describe features the CLI concept does not have. ## When it is the right tool The honest summary is: workspaces are good for *ephemeral or personal copies* of one stack in one account — a per-pull-request environment, a scratch copy while you test a refactor. They are a poor fit for prod-versus-staging separation, because sharing one backend, one credential set and one blast radius is exactly what real environment isolation is supposed to prevent.