A configuration uses CLI workspaces named dev and prod and builds resource names from the prefix app- followed by the interpolation of the current workspace name. Both workspaces store state in the same backend bucket, and engineers use the same cloud credentials for both. A security review asks whether this setup isolates production. What is the accurate assessment?
Select an answer to reveal the explanation.
Short Explanation
Think of CLI workspaces as labelled folders in one filing cabinet with one key. The labels keep your dev and prod papers apart, but anybody with the key opens both drawers. Real isolation needs separate cabinets and separate keys.
Full Explanation
A CLI workspace gives the same working directory and the same backend configuration a separate state snapshot, and terraform.workspace exposes the selected name so configuration can vary resource names or sizes. Nothing else changes when a workspace is selected: the backend bucket, its access policy, and the provider credentials are the same for every workspace. HashiCorp recommends other approaches for deployments that need separate credentials and access controls, which is what production isolation requires: separate backends or state locations with their own permissions, and separate credentials or roles per environment, for example distinct HCP Terraform workspaces with their own variables and team access. Workspaces do not attach their own backend policy or credentials. Interpolating the workspace name into resource names only prevents name collisions; any engineer can run terraform workspace select prod and plan or apply. TF_WORKSPACE simply selects a workspace through the environment; it locks nothing for other users. Exam caveat: HCP Terraform workspaces are a different concept from CLI workspaces and do support per-workspace permissions and variables. Operational check: list who can read and write each environment's state path and which identity each run uses.