Which open source Terraform feature allows you to manage multiple state files for different environments while keeping them linked to the same configuration?

Which open source Terraform feature allows you to manage multiple state files for different environments while keeping them linked to the same configuration?

• A. Terraform workspaces
• B. Terraform data sources
• C. Terraform local values
• D. Terraform modules

Answer: (A)

Workspaces let you keep separate state files for the same set of configuration files, one state per environment. This means you can have dev, staging, and prod all using the same Terraform code, but each environment has its own distinct state so changes in one don’t impact the others. When you start, you create or switch to a workspace (for example, a workspace named dev). Each workspace has its own state file stored by the backend, and the plan and apply operations you run while a particular workspace is selected will affect only that workspace’s resources. The default workspace is called default, and you switch between them with Terraform’s workspace commands. If you’re using a remote backend, Terraform handles maintaining separate state per workspace there as well. This approach is convenient because it avoids duplicating configuration files and you don’t need separate Terraform projects for each environment. It keeps environments linked to the same configuration, while the state is isolated per environment so you can test changes safely in one workspace before promoting them. Data sources, local values, and modules serve different roles. Data sources are for reading external data into configurations, local values are fixed values computed locally, and modules package reusable pieces of configuration. None of these inherently manage multiple environment state files the way workspaces do.

Workspaces let you keep separate state files for the same set of configuration files, one state per environment. This means you can have dev, staging, and prod all using the same Terraform code, but each environment has its own distinct state so changes in one don’t impact the others.

When you start, you create or switch to a workspace (for example, a workspace named dev). Each workspace has its own state file stored by the backend, and the plan and apply operations you run while a particular workspace is selected will affect only that workspace’s resources. The default workspace is called default, and you switch between them with Terraform’s workspace commands. If you’re using a remote backend, Terraform handles maintaining separate state per workspace there as well.

This approach is convenient because it avoids duplicating configuration files and you don’t need separate Terraform projects for each environment. It keeps environments linked to the same configuration, while the state is isolated per environment so you can test changes safely in one workspace before promoting them.

Data sources, local values, and modules serve different roles. Data sources are for reading external data into configurations, local values are fixed values computed locally, and modules package reusable pieces of configuration. None of these inherently manage multiple environment state files the way workspaces do.