> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Demo Making the Most of the Terraform CLI > Practical guide to Terraform CLI features, plan customization flags, and using environment variables for input variables and provider authentication. This concise guide walks through practical Terraform CLI features: built-in help, command-specific help, plan customization flags, and using environment variables both to set Terraform variables and to provide provider credentials. Keep this as a quick reference while working with Terraform locally or in CI. Minimal Terraform example (we'll use this throughout) ```hcl theme={null} provider "random" {} variable "num_of_pets" { type = number description = "How many pets do we want?" } resource "random_pet" "name" { length = var.num_of_pets } output "random_pet_name" { value = random_pet.name.id } ``` ## Getting CLI help Open a terminal in your working directory and request top-level help to see global usage and available subcommands: ```bash theme={null} $ terraform --help Usage: terraform [global options] `` [args] The available commands for execution are listed below. The primary workflow commands are given first, followed by less common or more advanced commands. Main commands: init Prepare your working directory for other commands validate Check whether the configuration is valid plan Show changes required by the current configuration apply Create or update infrastructure destroy Destroy previously-created infrastructure ``` Common and advanced commands (excerpt) | Command | Use Case | | ----------: | ------------------------------------------------------------ | | `init` | Initialize a working directory and download provider plugins | | `validate` | Check HCL syntax and basic configuration consistency | | `plan` | Produce an execution plan without changing infrastructure | | `apply` | Create or update resources described by the configuration | | `destroy` | Remove resources managed by Terraform | | `state` | Advanced state inspection and manipulation | | `workspace` | Manage named workspaces for different state instances | Further down in the full help output you’ll also find less-common and deprecated commands (for example, `taint` and `untaint` were deprecated in favor of flags such as `-replace`). Global options (use these before the subcommand) ```plaintext theme={null} -chdir=DIR Switch to a different working directory before executing the given subcommand. -help Show this help output, or the help for a specified subcommand. -version An alias for the "version" subcommand. ``` Request help for any specific subcommand: ```bash theme={null} $ terraform validate --help ``` This prints what the subcommand does and all supported flags (for example, `validate` documents JSON output and color control flags). Callout: subcommand help You can get help for any subcommand (for example, `terraform plan --help`) to see detailed options, examples, and usage notes. ## Deep dive: terraform plan `terraform plan` generates a speculative execution plan showing what Terraform would do to bring infrastructure in line with the configuration. It does not perform any changes unless you later pass a saved plan file to `apply`. Example help excerpt: ```bash theme={null} $ terraform plan --help Usage: terraform [global options] plan [options] Generates a speculative execution plan, showing what actions Terraform would take to apply the current configuration. This command will not actually perform the planned actions. You can optionally save the plan to a file, which you can then pass to the "apply" command to perform exactly the actions described in the plan. Plan Customization Options: -destroy -refresh=true|false -replace=resource_address -target=resource_address -var 'foo=bar' -var-file=filename -out=path -parallelism=n -state=statefile -no-color -input=true|false ``` Plan customization flags — quick reference | Flag | Purpose | Example | | --------------------------- | --------------------------------------------------- | ------------------------------------------ | | `-replace=resource_address` | Force resource replacement (replacement of `taint`) | `terraform plan -replace=aws_instance.web` | | `-target=resource_address` | Plan only specific resource(s) | `terraform plan -target=module.db` | | `-var` | Set a variable from the CLI | `terraform plan -var 'num_of_pets=3'` | | `-var-file` | Load variables from a file | `terraform plan -var-file=prod.tfvars` | | `-out` | Save a plan to a path for later `apply` | `terraform plan -out=tfplan` | | `-parallelism` | Limit concurrent operations | `terraform plan -parallelism=4` | Notes: * Use `-out` if you want to guarantee that `apply` performs the same actions as planned. * Prefer `-var-file` or environment variables in CI to avoid leaking secrets in shell history. ## Passing Terraform variables via environment Terraform supports setting input variables from the environment using the `TF_VAR_` pattern. For the example above, set `TF_VAR_num_of_pets` to provide `num_of_pets` from the environment. If you run `terraform plan` without supplying `num_of_pets`, Terraform will prompt: ```plaintext theme={null} $ terraform plan var.num_of_pets How many pets do we want? Enter a value: ``` Set the variable in a POSIX shell (macOS / Linux): ```bash theme={null} export TF_VAR_num_of_pets=3 ``` Rerunning `terraform plan` will now use that value without prompting: ```plaintext theme={null} $ terraform plan Plan: 1 to add, 0 to change, 0 to destroy. Changes to Outputs: + random_pet_name = (known after apply) Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now. ``` If you change `TF_VAR_num_of_pets` to another number (for example `6`), resources depending on `var.num_of_pets` will reflect the new value on the next plan or apply. Callout: using `TF_VAR_` environment variables Use `TF_VAR_` to inject Terraform variable values from the environment. Example: `export TF_VAR_num_of_pets=3`. This is useful in CI/CD pipelines and local scripts. ## Environment variables for provider authentication Provider SDKs typically read standard environment variables for authentication. These are provider-specific and are not Terraform-level variables. Common provider authentication environment variables: | Provider | Common env vars | Notes / docs | | -------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | AWS | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_DEFAULT_REGION` | See AWS provider docs: [https://registry.terraform.io/providers/hashicorp/aws](https://registry.terraform.io/providers/hashicorp/aws) | | GCP | `GOOGLE_CREDENTIALS`, `GOOGLE_PROJECT`, `GOOGLE_REGION` | Accepts service account JSON via `GOOGLE_CREDENTIALS` | | Azure | `ARM_CLIENT_ID`, `ARM_CLIENT_SECRET`, `ARM_SUBSCRIPTION_ID`, `ARM_TENANT_ID` | AzureRM provider reads these | | Vault | `VAULT_ADDR`, `VAULT_TOKEN` | Use `VAULT_TOKEN` or approles for auth | AWS example (POSIX shell): ```bash theme={null} export AWS_ACCESS_KEY_ID=AKIAEXAMPLEKEY export AWS_SECRET_ACCESS_KEY=exampleSecretKeyHere export AWS_DEFAULT_REGION=us-east-1 ``` And an AWS provider block in HCL: ```hcl theme={null} provider "aws" { region = "us-east-1" } ``` Terraform will use the environment variables above to authenticate with AWS during `plan` or `apply`. Callout: protect credentials Never commit credentials, tokens, or secret keys to version control. Use secure secrets management, environment injection in CI/CD, or a secrets backend (e.g., HashiCorp Vault) instead of hardcoding secrets in files. ## Summary and quick checklist * Use `terraform --help` and `terraform --help` to discover commands, flags, and usage examples. * `terraform plan` supports many customization flags (`-replace`, `-target`, `-var`, `-var-file`, `-out`); use `-out` when you need a reproducible apply step. * Supply Terraform input variables via the environment using `TF_VAR_` for automation-friendly workflows. * Provider authentication commonly relies on provider-specific environment variables (for example, AWS and Vault); consult provider docs for exact variable names. * Never store secrets in source control—use secure vaults or platform-managed secret injection. Further reading and references * Terraform CLI documentation: [https://www.terraform.io/docs/cli](https://www.terraform.io/docs/cli) * Terraform Providers: [https://registry.terraform.io/browse/providers](https://registry.terraform.io/browse/providers) * AWS provider docs: [https://registry.terraform.io/providers/hashicorp/aws/latest/docs](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) * HashiCorp Vault: [https://www.vaultproject.io/docs](https://www.vaultproject.io/docs) That's it — a compact, practical walkthrough of helpful Terraform CLI commands, plan options, and environment-based variable and credential patterns.