{"id":1245,"date":"2026-10-15T10:17:32","date_gmt":"2026-10-15T10:17:32","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1245"},"modified":"2026-10-15T10:22:55","modified_gmt":"2026-10-15T10:22:55","slug":"hcp-terraform-cloud-cli-complete-master-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/hcp-terraform-cloud-cli-complete-master-tutorial\/","title":{"rendered":"HCP Terraform Cloud CLI \u2014 Complete Master Tutorial"},"content":{"rendered":"\n

HCP Terraform Cloud \u2014 CLI Command Summary<\/h2>\n\n\n\n

Organization: motoshare<\/code> | Project: proezi<\/code><\/p>\n\n\n\n

#<\/th>Cloud operation<\/th>Command \/ Example<\/th>Usage<\/th><\/tr>
1<\/td>Login to Terraform Cloud<\/td>terraform login<\/code><\/td>Authenticate with HCP Terraform<\/td><\/tr>
2<\/td>Login to specific hostname<\/td>terraform login app.terraform.io<\/code><\/td>Authenticate explicitly with Terraform Cloud<\/td><\/tr>
3<\/td>Logout<\/td>terraform logout<\/code><\/td>Remove locally saved credentials<\/td><\/tr>
4<\/td>Authenticate using token<\/td>export TF_TOKEN_app_terraform_io=\"$TFC_TOKEN\"<\/code><\/td>Authenticate from CI\/CD without interactive login<\/td><\/tr>
5<\/td>Set Cloud organization<\/td>export TF_CLOUD_ORGANIZATION=motoshare<\/code><\/td>Configure organization when omitted from the cloud<\/code> block<\/td><\/tr>
6<\/td>Set Cloud project<\/td>export TF_CLOUD_PROJECT=proezi<\/code><\/td>Configure project when omitted from the cloud<\/code> block<\/td><\/tr>
7<\/td>Set Cloud workspace<\/td>export TF_WORKSPACE=proezi_dev<\/code><\/td>Select an existing workspace when cloud configuration permits<\/td><\/tr>
8<\/td>Connect to Terraform Cloud<\/td>terraform init<\/code><\/td>Initialize the cloud<\/code> block and connect the working directory<\/td><\/tr>
9<\/td>Migrate existing state to Cloud<\/td>terraform init -migrate-state<\/code><\/td>Migrate state from an existing backend to HCP Terraform<\/td><\/tr>
10<\/td>List connected Cloud workspaces<\/td>terraform workspace list<\/code><\/td>List workspaces mapped by the current cloud configuration<\/td><\/tr>
11<\/td>Show selected Cloud workspace<\/td>terraform workspace show<\/code><\/td>Identify the active workspace<\/td><\/tr>
12<\/td>Switch to Dev workspace<\/td>terraform workspace select proezi_dev<\/code><\/td>Select Dev when using a tag-based workspace configuration<\/td><\/tr>
13<\/td>Switch to Stage workspace<\/td>terraform workspace select proezi_stage<\/code><\/td>Select Stage when using a tag-based configuration<\/td><\/tr>
14<\/td>Switch to Prod workspace<\/td>terraform workspace select proezi_prod<\/code><\/td>Select Prod when using a tag-based configuration<\/td><\/tr>
15<\/td>Trigger remote Cloud plan<\/td>terraform plan<\/code><\/td>Execute a speculative plan in HCP Terraform<\/td><\/tr>
16<\/td>Trigger remote Cloud apply<\/td>terraform apply<\/code><\/td>Start a remote plan\/apply run in a CLI-driven workspace<\/td><\/tr>
17<\/td>Save remote Cloud plan<\/td>terraform plan -out=cloud.tfplan<\/code><\/td>Save a remote run for later review and approval<\/td><\/tr>
18<\/td>Inspect remote Cloud plan<\/td>terraform show cloud.tfplan<\/code><\/td>Review the saved remote plan<\/td><\/tr>
19<\/td>Apply saved remote plan<\/td>terraform apply cloud.tfplan<\/code><\/td>Apply the saved run in its originating workspace<\/td><\/tr>
20<\/td>Inspect Cloud remote state<\/td>terraform state list<\/code><\/td>List resources tracked in HCP Terraform state<\/td><\/tr>
21<\/td>Download Cloud remote state<\/td>terraform state pull<\/code><\/td>Retrieve the workspace’s current state document<\/td><\/tr>
22<\/td>Read Cloud outputs<\/td>terraform output<\/code><\/td>Read output values from the connected HCP workspace<\/td><\/tr>
23<\/td>Trigger remote destroy<\/td>terraform destroy<\/code><\/td>Destroy tracked infrastructure in a CLI-driven workspace; destructive<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Beginner \u2192 Advanced | Practical Examples | Hands-on Labs | Real Organization & Workspaces | Updated October 2026<\/p>\n\n\n\n

This guide explains how to operate HCP Terraform (formerly Terraform Cloud) from the command line, using your actual organization and workspace names.<\/p>\n\n\n\n

You’ll learn how to authenticate, connect Terraform code to cloud workspaces, execute plans and applies, manage variables, inspect remote state, troubleshoot failures, and automate Terraform operations.<\/p>\n\n\n\n

1. Your HCP Terraform environment<\/h2>\n\n\n\n

Organization: motoshare<\/a><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

These are the workspace names you supplied. I have not inspected their private settings or state, so the examples will distinguish configuration assumptions from confirmed details.<\/p>\n\n\n\n

2. Understand Terraform CLI vs Terraform Cloud API<\/h2>\n\n\n\n

This is the most important distinction.<\/p>\n\n\n\n

Interface<\/th>Purpose<\/th>Example<\/th><\/tr>
Terraform CLI<\/td>Plan, apply, validate, and manage infrastructure<\/td>terraform plan<\/code><\/td><\/tr>
HCP Terraform CLI-driven workflow<\/td>Execute Terraform CLI operations using an HCP Terraform workspace<\/td>terraform apply<\/code> with a cloud<\/code> block<\/td><\/tr>
HCP Terraform REST API<\/td>Manage organizations, projects, workspaces, variables, and runs programmatically<\/td>curl ...\/api\/v2\/...<\/code><\/td><\/tr>
HCP Terraform UI<\/td>Configure workspaces, teams, permissions, variables, and review runs<\/td>app.terraform.io<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

There is no general built-in terraform cloud<\/code> command that administers every HCP Terraform resource. You use the normal Terraform CLI for infrastructure, and the API or the hashicorp\/tfe<\/code> provider for broader platform administration.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

With Remote Execution, plans and applies run on HCP Terraform workers, and the results stream to your terminal. With Local Execution, Terraform runs on your computer while HCP Terraform stores the state.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

HashiCorp Developer<\/p>\n\n\n\n

+1<\/p>\n\n\n\n

3. Prerequisites and installation<\/h2>\n\n\n\n

You’ll need Terraform CLI, an HCP Terraform account with access to motoshare<\/code>, and a terminal. For API demonstrations, install curl<\/code> and jq<\/code>.<\/p>\n\n\n\n

3.1 Install Terraform CLI on macOS<\/h3>\n\n\n\n
brew tap hashicorp\/tap\nbrew install hashicorp\/tap\/terraform<\/code><\/pre>\n\n\n\n
Verify the installation:<\/p>\n\n\n\n
terraform version<\/code><\/pre>\n\n\n\n
To explore the commands available in your installed version:<\/p>\n\n\n\n
terraform -help\nterraform init -help\nterraform plan -help\nterraform workspace -help<\/code><\/pre>\n\n\n\n
Usage: The -help<\/code> option is especially useful because command flags and features can change between Terraform versions.<\/p>\n\n\n\n
3.2 Log in to Terraform Cloud<\/h3>\n\n\n\n
terraform login<\/code><\/pre>\n\n\n\n
You can also specify the hostname:<\/p>\n\n\n\n
terraform login app.terraform.io<\/code><\/pre>\n\n\n\n
Terraform opens an authentication flow for creating and saving an HCP Terraform user token.<\/p>\n\n\n\n
After logging in, the CLI can access workspaces your identity is authorized to use.<\/p>\n\n\n\n
3.3 Where are credentials stored?<\/h3>\n\n\n\n
On macOS and Linux, the default login credentials are stored at:<\/p>\n\n\n\n
~\/.terraform.d\/credentials.tfrc.json<\/code><\/pre>\n\n\n\n
The token is stored as readable text, so protect that file and never commit it to Git.<\/p>\n\n\n\n
To remove locally stored login credentials:<\/p>\n\n\n\n
terraform logout<\/code><\/pre>\n\n\n\n
This removes the local credential but does not revoke the token on the server.<\/p>\n\n\n\n
\"\"\/<\/figure>\n\n\n\n
HashiCorp Developer<\/p>\n\n\n\n
+1<\/p>\n\n\n\n
3.4 Authenticate in CI\/CD without interactive login<\/h3>\n\n\n\n
For a CI\/CD job, you can provide the token through a protected environment variable:<\/p>\n\n\n\n
export TF_TOKEN_app_terraform_io=\"$TFC_TOKEN\"<\/code><\/pre>\n\n\n\n
Here, TFC_TOKEN<\/code> represents a token securely injected into the job by your CI secrets manager.<\/p>\n\n\n\n
Avoid hardcoding the token in Terraform files, shell scripts, or GitHub repositories.<\/p>\n\n\n\n
4. Connect your Terraform CLI to an existing workspace<\/h2>\n\n\n\n
We’ll use your proezi_dev<\/code> workspace for this example.<\/p>\n\n\n\n
Step 1: Create a working directory<\/h3>\n\n\n\n
mkdir -p ~\/terraform-training\/proezi-dev\ncd ~\/terraform-training\/proezi-dev<\/code><\/pre>\n\n\n\n
Step 2: Create cloud.tf<\/code><\/h3>\n\n\n\n
terraform {\n  required_version = \">= 1.6.0\"\n\n  cloud {\n    organization = \"motoshare\"\n\n    workspaces {\n      name    = \"proezi_dev\"\n      project = \"proezi\"\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
What each setting does:<\/p>\n\n\n\n
Setting<\/th>Purpose<\/th><\/tr>
required_version<\/code><\/td>Enforces Terraform CLI version compatibility<\/td><\/tr>
cloud<\/code><\/td>Enables HCP Terraform integration<\/td><\/tr>
organization<\/code><\/td>Selects the motoshare<\/code> organization<\/td><\/tr>
workspaces.name<\/code><\/td>Targets proezi_dev<\/code><\/td><\/tr>
workspaces.project<\/code><\/td>Associates the workspace with project proezi<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
You don’t need to configure a separate backend \"remote\"<\/code> block when using cloud<\/code>. Terraform does not allow both together.<\/p>\n\n\n\n
\"\"\/<\/figure>\n\n\n\n
HashiCorp Developer<\/p>\n\n\n\n
Step 3: Initialize<\/h3>\n\n\n\n
terraform init<\/code><\/pre>\n\n\n\n
This connects the working directory to your HCP Terraform workspace, initializes providers and modules as needed, and prepares the state backend.<\/p>\n\n\n\n
Typical successful output:<\/p>\n\n\n\n
Initializing HCP Terraform...\n\nHCP Terraform has been successfully initialized!\n\nTerraform has been successfully initialized!<\/code><\/pre>\n\n\n\n
Step 4: Inspect existing infrastructure state<\/h3>\n\n\n\n
These are read-only commands:<\/p>\n\n\n\n
terraform state list\nterraform output<\/code><\/pre>\n\n\n\n
The first command lists resource addresses recorded in the workspace state. The second displays root-module output values, if any.<\/p>\n\n\n\n
Important: Do not run terraform plan<\/code>, terraform apply<\/code>, or terraform destroy<\/code> against this empty example directory if proezi_dev<\/code> already manages real infrastructure. Missing resource definitions could cause Terraform to propose destroying existing resources.<\/p>\n\n\n\n
This section is only for establishing connectivity and inspecting state.<\/p>\n\n\n\n
5. Hands-on lab \u2014 Your first CLI-driven Terraform Cloud run<\/h2>\n\n\n\n
For actual experimentation, I recommend creating a separate workspace, proezi_cli_lab<\/code>, inside the proezi<\/code> project. This keeps your real Dev, Stage, and Prod infrastructure untouched.<\/p>\n\n\n\n
The exercise uses Terraform’s built-in terraform_data<\/code> resource, so it doesn’t require AWS, Azure, or other cloud provider credentials and won’t provision external infrastructure.<\/p>\n\n\n\n
5.1 Prepare the lab directory<\/h3>\n\n\n\n
mkdir -p ~\/terraform-training\/proezi-cli-lab\ncd ~\/terraform-training\/proezi-cli-lab<\/code><\/pre>\n\n\n\n
Create these files:<\/p>\n\n\n\n
proezi-cli-lab\/\n\u251c\u2500\u2500 cloud.tf\n\u251c\u2500\u2500 variables.tf\n\u251c\u2500\u2500 main.tf\n\u251c\u2500\u2500 outputs.tf\n\u2514\u2500\u2500 lab.auto.tfvars<\/code><\/pre>\n\n\n\n
5.2 File 1 \u2014 cloud.tf<\/code><\/h3>\n\n\n\n
terraform {\n  required_version = \">= 1.6.0\"\n\n  cloud {\n    organization = \"motoshare\"\n\n    workspaces {\n      name    = \"proezi_cli_lab\"\n      project = \"proezi\"\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
When terraform init<\/code> encounters a named workspace that doesn’t exist, it can create the workspace automatically, subject to your permissions. Verify the new workspace’s settings before its first run.<\/p>\n\n\n\n
\"\"\/<\/figure>\n\n\n\n
HashiCorp Developer<\/p>\n\n\n\n
5.3 File 2 \u2014 variables.tf<\/code><\/h3>\n\n\n\n
variable \"app_name\" {\n  description = \"Application name\"\n  type        = string\n  default     = \"proezi\"\n}\n\nvariable \"environment\" {\n  description = \"Deployment environment\"\n  type        = string\n  default     = \"lab\"\n}\n\nvariable \"replicas\" {\n  description = \"Desired replica count\"\n  type        = number\n  default     = 1\n\n  validation {\n    condition     = var.replicas >= 1\n    error_message = \"Replicas must be at least 1.\"\n  }\n}<\/code><\/pre>\n\n\n\n
5.4 File 3 \u2014 main.tf<\/code><\/h3>\n\n\n\n
resource \"terraform_data\" \"application\" {\n  input = {\n    name        = var.app_name\n    environment = var.environment\n    replicas    = var.replicas\n  }\n}<\/code><\/pre>\n\n\n\n
terraform_data<\/code> is useful for learning Terraform operations without provisioning a real virtual machine, network, or database.<\/p>\n\n\n\n
5.5 File 4 \u2014 outputs.tf<\/code><\/h3>\n\n\n\n
output \"application_details\" {\n  description = \"Application configuration\"\n\n  value = terraform_data.application.output\n}\n\noutput \"environment_name\" {\n  value = var.environment\n}<\/code><\/pre>\n\n\n\n
5.6 File 5 \u2014 lab.auto.tfvars<\/code><\/h3>\n\n\n\n
app_name    = \"proezi\"\nenvironment = \"lab\"\nreplicas    = 2<\/code><\/pre>\n\n\n\n
Terraform automatically loads files ending in .auto.tfvars<\/code>.<\/p>\n\n\n\n
5.7 Execute the full CLI workflow<\/h3>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Run the commands:<\/p>\n\n\n\n
terraform init\n\nterraform fmt\n\nterraform validate\n\nterraform plan<\/code><\/pre>\n\n\n\n
Since this is a new lab workspace, the plan should propose creating one terraform_data.application<\/code> resource, assuming no existing lab state or policies prevent the run.<\/p>\n\n\n\n
Apply the configuration:<\/p>\n\n\n\n
terraform apply<\/code><\/pre>\n\n\n\n
Review the plan and type:<\/p>\n\n\n\n
yes<\/code><\/pre>\n\n\n\n
The apply runs in HCP Terraform when the workspace uses Remote Execution. You can view its history in:<\/p>\n\n\n\n
Open proezi_cli_lab<\/a>This link targets the proposed lab workspace, which will exist only after you create it.<\/p>\n\n\n\n
Now inspect the output:<\/p>\n\n\n\n
terraform output\nterraform output environment_name\nterraform output -json<\/code><\/pre>\n\n\n\n
Expected environment_name<\/code>:<\/p>\n\n\n\n
\"lab\"<\/code><\/pre>\n\n\n\n
5.8 Update a variable and rerun<\/h3>\n\n\n\n
Edit lab.auto.tfvars<\/code>:<\/p>\n\n\n\n
replicas = 3<\/code><\/pre>\n\n\n\n
Run:<\/p>\n\n\n\n
terraform plan\nterraform apply<\/code><\/pre>\n\n\n\n
Terraform should show an in-place change to the lab’s stored data resource, rather than creating real servers.<\/p>\n\n\n\n
Learning outcome: You’ve completed a CLI-driven remote run, created state in HCP Terraform, updated configuration, and inspected outputs.<\/p>\n\n\n\n
6. Master Terraform CLI command reference<\/h2>\n\n\n\n
The commands below work in ordinary Terraform configurations. When you connect a directory to HCP Terraform, their behavior depends on the workspace’s execution mode and workflow settings.<\/p>\n\n\n\n
6.1 Setup, authentication, and initialization<\/h3>\n\n\n\n
Command<\/th>Example<\/th>Usage<\/th><\/tr>
version<\/code><\/td>terraform version<\/code><\/td>Display CLI and provider versions<\/td><\/tr>
-help<\/code><\/td>terraform plan -help<\/code><\/td>Show options and syntax<\/td><\/tr>
login<\/code><\/td>terraform login<\/code><\/td>Authenticate with HCP Terraform<\/td><\/tr>
logout<\/code><\/td>terraform logout<\/code><\/td>Remove local authentication token<\/td><\/tr>
init<\/code><\/td>terraform init<\/code><\/td>Initialize providers, modules, and cloud connection<\/td><\/tr>
init -upgrade<\/code><\/td>terraform init -upgrade<\/code><\/td>Upgrade selected providers\/modules within configured constraints<\/td><\/tr>
init -reconfigure<\/code><\/td>terraform init -reconfigure<\/code><\/td>Reconfigure backend or cloud connection without attempting state migration<\/td><\/tr>
init -migrate-state<\/code><\/td>terraform init -migrate-state<\/code><\/td>Migrate existing state when intentionally changing its storage configuration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Use -migrate-state<\/code> only after reviewing the source and destination state and taking appropriate backups.<\/p>\n\n\n\n
6.2 Code validation and planning<\/h3>\n\n\n\n
Command<\/th>Example<\/th>Usage<\/th><\/tr>
fmt<\/code><\/td>terraform fmt<\/code><\/td>Format HCL files<\/td><\/tr>
fmt -check<\/code><\/td>terraform fmt -check -recursive<\/code><\/td>Check formatting without rewriting files<\/td><\/tr>
validate<\/code><\/td>terraform validate<\/code><\/td>Verify configuration syntax and structural validity<\/td><\/tr>
plan<\/code><\/td>terraform plan<\/code><\/td>Preview infrastructure changes<\/td><\/tr>
plan -var<\/code><\/td>terraform plan -var='replicas=3'<\/code><\/td>Supply a run-specific Terraform variable<\/td><\/tr>
plan -var-file<\/code><\/td>terraform plan -var-file=dev.tfvars<\/code><\/td>Load variable values from a selected file<\/td><\/tr>
plan -out<\/code><\/td>terraform plan -out=review.tfplan<\/code><\/td>Save a plan for later inspection\/apply<\/td><\/tr>
plan -detailed-exitcode<\/code><\/td>terraform plan -detailed-exitcode<\/code><\/td>Indicate whether changes are needed via exit status<\/td><\/tr>
plan -refresh-only<\/code><\/td>terraform plan -refresh-only<\/code><\/td>Inspect state updates based on real infrastructure<\/td><\/tr>
plan -replace<\/code><\/td>terraform plan -replace=aws_instance.web<\/code><\/td>Preview replacement of a specific resource<\/td><\/tr>
plan -target<\/code><\/td>terraform plan -target=aws_instance.web<\/code><\/td>Target a resource for exceptional recovery or repair<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
-target<\/code> and -replace<\/code> are not normal deployment practices. Use them only when their behavior is understood and justified.<\/p>\n\n\n\n
6.3 Applying and managing infrastructure<\/h3>\n\n\n\n
Command<\/th>Example<\/th>Usage<\/th><\/tr>
apply<\/code><\/td>terraform apply<\/code><\/td>Plan and apply changes<\/td><\/tr>
apply -auto-approve<\/code><\/td>terraform apply -auto-approve<\/code><\/td>Skip interactive approval; suitable only for properly controlled automation<\/td><\/tr>
apply FILE<\/code><\/td>terraform apply review.tfplan<\/code><\/td>Apply a previously saved plan<\/td><\/tr>
apply -refresh-only<\/code><\/td>terraform apply -refresh-only<\/code><\/td>Update state and outputs without normal infrastructure reconciliation<\/td><\/tr>
destroy<\/code><\/td>terraform destroy<\/code><\/td>Destroy all resources managed by the selected configuration\/state<\/td><\/tr>
destroy -target<\/code><\/td>terraform destroy -target=aws_instance.web<\/code><\/td>Target a subset for destruction; exceptional use only<\/td><\/tr>
show<\/code><\/td>terraform show<\/code><\/td>Display state information<\/td><\/tr>
show FILE<\/code><\/td>terraform show review.tfplan<\/code><\/td>Display the contents of a saved plan<\/td><\/tr>
output<\/code><\/td>terraform output<\/code><\/td>Show root-module output values<\/td><\/tr>
output -json<\/code><\/td>terraform output -json<\/code><\/td>Export output values in JSON<\/td><\/tr>
output -raw<\/code><\/td>terraform output -raw environment_name<\/code><\/td>Get a string output without quotes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
6.4 Terraform state operations<\/h3>\n\n\n\n
Command<\/th>Example<\/th>Usage<\/th><\/tr>
state list<\/code><\/td>terraform state list<\/code><\/td>List tracked resources<\/td><\/tr>
state show<\/code><\/td>terraform state show terraform_data.application<\/code><\/td>Inspect one tracked resource<\/td><\/tr>
state pull<\/code><\/td>terraform state pull<\/code><\/td>Retrieve the current state document<\/td><\/tr>
state mv<\/code><\/td>terraform state mv OLD NEW<\/code><\/td>Change a resource address in state<\/td><\/tr>
state rm<\/code><\/td>terraform state rm ADDRESS<\/code><\/td>Stop tracking a resource without deleting it<\/td><\/tr>
state replace-provider<\/code><\/td>terraform state replace-provider OLD NEW<\/code><\/td>Change provider addresses stored in state<\/td><\/tr>
import<\/code><\/td>terraform import ADDRESS ID<\/code><\/td>Bring an existing remote resource under Terraform state management<\/td><\/tr>
force-unlock<\/code><\/td>terraform force-unlock LOCK_ID<\/code><\/td>Manually release a state lock where supported by the backend<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
State-changing commands require special care because incorrect changes can cause future Terraform plans to replace or destroy infrastructure. Terraform state subcommands support remote state, and state modification commands write local backups.<\/p>\n\n\n\n
6.5 Workspaces, modules, testing, and debugging<\/h3>\n\n\n\n
Command<\/th>Example<\/th>Usage<\/th><\/tr>
workspace list<\/code><\/td>terraform workspace list<\/code><\/td>List workspaces available through the configuration<\/td><\/tr>
workspace select<\/code><\/td>terraform workspace select proezi_dev<\/code><\/td>Select a different workspace, when supported<\/td><\/tr>
workspace show<\/code><\/td>terraform workspace show<\/code><\/td>Display the selected CLI workspace<\/td><\/tr>
workspace new<\/code><\/td>terraform workspace new demo<\/code><\/td>Create a workspace, where supported<\/td><\/tr>
workspace delete<\/code><\/td>terraform workspace delete demo<\/code><\/td>Delete an eligible workspace; destructive administrative action<\/td><\/tr>
providers<\/code><\/td>terraform providers<\/code><\/td>Display required provider dependencies<\/td><\/tr>
get<\/code><\/td>terraform get<\/code><\/td>Download modules; generally prefer terraform init<\/code><\/td><\/tr>
console<\/code><\/td>terraform console<\/code><\/td>Interactively test HCL expressions<\/td><\/tr>
graph<\/code><\/td>terraform graph<\/code><\/td>Generate dependency-graph output<\/td><\/tr>
test<\/code><\/td>terraform test<\/code><\/td>Execute Terraform test files<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Important workspace limitation: terraform workspace select<\/code> is not the way to switch between workspaces when your cloud<\/code> block specifies a fixed workspaces.name<\/code>. Section 9 explains supported workspace-selection methods.<\/p>\n\n\n\n
7. Planning and applying \u2014 Detailed examples<\/h2>\n\n\n\n
These exercises use the separate proezi_cli_lab<\/code> workspace created in Section 5.<\/p>\n\n\n\n
7.1 Example: Standard remote plan<\/h3>\n\n\n\n
terraform plan<\/code><\/pre>\n\n\n\n
When to use: Before every infrastructure change.<\/p>\n\n\n\n
With a remote-execution workspace, this creates a speculative plan using your local Terraform files and the remote workspace context.<\/p>\n\n\n\n
A speculative plan can show potential changes, but cannot subsequently be applied directly.<\/p>\n\n\n\n
\"\"\/<\/figure>\n\n\n\n
HashiCorp Developer<\/p>\n\n\n\n
7.2 Example: Pass a variable directly<\/h3>\n\n\n\n
terraform plan -var=\"replicas=4\"<\/code><\/pre>\n\n\n\n
When to use: Temporarily override a Terraform input variable for a single run.<\/p>\n\n\n\n
The CLI value does not permanently change the stored workspace variable.<\/p>\n\n\n\n
7.3 Example: Use an explicit variable file<\/h3>\n\n\n\n
Create dev.tfvars<\/code>:<\/p>\n\n\n\n
app_name    = \"proezi\"\nenvironment = \"development\"\nreplicas    = 2<\/code><\/pre>\n\n\n\n
Execute:<\/p>\n\n\n\n
terraform plan -var-file=\"dev.tfvars\"<\/code><\/pre>\n\n\n\n
When to use: You want reusable environment-specific values without hardcoding everything into .tf<\/code> resources.<\/p>\n\n\n\n
7.4 Example: Check if a deployment is needed<\/h3>\n\n\n\n
terraform plan -detailed-exitcode\necho $?<\/code><\/pre>\n\n\n\n
Exit codes:<\/p>\n\n\n\n
Code<\/th>Meaning<\/th><\/tr>
0<\/code><\/td>Plan succeeded; no changes<\/td><\/tr>
1<\/code><\/td>An error occurred<\/td><\/tr>
2<\/code><\/td>Plan succeeded; changes are proposed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
This is helpful in CI\/CD pipelines that need to distinguish infrastructure drift or new changes from errors.<\/p>\n\n\n\n
7.5 Example: Save, review, and apply a plan<\/h3>\n\n\n\n
terraform plan -out=review.tfplan<\/code><\/pre>\n\n\n\n
Inspect:<\/p>\n\n\n\n
terraform show review.tfplan<\/code><\/pre>\n\n\n\n
Apply:<\/p>\n\n\n\n
terraform apply review.tfplan<\/code><\/pre>\n\n\n\n
For remote CLI-driven runs, this requires Terraform CLI 1.6 or later.<\/p>\n\n\n\n
HCP Terraform’s remote saved-plan file is a reference to a remote run, not an ordinary local binary plan. It can only be applied in the originating remote workspace, and it becomes stale if the underlying state is no longer valid.<\/p>\n\n\n\n
7.6 Example: Use automation approval<\/h3>\n\n\n\n
terraform apply -auto-approve<\/code><\/pre>\n\n\n\n
When to use: Only in approved automation where plan review, change controls, and workspace permissions are already established.<\/p>\n\n\n\n
Do not use this as a shortcut for deploying into proezi_prod<\/code>.<\/p>\n\n\n\n
7.7 Example: Inspect a plan in JSON<\/h3>\n\n\n\n
For a remote saved plan:<\/p>\n\n\n\n
terraform show -json review.tfplan<\/code><\/pre>\n\n\n\n
Unlike the human-readable plan, JSON can contain sensitive values in unredacted form. HCP Terraform requires workspace admin permission to inspect a remote saved plan in JSON. Store such output securely.<\/p>\n\n\n\n
7.8 Example: Refresh state<\/h3>\n\n\n\n
terraform plan -refresh-only<\/code><\/pre>\n\n\n\n
This previews how state would change to reflect infrastructure modified outside Terraform.<\/p>\n\n\n\n
To commit a refresh-only operation:<\/p>\n\n\n\n
terraform apply -refresh-only<\/code><\/pre>\n\n\n\n
This does not perform ordinary desired-state reconciliation. It updates Terraform’s recorded view of existing infrastructure and outputs.<\/p>\n\n\n\n
8. Terraform Cloud variables through CLI<\/h2>\n\n\n\n
HCP Terraform variables are especially important because they can be defined at multiple scopes.<\/p>\n\n\n\n
8.1 Common ways to provide variable values<\/h3>\n\n\n\n
Method<\/th>Example<\/th>Where the value comes from<\/th><\/tr>
Variable default<\/td>default = 2<\/code><\/td>Terraform configuration<\/td><\/tr>
Automatic .tfvars<\/code><\/td>lab.auto.tfvars<\/code><\/td>Configuration files<\/td><\/tr>
Explicit .tfvars<\/code><\/td>-var-file=dev.tfvars<\/code><\/td>Command line<\/td><\/tr>
CLI argument<\/td>-var='replicas=4'<\/code><\/td>Command line<\/td><\/tr>
Local shell<\/td>TF_VAR_replicas=4<\/code><\/td>Your terminal<\/td><\/tr>
Workspace Terraform variable<\/td>replicas = 2<\/code><\/td>HCP workspace settings<\/td><\/tr>
Project variable set<\/td>Shared application settings<\/td>HCP project<\/td><\/tr>
Organization variable set<\/td>Shared settings across projects<\/td>HCP organization<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
8.2 Example: Local environment variable<\/h3>\n\n\n\n
export TF_VAR_replicas=5\n\nterraform plan<\/code><\/pre>\n\n\n\n
Remove it after the test:<\/p>\n\n\n\n
unset TF_VAR_replicas<\/code><\/pre>\n\n\n\n
8.3 Example: Store the value in HCP Terraform<\/h3>\n\n\n\n
Open:<\/p>\n\n\n\n
proezi_dev \u2192 Variables<\/a><\/p>\n\n\n\n
Create a Terraform variable:<\/p>\n\n\n\n
Key<\/th>Value<\/th>Category<\/th><\/tr>
environment<\/code><\/td>development<\/code><\/td>Terraform<\/td><\/tr>
replicas<\/code><\/td>2<\/code><\/td>Terraform<\/td><\/tr>
app_name<\/code><\/td>proezi<\/code><\/td>Terraform<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
These are illustrative values, not changes I’ve made. Only add keys actually declared in the Terraform configuration used by that workspace.<\/p>\n\n\n\n
For proezi_stage<\/code>, you might set environment = staging<\/code>; for proezi_prod<\/code>, environment = production<\/code>.<\/p>\n\n\n\n
Workspace variables are persistent and apply to the workspace’s runs unless overridden by a higher-precedence source.<\/p>\n\n\n\n
8.4 Variable precedence in remote CLI runs<\/h3>\n\n\n\n
The practical precedence, highest first, is:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/p>\n\n\n\n
This is a simplified grouping. Within priority and ordinary variable sets, HCP Terraform also applies rules for set ownership, scope, and lexical order of set names.<\/p>\n\n\n\n
For example, suppose:<\/p>\n\n\n\n
    \n
  • lab.auto.tfvars<\/code> sets replicas = 2<\/code><\/li>\n\n\n\n
  • Your HCP workspace sets replicas = 3<\/code><\/li>\n\n\n\n
  • You execute terraform plan -var='replicas=6'<\/code><\/li>\n<\/ul>\n\n\n\n
    The plan uses 6, unless a priority variable set enforces a different value.<\/p>\n\n\n\n
    Important distinction: TF_VAR_replicas<\/code> is a Terraform input variable. AWS_ACCESS_KEY_ID<\/code>, AWS_SECRET_ACCESS_KEY<\/code>, and similar provider environment variables are a separate category. With remote execution, provider credentials generally need to be available in the HCP remote run environment, not merely on your laptop. Prefer short-lived, dynamic provider credentials where possible.<\/p>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    HashiCorp Developer<\/p>\n\n\n\n
    9. Managing Dev, Stage, and Prod workspaces<\/h2>\n\n\n\n
    This section directly addresses your three workspaces:<\/p>\n\n\n\n
      \n
    • proezi_dev<\/code><\/li>\n\n\n\n
    • proezi_stage<\/code><\/li>\n\n\n\n
    • proezi_prod<\/code><\/li>\n<\/ul>\n\n\n\n
      There are three useful ways to target them.<\/p>\n\n\n\n
      Method A \u2014 Separate Terraform directories<\/h3>\n\n\n\n
      Recommended for straightforward environment isolation<\/p>\n\n\n\n
      terraform\/\n\u251c\u2500\u2500 dev\/\n\u2502   \u2514\u2500\u2500 cloud.tf\n\u251c\u2500\u2500 stage\/\n\u2502   \u2514\u2500\u2500 cloud.tf\n\u2514\u2500\u2500 prod\/\n    \u2514\u2500\u2500 cloud.tf<\/code><\/pre>\n\n\n\n
      Each directory contains its own configuration for the correct HCP workspace.<\/p>\n\n\n\n
      For Dev:<\/p>\n\n\n\n
      terraform {\n  cloud {\n    organization = \"motoshare\"\n\n    workspaces {\n      name    = \"proezi_dev\"\n      project = \"proezi\"\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
      For Stage, use name = \"proezi_stage\"<\/code>. For Prod, use name = \"proezi_prod\"<\/code>.<\/p>\n\n\n\n
      You can then execute commands from the repository root:<\/p>\n\n\n\n
      terraform -chdir=dev init\nterraform -chdir=dev plan\n\nterraform -chdir=stage init\nterraform -chdir=stage plan\n\nterraform -chdir=prod init\nterraform -chdir=prod plan<\/code><\/pre>\n\n\n\n
      This is a clear mapping, but each directory must contain the intended complete configuration for its environment. Don’t create only a cloud.tf<\/code> and then run apply<\/code> against a workspace that already manages resources.<\/p>\n\n\n\n
      Method B \u2014 Workspace selection using tags<\/h3>\n\n\n\n
      If the three workspaces use the same Terraform configuration, you can choose them from one working directory using workspace tags.<\/p>\n\n\n\n
      First, deliberately apply the same key-value tag to all three workspaces through the HCP Terraform UI:<\/p>\n\n\n\n
      application = proezi<\/code><\/pre>\n\n\n\n
      Then, using Terraform CLI 1.10 or later, configure:<\/p>\n\n\n\n
      terraform {\n  cloud {\n    organization = \"motoshare\"\n\n    workspaces {\n      tags = {\n        application = \"proezi\"\n      }\n\n      project = \"proezi\"\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
      Now:<\/p>\n\n\n\n
      terraform init<\/code><\/pre>\n\n\n\n
      List matching workspaces:<\/p>\n\n\n\n
      terraform workspace list<\/code><\/pre>\n\n\n\n
      Select Dev:<\/p>\n\n\n\n
      terraform workspace select proezi_dev<\/code><\/pre>\n\n\n\n
      Confirm the selection:<\/p>\n\n\n\n
      terraform workspace show<\/code><\/pre>\n\n\n\n
      Run:<\/p>\n\n\n\n
      terraform plan<\/code><\/pre>\n\n\n\n
      Switch to Stage:<\/p>\n\n\n\n
      terraform workspace select proezi_stage\nterraform plan<\/code><\/pre>\n\n\n\n
      Switch to Prod:<\/p>\n\n\n\n
      terraform workspace select proezi_prod\nterraform plan<\/code><\/pre>\n\n\n\n
      This requires each workspace to match the configured tags and project.<\/p>\n\n\n\n
      Crucial: workspaces.name<\/code> and workspaces.tags<\/code> are mutually exclusive. You cannot use terraform workspace select<\/code> to switch among several HCP workspaces when the configuration is bound to a single name.<\/p>\n\n\n\n
      Method C \u2014 Workspace selection through an environment variable<\/h3>\n\n\n\n
      For scripts that must target an existing workspace without hardcoding its name, you can omit the workspaces<\/code> block:<\/p>\n\n\n\n
      terraform {\n  cloud {\n    organization = \"motoshare\"\n  }\n}<\/code><\/pre>\n\n\n\n
      Then:<\/p>\n\n\n\n
      export TF_WORKSPACE=proezi_dev\n\nterraform init\nterraform plan<\/code><\/pre>\n\n\n\n
      The environment variable selects an existing HCP Terraform workspace. It does not automatically create a missing workspace in this configuration.<\/p>\n\n\n\n
      To change the target in automation, supply a different TF_WORKSPACE<\/code> value for a separately initialized job or working directory.<\/p>\n\n\n\n
      Production recommendation: Keep production targeting explicit, use separate pipeline approvals, and validate the selected workspace before any state-changing operation.<\/p>\n\n\n\n
      \"\"\/<\/figure>\n\n\n\n
      HashiCorp Developer<\/p>\n\n\n\n
      10. Remote state management \u2014 Hands-on examples<\/h2>\n\n\n\n
      Terraform state records which infrastructure objects Terraform manages.<\/p>\n\n\n\n
      In HCP Terraform, state is stored centrally and can be shared by authorized users and automation.<\/p>\n\n\n\n
      10.1 List resources in remote state<\/h3>\n\n\n\n
      From an initialized workspace directory:<\/p>\n\n\n\n
      terraform state list<\/code><\/pre>\n\n\n\n
      For the lab, an expected resource address is:<\/p>\n\n\n\n
      terraform_data.application<\/code><\/pre>\n\n\n\n
      For a real AWS configuration, the output might look like:<\/p>\n\n\n\n
      aws_vpc.main\naws_subnet.public\naws_security_group.web\naws_instance.web<\/code><\/pre>\n\n\n\n
      These AWS addresses are examples, not confirmed resources in your workspaces.<\/p>\n\n\n\n
      10.2 Inspect one resource<\/h3>\n\n\n\n
      terraform state show terraform_data.application<\/code><\/pre>\n\n\n\n
      Usage: Examine a resource’s recorded attributes without generating a new plan.<\/p>\n\n\n\n
      10.3 Back up remote state<\/h3>\n\n\n\n
      From the isolated lab directory:<\/p>\n\n\n\n
      umask 077\nterraform state pull > lab-state-backup.tfstate<\/code><\/pre>\n\n\n\n
      Usage: Capture a state snapshot before maintenance or recovery exercises.<\/p>\n\n\n\n
      Never commit state backups to Git or share them casually. State may contain passwords, credentials, identifiers, and other sensitive values.<\/p>\n\n\n\n
      10.4 Move a resource address in state<\/h3>\n\n\n\n
      Command format:<\/p>\n\n\n\n
      terraform state mv OLD_ADDRESS NEW_ADDRESS<\/code><\/pre>\n\n\n\n
      Illustration:<\/p>\n\n\n\n
      terraform state mv \\\n  terraform_data.application \\\n  terraform_data.proezi_application<\/code><\/pre>\n\n\n\n
      Usage: Rename a tracked resource address without creating a new infrastructure object.<\/p>\n\n\n\n
      Do not execute this illustration without also updating the HCL resource declaration to match. A moved<\/code> block in version-controlled configuration is generally preferable for planned refactoring.<\/p>\n\n\n\n
      10.5 Remove a resource from state<\/h3>\n\n\n\n
      terraform state rm terraform_data.application<\/code><\/pre>\n\n\n\n
      Usage: Tell Terraform to forget an object.<\/p>\n\n\n\n
      This does not destroy the underlying object. For a real cloud resource, it can leave infrastructure running and unmanaged, so this command is intentionally a reference example, not a recommended lab step.<\/p>\n\n\n\n
      10.6 Import existing infrastructure<\/h3>\n\n\n\n
      Suppose an AWS S3 bucket already exists.<\/p>\n\n\n\n
      A conventional CLI import looks like:<\/p>\n\n\n\n
      terraform import \\\n  aws_s3_bucket.existing \\\n  my-existing-bucket<\/code><\/pre>\n\n\n\n
      You must first declare the resource in Terraform configuration and provide a correctly configured AWS provider.<\/p>\n\n\n\n
      An important HCP-specific detail is that terraform import<\/code> runs locally, even when plans and applies run remotely. Your local environment may therefore need access to provider credentials and the target infrastructure.<\/p>\n\n\n\n
      <\/p>\n","protected":false},"excerpt":{"rendered":"
      HCP Terraform Cloud \u2014 CLI Command Summary Organization: motoshare | Project: proezi # Cloud operation Command \/ Example Usage 1 Login to Terraform Cloud terraform login Authenticate… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1245","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1245","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1245"}],"version-history":[{"count":2,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1245\/revisions"}],"predecessor-version":[{"id":1253,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1245\/revisions\/1253"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1245"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1245"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1245"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}