Practice Terraform workspaces vocabulary: workspace-specific variable values, backends, environment separation, workspace listing, and context switching between environments.
0 / 14 completed
1 / 14
'The staging workspace has different variable values.' What is a Terraform workspace?
A Terraform workspace is an isolated state context. The same Terraform configuration can be run in multiple workspaces (dev, staging, prod) — each workspace has its own state file, so they manage independent infrastructure. Variable files or tfvars can be used to provide different values (instance sizes, replica counts, domain names) per workspace.
2 / 14
'Workspace-specific backends.' What does this mean in practice?
With remote backends (like S3), each workspace typically stores state in a separate location — for example s3://my-bucket/env/staging/terraform.tfstate vs s3://my-bucket/env/prod/terraform.tfstate. This ensures complete state isolation between environments, so a terraform apply in staging can never affect production state.
3 / 14
'We use workspaces for environment separation.' What is an alternative approach to workspaces for environment separation?
Many experienced Terraform users prefer separate directories per environment over workspaces — each environment has its own main.tf, tfvars, and remote state. This approach is more explicit (no risk of accidentally running against prod), easier to audit, and avoids workspace pitfalls like state isolation being less obvious. Workspaces work well for simple cases but separate-directory patterns scale better for large organisations.
4 / 14
'The workspace list shows dev/staging/prod.' What command shows available workspaces?
terraform workspace list shows all workspaces in the current backend configuration, with an asterisk indicating the active workspace. Example output: '* default\n dev\n staging\n prod' — the asterisk shows you're currently in default. This is a quick sanity check before running any terraform plan or apply to ensure you're targeting the correct environment.
5 / 14
'Switching workspaces changes the state context.' What is the risk of forgetting to switch workspaces?
Workspace context errors are a real operational risk. If an engineer means to apply changes to staging but is still in the prod workspace, terraform apply will make those changes to production. Best practices to mitigate this: always run terraform workspace show before applying, use CI/CD pipelines that explicitly set the workspace, add the workspace name to the shell prompt, and require manual confirmation for the prod workspace.
6 / 14
Sarah from the Dev team Slack channel asks: 'I'm deploying a new feature to staging but it's using my personal AWS credentials. I thought workspaces were supposed to isolate environments! What am I missing?'
Workspaces isolate environments by managing state and configuration separately. Terraform doesn't automatically inherit credentials; you must configure the backend to use a secure method like AWS IAM roles or access keys. The misconception here is assuming workspaces handle credential management automatically – it's a manual configuration step that needs careful attention, particularly when deploying to different environments.
7 / 14
Mark leaves this comment on a code review of a Terraform module: 'I'm seeing inconsistent resource creation across workspaces. This seems like a problem with variable scope.' What is the primary reason for this issue?
Variables within a Terraform workspace are designed to be specific to that environment. Without explicit scoping, a variable defined in one workspace would inadvertently affect another. This is why understanding and correctly configuring workspace-specific variables is crucial for reliable deployments across environments – it's about preventing accidental overrides.
8 / 14
David from the Infrastructure team sent this Slack message: 'Just ran `terraform apply` on my local dev workspace and it created a new S3 bucket named 'my-new-bucket'. But when I run the same command against the staging workspace, it doesn't create anything. What's going on?', What is likely the cause of this discrepancy?
This scenario highlights that workspaces isolate configurations. The primary reason for the difference lies in the configuration files themselves – each workspace uses its own specific settings and variables defined within its Terraform project. Options B and D are incorrect because Terraform doesn't generally manage bucket naming or automatically handle regional differences; option C is a misinterpretation of workspace priorities.
9 / 14
To ensure consistent variable definitions across workspaces, you should typically store your Terraform configuration files in a _________________________.
Using a remote state storage solution – such as AWS S3 or Azure Blob Storage – is the standard best practice. This allows all workspaces to access and modify the same Terraform state file, ensuring consistency and preventing duplicate resource creation. Storing configuration files locally would lead to synchronization issues.
10 / 14
During a standup meeting, Alex from the DevOps team says: 'We're using workspaces to manage different environments. It allows us to have separate state files for development, staging, and production.' What is the primary benefit of this approach compared to managing all configurations in a single Terraform project?
Workspaces provide independent state files for each environment. This isolation is crucial; without it, changes in one environment would directly impact others, leading to unpredictable and difficult-to-resolve conflicts. The core benefit lies in preventing these synchronization issues – a single project wouldn't offer this level of separation.
11 / 14
You're reviewing a PR that uses the `terraform workspace select` command. The commit message states: 'Switching workspaces changes the state context.' What does this mean in terms of Terraform's behavior?
'Changing the state context' refers to Terraform effectively 'forgetting' what it previously knew about the infrastructure. When you select a workspace, Terraform loads and applies *only* the configuration defined for that workspace – its state file is re-established based on the selected environment's settings. This is why it's vital to manage variables carefully.
12 / 14
Elena, a junior developer, is struggling to understand why her Terraform configuration isn't applying correctly. She's been using the same AWS credentials across different workspaces but getting errors related to permissions. What's the most likely reason for this issue?
Terraform relies on the AWS credentials provided to authenticate with AWS services. If those credentials lack the necessary permissions for the specific resources being created within a given workspace, you'll encounter permission errors during application. The other options represent fundamental aspects of Terraform or configuration issues, but not the root cause of this specific problem.
13 / 14
You are reviewing a Slack message from Ben, a developer who's trying to deploy a new feature to staging. He writes: 'I'm running `terraform plan` and it says I need to update the S3 bucket policy. But I didn't change anything! What's going on?' Considering workspaces and state files, what is the most probable explanation?
Workspaces use isolated state files. If a workspace's state file contains outdated or incorrect permissions (e.g., inherited from a previous deployment or a different environment), `terraform plan` will flag them as needing to be updated. This is because Terraform relies on the local state file to determine what changes are required.
14 / 14
Maria, a developer, is working on a new feature and needs to quickly test it in a staging environment. She wants to ensure that any changes she makes don't affect her development workspace. Which Terraform best practice should she follow?
Terraform workspaces are specifically designed to manage multiple environments independently. By creating separate state files for each workspace, changes made in one environment won't impact the others. This promotes collaboration and prevents accidental disruptions.
What does this Terraform Operations exercise cover?
This exercise, "Terraform Workspaces Vocabulary", tests your understanding of terraform operations vocabulary and phrasing through 14 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 14 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Terraform Operations exercise for?
It's designed for IT professionals and learners who want to sound natural discussing terraform operations topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Terraform Operations exercises?
Browse the full Terraform Operations exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.