Environments as workspaces in projects: variable sets and their precedence, workspace settings, remote state sharing, and policy sets scoped to environments.
Study it
Environments as workspaces in projects with variable sets
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
To keep every production workspace in eu-west-1, the platform team creates a priority variable set scoped to the production project that sets the Terraform variable aws_region. A week later, an engineer hard-codes region = "us-east-1" in a provider block, and the run deploys there. What else does the platform team need for strict enforcement?
AMake the variable set global instead of project-scoped to let eu-west-1 outrank everything
BMark the aws_region variable as sensitive to stop runs from changing it
CAdd a workspace-specific aws_region variable in each production workspace as a second layer
DA policy check or run task that rejects plans deploying outside eu-west-1
Show the answer and why
AMake the variable set global instead of project-scoped to let eu-west-1 outrank everything
Incorrect
A wider scope does not help; the configuration simply stopped using the variable.
BMark the aws_region variable as sensitive to stop runs from changing it
Incorrect
Sensitive only hides the value; it does not force the configuration to use it.
CAdd a workspace-specific aws_region variable in each production workspace as a second layer
Incorrect
A priority set already outranks workspace variables, and neither stops configuration from ignoring the variable.
DA policy check or run task that rejects plans deploying outside eu-west-1
Correct
Priority variable sets enforce values but cannot force configuration to use them; HashiCorp recommends policy checks or run tasks for stricter enforcement.
Priority variable sets win over more specific variables, but only for configurations that read the variable. Policy as code inspects the plan itself.
The app-prod workspace reads outputs from the net-prod workspace with terraform_remote_state, and its runs fail because app-prod cannot access net-prod's state. Both workspaces are in the prod project, and the fix must follow least privilege. Which two statements are correct? (Choose TWO.)
AAn organization API token added to the terraform_remote_state config in app-prod fixes the failure
BSharing net-prod's state with all workspaces in the organization is the least-privilege fix
CSelecting app-prod under net-prod's remote state sharing settings fixes the failure
DDuring HCP Terraform runs, app-prod's terraform_remote_state usually needs no API token in its config
ESwitching app-prod to local execution mode lets it read the state with an engineer's own token
Show the answer and why
AAn organization API token added to the terraform_remote_state config in app-prod fixes the failure
Incorrect
Credentials are not the missing piece, and an organization token would grant far more access than this read needs.
BSharing net-prod's state with all workspaces in the organization is the least-privilege fix
Incorrect
It works, but every workspace in the organization could then read the network state.
CSelecting app-prod under net-prod's remote state sharing settings fixes the failure
Correct
New workspaces share their state with no one by default; sharing can be granted to specific workspaces, which keeps access narrow.
DDuring HCP Terraform runs, app-prod's terraform_remote_state usually needs no API token in its config
Correct
HCP Terraform manages the API credentials for terraform_remote_state during the runs it manages, so access depends only on the sharing settings.
ESwitching app-prod to local execution mode lets it read the state with an engineer's own token
Incorrect
That moves runs onto engineers' machines and personal tokens instead of granting the workspace the access it needs.
Remote state sharing is off by default in HCP Terraform. Grant it to the specific consumers that need the outputs, and keep tokens out of the terraform_remote_state configuration.
A dev project auto-destroys inactive workspaces after seven days. A team keeps a demo workspace alive by running a speculative plan every morning, yet HCP Terraform destroys its infrastructure on schedule. Why?
ASpeculative plans count as activity only when they are queued from the UI
BAuto-destroy runs on a fixed calendar and ignores activity
COnly runs started by organization owners reset the timer
DInactivity means no state change, and speculative plans change none
Show the answer and why
ASpeculative plans count as activity only when they are queued from the UI
Incorrect
Activity is not judged by how a run is started.
BAuto-destroy runs on a fixed calendar and ignores activity
Incorrect
The schedule moves when a run updates the workspace's state.
COnly runs started by organization owners reset the timer
Incorrect
The documented measure of activity is a state change, not who started the run.
DInactivity means no state change, and speculative plans change none
Correct
A workspace is inactive when its state has not changed within the period, and only runs that update state delay the scheduled auto-destroy.
Only an apply that changes state, not a plan, pushes the auto-destroy schedule back.
Several projects contain workspaces tagged app:web. A configuration must use only the ones in the networking-development project. What goes in the cloud block?
Aproject = "networking-development" with the tags
BA second organization argument in the cloud block
CA workspace prefix
DNothing; tags are unique
Show the answer and why
Aproject = "networking-development" with the tags
Correct
The project argument limits matching to workspaces in that project that match the name or tags.
BA second organization argument in the cloud block
Incorrect
A cloud block names one organization.
CA workspace prefix
Incorrect
Selection uses name or tags, plus project.
DNothing; tags are unique
Incorrect
The same tags can appear in many projects.
Pair tags with project to keep each environment's workspaces apart.
An organization-owned set and a project-owned set are both scoped to the same workspaces and both set instance_type. Neither is a priority set. Which one wins?
AThe organization-owned set
BWhichever was attached first
CThe set that the project owns
DThe run fails on that conflict
Show the answer and why
AThe organization-owned set
Incorrect
Project-owned sets rank higher at the same scope.
BWhichever was attached first
Incorrect
Attachment order is not a factor.
CThe set that the project owns
Correct
Variable sets owned by projects take precedence over those owned by organizations.
DThe run fails on that conflict
Incorrect
Precedence resolves it.
Ownership lets project teams override organization defaults for their own workspaces.