diff --git a/content/terraform/v1.12.x/data/language-nav-data.json b/content/terraform/v1.12.x/data/language-nav-data.json
index b1efdcd7c..bf523e93d 100644
--- a/content/terraform/v1.12.x/data/language-nav-data.json
+++ b/content/terraform/v1.12.x/data/language-nav-data.json
@@ -210,7 +210,7 @@
     "title": "Variables and Outputs",
     "routes": [
       { "title": "Overview", "path": "values" },
-      { "title": "Input Variables", "path": "values/variables" },
+      { "title": "Variable block", "href": "/terraform/language/block/variable" },
       { "title": "Output block", "href": "/terraform/language/block/output" },
       { "title": "Local Values", "path": "values/locals" }
     ]
@@ -1142,6 +1142,10 @@
       {
         "title": "Terraform block",
         "path": "block/terraform"
+      },
+      {
+        "title": "Variable block",
+        "path": "block/variable"
       }
     ]
   },
diff --git a/content/terraform/v1.12.x/docs/cli/commands/import.mdx b/content/terraform/v1.12.x/docs/cli/commands/import.mdx
index c3097e739..003a392b6 100644
--- a/content/terraform/v1.12.x/docs/cli/commands/import.mdx
+++ b/content/terraform/v1.12.x/docs/cli/commands/import.mdx
@@ -67,11 +67,11 @@ The command-line flags are all optional. The following flags are available:
   can be set multiple times. Variable values are interpreted as
   [literal expressions](/terraform/language/expressions/types) in the
   Terraform language, so list and map values can be specified via this flag.
-
+<!-- TODO: add link to new variable usage page once done -->
 - `-var-file=foo` - Set variables in the Terraform configuration from
-  a [variable file](/terraform/language/values/variables#variable-definitions-tfvars-files). If
+  a [variable file](/terraform/language/block/variable#variable-definitions-tfvars-files). If
   `terraform.tfvars` or any `.auto.tfvars` files are present in the current
-  directory, they are automatically loaded. Terraform loads `terraform.tfvars` 
+  directory, they are automatically loaded. Terraform loads `terraform.tfvars`
   first and the `.auto.tfvars` files after in alphabetical order. Any files
   specified by `-var-file` override any values set automatically from files in
   the working directory. This flag can be used multiple times. This is only
diff --git a/content/terraform/v1.12.x/docs/cli/commands/plan.mdx b/content/terraform/v1.12.x/docs/cli/commands/plan.mdx
index 7cbbcf6fa..770c1d2e0 100644
--- a/content/terraform/v1.12.x/docs/cli/commands/plan.mdx
+++ b/content/terraform/v1.12.x/docs/cli/commands/plan.mdx
@@ -5,10 +5,10 @@ description: >-
   changes that Terraform will make to your infrastructure.
 ---
 
-# `terraform plan` command 
+# `terraform plan` command
 
 The `terraform plan` command creates an execution plan, which lets you preview
-the changes that Terraform plans to make to your infrastructure. 
+the changes that Terraform plans to make to your infrastructure.
 
 ## Introduction
 By default, Terraform performs the following operations when it creates a plan:
@@ -138,25 +138,25 @@ In addition to alternate [planning modes](#planning-modes), there are several op
   -> **Note:** Use `-target=ADDRESS` in exceptional circumstances only, such as recovering from mistakes or working around Terraform limitations. Refer to [Resource Targeting](#resource-targeting) for more details.
 
 - `-var 'NAME=VALUE'` - Sets a value for a single
-  [input variable](/terraform/language/values/variables) declared in the
+  [input variable](/terraform/language/block/variable) declared in the
   root module of the configuration. Use this option multiple times to set
   more than one variable. Refer to
   [Input Variables on the Command Line](#input-variables-on-the-command-line) for more information.
-
+<!-- TODO: add link to new variable usage page once done -->
 - `-var-file=FILENAME` - Sets values for potentially many
-  [input variables](/terraform/language/values/variables) declared in the
+  [input variables](/terraform/language/block/variable) declared in the
   root module of the configuration, using definitions from a
-  ["tfvars" file](/terraform/language/values/variables#variable-definitions-tfvars-files).
+  ["tfvars" file](/terraform/language/block/variable#variable-definitions-tfvars-files).
   Use this option multiple times to include values from more than one file.
-
+<!-- TODO: add link to new variable usage page once done -->
 There are several other ways to set values for input variables in the root
 module, aside from the `-var` and `-var-file` options. Refer to
-[Assigning Values to Root Module Variables](/terraform/language/values/variables#assigning-values-to-root-module-variables) for more information.
+[Assigning Values to Root Module Variables](/terraform/language/block/variable#assigning-values-to-root-module-variables) for more information.
 
 ### Input Variables on the Command Line
 
 You can use the `-var` command line option to specify values for
-[input variables](/terraform/language/values/variables) declared in your
+[input variables](/terraform/language/block/variable) declared in your
 root module.
 
 However, to do so will require writing a command line that is parsable both
@@ -222,10 +222,11 @@ terraform plan -var 'name=["a", "b", "c"]'
 terraform plan -var "name=[\"a\", \"b\", \"c\"]"
 ```
 
+<!-- TODO: add link to new variable usage page once done -->
 Similar constraints apply when setting input variables using environment
 variables. For more information on the various methods for setting root module
 input variables, see
-[Assigning Values to Root Module Variables](/terraform/language/values/variables#assigning-values-to-root-module-variables).
+[Assigning Values to Root Module Variables](/terraform/language/block/variable#assigning-values-to-root-module-variables).
 
 ### Resource Targeting
 
diff --git a/content/terraform/v1.12.x/docs/cli/config/environment-variables.mdx b/content/terraform/v1.12.x/docs/cli/config/environment-variables.mdx
index 70144c6fd..69c3b3565 100644
--- a/content/terraform/v1.12.x/docs/cli/config/environment-variables.mdx
+++ b/content/terraform/v1.12.x/docs/cli/config/environment-variables.mdx
@@ -1,7 +1,7 @@
 ---
 page_title: Terraform CLI environment variables reference
 description: >-
-  Terraform environment variables let you customize the Terraform CLI's default behavior. 
+  Terraform environment variables let you customize the Terraform CLI's default behavior.
   Learn about the Terraform CLI environment variables.
 ---
 
@@ -61,7 +61,8 @@ export TF_VAR_alist='[1,2,3]'
 export TF_VAR_amap='{ foo = "bar", baz = "qux" }'
 ```
 
-For more on how to use `TF_VAR_name` in context, check out the section on [Variable Configuration](/terraform/language/values/variables).
+<!-- TODO: add link to new variable usage page once done -->
+For more on how to use `TF_VAR_name` in context, check out the section on [Variable Configuration](/terraform/language/block/variable).
 
 ## TF_CLI_ARGS and TF_CLI_ARGS_name
 
diff --git a/content/terraform/v1.12.x/docs/cli/workspaces/index.mdx b/content/terraform/v1.12.x/docs/cli/workspaces/index.mdx
index 3baca17bd..3252ce8d2 100644
--- a/content/terraform/v1.12.x/docs/cli/workspaces/index.mdx
+++ b/content/terraform/v1.12.x/docs/cli/workspaces/index.mdx
@@ -21,7 +21,7 @@ Use the [`terraform workspace list`](/terraform/cli/commands/workspace/list), [`
 
 Use [the `terraform workspace select` command](/terraform/cli/commands/workspace/select) to change the currently selected workspace. For a given working directory, you can only select one workspace at a time. Most Terraform commands only interact with the currently selected workspace. This includes [provisioning](/terraform/cli/run) and [state manipulation](/terraform/cli/state).
 
-When you provision infrastructure in each workspace, you usually need to manually specify different [input variables](/terraform/language/values/variables) to differentiate each collection. For example, you might deploy test infrastructure to a different region.
+When you provision infrastructure in each workspace, you usually need to manually specify different [input variables](/terraform/language/block/variable) to differentiate each collection. For example, you might deploy test infrastructure to a different region.
 
 
 ## Use Cases
diff --git a/content/terraform/v1.12.x/docs/language/block/output.mdx b/content/terraform/v1.12.x/docs/language/block/output.mdx
index c2f3f217b..b8b192ce1 100644
--- a/content/terraform/v1.12.x/docs/language/block/output.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/output.mdx
@@ -158,7 +158,7 @@ Passing output values between child modules and the root module is useful for ma
 The following ephemeral contexts can set values for output blocks with the `ephemeral` argument, and they can also reference output blocks with the `ephemeral` argument:
 - Another child module's ephemeral `output` block
 - A [write-only argument](/terraform/language/resources/ephemeral/write-only)
-- [Variables with the `ephemeral` argument](/terraform/language/values/variables#exclude-values-from-state)
+- [Variables with the `ephemeral` argument](/terraform/language/block/variable#ephemeral)
 - [An `ephemeral` resource block](/terraform/language/resources/ephemeral)
 - Configuring providers in the [`provider` block](/terraform/language/providers)
 - In [provisioner](/terraform/language/resources/provisioners/syntax) and [connection](/terraform/language/resources/provisioners/connection) blocks
diff --git a/content/terraform/v1.12.x/docs/language/block/resource.mdx b/content/terraform/v1.12.x/docs/language/block/resource.mdx
index 931c92cb0..28405f94b 100644
--- a/content/terraform/v1.12.x/docs/language/block/resource.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/resource.mdx
@@ -62,7 +62,7 @@ The `resource` block supports the following arguments:
    - [`provisioner "<TYPE>"`](#provisioner) &nbsp; block
       - [`source`](#source) &nbsp; string
       - [`destination`](#destination) &nbsp; string
-      - [`content`](#content) &nbsp; string      
+      - [`content`](#content) &nbsp; string
       - [`command`](#command) &nbsp; string
       - [`working_dir`](#working_dir) &nbsp; string
       - [`interpreter`](#interpreter) &nbsp; string
@@ -82,13 +82,13 @@ The following `resource` block defines all of the supported built-in arguments y
 ```hcl
 resource "<TYPE>" "<LABEL>" {
   <PROVIDER_ARGUMENTS>
-  count = <NUMBER>      # `for_each` and `count` are mutually exclusive 
+  count = <NUMBER>      # `for_each` and `count` are mutually exclusive
   depends_on = [ <RESOURCE.ADDRESS.EXPRESSION> ]
-  for_each = {          # `for_each` and `count` are mutually exclusive 
+  for_each = {          # `for_each` and `count` are mutually exclusive
     <KEY> = <VALUE>
   }
-  for_each = [	     # `for_each` accepts a map or a set of strings 
-    "<VALUE>", 
+  for_each = [	     # `for_each` accepts a map or a set of strings
+    "<VALUE>",
     "<VALUE>"
   ]
   provider = <REFERENCE.TO.ALIAS>
@@ -143,24 +143,24 @@ resource "<TYPE>" "<LABEL>" {
 
 ## Specification
 
-A `resource` block supports the following configuration. 
+A `resource` block supports the following configuration.
 
 ### `resource "<TYPE>" "<LABEL>"`
 
-You must set the following arguments for every `resource` block: 
+You must set the following arguments for every `resource` block:
 
 - `TYPE`: Specifies the type of resource to create. You can declare either a resource type determined by the provider or the built-in `terraform_data` resource type, which stores values and triggers Terraform operations without creating actual infrastructure. For information about provider resource types, refer to the provider documentation.
 - `LABEL`: Specifies a name for the resource. Terraform uses this label to track the resource in your state file. The label does not affect settings on the actual infrastructure resource. Refer to [References to Named Values](/terraform/language/expressions/references) and [Resource naming](/terraform/language/style#resource-naming) for expression syntax and label recommendations.
 
-To reference the resource in your configuration, you must refer to it using `<TYPE>.<LABEL>` syntax. 
+To reference the resource in your configuration, you must refer to it using `<TYPE>.<LABEL>` syntax.
 
 ### `PROVIDER ARGUMENTS`
 
-The provider developer determines which arguments you can define for a resource. Refer to the provider documentation for details.  
+The provider developer determines which arguments you can define for a resource. Refer to the provider documentation for details.
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration. 
+The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration.
 
 ```hcl
 resource {
@@ -168,11 +168,11 @@ resource {
 }
 ```
 
-The value must be a whole number. You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number. 
+The value must be a whole number. You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number.
 
-In blocks where `count` is set, Terraform exposes an additional `count` object. You can reference the object to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`. 
+In blocks where `count` is set, Terraform exposes an additional `count` object. You can reference the object to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`.
 
-To refer to an individual instance of a resource created using the `count` meta-argument, use the `<TYPE>.<NAME>[INDEX]` syntax. For example, `aws_instance.server[0]` refers to the first instance of the `aws_instance` resource named `server`. 
+To refer to an individual instance of a resource created using the `count` meta-argument, use the `<TYPE>.<NAME>[INDEX]` syntax. For example, `aws_instance.server[0]` refers to the first instance of the `aws_instance` resource named `server`.
 
 <Tip>
 
@@ -184,8 +184,8 @@ The `count` argument is a meta-argument, which is built into Terraform and contr
 
 #### Summary
 
-- Data type: Number. 
-- Default: None.  
+- Data type: Number.
+- Default: None.
 - Example: [Create multiple instances of a resource](#create-multiple-instances-of-a-resource).
 
 ### `depends_on`
@@ -198,7 +198,7 @@ resource {
 }
 ```
 
-When a resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating another, even though the resources are configured independently. 
+When a resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating another, even though the resources are configured independently.
 
 Use the `depends_on` argument when the resources do not reference each other. We recommend always including a comment to explain resource dependencies when using a `depends_on` argument.
 
@@ -212,12 +212,12 @@ The `depends_on` argument is a meta-argument, which is built into Terraform and
 #### Summary
 
 - Data type: List.
-- Default: None.  
-- Example: [Specify a dependency](#specify-a-dependency). 
+- Default: None.
+- Example: [Specify a dependency](#specify-a-dependency).
 
 ### `for_each`
 
-The `for_each` meta-argument instructs Terraform to provision similar resources without requiring separate configuration blocks for each resource. 
+The `for_each` meta-argument instructs Terraform to provision similar resources without requiring separate configuration blocks for each resource.
 
 <Tabs>
 
@@ -225,7 +225,7 @@ The `for_each` meta-argument instructs Terraform to provision similar resources
 
 ```hcl
 resource {
-  for_each = [ "<VALUE>" ] 
+  for_each = [ "<VALUE>" ]
   # . . .
 }
 ```
@@ -257,16 +257,16 @@ The `for_each` argument does not implicitly convert lists or tuples to sets. To
 - [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
 - [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
 
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/values/variables#suppressing-values-in-cli-output), [sensitive outputs](/terraform/language/values/outputs#sensitive-suppressing-values-in-cli-output), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
+You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
 
 If you transform a value containing sensitive data into an argument for use in `for_each`, be aware that most functions in Terraform will return a sensitive result if given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
 
-Refer to [Sensitive Data in State](/terraform/language/state/sensitive-data) for more information. 
+Refer to [Sensitive Data in State](/terraform/language/state/sensitive-data) for more information.
 
 The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the resource. The object has the following attributes:
 
 - `each.key`: Map key or list member that corresponds to an instance.
-- `each.value`: Map value that corresponds to an instance. 
+- `each.value`: Map value that corresponds to an instance.
 
 Use the `<TYPE>.<NAME>[<KEY>]` syntax to access an instance of a resource created using `for_each`. For example, `azurerm_resource_group.rg["a_group"]` refers to an instance of the `azurrm_resource_group` resource named `rg` created off of the `a_group` key.
 
@@ -275,12 +275,12 @@ The `for_each` argument is a meta-argument, which is built into Terraform and co
 #### Summary
 
 - Data type: Map or set of strings.
-- Default: None.  
-- Example: [Create multiple instances of a resource](#create-multiple-instances-of-a-resource). 
+- Default: None.
+- Example: [Create multiple instances of a resource](#create-multiple-instances-of-a-resource).
 
 ### `provider`
 
-The `provider` argument instructs Terraform to use an alternate provider configuration to provision the resource. 
+The `provider` argument instructs Terraform to use an alternate provider configuration to provision the resource.
 
 ```hcl
 resource {
@@ -288,25 +288,25 @@ resource {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the resource type, but you can create multiple provider configurations and use a non-default configuration for specific resources. 
+By default, Terraform automatically selects a provider based on the resource type, but you can create multiple provider configurations and use a non-default configuration for specific resources.
 
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Multiple Provider Configurations](/terraform/language/providers/configuration#alias-multiple-provider-configurations) for instructions on how to reference a specific provider configuration.     
+Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Multiple Provider Configurations](/terraform/language/providers/configuration#alias-multiple-provider-configurations) for instructions on how to reference a specific provider configuration.
 
 The `provider` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/concepts/meta-arguments) for more information.
 
 #### Summary
 
 - Data type: Reference.
-- Default: None. 
+- Default: None.
 - Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration).
 
 ### `lifecycle`
 
-The `lifecycle` block defines lifecycle rules that instruct Terraform when and how to operate on your resource. 
+The `lifecycle` block defines lifecycle rules that instruct Terraform when and how to operate on your resource.
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     <lifecycle>
   }
 }
@@ -316,44 +316,44 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 - [`create_before_destroy`](#create_before_destroy): Terraform creates a replacement resource before destroying the current resource.
 - [`prevent_destroy`](#prevent_destroy): Terraform rejects operations to destroy the resource and returns an error.
-- [`ignore_changes`](#ignore_changes):  Specifies a list of resource attributes that Terraform ignores changes to. Otherwise, Terraform attempts to update the actual resource to match the configuration.  
+- [`ignore_changes`](#ignore_changes):  Specifies a list of resource attributes that Terraform ignores changes to. Otherwise, Terraform attempts to update the actual resource to match the configuration.
 - [`replace_triggered_by`](#replace-triggered_by): Terraform replaces the resource when any of the referenced resources or specified attributes change.
-- [`precondition`](#precondition): Specifies a condition that Terraform evaluates before creating the resource. Refer to [Test and validate](/terraform/language/test-and-validate) for more information.
-- [`postcondition`](#postcondition): Specifies a condition that Terraform evaluates after creating the resource. Refer to [Test and validate](/terraform/language/test-and-validate) for more information.
+- [`precondition`](#precondition): Specifies a condition that Terraform evaluates before creating the resource. Refer to [Test and validate](/terraform/language/test-and-validate/validate#preconditions-and-postconditions) for more information.
+- [`postcondition`](#postcondition): Specifies a condition that Terraform evaluates after creating the resource. Refer to [Test and validate](/terraform/language/test-and-validate/validate#preconditions-and-postconditions) for more information.
 
 Configurations defined in the `lifecycle` block affect how Terraform constructs and traverses the dependency graph. You can only use literal values in the lifecycle block because Terraform processes them before it evaluates arbitrary expressions for a run.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/concepts/meta-arguments) for more information.  
+The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/concepts/meta-arguments) for more information.
 
 #### Summary
 
 - Data type: Block.
-- Default: None 
+- Default: None
 
 ### `create_before_destroy`
 
-The `create_before_destroy` argument instructs Terraform to create a replacement resource before destroying the resource it replaces. 
+The `create_before_destroy` argument instructs Terraform to create a replacement resource before destroying the resource it replaces.
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     create_before_destroy = <boolean>
   }
 }
 ```
 
-By default, Terraform destroys a resource before creating a replacement. 
+By default, Terraform destroys a resource before creating a replacement.
 
-Refer to the documentation for the resource type you are configuring to understand which changes Terraform can make in-place and which require recreating the resource to decide whether to use the `create_before_destroy` argument. 
+Refer to the documentation for the resource type you are configuring to understand which changes Terraform can make in-place and which require recreating the resource to decide whether to use the `create_before_destroy` argument.
 
 Terraform propagates and applies the `create_before_destroy` behavior to all resource dependencies. For example, if `create_before_destroy` is enabled on resource A but not on resource B, but resource A is dependent on resource B, then Terraform enables `create_before_destroy` for resource B implicitly and records it in the state file. You cannot override `create_before_destroy` to `false` on resource B because that would imply dependency cycles in the graph.
 
-Setting`create_before_destroy` to `true` on a resource stops any configured destroy provisioners. 
+Setting`create_before_destroy` to `true` on a resource stops any configured destroy provisioners.
 
 #### Summary
 
 - Data type: Boolean
-- Default: None. 
+- Default: None.
 
 ### `prevent_destroy`
 
@@ -361,7 +361,7 @@ The `prevent_destroy` argument instructs Terraform to reject plans to destroy th
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     prevent_destroy = <boolean>
   }
 }
@@ -369,37 +369,37 @@ resource {
 
 Use this argument to prevent team members from accidentally replacing critical infrastructure, such as database instances.
 
-When the `prevent_destroy` argument is set, you must either remove the resource from the configuration or change the `prevent_destroy` argument to `false` to destroy it. Use this argument with caution. The `prevent_destroy` argument can make applying resource changes or destroying resources more complex. 
+When the `prevent_destroy` argument is set, you must either remove the resource from the configuration or change the `prevent_destroy` argument to `false` to destroy it. Use this argument with caution. The `prevent_destroy` argument can make applying resource changes or destroying resources more complex.
 
 #### Summary
 
 - Data type: Boolean.
-- Default: None.  
+- Default: None.
 
 ### `ignore_changes`
 
-The `ignore_changes` argument specifies a list of resource attributes for Terraform to ignore when planning updates to the resource. 
+The `ignore_changes` argument specifies a list of resource attributes for Terraform to ignore when planning updates to the resource.
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     ignore_changes = [ <attribute> ]
   }
 }
 ```
 
-Use this argument when the resource references data that may change but does not affect the resource after its creation. 
+Use this argument when the resource references data that may change but does not affect the resource after its creation.
 
 By default, Terraform detects any difference in the current settings of a real infrastructure object and plans to update the remote object to match the configuration.
 
-Terraform uses the specified arguments to create a resource, but ignores them when planning an `update` operation. You can specify arguments as the relative attribute addresses in the resource and reference members of maps and lists using index notation, such as `tags["Name"]` and `list[0]`. 
+Terraform uses the specified arguments to create a resource, but ignores them when planning an `update` operation. You can specify arguments as the relative attribute addresses in the resource and reference members of maps and lists using index notation, such as `tags["Name"]` and `list[0]`.
 
-You can also specify `all` instead of a list to ignore future changes to all resource attributes. This lets Terraform create and destroy the resource but it does not propose updates to it. 
+You can also specify `all` instead of a list to ignore future changes to all resource attributes. This lets Terraform create and destroy the resource but it does not propose updates to it.
 
 #### Summary
 
 - Data type: List.
-- Default: None. 
+- Default: None.
 - Example: [Ignore attribute changes](#ignore-attribute-changes).
 
 ### `replace_triggered_by`
@@ -408,7 +408,7 @@ The `replace_triggered_by` argument instructs Terraform to replace the resource
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     replace_triggered_by = [ <address.reference> ]
   }
 }
@@ -428,17 +428,17 @@ Adding the `replace_triggered_by` argument to a resource that uses `count` or `f
 
 #### Summary
 
-- Data type: List 
+- Data type: List
 - Default: None.
-- Example: [Specify triggers that replace resources](#specify-triggers-that-replace-resources)  
+- Example: [Specify triggers that replace resources](#specify-triggers-that-replace-resources)
 
 ### `precondition`
 
-The `precondition` block specifies a condition that must return `true` before Terraform evaluates and performs operations on the resource. You can also specify an error message for Terraform to print when the condition returns `false`. 
+The `precondition` block specifies a condition that must return `true` before Terraform evaluates and performs operations on the resource. You can also specify an error message for Terraform to print when the condition returns `false`.
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     precondition {
       condition = <expression>
       error_message = "<message>"
@@ -456,11 +456,11 @@ The following arguments in the `precondition` block are required:
 
 Terraform evaluates `precondition` blocks before evaluating the resource's configuration arguments. The `precondition` can take precedence over argument evaluation errors.
 
-Terraform evaluates precondition blocks after evaluating `count` and `for_each` meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions. 
+Terraform evaluates precondition blocks after evaluating `count` and `for_each` meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
 
-You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so can prevent Terraform from understanding that the data block result can be affected by changes in the resource block. 
+You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so can prevent Terraform from understanding that the data block result can be affected by changes in the resource block.
 
-Refer to [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.
+Refer to [Test and validate](/terraform/language/test-and-validate/validate#preconditions-and-postconditions) for information about adding validations to your Terraform configuration.
 
 #### Summary
 
@@ -470,11 +470,11 @@ Refer to [Test and validate](/terraform/language/test-and-validate) for informat
 
 ### `postcondition`
 
-The `postcondition` block specifies a condition that must return `true` after Terraform performs operations on the resource. You can also specify an error message for Terraform to print to the console when the condition returns `false`. 
+The `postcondition` block specifies a condition that must return `true` after Terraform performs operations on the resource. You can also specify an error message for Terraform to print to the console when the condition returns `false`.
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     postcondition {
       condition = <expression>
       error_message = "<message>"
@@ -490,11 +490,11 @@ The following arguments in the `precondition` block are required:
 | `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
 | `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
 
-Refer to [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.
+Refer to [Test and validate](/terraform/language/test-and-validate/validate) for information about adding validations to your Terraform configuration.
 
 Terraform evaluates `postcondition` blocks after planning and applying changes to the resource. Postcondition failures prevent changes to other resources that depend on the failing resource.
 
-You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so can prevent Terraform from understanding that the data block result can be affected by changes in the resource block. 
+You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so can prevent Terraform from understanding that the data block result can be affected by changes in the resource block.
 
 #### Summary
 
@@ -512,7 +512,7 @@ We recommend using configuration management tools or other means to perform acti
 
 </Warning>
 
-You can add the `connection` block to either the [`resource`](#resource) block or the [`provisioner`](#provisioner) block. When added to the `resource` block, the `connection` block sets default connection settings for all provisioners defined in the resource so that provisioners can connect to the remote resource after Terraform provisions it. 
+You can add the `connection` block to either the [`resource`](#resource) block or the [`provisioner`](#provisioner) block. When added to the `resource` block, the `connection` block sets default connection settings for all provisioners defined in the resource so that provisioners can connect to the remote resource after Terraform provisions it.
 
 ```hcl
 resource {
@@ -541,7 +541,7 @@ Terraform does not validate SSH host keys by default. You can establish a separa
 
 You can use ephemeral values for arguments in the `connection` block. Refer [Ephemerality in resources](/terraform/language/resources/ephemeral) for more information.
 
-Expressions in `connection` blocks cannot refer to their parent resource by name. References create dependencies, and referring to a resource by name within its own block would create a dependency cycle. Instead, use the `self` object in expressions to refer to the `connection` block's parent block, including all of its attributes. For example, use `self.public_ip` to reference the `public_ip` attribute in an `aws_instance`. 
+Expressions in `connection` blocks cannot refer to their parent resource by name. References create dependencies, and referring to a resource by name within its own block would create a dependency cycle. Instead, use the `self` object in expressions to refer to the `connection` block's parent block, including all of its attributes. For example, use `self.public_ip` to reference the `public_ip` attribute in an `aws_instance`.
 
 <span id="connection-arguments"/>
 
@@ -554,9 +554,9 @@ You can provide multiple connections so that an initial provisioner can connect
 The following table describes the arguments you can use in the `connection` block:
 
 | Argument | Description | Data type | Connection | Default |
-|---------------|--------------|-------------|---------| --- | 
+|---------------|--------------|-------------|---------| --- |
 | `type` | Specifies the type of connection for sending and receiving data from the remote resource. You can specify `ssh` or `winrm`. When set to `winrm`, provisioners implement Windows-specific behaviors, even when `target_platform` is set to `unix`, unless otherwise specified.| string |  | `ssh` |
-| `user` | Specifies the user to use for the connection. | string | `ssh`<p>`winrm`</p> | <p>`root` when `type` is `ssh`</p><p>`Administrator` when `type` is `winrm`</p> | 
+| `user` | Specifies the user to use for the connection. | string | `ssh`<p>`winrm`</p> | <p>`root` when `type` is `ssh`</p><p>`Administrator` when `type` is `winrm`</p> |
 | `password` | Specifies the password to use for the connection. | string | `ssh`<p>`winrm`</p> | none |
 | `host` | Specifies the address of the resource to connect to. <p>This argument is required.</p> | string | `ssh`<p>`winrm`</p> | none |
 | `port` | Specifies the port number to connect to. | number | `ssh`<p>`winrm`</p> | <p>`22` when `type` is `ssh`</p><p>`5985` when `type` is `winrm`</p> |
@@ -593,12 +593,12 @@ The following table describes the arguments you can use in the `connection` bloc
 
 ### `provisioner`
 
-The `provisioner` block defines actions to perform on the local machine or created resource, such as preparing servers or other infrastructure objects for service. 
+The `provisioner` block defines actions to perform on the local machine or created resource, such as preparing servers or other infrastructure objects for service.
 
 ```hcl
 resource {
   provisioner "<TYPE>" {
-    <arguments> 
+    <arguments>
   }
 }
 ```
@@ -611,10 +611,10 @@ We recommend using configuration management tools or other means to perform acti
 
 The `provisioner` block supports the following arguments:
 
-- `TYPE`: Specifies the type of provisioner to use. You must specify one of the following types:   
+- `TYPE`: Specifies the type of provisioner to use. You must specify one of the following types:
   - `file`: Copies files or directories from the machine where Terraform is running to the new resource. When the file provisioner communicates with a Windows system over SSH, you must configure OpenSSH to run the commands with `cmd.exe` and not PowerShell. PowerShell causes file parsing errors because it is incompatible with both Unix shells and the Windows command interpreter.
   - `local-exec`: Invokes an executable on the local machine after Terraform creates the resource.
-  - `remote-exec`: Invokes an executable on the remote resource after Terraform creates the resource.  
+  - `remote-exec`: Invokes an executable on the remote resource after Terraform creates the resource.
 - `LABEL`: Optional attribute for adding a unique name. Refer to [Resource naming](/terraform/language/style#resource-naming) for label recommendations.
 
 The type of provisioner determines which arguments you can add to the block. All types can use the [`connection`](#connection) argument. The following table lists each type's supported arguments:
@@ -633,7 +633,7 @@ The type of provisioner determines which arguments you can add to the block. All
 
 ### `source`
 
-The `source` specifies the location of a file or directory to copy to the location specified in the [`destination`](#destination) argument. 
+The `source` specifies the location of a file or directory to copy to the location specified in the [`destination`](#destination) argument.
 
 ```hcl
 resource {
@@ -644,13 +644,13 @@ resource {
 ```
 
 
-You can specify a string value that contains an expression. You can't use the `source` argument and the [`content`](#content) argument in the same `provisioner "file"` block. 
+You can specify a string value that contains an expression. You can't use the `source` argument and the [`content`](#content) argument in the same `provisioner "file"` block.
 
 When the `source` argument specifies a directory and the `type` argument in the [provisioner connection settings](#connection) is set to `ssh`, the corresponding directory specified in the `destination` argument must already exist. You can add a `provisioner "remote-exec"` block to your `resource` configuration to create the directory. If the directory does not already exist, Terraform creates it when the `type` argument in the [provisioner connection settings](#connection) is set to `winrm`.
 
-Adding a trailing slash to the `source` argument path instructs Terraform to copy the contents of the directory to the `destination` directory. For example, when `source = "/foo/"` and `destination = "/temp"`, Terraform uploads the contents of `/foo` directory into `/tmp`. 
+Adding a trailing slash to the `source` argument path instructs Terraform to copy the contents of the directory to the `destination` directory. For example, when `source = "/foo/"` and `destination = "/temp"`, Terraform uploads the contents of `/foo` directory into `/tmp`.
 
-Without a trailing slash, Terraform creates the directory under the directory specified in the `destination`. For example, when `source = "/foo"` and `destination = "/temp"`, Terraform uploads the `/foo` directory to `/tmp/foo`. 
+Without a trailing slash, Terraform creates the directory under the directory specified in the `destination`. For example, when `source = "/foo"` and `destination = "/temp"`, Terraform uploads the `/foo` directory to `/tmp/foo`.
 
 #### Summary
 
@@ -660,7 +660,7 @@ Without a trailing slash, Terraform creates the directory under the directory sp
 
 ### `content`
 
-The `content` argument specifies content to write directly to the location specified in the [`destination`](#destination) argument. 
+The `content` argument specifies content to write directly to the location specified in the [`destination`](#destination) argument.
 
 ```hcl
 resource {
@@ -671,9 +671,9 @@ resource {
 ```
 
 
-When `destination` points to a file, Terraform writes the value of the `content` argument to the file. When `destination` points to a directory, Terraform creates a file named `tf-file-content` inside the directory. We recommend setting the `destination` argument to a file when using `content` argument. Do not use the `content` argument and the [`source`](#source) argument in the same `provisioner "file"` block. 
+When `destination` points to a file, Terraform writes the value of the `content` argument to the file. When `destination` points to a directory, Terraform creates a file named `tf-file-content` inside the directory. We recommend setting the `destination` argument to a file when using `content` argument. Do not use the `content` argument and the [`source`](#source) argument in the same `provisioner "file"` block.
 
-You can specify a string value that contains an expression. You can't use the `source` argument and the [`content`](#content) argument in the same `provisioner "file"` block. 
+You can specify a string value that contains an expression. You can't use the `source` argument and the [`content`](#content) argument in the same `provisioner "file"` block.
 
 #### Summary
 
@@ -683,7 +683,7 @@ You can specify a string value that contains an expression. You can't use the `s
 
 ### `destination`
 
-The `destination` argument specifies a path on the remote resource that Terraform copies content to. You can use either [`source`](#source) or [`content`](#content) argument to provide content to the `destination` path. 
+The `destination` argument specifies a path on the remote resource that Terraform copies content to. You can use either [`source`](#source) or [`content`](#content) argument to provide content to the `destination` path.
 
 ```hcl
 resource {
@@ -696,15 +696,15 @@ resource {
 
 The remote system, not Terraform, evaluates the path you provide in the `destination` argument. As a result, valid values can vary depending on the operating system and remote access software running on the target.
 
-When the `type` argument in the [provisioner connection settings](#connection) is set to `ssh`, the provisioner passes the destination path as-is to the `scp` program on the remote host. By default, the OpenSSH `scp` implementation runs in the remote user's home directory. As a result, you can specify a relative path to upload into the home directory or an absolute path to upload to a different location. 
+When the `type` argument in the [provisioner connection settings](#connection) is set to `ssh`, the provisioner passes the destination path as-is to the `scp` program on the remote host. By default, the OpenSSH `scp` implementation runs in the remote user's home directory. As a result, you can specify a relative path to upload into the home directory or an absolute path to upload to a different location.
 
 The remote `scp` process runs with the access level of the user specified in the [provisioner connection settings](#connection), so permissions may prevent Terraform from writing directly to locations outside of the home directory.
 
-When the `type` argument in the [provisioner connection settings](#connection) is set to `winrm`, Terraform uses PowerShell to interpret the `destination` path. As a result, you must not use meta-characters that PowerShell might interpret. You should specifically avoid including untrusted external input in your `destination` argument because doing so can let arbitrary PowerShell code execute on the remote system. 
+When the `type` argument in the [provisioner connection settings](#connection) is set to `winrm`, Terraform uses PowerShell to interpret the `destination` path. As a result, you must not use meta-characters that PowerShell might interpret. You should specifically avoid including untrusted external input in your `destination` argument because doing so can let arbitrary PowerShell code execute on the remote system.
 
 Terraform performs the following process over WinRM connections:
 
-1. Generates a temporary filename in the directory set in the remote system's `TEMP` environment variable. 
+1. Generates a temporary filename in the directory set in the remote system's `TEMP` environment variable.
 1. Generates a sequence of `echo` commands to gradually append base64-encoded chunks of the source file to the temporary file.
 1. Uses an uploaded PowerShell script to read the temporary file, base64-decode, and write the raw result into the destination file.
 
@@ -718,7 +718,7 @@ Modern Windows systems support running an OpenSSH server, so we strongly recomme
 
 ### `command`
 
-The `command` argument specifies a command for a local executable to run. You can specify an absolute path or a relative path to the current working directory. 
+The `command` argument specifies a command for a local executable to run. You can specify an absolute path or a relative path to the current working directory.
 ```hcl
 resource {
   provisioner "local-exec" {
@@ -756,7 +756,7 @@ resource {
 
 ### `interpreter`
 
-The `interpreter` block specifies a list of interpreter arguments for running the executable specified in the [`command`](#command) argument. 
+The `interpreter` block specifies a list of interpreter arguments for running the executable specified in the [`command`](#command) argument.
 
 ```hcl
 resource {
@@ -777,7 +777,7 @@ The first argument in the list is a path to the interpreter. You can specify a r
 
 ### `environment`
 
-The `environment` block specifies a block of key value pairs that represent the environment for running the command specified in the [`command`](#command) argument. 
+The `environment` block specifies a block of key value pairs that represent the environment for running the command specified in the [`command`](#command) argument.
 
 ```hcl
 resource {
@@ -797,7 +797,7 @@ resource {
 
 ### `when`
 
-The `when` argument specifies a Terraform command that triggers actions specified in the provisioner. 
+The `when` argument specifies a Terraform command that triggers actions specified in the provisioner.
 
 ```hcl
 resource {
@@ -837,7 +837,7 @@ When `quiet` is set to `true`, Terraform prints `"Suppressed by quiet=true"` to
 - Data type: Boolean.
 - Default: None.
 
-### `inline` 
+### `inline`
 
 Specifies a list of command strings to execute on the remote resource.
 
@@ -860,7 +860,7 @@ The provisioner uses the remote resource's default shell unless you specify a sh
 
 ### `script`
 
-Specifies the relative or absolute path to a script on the local machine to copy and execute on the remote resource.  
+Specifies the relative or absolute path to a script on the local machine to copy and execute on the remote resource.
 
 
 ```hcl
@@ -905,7 +905,7 @@ The following examples show how to write configuration for common use cases.
 
 ### Define an AWS instance
 
-The following example defines an `aws_instance` resource named `web`. 
+The following example defines an `aws_instance` resource named `web`.
 
 ```hcl
 resource "aws_instance" "web" {
@@ -920,7 +920,7 @@ You can use either `count` or the `for_each` block to create multiple instances
 
 <Tabs>
 
-<Tab heading="count"> 
+<Tab heading="count">
 
 The following example creates one instance for each subnet provided in the input variable:
 
@@ -969,7 +969,7 @@ resource "aws_iam_user" "the-accounts" {
 }
 ```
 
-In the following example, the `module` block creates an instance of the `publish_bucket` module for each element in the `for_each` set. It uses the `each.key` attribute to create a unique name for each bucket.      
+In the following example, the `module` block creates an instance of the `publish_bucket` module for each element in the `for_each` set. It uses the `each.key` attribute to create a unique name for each bucket.
 
 <CodeBlockConfig filename="my_buckets.tf">
 
@@ -986,7 +986,7 @@ module "bucket" {
 <CodeBlockConfig filename="publish_bucket/bucket-and-cloudfront.tf">
 
 ```hcl
-variable "name" {} 
+variable "name" {}
 
 resource "aws_s3_bucket" "example" {
    bucket = var.name
@@ -997,8 +997,8 @@ resource "aws_iam_user" "deploy_user" {
    #...
 }
 ```
- 
-</CodeBlockConfig> 
+
+</CodeBlockConfig>
 
 </Tab>
 
@@ -1008,7 +1008,7 @@ resource "aws_iam_user" "deploy_user" {
 
 In the following example, the `aws_iam_instance_profile` resource references the `aws_iam_role` resource, instructing Terraform to create the upstream resource first. The `aws_iam_role_policy` resource configures an IAM policy that lets the EC2 instance access the S3 API.
 
-Terraform infers that it must create the instance profile before the EC2 instance, but it cannot infer that the software running in the EC2 instance needs access to the S3 API in order to boot properly. As a result, the configuration explicitly instructs Terraform to create the `aws_iam_role_policy` first: 
+Terraform infers that it must create the instance profile before the EC2 instance, but it cannot infer that the software running in the EC2 instance needs access to the S3 API in order to boot properly. As a result, the configuration explicitly instructs Terraform to create the `aws_iam_role_policy` first:
 
 ```hcl
 resource "aws_iam_role" "example" {
@@ -1024,7 +1024,7 @@ resource "aws_iam_role_policy" "example" {
   name   = "example"
   role   = aws_iam_role.example.name
   policy = jsonencode({
-    "Statement" = [{     
+    "Statement" = [{
       "Action" = "s3:*",
       "Effect" = "Allow",
     }],
@@ -1040,7 +1040,7 @@ resource "aws_instance" "example" {
   ]
 }
 
-data "aws_ami" "example" { 
+data "aws_ami" "example" {
   # AMI configuration
 }
 ```
@@ -1049,7 +1049,7 @@ Note that the `aws_iam_role` resource is partially defined. Refer to the [AWS pr
 
 ### Select an alternate provider configuration
 
-In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias. 
+In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias.
 
 ```hcl
 provider "google" {
@@ -1061,7 +1061,7 @@ provider "google" {
   region = "europe-west1"
 }
 
-resource "google_compute_instance" "example" {  
+resource "google_compute_instance" "example" {
   provider = google.europe
   # ...
 }
@@ -1089,7 +1089,7 @@ In the following example, Terraform replaces `aws_appautoscaling_target` each ti
 resource "aws_appautoscaling_target" "ecs_target" {
    ...
    lifecycle {
-   replace_triggered_by = [ 
+   replace_triggered_by = [
       aws_ecs_service.svc.id
      ]
    }
@@ -1098,7 +1098,7 @@ resource "aws_appautoscaling_target" "ecs_target" {
 
 ### Apply custom conditions
 
-The following example includes several configurations that illustrate how to define `precondition` and `postcondition` arguments in the `lifecycle` meta-argument. 
+The following example includes several configurations that illustrate how to define `precondition` and `postcondition` arguments in the `lifecycle` meta-argument.
 
 The following `data` block instructs Terraform to retrieve the ID of the `ami-abc123` AMI:
 
@@ -1192,7 +1192,7 @@ resource "aws_instance" "web" {
 
 You can configure provisioners to perform remote operations, such as executing scripts or running commands.
 
-In the following example, Terraform connects to the `web` instance using the `connection` settings so that the `remote-exec` provisioner can run the `puppet apply` and `consul join` commands on the resource: 
+In the following example, Terraform connects to the `web` instance using the `connection` settings so that the `remote-exec` provisioner can run the `puppet apply` and `consul join` commands on the resource:
 
 ```hcl
 resource "aws_instance" "web" {
@@ -1272,4 +1272,4 @@ resource "aws_instance" "web" {
     on_failure = continue
   }
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.12.x/docs/language/block/variable.mdx b/content/terraform/v1.12.x/docs/language/block/variable.mdx
new file mode 100644
index 000000000..81357cf1c
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/variable.mdx
@@ -0,0 +1,383 @@
+---
+page_title: variable block reference for the Terraform configuration language
+description: Use variables to parameterize your configuration, making your modules dynamic, reusable, and flexible by intaking values at run time.
+---
+
+# `variable` block reference
+
+Use the `variable` block to parameterize your configuration, making your modules dynamic, reusable, and flexible by letting them customize behavior with different values at run time.
+
+> **Hands-on:** Try the [Customize Terraform Configuration with Variables](/terraform/tutorials/configuration-language/variables) tutorial.
+
+## Background
+
+The `variable` block is similar to a function argument in other programming languages. Input variables let you customize Terraform modules without altering their source code. Variables serve as parameters for modules, making them composable and reusable.
+
+You can define variables in root modules, or in child modules:
+- In the root modules, you can set variable values using CLI options, environment variables, variable definition files, or through an HCP Terraform workspace.
+- In child modules, the parent module passes values to child modules as arguments to the `module` block.
+
+<!--TODO: Add a link to the define variable page once I write it.
+Learn more about the different ways to use and set values for variables, refer to [Define variables](/WIP-USAGE-PAGE).
+
+-->
+
+## Configuration model
+
+The `variable` block supports the following arguments:
+
+- [`variable "<LABEL>"`](#variable) &nbsp; block
+  - [`type`](#type) &nbsp; type constraint
+  - [`default`](#default) &nbsp; expression
+  - [`description`](#description) &nbsp; string
+  - [`validation`](#validation) &nbsp; block
+    - [`condition`](#validation) &nbsp; expression
+    - [`error_message`](#validation) &nbsp; string
+  - [`sensitive`](#sensitive) &nbsp; boolean
+  - [`nullable`](#nullable) &nbsp; boolean
+  - [`ephemeral`](#ephemeral) &nbsp; boolean
+
+## Complete configuration
+
+All available arguments are defined in the following `variable` block. There are no mutually exclusive arguments for a `variable` block.
+
+```hcl
+variable "<LABEL>" {
+  type        = <TYPE>
+  default     = <DEFAULT_VALUE>
+  description = "<DESCRIPTION>"
+  sensitive   = <true|false>
+  nullable    = <true|false>
+  ephemeral   = <true|false>
+
+  validation {
+    condition     = <EXPRESSION>
+    error_message = "<ERROR_MESSAGE>"
+  }
+}
+```
+
+## Specification
+
+A `variable` block supports the following configuration.
+
+### `variable "<LABEL>"`
+
+The label after the `variable` keyword is a name for the variable, which must be unique among all variables in the same module. The name of a variable can be any valid [identifier](/terraform/language/syntax/configuration#identifiers) except the following reserved names: `source`, `version`, `providers`, `count`, `for_each`, `lifecycle`, `depends_on`, or `locals`.
+
+The following arguments are supported in a `variable` block:
+
+| Argument | Description | Type | Required? |
+| --- | --- | --- | --- |
+| `type` | Specify a type constraint for the value argument of this variable. | Type constraint | Optional |
+| `default` | Sets the default value for this variable. Variables without a default value are required to define a value argument. | Expression | Optional |
+| `description` | A description of the variable’s purpose and the value it expects. | String | Optional |
+| `validation` | Specify a rule the value of this variable must meet, in addition to any type constraints. | Block | Optional |
+| `sensitive` | Specifies if Terraform hides this value in CLI output. | Boolean | Optional |
+| `nullable` | Specifies if the value of a variable can be `null`. | Boolean | Optional |
+| `ephemeral` | Specifies whether to prevent storing this value in state or plan files. | Boolean | Optional |
+
+### `type`
+
+The `type` argument in a `variable` block constrains the type of value that you can assign to that variable. If you do not set a type constraint, the variable accepts a value of any type.
+
+```hcl
+variable "unique_name" {
+  type = <type-constraint>
+}
+```
+
+Defining type constraints helps your module consumer understand what value your variable needs, and type constraints also provide helpful error messages if consumers attempt to use an invalid type.
+
+You can use any valid primitive, complex, or structural type as a constraint in a variable block. For details about types, constructors, and conversions, refer to [Type constraints](/terraform/language/expressions/types).
+
+#### Summary
+
+- Data type: Type constraint
+- Default: `any`
+- Example: [Basic variable declaration](#basic-variable-declaration)
+
+### `default`
+
+The `default` argument defines a default value for the variable, making it optional to provide a value. If you do not provide a variable value when using a module, Terraform uses the default value.
+
+
+```hcl
+variable "region" {
+  type    = string
+  default = <default-value>
+}
+```
+
+If you specify both the `type` and `default` arguments, the default value must convert to the specified type. The `default` argument requires a literal value and cannot reference other objects in the configuration.
+
+#### Summary
+
+- Data type: Expression
+- Default: None, but you must define a value argument if you do not define a default argument.
+- Example: [Basic variable declaration](#basic-variable-declaration)
+
+### `description`
+
+The `description` argument in a `variable` block documents the purpose of a variable and the value the block expects.
+
+```hcl
+variable "image_id" {
+  type        = string
+  description = "<description-from-the-module-consumer-point-of-view>”
+}
+```
+
+Write your description from the perspective of a module consumer to help your users understand how to use this variable. If you need to leave commentary about a variable block as a module maintainer, use a comment instead.
+
+#### Summary
+
+- Data type: String
+- Default: None
+- Example: [Basic variable declaration](#basic-variable-declaration)
+
+
+### `validation`
+
+The `validation` block lets you enforce that a variable value meets your specific requirements, in addition to any type constraints. Use variable validations to guarantee a variable meets your configuration’s needs before Terraform finishes generating a plan.
+
+```hcl
+variable "unique_name" {
+  value  = <expression-to-evaluate>
+
+  validation {
+    condition     = <expression-to-verify>
+    error_message = "<error message string>"
+  }
+}
+```
+
+You can specify the following arguments in the `validation` block:
+
+| Argument | Description | Type | Required |
+| --- | --- | --- | --- |
+| `condition` | Expression that must evaluate to `true` for Terraform to proceed with an operation. | A valid [Conditional expression](/terraform/language/expressions/conditionals). | Required |
+| `error_message` | Message to display if the condition evaluates to false. | String | Required |
+
+Terraform evaluates variable validations while it creates a plan, and if a validation block's `condition` expression evaluates to `false`, then Terraform throws an error, displays the `error_message`, and stops the current operation. Refer to [Validate your configuration](/terraform/language/test-and-validate/validate#input-variable-validation) for more details and examples.
+
+#### Summary
+
+- Data type: Block
+- Default: None
+- Example: [Variable with validation](#variable-with-validation)
+
+### `sensitive`
+
+
+The `sensitive` argument prevents Terraform from showing a variable block's value in CLI output when you use that variable in your configuration.
+
+```hcl
+variable "user_password" {
+  type      = string
+  sensitive = true
+}
+```
+
+When you mark a variable as sensitive, Terraform redacts its value in plan and apply logs. Terraform also treats any expressions that use a sensitive variable as sensitive.
+
+```hcl
+Terraform will perform the following actions:
+
+  # some_resource.a will be created
+  + resource "some_resource" "a" {
+      + user_password = (sensitive value)
+    }
+
+Plan: 1 to add, 0 to change, 0 to destroy.
+```
+
+Terraform still records sensitive values in state, so anyone who can access your state data can access your sensitive values. For more information about safely storing sensitive data, refer to [Sensitive data in state](/terraform/language/state/sensitive-data).
+
+#### Summary
+
+- Data type: Boolean
+- Default: `false`
+- Example: [Sensitive variable](#sensitive-variable)
+
+### `nullable`
+
+Enabling the `nullable` argument lets module consumers assign the value `null` to the variable.
+
+```hcl
+variable "example" {
+  type     = string
+  nullable = false
+}
+```
+
+If `nullable` is `false` in a variable block, then that variable must have a value that is not null. If nullable is true and the variable has a `default` argument, you can explicitly set the variable value to null, overwriting the default argument.
+
+If a variable uses a collection or structural type, such as a list or object, a module consumer can  use `null` in nested elements as long as the collection or structure itself is not null.
+
+#### Summary
+
+- Data type: Boolean
+- Default: `true`
+
+### `ephemeral`
+
+<Note>
+
+Ephemeral variables are available in Terraform v1.10 and later.
+
+</Note>
+
+The `ephemeral` argument makes a variable available during runtime, but Terraform omits ephemeral values from state and plan files. The `ephemeral` argument is useful for values that only exist temporarily, such as a short-lived token or session identifier.
+
+```hcl
+variable "session_token" {
+  type      = string
+  ephemeral = true
+}
+```
+
+You can reference and set ephemeral variables values from specific contexts:
+- An [`output` block](/terraform/language/block/output#ephemeral) with the ephemeral argument
+- In another variable block with the ephemeral argument
+- A [write-only argument](/terraform/language/resources/ephemeral/write-only) in a resource block
+- [An `ephemeral` resource block](/terraform/language/resources/ephemeral)
+- In the [`provider` block](/terraform/language/providers) to configure providers
+- In [provisioner](/terraform/language/resources/provisioners/syntax) and [connection](/terraform/language/resources/provisioners/connection) blocks
+
+If another expression references a variable with the `ephemeral` argument, that expression also implicitly becomes ephemeral.
+
+#### Summary
+
+- Data type: Boolean
+- Default: `false`
+- Example: [Ephemeral variable](#ephemeral-variable)
+
+## Examples
+
+The following examples demonstrate common use cases for `variable` blocks.
+
+### Basic variable declaration
+
+In the following example, the image_id variable requires a string value and has no default, making it required. The availability_zone_names variable accepts a list of strings and provides a default value, making it optional for users to provide a value for this variable:
+
+```hcl
+variable "image_id" {
+  type        = string
+  description = "The ID of the machine image (AMI) to use for the server."
+}
+
+variable "availability_zone_names" {
+  type        = list(string)
+  description = "List of availability zones where resources will be deployed."
+  default     = ["us-west-1a"]
+}
+```
+
+### Set a value to a complex type
+
+In the following example, the `docker_ports` variable accepts a list of objects where each object must have `internal` and `external` number attributes and a `protocol` string attribute:
+
+```hcl
+variable "docker_ports" {
+  type = list(object({
+    internal = number
+    external = number
+    protocol = string
+  }))
+  description = "List of port configurations for Docker containers."
+  default = [
+    {
+      internal = 8300
+      external = 8300
+      protocol = "tcp"
+    }
+  ]
+}
+```
+
+### Variable with validation
+In the following example, the validation block ensures that the `image_id` value is longer than 4 characters and starts with "ami-". If the variable value does not meet the condition, Terraform displays the specified error message:
+
+```hcl
+variable "image_id" {
+  type        = string
+  description = "The ID of the machine image (AMI) to use for the server."
+
+  validation {
+    condition     = length(var.image_id) > 4 && substr(var.image_id, 0, 4) == "ami-"
+    error_message = "The image_id value must be a valid AMI ID, starting with \"ami-\"."
+  }
+}
+```
+
+### Sensitive variable
+
+In the following example, the `database_password` variable is marked as sensitive, which causes Terraform to redact both the variable value and any resource attributes that use it from logs:
+
+```hcl
+variable "database_password" {
+  type        = string
+  description = "Password for the database instance."
+  sensitive   = true
+}
+
+resource "aws_db_instance" "example" {
+  identifier = "my-database"
+  engine     = "mysql"
+  username   = "admin"
+  password   = var.database_password
+  # …
+}
+```
+
+When you run a plan or apply operation, Terraform displays sensitive values as `(sensitive value)`. Terraform obscures both the database_password variable and any resource arguments that use that variable, for example Terraform logs the following when applying the configuration:
+
+```shell-session
+Terraform will perform the following actions:
+
+  # aws_db_instance.example will be created
+  + resource "aws_db_instance" "example" {
+      + identifier = "my-database"
+      + engine     = "mysql"
+      + username   = "admin"
+      + password   = (sensitive value)
+    }
+
+Plan: 1 to add, 0 to change, 0 to destroy.
+```
+
+Any expression that references a sensitive variable becomes sensitive automatically.
+
+
+### Ephemeral variable
+
+The following example configures the AWS provider by referencing credentials from three separate variables containing sensitive data. The `access_key`, `secret_key`, and  `session_token` variables are `ephemeral`, so they are available during Terraform operations, but are not stored in state or plan files afterwards.
+
+```hcl
+variable "access_key" {
+  description = "AWS access key"
+  type     = string
+  ephemeral = true
+}
+
+variable "secret_key" {
+  description = "AWS sensitive secret key."
+  type     = string
+  sensitive = true
+  ephemeral = true
+}
+
+variable "session_token" {
+  description = "AWS session token."
+  type     = string
+  sensitive = true
+  ephemeral = true
+}
+
+provider "aws" {
+  access_key = var.access_key
+  secret_key = var.secret_key
+  token      = var.session_token
+}
+```
diff --git a/content/terraform/v1.12.x/docs/language/expressions/function-calls.mdx b/content/terraform/v1.12.x/docs/language/expressions/function-calls.mdx
index 556db72d6..b98339c14 100644
--- a/content/terraform/v1.12.x/docs/language/expressions/function-calls.mdx
+++ b/content/terraform/v1.12.x/docs/language/expressions/function-calls.mdx
@@ -52,7 +52,7 @@ The expansion symbol is three periods (`...`), not a Unicode ellipsis character
 
 ## Using Sensitive Data as Function Arguments
 
-When using sensitive data, such as [an input variable](/terraform/language/values/variables#suppressing-values-in-cli-output)
+When using sensitive data, such as [an input variable](/terraform/language/block/variable#sensitive)
 or [an output defined](/terraform/language/block/output#sensitive) as sensitive
 as function arguments, the result of the function call will be marked as sensitive.
 
diff --git a/content/terraform/v1.12.x/docs/language/expressions/references.mdx b/content/terraform/v1.12.x/docs/language/expressions/references.mdx
index 954efdc82..0eeebdcd1 100644
--- a/content/terraform/v1.12.x/docs/language/expressions/references.mdx
+++ b/content/terraform/v1.12.x/docs/language/expressions/references.mdx
@@ -61,7 +61,7 @@ For more information about how to use resource references, see
 
 ### Input Variables
 
-`var.<NAME>` is the value of the [input variable](/terraform/language/values/variables) of the given name.
+`var.<NAME>` is the value of the [input variable](/terraform/language/block/variable) of the given name.
 
 If the variable has a type constraint (`type` argument) as part of its
 declaration, Terraform will automatically convert the caller's given value
@@ -182,7 +182,7 @@ where they appear. Some of most common local names are:
 
 -> **Note:** Local names are often referred to as _variables_ or
 _temporary variables_ in their documentation. These are not [input
-variables](/terraform/language/values/variables); they are just arbitrary names
+variables](/terraform/language/block/variable); they are just arbitrary names
 that temporarily represent a value.
 
 The names in this section relate to top-level configuration blocks only.
@@ -295,12 +295,13 @@ certain attributes as _sensitive_, in which case Terraform will show a
 placeholder marker `(sensitive value)` instead of the actual value when rendering
 a plan involving that attribute.
 
+<!-- TODO: add link to new variable usage page once done - sensitive -->
 A provider attribute marked as sensitive behaves similarly to
-[an input variable declared as sensitive](/terraform/language/values/variables#suppressing-values-in-cli-output),
+[an input variable declared as sensitive](/terraform/language/block/variable#sensitive),
 where Terraform will hide the value in the plan and apply messages and will
 also hide any other values you derive from it as sensitive.
 However, there are some limitations to that behavior as described in
-[Cases where Terraform may disclose a sensitive variable](/terraform/language/values/variables#cases-where-terraform-may-disclose-a-sensitive-variable).
+[Cases where Terraform may disclose a sensitive variable](/terraform/language/block/variable#cases-where-terraform-may-disclose-a-sensitive-variable).
 
 If you use a sensitive value from a resource attribute as part of an
 [output value](/terraform/language/block/output) then Terraform will require
diff --git a/content/terraform/v1.12.x/docs/language/expressions/type-constraints.mdx b/content/terraform/v1.12.x/docs/language/expressions/type-constraints.mdx
index cef8cb50f..a0d7b0c28 100644
--- a/content/terraform/v1.12.x/docs/language/expressions/type-constraints.mdx
+++ b/content/terraform/v1.12.x/docs/language/expressions/type-constraints.mdx
@@ -27,7 +27,7 @@ function-like constructs called _type constructors._
 Type constraints look like other kinds of Terraform
 [expressions](/terraform/language/expressions), but are a special syntax. Within the
 Terraform language, they are only valid in the `type` argument of an
-[input variable](/terraform/language/values/variables).
+[input variable](/terraform/language/block/variable).
 
 ## Primitive Types
 
@@ -89,17 +89,17 @@ The three kinds of collection type in the Terraform language are:
   compatibility with older configurations; for new code, we recommend using
   the full form.
 
-  You can use the following characters to define maps: 
-      - `{}` 
-      - `:` 
-      - `=` 
-  For example, `{ "foo": "bar", "bar": "baz" }` and  `{ foo = "bar", bar = "baz" }` define the same map. 
+  You can use the following characters to define maps:
+      - `{}`
+      - `:`
+      - `=`
+  For example, `{ "foo": "bar", "bar": "baz" }` and  `{ foo = "bar", bar = "baz" }` define the same map.
   You must place map keys in quotation marks when a key starts with a number, contains spaces, or contains special characters. Otherwise, you can omit them.
-  You must place commas between keys-value pairs in single-line maps. 
+  You must place commas between keys-value pairs in single-line maps.
   You can place key-value pairs in multi-line maps on new lines.
 
   -> **Note:** Although colons are valid delimiters between keys and values, `terraform fmt` ignores them. In contrast, `terraform fmt` attempts to vertically align equals signs.
-  
+
 * `set(...)`: a collection of unique values that do not have any secondary
   identifiers or ordering.
 
diff --git a/content/terraform/v1.12.x/docs/language/functions/can.mdx b/content/terraform/v1.12.x/docs/language/functions/can.mdx
index c02f08207..021e08038 100644
--- a/content/terraform/v1.12.x/docs/language/functions/can.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/can.mdx
@@ -17,7 +17,7 @@ fallback values for failing expressions.
 
 The primary purpose of `can` is to turn an error condition into a boolean
 validation result when writing
-[custom variable validation rules](/terraform/language/values/variables#custom-validation-rules).
+[variable validation](/terraform/language/block/variable#validation).
 For example:
 
 ```hcl
diff --git a/content/terraform/v1.12.x/docs/language/functions/ephemeralasnull.mdx b/content/terraform/v1.12.x/docs/language/functions/ephemeralasnull.mdx
index 4c9379836..4a000cef4 100644
--- a/content/terraform/v1.12.x/docs/language/functions/ephemeralasnull.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/ephemeralasnull.mdx
@@ -37,7 +37,7 @@ output "example_output" {
 }
 ```
 
-For more information on which Terraform blocks can be ephemeral, refer to ephemeral [inputs](/terraform/language/values/variables#exclude-values-from-state), [outputs](/terraform/language/block/output#ephemeral), and [resources](/terraform/language/resources/ephemeral).
+For more information on which Terraform blocks can be ephemeral, refer to ephemeral [inputs](/terraform/language/block/variable#ephemeral), [outputs](/terraform/language/block/output#ephemeral), and [resources](/terraform/language/resources/ephemeral).
 
 ## Example use case
 
diff --git a/content/terraform/v1.12.x/docs/language/functions/issensitive.mdx b/content/terraform/v1.12.x/docs/language/functions/issensitive.mdx
index 913edaab4..d65488603 100644
--- a/content/terraform/v1.12.x/docs/language/functions/issensitive.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/issensitive.mdx
@@ -9,11 +9,11 @@ description: The issensitive function true if the value passed is marked as sens
 
 `issensitive` takes any value and returns true if Terraform
 treats it as sensitive, with the same meaning and behavior as for
-[sensitive input variables](/terraform/language/values/variables#suppressing-values-in-cli-output).
+[sensitive input variables](/terraform/language/block/variable#sensitive).
 
 If a value not marked as sensitive is passed the function returns false.
 
-See [`sensitive`](/terraform/language/functions/sensitive), [`nonsensitive`](/terraform/language/functions/nonsensitive), and [sensitive input variables](/terraform/language/values/variables#suppressing-values-in-cli-output) for more information on sensitive values.
+See [`sensitive`](/terraform/language/functions/sensitive), [`nonsensitive`](/terraform/language/functions/nonsensitive), and [sensitive input variables](/terraform/language/block/variable#sensitive) for more information on sensitive values.
 
 ## Examples
 
diff --git a/content/terraform/v1.12.x/docs/language/functions/sensitive.mdx b/content/terraform/v1.12.x/docs/language/functions/sensitive.mdx
index 2aeb2da17..90779d8ab 100644
--- a/content/terraform/v1.12.x/docs/language/functions/sensitive.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/sensitive.mdx
@@ -9,7 +9,7 @@ description: The sensitive function marks a value as being sensitive.
 
 `sensitive` takes any value and returns a copy of it marked so that Terraform
 will treat it as sensitive, with the same meaning and behavior as for
-[sensitive input variables](/terraform/language/values/variables#suppressing-values-in-cli-output).
+[sensitive input variables](/terraform/language/block/variable#sensitive).
 
 Wherever possible we recommend marking your input variable and/or output value
 declarations as sensitive directly, instead of using this function, because in
diff --git a/content/terraform/v1.12.x/docs/language/functions/terraform-applying.mdx b/content/terraform/v1.12.x/docs/language/functions/terraform-applying.mdx
index 7a9f2a98f..1331996e2 100644
--- a/content/terraform/v1.12.x/docs/language/functions/terraform-applying.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/terraform-applying.mdx
@@ -35,7 +35,7 @@ provider "aws" {
 The `terraform.applying` symbol is an ephemeral value and is only available during Terraform operations. Terraform does not write ephemeral values to plan or state files. Additionally, you can only reference `terraform.applying` in the following ephemeral contexts:
 
 - In a [write-only argument](/terraform/language/resources/ephemeral/write-only)
-- In [ephemeral variables](/terraform/language/values/variables#exclude-values-from-state)
+- In [ephemeral variables](/terraform/language/block/variable#ephemeral)
 - In [local values](/terraform/language/values/locals#ephemeral-values)
 - In [ephemeral resources](/terraform/language/resources/ephemeral)
 - In [ephemeral outputs](/terraform/language/block/output#ephemeral)
diff --git a/content/terraform/v1.12.x/docs/language/functions/terraform-decode_tfvars.mdx b/content/terraform/v1.12.x/docs/language/functions/terraform-decode_tfvars.mdx
index 6bd7d6c8c..4c125aa80 100644
--- a/content/terraform/v1.12.x/docs/language/functions/terraform-decode_tfvars.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/terraform-decode_tfvars.mdx
@@ -9,9 +9,11 @@ description: >-
 
 -> **Note:** This function is supported only in Terraform v1.8 and later.
 
+<!-- TODO: add link to new variable usage page once done -->
+
 `provider::terraform::decode_tfvars` is a rarely-needed function which takes
 a string containing the content of a
-[`.tfvars` file](/terraform/language/values/variables#variable-definitions-tfvars-files)
+[`.tfvars` file](/terraform/language/block/variable#variable-definitions-tfvars-files)
 and returns an object describing the raw variable values it defines.
 
 To use this function, your module must declare a dependency on the built-in
diff --git a/content/terraform/v1.12.x/docs/language/functions/terraform-encode_tfvars.mdx b/content/terraform/v1.12.x/docs/language/functions/terraform-encode_tfvars.mdx
index c7e36d1c4..7f1505012 100644
--- a/content/terraform/v1.12.x/docs/language/functions/terraform-encode_tfvars.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/terraform-encode_tfvars.mdx
@@ -9,10 +9,12 @@ description: >-
 
 -> **Note:** This function is supported only in Terraform v1.8 and later.
 
+<!-- TODO: add link to new variable usage page once done -->
+
 `provider::terraform::encode_tfvars` is a rarely-needed function which takes
 an object value and produces a string containing a description of that object
 using the same syntax as Terraform CLI would expect in a
-[`.tfvars` file](/terraform/language/values/variables#variable-definitions-tfvars-files).
+[`.tfvars` file](/terraform/language/block/variable#variable-definitions-tfvars-files).
 
 In most cases it's better to pass data between Terraform configurations using
 [Data Sources](/terraform/language/data-sources),
@@ -49,7 +51,7 @@ example = "Hello!"
 Due to Terraform's requirements for the `.tfvars` format, all of the attributes
 of the given object must be valid Terraform variable names, as would be
 accepted in an
-[input variable declaration](/terraform/language/values/variables#declaring-an-input-variable).
+[input variable declaration](/terraform/language/block/variable#basic-variable-declaration).
 
 The `.tfvars` format is specific to Terraform and so we do not recommend using
 it as a general serialization format.
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/for_each.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/for_each.mdx
index a7db1fcfd..3c653d1b7 100644
--- a/content/terraform/v1.12.x/docs/language/meta-arguments/for_each.mdx
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/for_each.mdx
@@ -109,7 +109,7 @@ that cannot be determined before apply, and a `-target` may be needed.
 including `uuid`, `bcrypt`, or `timestamp`, as their evaluation is deferred during the
 main evaluation step.
 
-Sensitive values, such as [sensitive input variables](/terraform/language/values/variables#suppressing-values-in-cli-output),
+Sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive),
 [sensitive outputs](/terraform/language/block/output#sensitive),
 or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes),
 cannot be used as arguments to `for_each`. The value used in `for_each` is used
@@ -256,7 +256,7 @@ removes any duplicate elements. `toset(["b", "a", "b"])` will produce a set
 containing only `"a"` and `"b"` in no particular order; the second `"b"` is
 discarded.
 
-If you are writing a module with an [input variable](/terraform/language/values/variables) that
+If you are writing a module with an [input variable](/terraform/language/block/variable) that
 will be used as a set of strings for `for_each`, you can set its type to
 `set(string)` to avoid the need for an explicit type conversion:
 
diff --git a/content/terraform/v1.12.x/docs/language/modules/develop/index.mdx b/content/terraform/v1.12.x/docs/language/modules/develop/index.mdx
index 5081eb6d8..b437cb4ac 100644
--- a/content/terraform/v1.12.x/docs/language/modules/develop/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/modules/develop/index.mdx
@@ -30,7 +30,7 @@ Re-usable modules are defined using all of the same
 [configuration language](/terraform/language) concepts we use in root modules.
 Most commonly, modules use:
 
-* [Input variables](/terraform/language/values/variables) to accept values from
+* [Input variables](/terraform/language/block/variable) to accept values from
   the calling module.
 * [Output values](/terraform/language/block/output) to return results to the
   calling module, which it can then use to populate arguments elsewhere.
diff --git a/content/terraform/v1.12.x/docs/language/modules/develop/structure.mdx b/content/terraform/v1.12.x/docs/language/modules/develop/structure.mdx
index df07d7cd1..d79a44a52 100644
--- a/content/terraform/v1.12.x/docs/language/modules/develop/structure.mdx
+++ b/content/terraform/v1.12.x/docs/language/modules/develop/structure.mdx
@@ -55,7 +55,7 @@ don't need to do any extra work to follow the standard structure.
 * **Variables and outputs should have descriptions.** All variables and
   outputs should have one or two sentence descriptions that explain their
   purpose. This is used for documentation. See the documentation for
-  [variable configuration](/terraform/language/values/variables) and
+  [variable configuration](/terraform/language/block/variable) and
   [output configuration](/terraform/language/block/output) for more details.
 
 * **Nested modules**. Nested modules should exist under the `modules/`
diff --git a/content/terraform/v1.12.x/docs/language/modules/syntax.mdx b/content/terraform/v1.12.x/docs/language/modules/syntax.mdx
index ca4facc2b..5b76f89d6 100644
--- a/content/terraform/v1.12.x/docs/language/modules/syntax.mdx
+++ b/content/terraform/v1.12.x/docs/language/modules/syntax.mdx
@@ -29,7 +29,7 @@ about creating re-usable child modules, see [Module Development](/terraform/lang
 
 To _call_ a module means to include the contents of that module into the
 configuration with specific values for its
-[input variables](/terraform/language/values/variables). Modules are called
+[input variables](/terraform/language/block/variable). Modules are called
 from within other modules using `module` blocks:
 
 ```hcl
@@ -53,7 +53,7 @@ Module calls use the following kinds of arguments:
 
 - The `version` argument is recommended for modules from a registry.
 
-- Most other arguments correspond to [input variables](/terraform/language/values/variables)
+- Most other arguments correspond to [input variables](/terraform/language/block/variable)
   defined by the module. (The `servers` argument in the example above is one of
   these.)
 
diff --git a/content/terraform/v1.12.x/docs/language/resources/ephemeral/reference.mdx b/content/terraform/v1.12.x/docs/language/resources/ephemeral/reference.mdx
index 7842e12ad..09469e4a6 100644
--- a/content/terraform/v1.12.x/docs/language/resources/ephemeral/reference.mdx
+++ b/content/terraform/v1.12.x/docs/language/resources/ephemeral/reference.mdx
@@ -54,7 +54,7 @@ ephemeral resources:
 * In a [write-only argument](/terraform/language/resources/ephemeral/write-only)
 * In another ephemeral resource
 * In [local values](/terraform/language/values/locals#ephemeral-values)
-* In [ephemeral variables](/terraform/language/values/variables#exclude-values-from-state)
+* In [ephemeral variables](/terraform/language/block/variable#ephemeral)
 * In [ephemeral outputs](/terraform/language/block/output#ephemeral)
 * Configuring providers in the `provider` block
 * In [provisioner](/terraform/language/resources/provisioners/syntax) and [connection](/terraform/language/resources/provisioners/connection) blocks
diff --git a/content/terraform/v1.12.x/docs/language/resources/provisioners/connection.mdx b/content/terraform/v1.12.x/docs/language/resources/provisioners/connection.mdx
index 8822f7188..1c46a5a28 100644
--- a/content/terraform/v1.12.x/docs/language/resources/provisioners/connection.mdx
+++ b/content/terraform/v1.12.x/docs/language/resources/provisioners/connection.mdx
@@ -41,7 +41,7 @@ more predictable.
 The configuration for a `connection` block may use ephemeral values, such as
 [`ephemeral` resources](/terraform/language/resources/ephemeral), [`ephemeral`
 local values](/terraform/language/values/locals#ephemeral-values), [`ephemeral`
-variables](/terraform/language/values/variables#ephemeral), or [`ephemeral`
+variables](/terraform/language/block/variable#ephemeral), or [`ephemeral`
 output
 values](/terraform/language/block/output#ephemeral).
 
diff --git a/content/terraform/v1.12.x/docs/language/resources/provisioners/syntax.mdx b/content/terraform/v1.12.x/docs/language/resources/provisioners/syntax.mdx
index 9e06a657e..f85d5a8e8 100644
--- a/content/terraform/v1.12.x/docs/language/resources/provisioners/syntax.mdx
+++ b/content/terraform/v1.12.x/docs/language/resources/provisioners/syntax.mdx
@@ -231,7 +231,7 @@ block would create a dependency cycle.
 The configuration for a `provisioner` block may use ephemeral values, such as
 [`ephemeral` resources](/terraform/language/resources/ephemeral), [`ephemeral`
 local values](/terraform/language/values/locals#ephemeral-values), [`ephemeral`
-variables](/terraform/language/values/variables#ephemeral), or [`ephemeral`
+variables](/terraform/language/block/variable#ephemeral), or [`ephemeral`
 output
 values](/terraform/language/block/output#ephemeral).
 
@@ -241,7 +241,7 @@ logs.
 ### Sensitive values
 
 The configuration for a `provisioner` block may use sensitive values, such as
-[`sensitive` variables](/terraform/language/values/variables#suppressing-values-in-cli-output)
+[`sensitive` variables](/terraform/language/block/variable#sensitive)
 or [`sensitive` output values](/terraform/language/block/output#sensitive).
 Terraform suppresses sensitive values in all log output.
 
diff --git a/content/terraform/v1.12.x/docs/language/resources/terraform-data.mdx b/content/terraform/v1.12.x/docs/language/resources/terraform-data.mdx
index 4e82c4481..b2713a7ea 100644
--- a/content/terraform/v1.12.x/docs/language/resources/terraform-data.mdx
+++ b/content/terraform/v1.12.x/docs/language/resources/terraform-data.mdx
@@ -7,7 +7,7 @@ description: >-
 
 # The `terraform_data` Managed Resource Type
 
-The `terraform_data` implements the standard resource lifecycle, but does not directly take any other actions. 
+The `terraform_data` implements the standard resource lifecycle, but does not directly take any other actions.
 You can use the `terraform_data` resource without requiring or configuring a provider. It is always available through a built-in provider with the [source address](/terraform/language/providers/requirements#source-addresses) `terraform.io/builtin/terraform`.
 
 The `terraform_data` resource is useful for storing values which need to follow a manage resource lifecycle, and for triggering provisioners when there is no other logical managed resource in which to place them.
@@ -18,7 +18,7 @@ The `terraform_data` resource is useful for storing values which need to follow
 
 [The `replace_triggered_by` lifecycle argument](/terraform/language/meta-arguments/lifecycle#replace_triggered_by) requires all of the given addresses to be for resources, because the decision to force replacement is based on the planned actions for all of the mentioned resources.
 
-Plain data values such as [Local Values](/terraform/language/values/locals) and [Input Variables](/terraform/language/values/variables) don't have any side-effects to plan against and so they aren't valid in `replace_triggered_by`. You can use `terraform_data`'s behavior of planning an action each time `input` changes to _indirectly_ use a plain value to trigger replacement.
+Plain data values such as [Local Values](/terraform/language/values/locals) and [Input Variables](/terraform/language/block/variable) don't have any side-effects to plan against and so they aren't valid in `replace_triggered_by`. You can use `terraform_data`'s behavior of planning an action each time `input` changes to _indirectly_ use a plain value to trigger replacement.
 
 
 ```hcl
diff --git a/content/terraform/v1.12.x/docs/language/stacks/reference/tfstack.mdx b/content/terraform/v1.12.x/docs/language/stacks/reference/tfstack.mdx
index 4f6d1ce52..0f68a89d2 100644
--- a/content/terraform/v1.12.x/docs/language/stacks/reference/tfstack.mdx
+++ b/content/terraform/v1.12.x/docs/language/stacks/reference/tfstack.mdx
@@ -70,7 +70,7 @@ To learn more about breaking down your infrastructure into components, refer to
 
 Use the `variable` block to declare input variables for your Stack configuration. Using `variable` blocks in Stacks is similar to traditional Terraform configurations but with a few minor differences.
 
-In Stack configurations, `variable` blocks must define a `type` field and do not support the `validation` argument. Learn more about Terraform [Variables](/terraform/language/values/variables).
+In Stack configurations, `variable` blocks must define a `type` field and do not support the `validation` argument. Learn more about Terraform [Variables](/terraform/language/block/variable).
 
 ### Complete configuration
 
@@ -96,7 +96,7 @@ This section provides details about the fields you can configure in the `variabl
 | `default` | A default value for the variable which Terraform uses if no value is provided. | any | Optional |
 | `sensitive` | Marks the variable as sensitive, which prevents its value from being displayed in logs or in the HCP Terraform user interface. | bool | Optional |
 | `nullable` | Specifies whether the variable can be null. | bool | Optional |
-| `ephemeral` | Marks that this variable’s value is dynamic. For example, an expiring authentication token is `ephemeral`. Learn more about [Ephemeral variables](/terraform/language/values/variables#exclude-values-from-state). | bool | Optional |
+| `ephemeral` | Marks that this variable’s value is dynamic. For example, an expiring authentication token is `ephemeral`. Learn more about [Ephemeral variables](/terraform/language/block/variable#ephemeral). | bool | Optional |
 
 ## `output` block configuration
 
diff --git a/content/terraform/v1.12.x/docs/language/state/sensitive-data.mdx b/content/terraform/v1.12.x/docs/language/state/sensitive-data.mdx
index fd758b421..e78cdc4a0 100644
--- a/content/terraform/v1.12.x/docs/language/state/sensitive-data.mdx
+++ b/content/terraform/v1.12.x/docs/language/state/sensitive-data.mdx
@@ -19,7 +19,7 @@ When using [remote state](/terraform/language/state/remote), state is only ever
 
 Terraform allows you to mark variables and outputs as ephemeral. Providers can also support specific `ephemeral` resources. Ephemerality in Terraform means that the data of a block is available during runtime, but Terraform does not write that data to state or plan files. The `ephemeral` property is helpful when managing credentials, tokens, or other temporary resources you do not want to store in Terraform state files.
 
-Learn more about defining ephemeral [input variables](/terraform/language/values/variables#exclude-values-from-state), [outputs](/terraform/language/block/output#ephemeral), and [resources](/terraform/language/resources/ephemeral).
+Learn more about defining ephemeral [input variables](/terraform/language/block/variable#ephemeral), [outputs](/terraform/language/block/output#ephemeral), and [resources](/terraform/language/resources/ephemeral).
 
 ## Recommendations
 
diff --git a/content/terraform/v1.12.x/docs/language/style.mdx b/content/terraform/v1.12.x/docs/language/style.mdx
index 2991475b0..5ee92d09e 100644
--- a/content/terraform/v1.12.x/docs/language/style.mdx
+++ b/content/terraform/v1.12.x/docs/language/style.mdx
@@ -7,7 +7,7 @@ description: >-
 
 # Style Guide
 
-The flexibility of Terraform's configuration language gives you many options to choose from as you write your code, structure your directories, and test your configuration. While some design decisions depend on your organization's needs or preferences, there are some common patterns that we suggest you adopt. Adopting and adhering to a style guide keeps your Terraform code legible, scalable, and maintainable. 
+The flexibility of Terraform's configuration language gives you many options to choose from as you write your code, structure your directories, and test your configuration. While some design decisions depend on your organization's needs or preferences, there are some common patterns that we suggest you adopt. Adopting and adhering to a style guide keeps your Terraform code legible, scalable, and maintainable.
 
 This article discusses best practices and some considerations to keep in mind as you develop your organization's style guide. The article is split into two sections. The first section covers code style recommendations, such as formatting and resource organization. The second section covers operations and workflow recommendations, such as lifecycle management through meta-arguments, versioning, and sensitive data management.
 
@@ -18,7 +18,7 @@ Writing Terraform code in a consistent style makes it easier to read and maintai
 - Run `terraform fmt` and `terraform validate` before committing your code to version control.
 - Use a linter such as [TFLint](https://github.com/terraform-linters/tflint) to enforce your organization's own coding best practices.
 - Use `#` for single and multi-line comments.
-- Use nouns for resource names and do not include the resource type in the name. 
+- Use nouns for resource names and do not include the resource type in the name.
 - Use underscores to separate multiple words in names. Wrap the resource type and name in double quotes in your resource definition.
 - Let your code build on itself: define dependent resources after the resources they reference.
 - Include a type and description for every variable.
@@ -46,7 +46,7 @@ The Terraform parser allows you some flexibility in how you lay out the elements
 - When both arguments and blocks appear together inside a block body, place all of the arguments together at the top and then place nested blocks below them. Use one blank line to separate the arguments from the blocks.
 - Use empty lines to separate logical groups of arguments within a block.
 - For blocks that contain both arguments and "meta-arguments" (as defined by the Terraform language semantics), list meta-arguments first and separate them from other arguments with one blank line. Place meta-argument blocks last and separate them from other blocks with one blank line. Refer to [dynamic resource count](#dynamic-resource-count) for more information on meta-arguments.
-  
+
   <CodeBlockConfig hideClipboard>
 
   ```hcl
@@ -91,7 +91,7 @@ For more information, refer to the [Terraform `validate` documentation](/terrafo
 
 We recommend the following file naming conventions:
 
-- A `backend.tf` file that contains your [backend configuration](/terraform/language/backend). You can define multiple `terraform` blocks in your configuration to separate your backend configuration from your Terraform and provider versioning configuration. 
+- A `backend.tf` file that contains your [backend configuration](/terraform/language/backend). You can define multiple `terraform` blocks in your configuration to separate your backend configuration from your Terraform and provider versioning configuration.
 - A `main.tf` file that contains all resource and data source blocks.
 - A `outputs.tf` file that contains all output blocks in alphabetical order.
 - A `providers.tf` file that contains all `provider` blocks and configuration.
@@ -109,7 +109,7 @@ As your codebase grows, limiting it to just these files can become difficult to
 
 No matter how you decide to split your code, it should be immediately clear where a maintainer can find a specific resource or data source definition.
 
-As your configuration grows, you may need to separate it into multiple state files. The HashiCorp Well-Architected Framework provides more guidance about [configuration structure and scope](/well-architected-framework/operational-excellence/operational-excellence-workspaces-projects#workspace-structure). 
+As your configuration grows, you may need to separate it into multiple state files. The HashiCorp Well-Architected Framework provides more guidance about [configuration structure and scope](/well-architected-framework/operational-excellence/operational-excellence-workspaces-projects#workspace-structure).
 
 ## Linting and static code analysis
 
@@ -117,7 +117,7 @@ Terraform does not have a built-in linter, but many organizations rely on a thir
 
 ## Comments
 
-Write your code so it is easy to understand. Only when necessary, use comments to clarify complexity for other maintainers. 
+Write your code so it is easy to understand. Only when necessary, use comments to clarify complexity for other maintainers.
 
 Use `#` for both single- and multi-line comments. The `//` and `/* */` comment syntaxes are not considered idiomatic, but Terraform supports them to remain backward-compatible with earlier versions of HCL.
 
@@ -196,10 +196,10 @@ We recommend following a consistent order for resource parameters:
 
 While variables make your modules more flexible, overusing variables can make code difficult to understand. When deciding whether to expose a variable for a resource setting, consider whether that parameter will change between deployments.
 
-- Define a `type` and a `description` for every variable. 
-- If the variable is optional, define a reasonable `default`. 
+- Define a `type` and a `description` for every variable.
+- If the variable is optional, define a reasonable `default`.
 - For sensitive variables, such as passwords and private keys, set the `sensitive` parameter to `true`. Remember that Terraform will still store this value in plain text in its state, but it will not display it when you run `terraform plan` or `terraform apply`. Refer to [secrets management](#secrets-management) for more information on how to securely handle sensitive values.
-- Use [input variable validation](/terraform/language/values/variables#custom-validation-rules) to create additional rules for your variable values in addition to Terraform's type validation. Only use variable validation when your variable values have uniquely restrictive requirements. For example, if your Terraform configuration requires two web instances, add a `validation` block to enforce it:
+- Use [input variable validation](/terraform/language/block/variable#validation) to create additional rules for your variable values in addition to Terraform's type validation. Only use variable validation when your variable values have uniquely restrictive requirements. For example, if your Terraform configuration requires two web instances, add a `validation` block to enforce it:
 
   <CodeBlockConfig hideClipboard>
 
@@ -223,11 +223,11 @@ We recommend following a consistent order for variable parameters:
 1. Description
 1. Default (optional)
 1. Sensitive (optional)
-1. [Validation blocks](/terraform/language/values/variables#custom-validation-rules)
+1. [Validation blocks](/terraform/language/block/variable#validation)
 
 ## Outputs
 
-Output values let you expose data about your infrastructure on the command line and make it easy to reference in other Terraform configurations. Like you would for variables, provide a `description` for each output. 
+Output values let you expose data about your infrastructure on the command line and make it easy to reference in other Terraform configurations. Like you would for variables, provide a `description` for each output.
 
 We recommend that you use the following order for your output parameters:
 
@@ -262,9 +262,9 @@ output "web_public_ip" {
 
 ## Local values
 
-Local values let you reference an [expression](/terraform/language/expressions) or value multiple times. Use local values sparingly, as overuse can make your code harder to understand. 
+Local values let you reference an [expression](/terraform/language/expressions) or value multiple times. Use local values sparingly, as overuse can make your code harder to understand.
 
-For example, you can use a local value to create a suffix for the region and environment (for example, `development` or `test`), and append it to multiple resources. 
+For example, you can use a local value to create a suffix for the region and environment (for example, `development` or `test`), and append it to multiple resources.
 
 <CodeBlockConfig hideClipboard>
 
@@ -292,7 +292,7 @@ Define local values in one of two places:
 
 As for other Terraform objects, use descriptive nouns for local value names and underscores to separate multiple words.
 
-For more information, refer to the [local values documentation](/terraform/language/values/locals) and the [Simplify Terraform configuration with locals](/terraform/tutorials/configuration-language/locals) tutorial. 
+For more information, refer to the [local values documentation](/terraform/language/values/locals) and the [Simplify Terraform configuration with locals](/terraform/tutorials/configuration-language/locals) tutorial.
 
 ## Provider aliasing
 
@@ -331,9 +331,9 @@ module "aws_vpc" {
 
 </CodeBlockConfig>
 
-- Any provider block that does not define the `alias` parameter is the default provider configuration. 
-- Always include a default provider configuration and define all of your providers in the same file. 
-- If you define multiple instances of a provider, define the default first. 
+- Any provider block that does not define the `alias` parameter is the default provider configuration.
+- Always include a default provider configuration and define all of your providers in the same file.
+- If you define multiple instances of a provider, define the default first.
 - For non-default providers, define the `alias` as the first parameter of the `provider` block.
 
 ## Dynamic resource count
@@ -393,7 +393,7 @@ web_ui_public_ip = "18.216.208.182"
 
 </CodeBlockConfig>
 
-Refer to the [for_each meta-argument documentation](/terraform/language/meta-arguments/for_each) for more examples. 
+Refer to the [for_each meta-argument documentation](/terraform/language/meta-arguments/for_each) for more examples.
 
 The `count` meta-argument lets you create multiple instances of a resource from a single resource block. Refer to the [count meta-argument documentation](/terraform/language/meta-arguments/count) for examples.
 
@@ -431,14 +431,14 @@ Do not commit:
 
 - Your `terraform.tfstate` state file, including `terraform.tfstate.*` backup state files.
 - Your `.terraform.tfstate.lock.info` file. Terraform creates and deletes this file automatically when you run a `terraform apply` command and contains info about your [state lock](/terraform/language/state/locking)
-- Your `.terraform` directory, where Terraform downloads providers and child modules. 
+- Your `.terraform` directory, where Terraform downloads providers and child modules.
 [Saved plan files](/terraform/cli/commands/plan#out-filename) that you create when you include the `-out` flag when you run `terraform plan`.
 - Any `.tfvars` files that contain sensitive information.
 
 Always commit:
 
 - All Terraform code files
-- Your `.terraform.lock.hcl` [dependency lock file](/terraform/language/files/dependency-lock) 
+- Your `.terraform.lock.hcl` [dependency lock file](/terraform/language/files/dependency-lock)
 - A `.gitignore` file that excludes the files listed below
 - A `README.md` to describe the code, input variables, and outputs
 
@@ -458,9 +458,9 @@ This section reviews standards that enable predictable and secure Terraform work
 
 ## Version pinning
 
-To prevent provider and module upgrades from introducing unintentional changes to your infrastructure, use version pinning. 
+To prevent provider and module upgrades from introducing unintentional changes to your infrastructure, use version pinning.
 
-Specify provider versions using the [required_providers block](/terraform/language/providers/requirements#requiring-providers). Terraform [version constraints](/terraform/language/providers/requirements#version-constraints) support a range of accepted versions. 
+Specify provider versions using the [required_providers block](/terraform/language/providers/requirements#requiring-providers). Terraform [version constraints](/terraform/language/providers/requirements#version-constraints) support a range of accepted versions.
 
 Pin modules to a specific major and minor version as shown in the example below to ensure stability. You can use looser restrictions if you are certain that the module does not introduce breaking changes outside of major version updates.
 
@@ -505,7 +505,7 @@ The Terraform registry requires that repositories match a naming convention for
 
 ## Module structure
 
-Terraform modules define self-contained, reusable pieces of infrastructure-as-code. 
+Terraform modules define self-contained, reusable pieces of infrastructure-as-code.
 
 Use modules to group together logically related resources that you need to provision together. For example:
 
@@ -516,9 +516,9 @@ Review the [module creation recommended pattern documentation](/terraform/tutori
 
 ## Local modules
 
-Local modules are sourced from local disk rather than a remote module registry. We recommend publishing your modules to a module registry, such as the [HCP Terraform private registry](/terraform/cloud-docs/registry), to easily version, share, and reuse modules across your organization. If you cannot use a module registry, using local modules can simplify maintaining and updating your code. 
+Local modules are sourced from local disk rather than a remote module registry. We recommend publishing your modules to a module registry, such as the [HCP Terraform private registry](/terraform/cloud-docs/registry), to easily version, share, and reuse modules across your organization. If you cannot use a module registry, using local modules can simplify maintaining and updating your code.
 
-We recommend that you define child modules in the `./modules/<module_name>` directory. 
+We recommend that you define child modules in the `./modules/<module_name>` directory.
 
 ## Repository structure
 
@@ -554,7 +554,7 @@ Another approach is to group all modules and infrastructure configuration into a
 
 </CodeBlockConfig>
 
-The advantage of monolithic repositories is having a single source of truth that tracks every infrastructure change. However, monolithic repositories can complicate your CI/CD automation: since any code change triggers a deployment that operates on your entire repository, your workflow must target only the modified directories. You also lose the granular access control, since anyone with repository access can modify any file in it. 
+The advantage of monolithic repositories is having a single source of truth that tracks every infrastructure change. However, monolithic repositories can complicate your CI/CD automation: since any code change triggers a deployment that operates on your entire repository, your workflow must target only the modified directories. You also lose the granular access control, since anyone with repository access can modify any file in it.
 
 If your organization requires a monolithic approach, HCP Terraform and Terraform Enterprise let you scope a workspace to a specific directory in a repository, simplifying your workflows.
 
@@ -595,9 +595,9 @@ We recommend that your repository's `main` branch be the source of truth for all
 
 </CodeBlockConfig>
 
-In this scenario, you would create three workspaces per environment. For example, your production environment would have a `prod-compute`, `prod-database`, and `prod-networking` workspace. Read more about [Terraform workspace and project best practices](/well-architected-framework/operational-excellence/operational-excellence-workspaces-projects). 
+In this scenario, you would create three workspaces per environment. For example, your production environment would have a `prod-compute`, `prod-database`, and `prod-networking` workspace. Read more about [Terraform workspace and project best practices](/well-architected-framework/operational-excellence/operational-excellence-workspaces-projects).
 
-If you do not use HCP Terraform or Terraform Enterprise, we recommend that you use modules to encapsulate your configuration, and use a directory for each environment so that each one has a separate state file. The configuration in each of these directories would call the local modules, each with parameters specific to their environment. This also lets you maintain separate variable and backend configurations for each environment. 
+If you do not use HCP Terraform or Terraform Enterprise, we recommend that you use modules to encapsulate your configuration, and use a directory for each environment so that each one has a separate state file. The configuration in each of these directories would call the local modules, each with parameters specific to their environment. This also lets you maintain separate variable and backend configurations for each environment.
 
 <CodeBlockConfig hideClipboard>
 
@@ -627,7 +627,7 @@ If you do not use HCP Terraform or Terraform Enterprise, we recommend that you u
 
 ## State sharing
 
-Since your state contains sensitive information, avoid sharing full state files when possible. 
+Since your state contains sensitive information, avoid sharing full state files when possible.
 
 If you use HCP Terraform or Terraform Enterprise and need to reference resources across workspaces, use the [`tfe_outputs`](https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/data-sources/outputs) data source.
 
@@ -672,7 +672,7 @@ Policies are rules that HCP Terraform enforces on Terraform runs. You can use po
 
 We recommend that you store policies in a separate VCS repository from your Terraform code.
 
-For more information, refer to the [policy enforcement documentation](/terraform/cloud-docs/policy-enforcement), as well as the [enforce policy with Sentinel](/terraform/tutorials/policy) and [detect infrastructure drift and enforce OPA policies](/terraform/tutorials/cloud/drift-and-opa) tutorials.
+For more information, refer to the [policy enforcement documentation](/terraform/cloud-docs/policy-enforcement), as well as the [enforce policy with Sentinel](/terraform/tutorials/policy) and [detect infrastructure drift and enforce OPA policies](/terraform/tutorials/cloud/validation-enforcement) tutorials.
 
 ## Next steps
 
diff --git a/content/terraform/v1.12.x/docs/language/test-and-validate/validate.mdx b/content/terraform/v1.12.x/docs/language/test-and-validate/validate.mdx
index 39a7bd82e..43ad1dae2 100644
--- a/content/terraform/v1.12.x/docs/language/test-and-validate/validate.mdx
+++ b/content/terraform/v1.12.x/docs/language/test-and-validate/validate.mdx
@@ -65,7 +65,7 @@ variable "image_id" {
 
 If you set the value of the `image_id` variable to a string without AMI ID syntax, the condition evaluates to `false`. When a variable validation fails, Terraform errors, displays the configured `error_message`, and stops the operation from proceeding. While provider APIs often error on these same validations, this helps your users avoid the error and issues a helpful error message. You can also use these validations to enforce your organization's design decisions, such as naming conventions.
 
-To learn more about variable validations, refer to the [input variable block](/terraform/language/values/variables).
+To learn more about variable validations, refer to the [input variable block](/terraform/language/block/variable#validation).
 
 ### Preconditions and postconditions
 
diff --git a/content/terraform/v1.12.x/docs/language/tests/index.mdx b/content/terraform/v1.12.x/docs/language/tests/index.mdx
index 840c7c580..9dc47bb30 100644
--- a/content/terraform/v1.12.x/docs/language/tests/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/tests/index.mdx
@@ -174,7 +174,7 @@ Additionally, test assertions can directly reference outputs from current and pr
 
 ## Variables
 
-You can provide values for [Input Variables](/terraform/language/values/variables) within your configuration directly from your test files.
+You can provide values for [Input Variables](/terraform/language/block/variable) within your configuration directly from your test files.
 
 The test file syntax supports `variables` blocks at both the root level and within `run` blocks. Terraform passes all variable values from the test file into all `run` blocks within the file. You can override variable values for a particular `run` block with values provided directly within that `run` block.
 
@@ -220,7 +220,8 @@ We've added a second `run` block that specifies the `bucket_prefix` variable val
 
 In addition to specifying variable values via test files, the Terraform `test` command also supports the other typical mechanisms for specifying variable values.
 
-You can specify values for variables across all tests with the [Command Line](/terraform/language/values/variables#variables-on-the-command-line) and with [Variable Definition Files](/terraform/language/values/variables#variable-definitions-tfvars-files).
+<!-- TODO: add link to new variable usage page once done -->
+You can specify values for variables across all tests with the [Command Line](/terraform/language/block/variable#variables-on-the-command-line) and with [Variable Definition Files](/terraform/language/block/variable#variable-definitions-tfvars-files).
 
 As with the main configuration direction, Terraform will automatically load any variables defined in the automatic variable files within a test directory. The automatic variable files are `terraform.tfvars`, `terraform.tfvars.json`, and any files that end with `.auto.tfvars` or `.auto.tfvars.json`.
 
@@ -230,7 +231,8 @@ This is particularly useful for using sensitive variables values and for configu
 
 ### Variable definition precedence
 
-[Variable Definition Precedence](/terraform/language/values/variables#variable-definition-precedence) remains the same within tests, except for variable values that test files provide. The variables defined in test files take the highest precedence, overriding environment variables, variables files, or command-line input.
+<!-- TODO: add link to new variable usage page once done -->
+[Variable Definition Precedence](/terraform/language/block/variable#variable-definition-precedence) remains the same within tests, except for variable values that test files provide. The variables defined in test files take the highest precedence, overriding environment variables, variables files, or command-line input.
 
 For tests defined in a test directory, any variable values defined in automatic variable files from the test directory will override values defined in automatic variable files from the main configuration directory.
 
diff --git a/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx b/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx
index 614893c50..9833caeb2 100644
--- a/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx
+++ b/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx
@@ -78,7 +78,7 @@ providers) will retain their current functionality:
   in `resource`, `data`, and `module` blocks.
 * [`provider`](/terraform/language/providers/configuration) blocks to configure
   providers, and the `alias` meta-argument.
-* [`variable`](/terraform/language/values/variables#declaring-an-input-variable),
+* [`variable`](/terraform/language/block/variable),
   [`output`](/terraform/language/block/output#declaring-an-output-value), and
   [`locals`](/terraform/language/values/locals#declaring-a-local-value) blocks
   for declaring the various kinds of named values in a module.
diff --git a/content/terraform/v1.12.x/docs/language/values/index.mdx b/content/terraform/v1.12.x/docs/language/values/index.mdx
index caa935443..76a7ca96a 100644
--- a/content/terraform/v1.12.x/docs/language/values/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/values/index.mdx
@@ -10,7 +10,7 @@ description: >-
 The Terraform language includes a few kinds of blocks for requesting or
 publishing named values.
 
-- [Input Variables](/terraform/language/values/variables) serve as parameters for
+- [Input Variables](/terraform/language/block/variable) serve as parameters for
   a Terraform module, so users can customize behavior without editing the source.
 
 - [Output Values](/terraform/language/block/output) are like return values for a
diff --git a/content/terraform/v1.12.x/docs/language/values/locals.mdx b/content/terraform/v1.12.x/docs/language/values/locals.mdx
index d659d9f2c..16eb7aa5c 100644
--- a/content/terraform/v1.12.x/docs/language/values/locals.mdx
+++ b/content/terraform/v1.12.x/docs/language/values/locals.mdx
@@ -16,7 +16,7 @@ the expression.
 If you're familiar with traditional programming languages, it can be useful to
 compare Terraform modules to function definitions:
 
-- [Input variables](/terraform/language/values/variables) are like function arguments.
+- [Input variables](/terraform/language/block/variable) are like function arguments.
 - [Output values](/terraform/language/block/output) are like function return values.
 - Local values are like a function's temporary local variables.
 
diff --git a/content/terraform/v1.12.x/docs/language/values/variables.mdx b/content/terraform/v1.12.x/docs/language/values/variables.mdx
deleted file mode 100644
index a6738f370..000000000
--- a/content/terraform/v1.12.x/docs/language/values/variables.mdx
+++ /dev/null
@@ -1,587 +0,0 @@
----
-page_title: Input Variables - Configuration Language
-description: >-
-  Input variables allow you to customize modules without altering their source
-  code. Learn how to declare, define, and reference variables in configurations.
----
-
-# Input Variables
-
-> **Hands-on:** Try the [Customize Terraform Configuration with Variables](/terraform/tutorials/configuration-language/variables?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
-
-Input variables let you customize aspects of Terraform modules without altering
-the module's own source code. This functionality allows you to share modules across different
-Terraform configurations, making your module composable and reusable.
-
-When you declare variables in the root module of your configuration, you can
-set their values using CLI options and environment variables.
-When you declare them in [child modules](/terraform/language/modules),
-the calling module should pass values in the `module` block.
-
-If you're familiar with traditional programming languages, it can be useful to
-compare Terraform modules to function definitions:
-
-* Input variables are like function arguments.
-* [Output values](/terraform/language/block/output) are like function return values.
-* [Local values](/terraform/language/values/locals) are like a function's temporary local variables.
-
--> **Note:** For brevity, input variables are often referred to as just
-"variables" or "Terraform variables" when it is clear from context what sort of
-variable is being discussed. Other kinds of variables in Terraform include
-_environment variables_ (set by the shell where Terraform runs) and _expression
-variables_ (used to indirectly represent a value in an
-[expression](/terraform/language/expressions)).
-
-## Declaring an Input Variable
-
-Each input variable accepted by a module must be declared using a `variable`
-block:
-
-```hcl
-variable "image_id" {
-  type = string
-}
-
-variable "availability_zone_names" {
-  type    = list(string)
-  default = ["us-west-1a"]
-}
-
-variable "docker_ports" {
-  type = list(object({
-    internal = number
-    external = number
-    protocol = string
-  }))
-  default = [
-    {
-      internal = 8300
-      external = 8300
-      protocol = "tcp"
-    }
-  ]
-}
-```
-
-The label after the `variable` keyword is a name for the variable, which must
-be unique among all variables in the same module. This name is used to
-assign a value to the variable from outside and to reference the variable's
-value from within the module.
-
-The name of a variable can be any valid [identifier](/terraform/language/syntax/configuration#identifiers)
-_except_ the following: `source`, `version`, `providers`, `count`, `for_each`, `lifecycle`, `depends_on`, `locals`.
-
-These names are reserved for meta-arguments in
-[module configuration blocks](/terraform/language/modules/syntax), and cannot be
-declared as variable names.
-
-## Arguments
-
-Terraform CLI defines the following optional arguments for variable declarations:
-
-* [`default`][inpage-default] - A default value which then makes the variable optional.
-* [`type`][inpage-type] - This argument specifies what value types are accepted for the variable.
-* [`description`][inpage-description] - This specifies the input variable's documentation.
-* [`validation`][inpage-validation] - A block to define validation rules, usually in addition to type constraints.
-* [`ephemeral`][inpage-ephemeral] - This variable is available during runtime, but not written to state or plan files.
-* [`sensitive`][inpage-sensitive] - Limits Terraform UI output when the variable is used in configuration.
-* [`nullable`][inpage-nullable] - Specify if the variable can be `null` within the module.
-
-### Default values
-
-[inpage-default]: #default-values
-
-The variable declaration can also include a `default` argument. If present,
-the variable is considered to be _optional_ and the default value will be used
-if no value is set when calling the module or running Terraform. The `default`
-argument requires a literal value and cannot reference other objects in the
-configuration.
-
-### Type Constraints
-
-[inpage-type]: #type-constraints
-
-The `type` argument in a `variable` block allows you to restrict the
-[type of value](/terraform/language/expressions/types) that will be accepted as
-the value for a variable. If no type constraint is set then a value of any type
-is accepted.
-
-While type constraints are optional, we recommend specifying them; they
-can serve as helpful reminders for users of the module, and they
-allow Terraform to return a helpful error message if the wrong type is used.
-
-Type constraints are created from a mixture of type keywords and type
-constructors. The supported type keywords are:
-
-* `string`
-* `number`
-* `bool`
-
-The type constructors allow you to specify complex types such as
-collections:
-
-* `list(<TYPE>)`
-* `set(<TYPE>)`
-* `map(<TYPE>)`
-* `object({<ATTR NAME> = <TYPE>, ... })`
-* `tuple([<TYPE>, ...])`
-
-The keyword `any` may be used to indicate that any type is acceptable. For
-more information on the meaning and behavior of these different types, as well
-as detailed information about automatic conversion of complex types, see
-[Type Constraints](/terraform/language/expressions/types).
-
-If both the `type` and `default` arguments are specified, the given default
-value must be convertible to the specified type.
-
-### Input Variable Documentation
-
-[inpage-description]: #input-variable-documentation
-
-Because the input variables of a module are part of its user interface, you can
-briefly describe the purpose of each variable using the optional
-`description` argument:
-
-```hcl
-variable "image_id" {
-  type        = string
-  description = "The id of the machine image (AMI) to use for the server."
-}
-```
-
-The description should concisely explain the purpose
-of the variable and what kind of value is expected. This description string
-might be included in documentation about the module, and so it should be written
-from the perspective of the user of the module rather than its maintainer. For
-commentary for module maintainers, use comments.
-
-### Custom Validation Rules
-
-[inpage-validation]: #custom-validation-rules
-
--> This feature was introduced in Terraform CLI v0.13.0.
-
-You can specify custom validation rules for a particular variable by adding a `validation` block within the corresponding `variable` block. The example below checks whether the AMI ID has the correct syntax.
-
-```hcl
-variable "image_id" {
-  type        = string
-  description = "The id of the machine image (AMI) to use for the server."
-
-  validation {
-    condition     = length(var.image_id) > 4 && substr(var.image_id, 0, 4) == "ami-"
-    error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"."
-  }
-}
-```
-
-Refer to [Validate your configuration](/terraform/language/test-and-validate/validate#input-variable-validation) for more details.
-
-### Exclude values from state
-
--> **Note**: Ephemeral variables are available in Terraform v1.10 and later.
-
-[inpage-ephemeral]: #exclude-values-from-state
-
-Setting a variable as `ephemeral` makes it available during runtime, but Terraform omits ephemeral values from state and plan files. Marking an input variable as `ephemeral` is useful for data that only needs to exist temporarily, such as a short-lived token or session identifier.
-
-Mark an input variable as ephemeral by setting the `ephemeral` argument to `true`:
-
-```hcl
-variable "session_token" {
-  type      = string
-  ephemeral = true
-}
-```
-
-Ephemeral variables are available during the current Terraform operation, and Terraform does not store them in state or plan files. So, unlike [`sensitive`](#sensitive) inputs, Terraform ensures ephemeral values are not available beyond the lifetime of the current Terraform run.
-
-You can only reference ephemeral variables in specific contexts or Terraform throws an error. The following are valid contexts for referencing ephemeral variables:
-
-* In a [write-only argument](/terraform/language/resources/ephemeral/write-only)
-* Another ephemeral variable
-* In [local values](/terraform/language/values/locals#ephemeral-values)
-* In [ephemeral resources](/terraform/language/resources/ephemeral)
-* In [ephemeral outputs](/terraform/language/block/output#ephemeral)
-* Configuring providers in the `provider` block
-* In [provisioner](/terraform/language/resources/provisioners/syntax) and [connection](/terraform/language/resources/provisioners/connection) blocks
-
-If another expression references an `ephemeral` variable, that expression implicitly becomes ephemeral.
-
-```hcl
-variable "password" {
-  type      = string
-  ephemeral = true
-}
-
-locals {
-  # local.database_password is implicitly ephemeral because
-  # var.password is ephemeral.
-  database_password = var.password
-}
-```
-
-The `local.database_password` value is implicitly ephemeral because it depends on `var.password`.
-
-### Suppressing Values in CLI Output
-
-[inpage-sensitive]: #suppressing-values-in-cli-output
-
-> **Hands-on:** Try the [Protect Sensitive Input Variables](/terraform/tutorials/configuration-language/sensitive-variables?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
-
-Setting a variable as `sensitive` prevents Terraform from showing its value in
-the `plan` or `apply` output, when you use that variable elsewhere in your
-configuration.
-
-Terraform will still record sensitive values in the [state](/terraform/language/state),
-and so anyone who can access the state data will have access to the sensitive
-values in cleartext. If you want to omit a value from state, mark that value as [`ephemeral`](#ephemeral). For more information, refer to
-[Sensitive Data in State](/terraform/language/state/sensitive-data).
-
-Declare a variable as sensitive by setting the `sensitive` argument to `true`:
-
-```hcl
-variable "user_information" {
-  type = object({
-    name    = string
-    address = string
-  })
-  sensitive = true
-}
-
-resource "some_resource" "a" {
-  name    = var.user_information.name
-  address = var.user_information.address
-}
-```
-
-Any expressions whose result depends on the sensitive variable will be treated
-as sensitive themselves, and so in the above example the two arguments of
-`resource "some_resource" "a"` will also be hidden in the plan output:
-
-```
-Terraform will perform the following actions:
-
-  # some_resource.a will be created
-  + resource "some_resource" "a" {
-      + name    = (sensitive value)
-      + address = (sensitive value)
-    }
-
-Plan: 1 to add, 0 to change, 0 to destroy.
-```
-
-In some cases where you use a sensitive variable inside a nested block, Terraform
-may treat the entire block as redacted. This happens for resource types where
-all of the blocks of a particular type are required to be unique, and so
-disclosing the content of one block might imply the content of a sibling block.
-
-```
-  # some_resource.a will be updated in-place
-  ~ resource "some_resource" "a" {
-      ~ nested_block {
-          # At least one attribute in this block is (or was) sensitive,
-          # so its contents will not be displayed.
-        }
-    }
-```
-
-A provider can also
-[declare an attribute as sensitive](/terraform/plugin/sdkv2/best-practices/sensitive-state#using-the-sensitive-flag),
-which will cause Terraform to hide it from regular output regardless of how
-you assign it a value. For more information, see
-[Sensitive Resource Attributes](/terraform/language/expressions/references#sensitive-resource-attributes).
-
-If you use a sensitive value as part of an
-[output value](/terraform/language/block/output) then Terraform will require
-you to also mark the output value itself as sensitive, to confirm that you
-intended to export it.
-
-#### Cases where Terraform may disclose a sensitive variable
-
-A `sensitive` variable is a configuration-centered concept, and values are sent to providers without any obfuscation. A provider error could disclose a value if that value is included in the error message. For example, a provider might return the following error even if "foo" is a sensitive value: `"Invalid value 'foo' for field"`
-
-If a resource attribute is used as, or part of, the provider-defined resource id, an `apply` will disclose the value. In the example below, the `prefix` attribute has been set to a sensitive variable, but then that value ("jae") is later disclosed as part of the resource id:
-
-```
-  # random_pet.animal will be created
-  + resource "random_pet" "animal" {
-      + id        = (known after apply)
-      + length    = 2
-      + prefix    = (sensitive value)
-      + separator = "-"
-    }
-
-Plan: 1 to add, 0 to change, 0 to destroy.
-
-...
-
-random_pet.animal: Creating...
-random_pet.animal: Creation complete after 0s [id=jae-known-mongoose]
-```
-
-### Disallowing Null Input Values
-
-[inpage-nullable]: #disallowing-null-input-values
-
--> This feature is available in Terraform v1.1.0 and later.
-
-The `nullable` argument in a variable block controls whether the module caller
-may assign the value `null` to the variable.
-
-```hcl
-variable "example" {
-  type     = string
-  nullable = false
-}
-```
-
-The default value for `nullable` is `true`. When `nullable` is `true`, `null`
-is a valid value for the variable, and the module configuration must always
-account for the possibility of the variable value being `null`. Passing a
-`null` value as a module input argument will override any `default` value.
-
-Setting `nullable` to `false` ensures that the variable value will never be
-`null` within the module. If `nullable` is `false` and the variable has a
-`default` value, then Terraform uses the default when a module input argument is `null`.
-
-The `nullable` argument only controls where the direct value of the variable may be `null`.
-For variables of collection or structural types, such as lists or objects,
-the caller may still use `null` in nested elements or attributes, as long as
-the collection or structure itself is not null.
-
-## Using Input Variable Values
-
-Within the module that declared a variable, its value can be accessed from
-within [expressions](/terraform/language/expressions) as `var.<NAME>`,
-where `<NAME>` matches the label given in the declaration block:
-
--> **Note:** Input variables are _created_ by a `variable` block, but you
-_reference_ them as attributes on an object named `var`.
-
-```hcl
-resource "aws_instance" "example" {
-  instance_type = "t2.micro"
-  ami           = var.image_id
-}
-```
-
-The value assigned to a variable can only be accessed in expressions within
-the module where it was declared.
-
-## Assigning Values to Root Module Variables
-
-When variables are declared in the root module of your configuration, they
-can be set in a number of ways:
-
-* [In an HCP Terraform workspace](/terraform/cloud-docs/workspaces/variables).
-* Individually, with the `-var` command line option.
-* In variable definitions (`.tfvars`) files, either specified on the command line
-  or automatically loaded.
-* As environment variables.
-
-The following sections describe these options in more detail. This section does
-not apply to _child_ modules, where values for input variables are instead
-assigned in the configuration of their parent module, as described in
-[_Modules_](/terraform/language/modules).
-
-### Variables on the Command Line
-
-To specify individual variables on the command line, use the `-var` option
-when running the `terraform plan` and `terraform apply` commands:
-
-```
-terraform apply -var="image_id=ami-abc123"
-terraform apply -var='image_id_list=["ami-abc123","ami-def456"]' -var="instance_type=t2.micro"
-terraform apply -var='image_id_map={"us-east-1":"ami-abc123","us-east-2":"ami-def456"}'
-```
-
-The above examples show appropriate syntax for Unix-style shells, such as on
-Linux or macOS. For more information on shell quoting, including additional
-examples for Windows Command Prompt, see
-[Input Variables on the Command Line](/terraform/cli/commands/plan#input-variables-on-the-command-line).
-
-You can use the `-var` option multiple times in a single command to set several
-different variables.
-
-<a id="variable-files"></a>
-
-### Variable Definitions (`.tfvars`) Files
-
-To set lots of variables, it is more convenient to specify their values in
-a _variable definitions file_ (with a filename ending in either `.tfvars`
-or `.tfvars.json`) and then specify that file on the command line with
-`-var-file`:
-
-Linux, Mac OS, and UNIX:
-
-```shell
-terraform apply -var-file="testing.tfvars"
-```
-
-PowerShell:
-
-```shell
-terraform apply -var-file='testing.tfvars'
-```
-
-Windows `cmd.exe`:
-
-```shell
-terraform apply -var-file="testing.tfvars"
-```
-
--> **Note:** This is how HCP Terraform passes
-[workspace variables](/terraform/cloud-docs/workspaces/variables) to Terraform.
-
-A variable definitions file uses the same basic syntax as Terraform language
-files, but consists only of variable name assignments:
-
-```hcl
-image_id = "ami-abc123"
-availability_zone_names = [
-  "us-east-1a",
-  "us-west-1c",
-]
-```
-
-Terraform also automatically loads a number of variable definitions files
-if they are present:
-
-* Files named exactly `terraform.tfvars` or `terraform.tfvars.json`.
-* Any files with names ending in `.auto.tfvars` or `.auto.tfvars.json`.
-
-Files whose names end with `.json` are parsed instead as JSON objects, with
-the root object properties corresponding to variable names:
-
-```json
-{
-  "image_id": "ami-abc123",
-  "availability_zone_names": ["us-west-1a", "us-west-1c"]
-}
-```
-
-### Environment Variables
-
-As a fallback for the other ways of defining variables, Terraform searches
-the environment of its own process for environment variables named `TF_VAR_`
-followed by the name of a declared variable.
-
-This can be useful when running Terraform in automation, or when running a
-sequence of Terraform commands in succession with the same variables.
-For example, at a `bash` prompt on a Unix system:
-
-```
-$ export TF_VAR_image_id=ami-abc123
-$ terraform plan
-...
-```
-
-On operating systems where environment variable names are case-sensitive,
-Terraform matches the variable name exactly as given in configuration, and
-so the required environment variable name will usually have a mix of upper
-and lower case letters as in the above example.
-
-### Complex-typed Values
-
-When variable values are provided in a variable definitions file, you can use
-Terraform's usual syntax for
-[literal expressions](/terraform/language/expressions/types#literal-expressions)
-to assign complex-typed values, like lists and maps.
-
-Some special rules apply to the `-var` command line option and to environment
-variables. For convenience, Terraform defaults to interpreting `-var` and
-environment variable values as literal strings, which need only shell quoting,
-and no special quoting for Terraform. For example, in a Unix-style shell:
-
-```
-$ export TF_VAR_image_id='ami-abc123'
-```
-
-However, if a root module variable uses a [type constraint](#type-constraints)
-to require a complex value (list, set, map, object, or tuple), Terraform will
-instead attempt to parse its value using the same syntax used within variable
-definitions files, which requires careful attention to the string escaping rules
-in your shell:
-
-```
-$ export TF_VAR_availability_zone_names='["us-west-1b","us-west-1d"]'
-```
-
-For readability, and to avoid the need to worry about shell escaping, we
-recommend always setting complex variable values via variable definitions files.
-For more information on quoting and escaping for `-var` arguments,
-see
-[Input Variables on the Command Line](/terraform/cli/commands/plan#input-variables-on-the-command-line).
-
-### Values for Undeclared Variables
-
-If you have defined a variable value, but not its corresponding `variable {}`
-definition, you may get an error or warning depending on how you have provided
-that value.
-
-If you provide values for undeclared variables defined as [environment variables](#environment-variables)
-you will not get an error or warning. This is because environment variables may
-be declared but not used in all configurations that might be run.
-
-If you provide values for undeclared variables defined [in a file](#variable-definitions-tfvars-files)
-you will get a warning. This is to help in cases where you have provided a variable
-value _meant_ for a variable declaration, but perhaps there is a mistake in the
-value definition. For example, the following configuration:
-
-```terraform
-variable "moose" {
-  type = string
-}
-```
-
-And the following `.tfvars` file:
-
-```hcl
-mosse = "Moose"
-```
-
-Will cause Terraform to warn you that there is no variable declared `"mosse"`, which can help
-you spot this mistake.
-
-If you use `.tfvars` files across multiple configurations and expect to continue to see this warning,
-you can use the [`-compact-warnings`](/terraform/cli/commands/plan#compact-warnings)
-option to simplify your output.
-
-If you provide values for undeclared variables on the [command line](#variables-on-the-command-line),
-Terraform will return an error. To avoid this error, either declare a variable block for the value, or remove
-the variable value from your Terraform call.
-
-### Variable Definition Precedence
-
-The above mechanisms for setting variables can be used together in any
-combination. If the same variable is assigned multiple values, Terraform uses
-the _last_ value it finds, overriding any previous values. Note that the same
-variable cannot be assigned multiple values within a single source.
-
-Terraform loads variables in the following order, with later sources taking
-precedence over earlier ones:
-
-* Environment variables
-* The `terraform.tfvars` file, if present.
-* The `terraform.tfvars.json` file, if present.
-* Any `*.auto.tfvars` or `*.auto.tfvars.json` files, processed in lexical order
-  of their filenames.
-* Any `-var` and `-var-file` options on the command line, in the order they
-  are provided. (This includes variables set by an HCP Terraform
-  workspace.)
-
-~> **Important:** In Terraform 0.12 and later, variables with map and object
-values behave the same way as other variables: the last value found overrides
-the previous values. This is a change from previous versions of Terraform, which
-would _merge_ map values instead of overriding them.
-
-#### Variable precedence within Terraform tests
-
-Within Terraform test files, you can specify variable values within
-`variables` blocks, either nested within `run` blocks or defined directly within
-the file.
-
-Variables defined in this way take precedence over all other mechanisms during
-test execution, with variables defined within `run` blocks taking precedence
-over those defined within the file.