Do Terraform workspaces isolate provider credentials for repeatable developer environments

Answer

No. Selecting a Terraform workspace does not isolate provider credentials. Workspaces isolate state, not provider configuration. The same provider blocks and configuration are evaluated for every workspace; only the state file path changes. Credential, region or account differences must be supplied via variables, and without explicit per-workspace variable loading the same values will be used across workspaces.

Confirmed facts

• Workspaces create a separate state file per workspace in a remote backend with locking. terraform workspace show changes the state target, not the configuration.
• Provider configuration is shared across workspaces. The provider plugin is initialized once per run with the values present at plan/apply time.
• If a provider block references input variables, e.g. access_key = var.aws_access_key, the provider will use whatever value the variable resolves to for that run. Workspace selection alone does not re-evaluate the provider.
• Backend configuration, including credentials needed to access the remote state store, is shared unless overridden with -backend-config or backend-specific variables. Workspaces do not create separate backend credentials.

Likely explanation for the uncertainty

It is common to assume workspaces provide per-developer isolation because state is isolated. In practice the configuration graph, provider schema and provider blocks are identical across workspaces. Variable defaults mask differences: if a variable has a default and no workspace-specific value is supplied, Terraform uses the default for every workspace, which can unintentionally leak the same credentials.

Variable loading that avoids credential leakage

Use workspace-scoped variable values and avoid defaults for secrets.

1. Do not hard-code credentials in provider blocks. Pass them via variables or environment variables only.
2. Name tfvars per workspace and load explicitly: terraform apply -var-file=dev.tfvars or terraform apply -var-file=terraform.tfvars.d/${TF_WORKSPACE}.tfvars. Terraform loads terraform.tfvars then terraform.tfvars.json then any *.auto.tfvars in terraform.tfvars.d in alphabetical order.
3. In CI or Terraform Cloud, use workspace variable sets per workspace instead of organization defaults. Set sensitive variables as sensitive and do not define defaults for them.
4. For local developer repeatability, export TF_VAR_* per developer or per branch and never commit them. Keep a *.example.tfvars with non-sensitive placeholders only.

When a variable default differs from a workspace-specific value, Terraform uses the workspace-specific value if it is supplied via the loading strategy above. If it is not supplied, the default is used for that run. There is no automatic detection of external drift and no automatic switching of provider credentials on workspace change.

Verification steps for this case

terraform workspace new dev
terraform workspace new feature-branch
# set different values for a provider-referenced variable
terraform plan -var-file=dev.tfvars
terraform workspace select feature-branch
terraform plan -var-file=feature-branch.tfvars

Check the plan output for the provider configuration and confirm state isolation with terraform state list after each switch.

Missing diagnostic detail: Are your provider credentials currently hard-coded in the provider block or referenced via variables / TF_VAR_? The recommended isolation strategy changes if credentials are hard-coded, because hard-coding makes them identical across all workspaces regardless of variable files.