TF-004 Use the core Terraform workflow Practice Question
A company uses Terraform workspaces to manage environments. They have a monorepo with separate configurations for each environment. They want to introduce a new team that will manage only the staging environment. The new team will run terraform commands only on the staging workspace. They are using a single S3 backend for all workspaces. The team is concerned about accidentally applying changes to other workspaces. What is the best way to restrict the team's access?
⚠ Common exam trap
Many candidates confuse IAM-based state file access control with workspace-level command restrictions, not realizing that Terraform commands are executed client-side and IAM cannot prevent a user from running `terraform apply` on a different workspace if they have the state file path and credentials.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use Terraform Cloud with team-based permissions.
Terraform Cloud provides native workspace-level permissions, allowing you to grant the new team access only to the staging workspace while preventing them from applying changes to other workspaces. This is the most secure and manageable approach, as it leverages Terraform Cloud's RBAC (Role-Based Access Control) to enforce separation of duties without modifying the backend configuration or relying on error-prone manual processes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a separate S3 bucket for staging and configure a different backend.
Why it's wrong here
Creating a separate S3 backend for staging does not prevent the team from accidentally targeting other workspaces if they still have access to the original backend’s state files; the team could simply run `terraform workspace select` on any workspace in the original bucket. This approach is tempting because isolating backends by environment is a common pattern for enforcing physical separation of state, which would be the correct choice if the goal were to prevent any cross-environment state access entirely.
- ✓
Use Terraform Cloud with team-based permissions.
Why this is correct
Terraform Cloud provides robust Role-Based Access Control (RBAC) capabilities, enabling granular permissions to be set at the workspace level. This allows administrators to define specific teams or users who can interact with, modify, or even view particular workspaces, such as a "staging" workspace. By enforcing these permissions, Terraform Cloud effectively prevents team members from accidentally or intentionally targeting production or other sensitive environments, as their access would be explicitly denied by the platform.
- ✗
Use terraform workspace select staging in the CI/CD pipeline and only allow that.
Why it's wrong here
While restricting the CI/CD pipeline to only use `terraform workspace select staging` ensures automated deployments target the correct environment, it does not prevent individual team members from executing `terraform workspace select` commands locally. A developer with access to the backend configuration could still inadvertently or intentionally switch to a different workspace (e.g., `production`) on their local machine and apply changes, bypassing the CI/CD's intended safeguards. This approach only controls the pipeline's behavior, not user behavior.
- ✗
Use IAM policies to restrict access to the state files of other workspaces.
Why it's wrong here
AWS IAM policies can effectively restrict access to specific S3 buckets or object prefixes, thereby controlling who can read or write Terraform state files. However, Terraform workspaces, when using an S3 backend, typically store their state files within the *same* S3 bucket, often under different prefixes (e.g., `env:/staging/terraform.tfstate`). IAM policies cannot inherently distinguish between these logical workspaces within a single bucket's scope for a user who already has access to the bucket. Therefore, while IAM can prevent access to the *entire* state bucket, it doesn't prevent a user with bucket access from running `terraform workspace select` and targeting a different workspace within that bucket.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.