diff --git a/content/terraform/v1.11.x/docs/language/ephemeral/index.mdx b/content/terraform/v1.11.x/docs/language/ephemeral/index.mdx
index 8a89c1e76..30c098841 100644
--- a/content/terraform/v1.11.x/docs/language/ephemeral/index.mdx
+++ b/content/terraform/v1.11.x/docs/language/ephemeral/index.mdx
@@ -1,28 +1,17 @@
 ---
-page_title: Ephemeral block reference for the Terraform configuration language
+page_title: Ephemeral block configuration reference
 description: Learn to define ephemeral blocks in Terraform configurations to keep temporary and sensitive information out of Terraform state and plan files.
 ---
 
-# Ephemeral block reference
+# Ephemeral block configuration reference
 
-Ephemeral resources are Terraform resources that are essentially temporary. Ephemeral resources have a unique lifecycle, and Terraform does not store them in its state. Each `ephemeral` block describes one or more ephemeral resources, such as a temporary password or connection to another system.
+This topic provides reference information for the `ephemeral` block.
 
 -> **Note**: Ephemeral resources are available in Terraform v1.10 and later.
 
-## Lifecycle
-
-The lifecycle of an `ephemeral` resource is different from other resources and data sources. Terraform performs the following lifecycle steps for each ephemeral resource in a configuration:
-
-1. If Terraform needs to access the result of an ephemeral resource, it opens
-that ephemeral resource. For example, if Terraform opens an ephemeral resource for a Vault secret, the Vault provider obtains a lease and returns the secret.
+## Introduction
 
-1. If Terraform needs access to the ephemeral resource for longer than the
-remote system's enforced expiration time, Terraform asks the provider
-to periodically renew it. For example, if Terraform renews a Vault secret `ephemeral` resource, the Vault provider calls Vault's lease renewal API endpoint to extend the expiration time.
-
-1. Once Terraform no longer needs an ephemeral resource, Terraform closes
-it. This happens after the providers that depend on an ephemeral resource
-complete all of their work for the current Terraform run phase. For example, closing a Vault secret ephemeral resource means the Vault provider explicitly ends the lease, allowing Vault to immediately revoke the associated credentials.
+Ephemeral resources are Terraform resources that are essentially temporary. Ephemeral resources have a unique lifecycle, and Terraform does not store them in its state. Each `ephemeral` block describes one or more ephemeral resources, such as a temporary password or connection to another system.
 
 ## Dependency graph
 
@@ -64,9 +53,9 @@ 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 outputs](/terraform/language/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files)
+* In [local values](/terraform/language/block/locals)
+* 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/data/language-nav-data.json b/content/terraform/v1.12.x/data/language-nav-data.json
index 4e0a47a18..95ac8bd6c 100644
--- a/content/terraform/v1.12.x/data/language-nav-data.json
+++ b/content/terraform/v1.12.x/data/language-nav-data.json
@@ -211,8 +211,8 @@
     "routes": [
       { "title": "Overview", "path": "values" },
       { "title": "Input Variables", "path": "values/variables" },
-      { "title": "Output Values", "path": "values/outputs" },
-      { "title": "Local Values", "path": "values/locals" }
+      { "title": "Output block", "href": "/terraform/language/block/output" },
+      { "title": "Locals block", "href": "/terraform/language/block/locals" }
     ]
   },
   {
@@ -336,7 +336,13 @@
       }
     ]
   },
-  { "title": "Checks", "path": "checks" },
+  { "title": "Check block", "href": "/terraform/language/block/check" },
+  {
+    "title": "Testing and Validation",
+    "routes": [
+     { "title": "Validate your configuration", "path": "test-and-validate/validate" }
+  ]
+  },
   {
       "title": "Import",
       "routes": [
@@ -379,10 +385,6 @@
         "title": "Dynamic Blocks",
         "path": "expressions/dynamic-blocks"
       },
-      {
-        "title": "Custom Conditions",
-        "path": "expressions/custom-conditions"
-      },
       {
         "title": "Type Constraints",
         "path": "expressions/type-constraints"
@@ -1117,5 +1119,47 @@
     "path": "v1-compatibility-promises"
   },
   { "divider": true },
+  { "heading": "REFERENCE" },
+  {
+    "title": "Configuration blocks",
+    "routes": [
+      {
+        "title": "check",
+        "path": "block/check"
+      },
+      {
+        "title": "data",
+        "path": "block/data"
+      },
+      {
+        "title": "locals",
+        "path": "block/locals"
+      },
+      {
+        "title": "moved",
+        "path": "block/moved"
+      },
+      {
+        "title": "output",
+        "path": "block/output"
+      },
+      {
+        "title": "removed",
+        "path": "block/removed"
+      },
+      {
+        "title": "resource",
+        "path": "block/resource"
+      },
+      {
+        "title": "terraform",
+        "path": "block/terraform"
+      },
+      {
+        "title": "variable",
+        "path": "block/variable"
+      }
+    ]
+  },
   { "title": "Terraform Internals", "href": "/internals" }
 ]
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/inspect/index.mdx b/content/terraform/v1.12.x/docs/cli/inspect/index.mdx
index cd323c172..63c1d2f73 100644
--- a/content/terraform/v1.12.x/docs/cli/inspect/index.mdx
+++ b/content/terraform/v1.12.x/docs/cli/inspect/index.mdx
@@ -1,5 +1,5 @@
 ---
-page_title: Inspect infrastructure 
+page_title: Inspect infrastructure
 description: >-
   The terraform inspect commands return dependency information and outputs. Learn how to use terraform inspect commands
   to understand your infrastructure.
@@ -20,7 +20,7 @@ or just to gain a deeper or more holistic understanding of your infrastructure.
 - [The `terraform graph` command](/terraform/cli/commands/graph) creates a visual
   representation of a configuration or a set of planned changes.
 - [The `terraform output` command](/terraform/cli/commands/output) can get the
-  values for the top-level [output values](/terraform/language/values/outputs) of
+  values for the top-level [output values](/terraform/language/block/output) of
   a configuration, which are often helpful when making use of the infrastructure
   Terraform has provisioned.
 - [The `terraform show` command](/terraform/cli/commands/show) can generate
diff --git a/content/terraform/v1.12.x/docs/cli/test/index.mdx b/content/terraform/v1.12.x/docs/cli/test/index.mdx
index 08177edce..564e1ef22 100644
--- a/content/terraform/v1.12.x/docs/cli/test/index.mdx
+++ b/content/terraform/v1.12.x/docs/cli/test/index.mdx
@@ -1,5 +1,5 @@
 ---
-page_title: Testing features in Terraform 
+page_title: Testing features in Terraform
 description: >-
   Learn about the terraform test command, which runs structured tests and validations for your configuration to ensure
   correctness in your infrastructure.
@@ -13,14 +13,14 @@ This topic provides an overview of the testing features in Terraform to help you
 
 Terraform provides the following types of testing capabilities:
 
-1. Configuration and infrastructure validation as part of your regular Terraform operations. Refer to [Custom Conditions](/terraform/language/expressions/custom-conditions) and [Checks](/terraform/language/checks) to learn more about these types of testing capabilities.
+1. Configuration and infrastructure validation as part of your regular Terraform operations. Refer to [Validate your configuration](/terraform/language/test-and-validate/validate) to learn more.
 1. Traditional unit and integration testing on your configuration. Refer to the [`terraform test` command](/terraform/cli/commands/test) documentation to learn more about this testing capability.
 
-### Additional testing and validation features 
+### Additional testing and validation features
 
-- [Input Variable Validation](/terraform/language/expressions/custom-conditions#input-variable-validation)
-- [Pre and Post-conditions](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions)
-- [Checks](/terraform/language/checks) 
+- [Input Variable Validation](/terraform/language/test-and-validate/validate#input-variable-validation)
+- [Preconditions and postconditions](/terraform/language/test-and-validate/validate#preconditions-and-postconditions)
+- [Checks](/terraform/language/block/check)
 
 ## How the `terraform test` command works
 
@@ -41,14 +41,14 @@ Terraform test files [have their own configuration syntax](/terraform/language/t
 
 Validations allow you to verify aspects of your configuration and infrastructure as it is applied and created. HCP Terraform also supports automated [continuous validation](/terraform/cloud-docs/workspaces/health#continuous-validation).
 
-The Terraform `test` command also executes any validations within your configuration as part of the tests it executes. For more information on the available validation, refer to [Checks](/terraform/language/checks) and [Custom Conditions](/terraform/language/expressions/custom-conditions).
+The Terraform `test` command also executes any validations within your configuration as part of the tests it executes. Refer to [Validate your configuration](/terraform/language/test-and-validate/validate) to learn more.
 
 ## Tests versus validations
 
 You can write many validations as test assertions, but there are specific use cases for both.
 
-Validations are executed during Terraform plan and apply operations, and the Terraform `test` command also runs validations while executing tests. Therefore, use validations to validate aspects of your configuration that should always be true and could impact the valid execution of your infrastructure. 
+Terraform executes validations during plan and apply operations and when you run the `terraform test` command. Therefore, use validations to validate aspects of your configuration that should always be true and could impact the valid execution of your infrastructure.
 
 Module authors should note that validations are executed and exposed to module users, so if they fail, ensure the failure messages are understandable and actionable.
 
-In contrast, Terraform only executes tests when you run `terraform test`. Use tests to assert the correctness of any logical operations or specific behavior within your configuration. For example, you can test that Terraform creates conditional resources based on an input by setting the input controlling those resources to a certain value then verifying the resources Terraform creates.
\ No newline at end of file
+By contrast, Terraform only executes tests when you run `terraform test`. Use tests to assert the correctness of any logical operations or specific behavior within your configuration. For example, you can test that Terraform creates conditional resources based on an input by setting the input controlling those resources to a certain value then verifying the resources Terraform creates.
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/check.mdx b/content/terraform/v1.12.x/docs/language/block/check.mdx
new file mode 100644
index 000000000..828dc56fd
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/check.mdx
@@ -0,0 +1,235 @@
+---
+page_title: check block reference for the Terraform configuration language
+description: How to use the `check` block to validate infrastructure outside of the usual resource lifecycle.
+---
+
+# `check` block reference
+
+Use the `check` block to validate your infrastructure outside of the typical resource lifecycle.
+
+Terraform executes the `check` block as the last step of plan or apply operation, after Terraform has planned or provisioned your infrastructure. When a `check` block's assertion fails, Terraform reports a warning and continues executing the current operation.
+
+## Background
+
+Terraform evaluates `check` blocks locally whenever you plan or apply your configuration. In HCP Terraform, you can enable health checks on a workspace to automatically and continuously execute checks defined in that workspace's configuration. Refer to [Continuous validation](/terraform/cloud-docs/workspaces/health#continuous-validation) for details.
+
+The `check` block is one of the ways you can validate your configuration. Checks contain assertions, which specify the condition that Terraform is verifying during that check. Other validations run during other stages of a Terraform operation, and can block operations if they fail. The `check` block is the only validation that does not block operations, if a `check` block's assertion fails, Terraform reports a warning and continues executing the current operation.
+
+For information on all of the ways to validation configuration in Terraform, refer to [Validate your configuration](/terraform/language/test-and-validate/validate#input-variable-validation).
+
+## Configuration model
+
+The `check` block supports the following arguments:
+
+- [`check "<LABEL>"`](#check) &nbsp; block
+   - [`assert`](#assert) &nbsp; block (required)
+      - [`condition`](#assert) &nbsp; expression
+      - [`error_message`](#assert) &nbsp; string
+   - [`data "<TYPE>" "<LABEL>"`](#data) &nbsp; block
+      - [`PROVIDER_ARGUMENTS`](#provider_arguments) &nbsp; block | refer to your provider documentation
+     - [`depends_on`](#depends_on) &nbsp; list of references
+     - [`provider`](#provider) &nbsp; reference
+
+## Complete configuration
+
+All available arguments are defined in the following `check` block. There are no mutually exclusive arguments for a `check` block.
+
+```hcl
+check "<LABEL>" {
+ data "<TYPE>" "<LABEL>" {
+   <DATA_CONFIGURATION>
+ }
+
+ assert {
+   condition     = <EXPRESSION>
+   error_message = "<error message string>"
+ }
+}
+```
+
+A `check` block can contain [multiple assertions](#multiple-assertions).
+
+## Specification
+
+A `check` block supports the following configuration.
+
+### `check "<LABEL>"`
+
+[Follow Terraform's resource naming rules](/terraform/language/style#resource-naming) when you declare a `check` block.
+
+You can define the following blocks on a `check` block.
+
+| Argument | Description | Type | Required |
+| --- | --- | --- | --- |
+| `assert` | The validation condition to evaluate. A `check` block contains one or more assertions. | Block | Required |
+| `data` | Specifies a data source to use for validation. You can only reference this data source within its parent `check` block. | Block | Optional |
+
+### `assert`
+
+A `check` block must contain at least one `assert` block. Each `assert` block specifies a condition that Terraform evaluates after plan and apply operations.
+
+```hcl
+check "unique_name" {
+ assert {
+   condition     = <expression-to-verify>
+   error_message = "The error message Terraform displays if the assert expression is false."
+ }
+}
+```
+
+For a check to pass, each `assert` block's `condition` must evaluate to `true`. The `condition` arguments within an `assert` block can reference [nested data sources](#data) within the parent `check` block and any variables, resources, data sources, or module outputs within the current module.
+
+The `assert` block supports the following arguments:
+
+| Argument | Description | Type | Required |
+| --- | --- | --- | --- |
+| `condition` | Expression that Terraform evaluates. If the expression evaluates to `true`, then the `assert` block passes. | Expression | Required |
+| `error_message` | Message to display if the condition evaluates to `false`. | String | Required |
+
+Refer to the [examples](#examples) to learn more about defining assertions within a `check` block.
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+- Required: Yes, each `check` block must contain at least one `assert` block.
+- Example: [Declare multiple assertions](#multiple-assetions).
+
+### `data "<TYPE>" "<LABEL>"`
+
+The `data` block fetches information that you can reference in expressions in the `assert` block's `condition` argument.
+
+```hcl
+check "unique_name" {
+ data "TYPE" "<LABEL>" {
+   <provider_specific_arguments>
+ }
+
+ assert { #... }
+}
+```
+
+Defining a `data` block in a `check` block is optional. You can only reference a nested data source within its parent `check` block. If a nested data source's provider raises errors, they are masked as warnings and do not prevent the Terraform operation from continuing.
+
+Unlike other [data sources](/terraform/language/data-sources), Terraform fetches the information for nested data sources as the final step of a plan or apply operation. You can use nested data sources to fetch information about your infrastructure after Terraform has applied the rest of your configuration. For example, you can use a nested `data` block to ping your website's API to ensure Terraform successfully applied and built your website's infrastructure.
+
+A nested `data` block requires a type and a label:
+
+- `TYPE`: Specifies the type of data source to use.
+- `LABEL`: A unique name for this data source. Refer to [Resource naming](/terraform/language/style#resource-naming) for label recommendations.
+
+The arguments within a `data` block are provider-specific. Refer to the [registry documentation](https://registry.terraform.io/) for your specified provider for details.
+
+### `depends_on`
+
+The `depends_on` argument specifies an upstream resource that the `data` block depends on. Terraform must complete all operations on the upstream resource before fetching information from the `data` block.
+
+```hcl
+check "unique_name" {
+ data "aws_ami" "web" {
+   <provider_specific_arguments>
+   depends_on = [<another_resource.name>]
+ }
+
+ assert { #... }
+}
+```
+
+We recommend adding the `depends_on` argument if your nested data source depends on another resource without referencing that resource directly.
+
+For example, if you define a `check` that verifies that a website API returns `200`, that check fails the first time Terraform runs your configuration because your website's infrastructure does not exist yet. You can set the `depends_on` argument to a resource, such as the load balancer, to ensure Terraform only runs the `check` once the website is up. When running an operation, Terraform evaluates the `check`, warns `known after apply` until that crucial piece of your website is ready, and continues the operation.
+
+However, this strategy only works when the `data` block does not directly reference the resource specified in the `depends_on` argument. Otherwise, anytime that resource changes, the `check` block warns `known after apply` until Terraform updates that resource, making your check potentially noisy and ineffective. Refer to the [example](#resource-dependency) for more details.
+
+The `depends_on` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments/depends_on) for additional information.
+
+<!-- TODO: Update meta-arguments concept link once we have the page -->
+
+### `provider`
+
+The `provider` argument instructs Terraform to use an alternate provider configuration to provision the nested data source.
+
+```hcl
+check "unique_name" {
+ data "aws_ami" "web" {
+   <provider_specific_arguments>
+   provider = <provider>.<alias>
+ }
+
+ assert { #... }
+}
+```
+
+By default, Terraform automatically selects a provider based on the nested data source's type, but you can create multiple provider configurations and use a non-default configuration for specific data sources.
+
+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/meta-arguments/resource-provider) for additional information.
+
+<!-- TODO: Update meta-arguments concept link once we have the page -->
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+- Supported meta-arguments: `depends_on` and `provider`.
+- Example: [Resource dependency](#resource-dependency).
+
+## Examples
+
+The following examples demonstrate common use cases for `check` blocks.
+
+### Validate endpoint health
+
+In the following example, the `data` block calls an API endpoint to validate that the endpoint returns a healthy status code. If the endpoint does not return a `200` code, Terraform prints the error message specified in the `assert` block:
+
+```hcl
+check "health_check" {
+ data "http" "endpoint" {
+   url = "https://api.example.com/health"
+ }
+
+ assert {
+   condition     = data.http.endpoint.status_code == 200
+   error_message = "Health check failed: ${data.http.endpoint.url} returned ${data.http.endpoint.status_code}"
+ }
+}
+```
+
+### Multiple assertions
+
+In the following example, the `data` block queries the `aws_lb` resource. The `check` block asserts that the load balancer must have at least one security group attached and that deletion protection must be enabled:
+
+```hcl
+check "service_validation" {
+ data "aws_lb" "app" {
+   name = "application-lb"
+ }
+
+ assert {
+   condition     = data.aws_lb.app.enable_deletion_protection
+   error_message = "Load balancer must have deletion protection enabled"
+ }
+
+ assert {
+   condition     = length(data.aws_lb.app.security_groups) > 0
+   error_message = "Load balancer must have at least one security group"
+ }
+}
+```
+
+### Resource dependency
+
+In the following example, Terraform waits to run the check  until it creates the `aws_db_instance.main` database. Terraform prints `known after apply`, instead of printing false warnings, until it finishes creating the database:
+
+```hcl
+check "database_connection" {
+ data "postgresql_database" "app_db" {
+   name       = "application"
+   depends_on = [aws_db_instance.main]
+ }
+
+ assert {
+   condition     = data.postgresql_database.app_db.allow_connections
+   error_message = "Database is not accepting connections"
+ }
+}
+```
diff --git a/content/terraform/v1.12.x/docs/language/block/data.mdx b/content/terraform/v1.12.x/docs/language/block/data.mdx
new file mode 100644
index 000000000..72c193d6e
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/data.mdx
@@ -0,0 +1,427 @@
+---
+page_title: data block reference
+description: Learn how to configure a `data` block that gets data from the specified data source for use in the configuration.
+---
+
+# `data` block reference
+
+The `data` block fetches data about a resource from the provider without provisioning an associated infrastructure object. You can reference data source attributes to configure other resources, keeping your configuration dynamic and preventing hardcoding. Refer to [Query infrastructure data](/terraform/language/data-sources) for more information.
+
+The source type, arguments, and attributes depend on the provider. Refer to the provider documentation for more information.
+
+## Configuration model
+
+The `data` block supports the following configuration:
+
+- [`data "<TYPE>" "<LABEL>"`](#data) &nbsp block
+  - [provider-specific arguments](#provider-specific-arguments) &nbsp block | refer to your provider documentation
+  - [`count`](#count) &nbsp number | mutually exclusive with `for_each`
+  - [`depends_on`](#depends_on) &nbsp list of references 
+  - [`for_each`](#for_each) &nbsp map or set of strings | mutually exclusive with `count`
+  - [`provider`](#provider) &nbsp reference
+  - [`lifecycle`](#lifecycle) &nbsp block
+    - [`precondition`](#precondition) &nbsp block
+      - [`condition`](#precondition) &nbsp string
+      - [`error_message`](#precondition) & nbsp string
+    - [`postcondition`](#postcondition) &nbsp block
+      - [`condition`](#postcondition) &nbsp string
+      - [`error_message`](#postcondition) &nbsp string
+
+## Complete configuration
+
+The following `data` block includes all built-in arguments supported in a data source:
+
+```hcl
+data "<TYPE>" "<LABEL>" {
+   <PROVIDER-SPECIFIC ARGUMENTS>
+   count = <NUMBER>      # `count` and `for_each` are mutually exclusive
+   depends_on = [ <RESOURCE.ADDRESS.EXPRESSION> ]
+   for_each = {          # `for_each` and `count` are mutually exclusive 
+      <KEY> = <VALUE>
+   }
+   for_each = [       # `for_each` accepts a map or a set of strings 
+    "<VALUE>", 
+    "<VALUE>"
+   ]
+   provider = <REFERENCE.TO.ALIAS>
+   lifecycle {
+      precondition {
+         condition = <EXPRESSION>
+         error_message = "<STRING>"
+    }
+    postcondition {
+      condition = <EXPRESSION>
+      error_message = "<STRING>"
+    }
+  }
+}
+```
+
+## Specification
+
+A `data` block supports the following configuration.
+
+### `data "<TYPE>" "<LABEL>"`
+
+You must set the following arguments for every `data` block:
+
+- `TYPE`: Specifies the data source type. Provider developers define the support data sources. Refer to the provider documentation for details. Terraform also includes the [`terraform_remote_state` data source](/terraform/language/state/remote-state-data), which lets you access state data from other workspaces. 
+- `LABEL`: Specifies a name for the data source. Use the `data.<label>.<attribute>` syntax to reference the data. Refer to [References to Named Values](/terraform/language/expressions/references) and [Resource naming](/terraform/language/style#resource-naming) for expression syntax and label recommendations.
+
+### Provider-specific arguments
+
+The provider developer determines which arguments you can define for a data source. Refer to the provider documentation for details. 
+
+### `count`
+
+The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration.   
+
+```hcl
+data "<TYPE>" "<LABEL>" {
+  count = <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`.
+
+To refer to an individual instance of a data source created using the `count` meta-argument, use the `<TYPE>.<NAME>[INDEX]` syntax. For example, `data.aws_instance.server[0]` refers to the first instance of the `aws_instance` data source named `server`.
+
+<Tip>
+
+You can use the `count` argument as a conditional for creating data sources. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the data source when a variable named `creator` is set to `true`. Refer to [​​Conditional Expressions]/terraform/language/expressions/conditionals) for more information.
+
+</Tip>
+
+The `count` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+
+#### Summary
+
+- Data type: Number.
+- Default: None.
+
+### `depends_on`
+
+The `depends_on` meta-argument specifies an upstream resource that the data source depends on. Terraform must complete all operations on the upstream resource before performing operations on the data source containing the `depends_on` argument.
+
+```
+data "<TYPE>" "<LABEL>" {
+  depends_on = [ <resource reference> ]
+}
+```
+
+When a data source configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create one resource before creating a data source, even though the resource and the data source are configured independently.
+
+Use the `depends_on` argument when the resource and data source do not reference each other. We recommend always including a comment to explain dependencies when using a `depends_on` argument.
+
+When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
+
+Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data sources associated with that module. Refer to [Resource dependencies](/terraform/language/manage-resources#resource-dependencies) and [Data resource dependencies](/terraform/language/configure-data-sources#data-resource-dependencies) for more information.
+
+The depends_on 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: List.
+- 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.
+
+<Tabs>
+
+<Tab heading="List of values">
+
+```hcl
+data "<TYPE>" "<LABEL>" {
+  for_each = [ "<VALUE>" ] 
+  # . . .
+}
+```
+
+</Tab>
+
+<Tab heading="Map of key-value pairs">
+
+```hcl
+data "<TYPE>" "<LABEL>" {
+  for_each = {
+    "<KEY>" = "<VALUE>"
+  }
+}
+```
+
+</Tab>
+
+</Tabs>
+
+The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
+
+You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
+
+Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
+
+The `for_each` argument does not implicitly convert lists or tuples to sets. To declare data source instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
+
+- [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 data source 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`, most functions in Terraform return a sensitive result when 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. 
+
+The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the data source. 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. 
+
+Use the `<TYPE>.<NAME>[<KEY>]` syntax to access an instance of a data source created using `for_each`. For example, `data.azurerm_resource_group.rg["a_group"]` refers to an instance of the `data.azurrm_resource_group` resource named `rg` created off of the `a_group` key.
+
+The `for_each` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+
+
+#### Summary
+
+- Data type: Map or set of strings.
+- Default: None.  
+
+### `provider`
+
+The `provider` argument instructs Terraform to use an alternate provider configuration. 
+
+```hcl
+data "<TYPE>" "<LABEL>" {
+  provider = <provider>.<alias>
+}
+```
+
+By default, Terraform automatically selects a provider based on the data source type, but you can create multiple provider configurations and use a non-default configuration for specific data sources. 
+
+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. 
+
+### `lifecycle`
+
+The `lifecycle` block defines lifecycle rules for how Terraform operates on your data source. 
+
+```hcl
+data "<TYPE>" "<LABEL>" {
+  lifecycle { 
+    <lifecycle>
+  }
+}
+```
+
+You can specify the following lifecycle rules to manage how Terraform performs operations on the resource:
+
+- [`precondition`](#precondition): Specifies a condition that Terraform evaluates before creating the data source. Refer to [Test and validate](/terraform/language/test-and-validate) for more information.
+- [`postcondition`](#postcondition): Specifies a condition that Terraform evaluates after creating the data source. Refer to [Test and validate](/terraform/language/test-and-validate) 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 data sources. Refer to [Meta-arguments](/terraform/language/concepts/meta-arguments) for more information. 
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+
+### `precondition`
+
+The `precondition` block specifies a condition that must return `true` before Terraform evaluates and performs operations on the data source. You can also specify an error message for Terraform to print when the condition returns `false`. 
+
+```hcl
+resource {
+  lifecycle { 
+    precondition {
+      condition = <expression>
+      error_message = "<message>"
+    }
+  }
+}
+```
+
+The following arguments in the `precondition` block are required:
+
+| Argument | Description | Data type |
+| --- | --- | --- |
+| `condition` | Expression that must return `true` for Terraform to proceed with an operation. 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 |
+
+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`](#count) and [`for_each`](#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 may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block. 
+
+Refer to [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.
+
+ #### Summary
+
+- Data type: Block.
+- Default: None.
+- Example: [Apply custom conditions](#apply-custom-conditions).
+
+### `postcondition`
+
+The `postcondition` block specifies a condition that must return `true` after Terraform performs operations on the data source. You can also specify an error message for Terraform to print to the console when the condition returns `false`. 
+
+```hcl
+data "<TYPE>" "<LABEL>" {
+  lifecycle { 
+    postcondition {
+      condition = <expression>
+      error_message = "<message>"
+    }
+  }
+}
+```
+
+The following arguments in the `precondition` block are required:
+
+| Argument | Description | Data type |
+| --- | --- | --- |
+| `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 |
+
+Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. 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 may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block. 
+
+Refer to [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+- Example: [Apply custom conditions](#apply-custom-conditions).
+
+## Examples
+
+The following examples show how to write configuration for common use cases.
+
+### Specify a dependency
+
+In the following example, Terraform gets an AMI for use in the `aws_instance` resource after creating the `aws_subnet.example_subnet` resource:   
+
+```hcl 
+resource "aws_vpc" "example_vpc" {
+  cidr_block = "10.0.0.0/16"
+}
+
+resource "aws_subnet" "example_subnet" {
+  vpc_id     = aws_vpc.example_vpc.id
+  cidr_block = "10.0.1.0/24"
+}
+
+data "aws_ami" "example_ami" {
+  most_recent = true
+  owners      = ["amazon"]
+  filter {
+    name   = "name"
+    values = ["amzn2-ami-hvm-*"]
+  }
+  filter {
+    name   = "architecture"
+    values = ["x86_64"]
+  }
+  depends_on = [aws_subnet.example_subnet]  
+}
+
+resource "aws_instance" "example_instance" {
+  ami           = data.aws_ami.example_ami.id
+  instance_type = "t2.micro"
+  subnet_id     = aws_subnet.example_subnet.id
+}
+```
+
+Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.  
+
+### Select an alternate provider configuration
+
+In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias. 
+
+```hcl
+provider "google" {
+  region = "us-central1"
+}
+
+provider "google" {
+  alias  = "europe"
+  region = "europe-west1"
+}
+
+data "google_compute_instance" "example" {  
+  provider = google.europe
+  # ...
+}
+```
+
+### 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 `data` block instructs Terraform to retrieve the ID of the `ami-abc123` AMI:
+
+```hcl
+data "aws_ami" "example" {
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-abc123"]
+  }
+}
+```
+
+In the following code, the `precondition` block specifies that the AMI ID retrieved from the `data` block must include `x86_64` as its `architecture` attribute. The `postcondition` block specifies that the EC2 instance must be allocated a public DNS hostname. When either condition is not met, Terraform returns the `error_message` for the failed condition:
+
+```hcl
+resource "aws_instance" "example" {
+  instance_type = "t3.micro"
+  ami           = data.aws_ami.example.id
+
+  lifecycle {
+    precondition {
+      condition     = data.aws_ami.example.architecture == "x86_64"
+      error_message = "The selected AMI must be for the x86_64 architecture."
+    }
+
+    postcondition {
+      condition     = self.public_dns != ""
+      error_message = "EC2 instance must be in a VPC that has public DNS hostnames enabled."
+    }
+  }
+}
+```
+
+The following `data` block retrieves the root storage volume connected to the `aws_instance.example` EC2 instance using the `volume_id` attribute. When a `data` resource verifies the result of a managed resource declared in the same configuration, you must define the check in a `postcondition` block in the resource so that Terraform waits for changes to the managed resource to complete before reading the data resource.
+
+```hcl
+data "aws_ebs_volume" "example" {
+  filter {
+    name = "volume-id"
+    values = [aws_instance.example.root_block_device[0].volume_id]
+  }
+  lifecycle {
+    # The EC2 instance will have an encrypted root volume.
+    postcondition {
+      condition     = self.encrypted
+      error_message = "The server's root volume is not encrypted."
+    }
+  }
+}
+output "api_base_url" {
+  value = "https://${aws_instance.example.private_dns}:8433/"
+}
+```
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/block/locals.mdx b/content/terraform/v1.12.x/docs/language/block/locals.mdx
new file mode 100644
index 000000000..a3bb14f2c
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/locals.mdx
@@ -0,0 +1,139 @@
+---
+page_title: Locals block reference for the Terraform configuration language
+description: Use the `locals` block to define values and reuse them within a Terraform module.
+---
+
+# `locals` block reference
+
+Use the `locals` block to define values and reuse them within a Terraform module.
+
+> **Hands-on:** Try the [Simplify Terraform Configuration with Locals](/terraform/tutorials/configuration-language/locals) tutorial.
+
+## Background
+
+The `locals` block is similar to function-scoped variables in other programming languages. Local values assign names to expressions, letting you use the name multiple times within a module instead of repeating the expression.
+
+You can define local values in any module. Local values can be any valid Terraform expression, and can reference variables, resource attributes, function outputs, or other local values to transform or combine data.
+
+<!--TODO: Add a link to the usage page once I write it (WIP name)
+Learn more about using locals, refer to [Parameterize your module](/WIP-USAGE-PAGE).
+
+-->
+
+## Configuration model
+
+The `locals` block supports assigning a name to an expression:
+
+- [`locals`](#locals) &nbsp; block
+  - [`<LOCAL_NAME> = <EXPRESSION>`](#local-value-assignment) &nbsp; assignment
+
+## Complete configuration
+
+The `locals` block supports assigning names to expressions:
+
+```hcl
+locals {
+  <LOCAL_NAME> = <EXPRESSION>
+  <OTHER_LOCAL_NAME> = <OTHER_EXPRESSION>
+}
+```
+
+## Specification
+
+A `locals` block supports the following configuration.
+
+### `locals`
+
+You can define any number of temporary values within a module using a `locals` block. You can declare multiple `locals` blocks in a single module, Terraform treats them as if they were all defined in a single block.
+
+```hcl
+locals {
+  value_name = <expression>
+}
+
+locals {
+  other_value_name = <other_expression>
+}
+```
+
+Local value names must be valid [identifiers](/terraform/language/syntax/configuration#identifiers). You can assign any valid Terraform expression as a `locals` value, and can include references to variables, resources, data sources, or other local values.
+
+#### Summary
+
+- Data type: Block
+- Required: Must assign at least one value for each `locals` block you define.
+- Example: [Basic locals example](#basic-locals-example)
+
+## Examples
+
+The following examples demonstrate common use cases for `locals` blocks.
+
+### Basic locals example
+
+In the following example, the `locals` block defines local values for service metadata, then the `aws_instance` resource references those values using `local.<value_name>` syntax:
+
+```hcl
+locals {
+  service_name = "forum"
+  owner        = "community-team"
+  environment  = "production"
+}
+
+resource "aws_instance" "web" {
+  ami           = "ami-12345678"
+  instance_type = "t3.micro"
+
+  tags = {
+    Name        = local.service_name
+    Owner       = local.owner
+    Environment = local.environment
+  }
+}
+```
+
+The `locals` block defines local values, but you reference them as attributes on an object named `local`, which is singular. You can access local values in the module where you define them, but not in other modules.
+
+### Combine and transform data
+
+In the following example, `local.instance_ids` combines instance IDs from two different resource lists with the concat function. The `local.common_tags` value is a map that references other local values and variables.
+
+```hcl
+locals {
+  instance_ids = concat(aws_instance.blue[*].id, aws_instance.green[*].id)
+
+  common_tags = {
+    Service     = local.service_name
+    Owner       = local.owner
+    Environment = var.environment
+    ManagedBy   = "terraform"
+  }
+}
+```
+
+### Multiple `locals` blocks
+
+In the following example, multiple `locals` blocks organize related values. The first `locals` block organizes network configuration, the second application configuration, and the third contains computed values:
+
+```hcl
+locals {
+  # Network configuration
+  vpc_cidr = "10.0.0.0/16"
+  az_count = length(data.aws_availability_zones.available.names)
+}
+
+locals {
+  # Application configuration
+  app_name = "${var.project_name}-${var.environment}"
+  app_port = 8080
+}
+
+locals {
+  # Computed values
+  subnet_cidrs = [
+    for i in range(local.az_count) :
+    cidrsubnet(local.vpc_cidr, 8, i)
+  ]
+}
+```
+
+Terraform treats multiple `locals` blocks as if they were defined in a single block, but you can use separate blocks to organize your related values into visually distinct blocks to make it easier for users to understand your configuration.
diff --git a/content/terraform/v1.12.x/docs/language/moved.mdx b/content/terraform/v1.12.x/docs/language/block/moved.mdx
similarity index 70%
rename from content/terraform/v1.12.x/docs/language/moved.mdx
rename to content/terraform/v1.12.x/docs/language/block/moved.mdx
index b5dbc79ab..eab4df433 100644
--- a/content/terraform/v1.12.x/docs/language/moved.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/moved.mdx
@@ -1,23 +1,27 @@
 ---
-page_title: moved block configuration reference
+page_title: moved block reference for the Terraform configuration language
 description: Learn about the `moved` block that you can specify in Terraform configurations. The `moved` block programmatically changes the location of a resource.
 ---
 
 # `moved` block reference
 
-This topic provides reference information for the `moved` block. Use this block to programmatically change the address of a resource. Refer to [Refactoring](/terraform/language/modules/develop/refactoring) for details about how to use the `moved` block in your Terraform configurations.
+This topic provides reference information for the `moved` block.
+
+## Introduction
+
+The `moved` block programmatically changes the address of a resource. Refer to [Refactoring](/terraform/language/modules/develop/refactoring) for details about how to use the `moved` block in your Terraform configurations.
 
 ## Configuration model
 
-The `moved` block supports the following arguments:
+The following list outlines field hierarchy, language-specific data types, and requirements in the `moved` block.
 
-- [`moved`](#moved): &nbsp block
-  - [`from`](#moved):  &nbsp reference | required
-  - [`to`](#moved):  &nbsp reference | required
+- [`moved`](#moved): map
+  - [`from`](#moved): reference
+  - [`to`](#moved): reference
 
 ## Complete configuration
 
-The following `moved` block defines all of the supported built-in arguments you can set:
+When every field is defined, a `moved` block has the following form:
 
 ```hcl
 moved {
@@ -28,13 +32,13 @@ moved {
 
 ## Specification
 
-A `moved` block supports the following configuration. 
+This section provides details about the fields you can configure in the `moved` block.
 
 ### `moved`
 
-The `moved` block specifies the previous address and the new address for the resource. The following table describes the arguments you can set in the `moved` block.
+Map that specifies addresses for the resource. The following table describes the fields you can set in the `moved` block.
 
-| Argument | Description | Type | Required |
+| Field | Description | Type | Required |
 | ---   | ---         | ---  | ---      |
 | `from` | Specifies a resource's previous address. The syntax allows Terraform to select modules, resources, and resources inside child modules. | string | required |
 | `to` | Specifies the new address to relocate the resource to. The syntax allows Terraform to select modules, resources, and resources inside child modules. | string | required |
@@ -50,4 +54,4 @@ moved {
   from = aws_instance.a
   to   = aws_instance.b
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.12.x/docs/language/block/output.mdx b/content/terraform/v1.12.x/docs/language/block/output.mdx
new file mode 100644
index 000000000..b8b192ce1
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/output.mdx
@@ -0,0 +1,296 @@
+---
+page_title: Output block reference for the Terraform configuration language
+description: Use the `output` block to expose information about your module's infrastructure.
+---
+
+# `output` block reference
+
+The `output` block lets you expose information about your infrastructure.
+
+> **Hands-on:** Try the [Output Data From Terraform](/terraform/tutorials/configuration-language/outputs) tutorial.
+
+## Background
+
+The value of an `output` block is similar to a return value in other programming languages. The `output` block exposes information about your infrastructure that you can reference on the command line, in HCP Terraform, and in other Terraform configurations that can access your configuration's state. The `output` block serves four main purposes in Terraform:
+
+- Child modules can expose resource attributes to parent modules.
+- Root modules can display values in CLI output.
+- Other Terraform configurations using [remote state](/terraform/language/state/remote) can access root module outputs with the `terraform_remote_state` data source.
+- Passing information from a Terraform operation to an automation tool.
+
+In HCP Terraform, your `output` block values appear in the UI after Terraform applies your configuration. You can [mark outputs as sensitive in HCP Terraform](/terraform/cloud-docs/workspaces/variables/managing-variables#sensitive-values) to hide their values in the UI and in API responses.
+
+## Configuration model
+
+The `output` block supports the following arguments:
+
+- [`output "<LABEL>"`](#output) &nbsp; block
+  - [`value`](#value) &nbsp; expression
+  - [`description`](#description) &nbsp; string
+  - [`sensitive`](#sensitive) &nbsp; boolean
+  - [`ephemeral`](#ephemeral) &nbsp; boolean
+  - [`depends_on`](#depends_on) &nbsp; list of references
+  - [`precondition`](#precondition) &nbsp; block
+    - [`condition`](#precondition) &nbsp; expression
+    - [`error_message`](#precondition) &nbsp; string
+
+## Complete configuration
+
+All available arguments are defined in the following `output` block. There are no mutually exclusive arguments for an `output` block.
+
+```hcl
+output "<LABEL>" {
+  value       = <EXPRESSION>
+  description = "<STRING>"
+  sensitive   = <true|false>
+  ephemeral   = <true|false>
+  depends_on  = [<REFERENCE>]
+
+  precondition {
+    condition     = <EXPRESSION>
+    error_message = "<STRING>"
+  }
+}
+```
+
+## Specification
+
+An `output` block supports the following configuration.
+
+### `output "<LABEL>"`
+
+[Follow Terraform's resource naming rules](/terraform/language/style#resource-naming) when declaring an `output` block.
+
+The following arguments are supported in an `output` block:
+
+| Argument | Description | Type | Required? |
+| --- | --- | --- | --- |
+| `value` | The value Terraform returns for this output. | Expression | Required |
+| `description` | A description of the output's purpose and how to use it. | String | Optional |
+| `sensitive` | Specifies if Terraform hides this value in CLI output. | Boolean | Optional |
+| `ephemeral` | Specifies whether to prevent storing this value in state. | Boolean | Optional |
+| `depends_on` | A list of explicit dependencies for this output. | List | Optional |
+| `precondition` | A condition to validate before computing the output or storing it in state. | Block | Optional |
+
+### `value`
+
+You must include a `value` argument in each `output` block. Terraform evaluates the `value` argument's expression and exposes the result as the return value of an output and stores that value in state.
+
+```hcl
+output "unique_name" {
+  value = <expression-to-evaluate>
+}
+```
+
+Any valid expression can be an output `value.` Refer to [Expressions](/terraform/language/expressions/) to learn more.
+
+#### Summary
+
+- Data type: Expression
+- Default: None
+- Required: Yes
+
+### `description`
+
+Use the `description` argument in an `output` block to explain the purpose of this output, requirements, and what kind of value this output exports.
+
+```hcl
+output "instance_ip_addr" {
+  value       = <expression-to-evaluate>
+  description = "<concise description from the perspective of a module consumer>."
+}
+```
+We recommend writing the description from the point of view of a module consumer to help consumers understand why the output exists and how to use it.
+
+#### Summary
+
+- Data type: String
+- Default: None
+
+### `sensitive`
+
+Add the `sensitive` argument to an `output` block to hide that block's value in the CLI output of a Terraform operation.
+
+```hcl
+output "admin_password" {
+  value     = <expression-to-evaluate>
+  sensitive = <boolean>
+}
+```
+
+If you set the `sensitive` argument to `true`, Terraform redacts that output value in plan and apply operations:
+
+```shell-session
+Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
+
+Outputs:
+
+admin_password = (sensitive value)
+```
+
+If you use the [`terraform output` command](/terraform/cli/commands/output) with the `-json` or `-raw` command-line flags, Terraform displays `sensitive` values in plain text.
+
+Terraform also 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`
+
+### `ephemeral`
+
+-> **Note**: Ephemeral outputs are available in Terraform v1.10 and later.
+
+Add the `ephemeral` argument to `output` blocks in child modules to pass data between modules without persisting that data to state or plan files. You cannot add the `ephemeral` argument to `output` blocks in the root module.
+
+```hcl
+output "unique_password" {
+  value     = <expression-to-evaluate>
+  ephemeral = <boolean>
+}
+```
+
+Passing output values between child modules and the root module is useful for managing credentials, tokens, and other temporary values that you do not want to store in state. If you enable the `ephemeral` argument on an `output` block, then your configuration must meet the following conditions:
+
+- The value of the `output` block must come from an ephemeral context.
+- You can only reference that output in other ephemeral contexts.
+
+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/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
+
+#### Summary
+
+- Data type: Boolean
+- Default: `false`
+
+### `depends_on`
+
+The `depends_on` argument specifies an explicit dependency on another upstream resource for an `output` block. Terraform will complete all operations on the upstream resource before it computes the value of an `output` block that depends on it.
+
+```hcl
+output "unique_name" {
+  value      = <expression-to-evaluate>
+  depends_on = [<another_resource.name>]
+}
+```
+
+If the `value` expression in an `output` block references another resource, Terraform automatically determines the dependency order. If you need to establish a dependency between resources and outputs that are configured independently and do not reference each other, you can use the`depends_on` argument to declare an explicit dependency. If you add the `depends_on` argument, we recommend adding a comment to explain it.
+
+The `depends_on` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments/depends_on) for additional information.
+
+<>{/* TODO: Update meta-arguments concept link once we have the page*/}</>
+
+#### Summary
+
+- Data type: List of references
+- Default: None
+
+### `precondition`
+
+The `precondition` block lets you validate that the value of an `output` block meets specific requirements. Use preconditions on outputs to validate that your output values meet your requirements before Terraform exposes them or stores their values in state.
+
+```hcl
+output "unique_name" {
+  value  = <expression-to-evaluate>
+
+  precondition {
+    condition     = <expression-to-verify>
+    error_message = "<error message string>"
+  }
+}
+```
+
+You can specify the following arguments in the `precondition` block:
+
+| Attribute | Description | Data type | Required? |
+| :---- | :---- | :---- | :---- |
+| `condition` | Expression that must return `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 preconditions on outputs when creating or applying a plan, and if a precondition block's `condition` expression evaluates to `false`, then Terraform throws an error with the `error_message` and stops the current operation.
+
+Refer to [Validate your configuration](/terraform/language/test-and-validate/validate#preconditions) for more details about preconditions.
+
+#### Summary
+
+- Data type: Block
+- Default: None
+
+## Examples
+
+The following examples demonstrate common use cases for `output` values.
+
+### Basic example
+
+In the following example, an `output` block exposes a server's private IP address from the current module:
+
+```hcl
+output "instance_ip_addr" {
+  value       = aws_instance.server.private_ip
+  description = "The private IP address of the main server instance."
+}
+```
+
+### Accessing child module outputs
+
+In the following example, the current module uses an output named `instance_ip_addr` from a child module named `web_server`:
+
+```hcl
+output "website_url" {
+  value = "https://${module.web_server.instance_ip_addr}"
+  description = "The URL of the web server, starting with https://."
+}
+```
+
+### Sensitive output
+
+In the following example, the `db_password` output sets the `sensitive` argument to `true` to prevent Terraform from displaying the database password in CLI output:
+
+```hcl
+output "db_password" {
+  value     = aws_db_instance.db.password
+  description = "The database password."
+  sensitive = true
+}
+```
+
+### Output with validation
+
+In the following example, the `instance_public_ip` output has a `precondition` to ensure certain conditions are met before exposing the output or saving it to state. Before `instance_public_ip` shares the public IP for server, the output's precondition ensures a server's security group has at least one ingress rule to allow traffic on ports `80` or `443`:
+
+```hcl
+output "instance_public_ip" {
+  value = aws_instance.web.public_ip
+  description = "Public IP address of the instance."
+
+  precondition {
+    condition     = length([for rule in aws_security_group.web.ingress : rule if rule.to_port == 80 || rule.to_port == 443]) > 0
+    error_message = "Security group must allow HTTP (port 80) or HTTPS (port 443) ingress traffic."
+  }
+}
+```
+If the server's security group does not allow ingress on ports `80` or `443`, then Terraform throws an error with the `error_message` and stops the current operation.
+
+### Explicit dependencies
+
+In the following example, `instance_ip_addr` adds an explicit dependency on the security group rule to ensure that Terraform creates the security group before exposing the IP address:
+
+```hcl
+output "instance_ip_addr" {
+  value       = aws_instance.server.private_ip
+  description = "The private IP address of the main server instance."
+
+  depends_on = [
+    # Services are unreachable unless the security group rule is created
+    # before exposing this IP address.
+    aws_security_group_rule.local_access,
+  ]
+}
+```
+
+The `output` block typically does not require explicit dependencies so we recommend that when you add an explicit dependency, include a comment to explain why it's necessary.
diff --git a/content/terraform/v1.12.x/docs/language/block/removed.mdx b/content/terraform/v1.12.x/docs/language/block/removed.mdx
new file mode 100644
index 000000000..26062c2e4
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/removed.mdx
@@ -0,0 +1,417 @@
+---
+page_title: removed block reference
+description: Learn how to configure a `removed` block, which removes a resource from state.
+---
+
+# `removed` block reference
+
+The `removed` block specifies a resource to remove from state without changing the underlying infrastructure. Refer to [Remove a resource](/terraform/language/resources/remove)<!--URL TBD --> for instructions.
+
+## Configuration model
+
+The `removed` block supports the following arguments.
+
+- [`removed`](#removed) &nbsp block
+  - [`from`](#from) &nbsp address
+  - [`lifecycle`](#lifecycle) &nbsp block | required
+    - [`destroy`](#lifecycle) &nbsp boolean 
+  - [`connection`](#connection) &nbsp block
+  - [`provisioner "<TYPE>"`](#provisioner) &nbsp block 
+    - [`when`](#when) &nbsp | keyword 
+    - [`command`](#command) &nbsp string
+    - [`interpreter`](#interpreter) &nbsp list
+    - [`working_dir`](#working_dir) &nbsp string
+    - [`on_failure`](#on_failure) &nbsp keyword  
+    - [`quiet`](#quiet) &nbsp boolean
+    - [`connection`](#connection) &nbsp block
+    - [`inline`](#inline) &nbsp list | mutually exclusive with `script` and `script`
+    - [`script`](#script) &nbsp string | mutually exclusive with `inline` and `scripts`
+    - [`scripts`](#script) &nbsp list | mutually exclusive with `inline` and `script`  
+
+## Complete configuration
+
+The following `removed` block defines all supported arguments. 
+
+```hcl
+removed {
+  from = "<resource.address>"
+  lifecycle {
+    destroy = < true || false >
+  }
+  connection {
+    <connection-settings>
+  }
+  provisioner "<TYPE>" {
+    when = destroy
+    <provisioner-type-arguments>  
+  }
+}
+```
+
+## Specification
+
+A `removed` block supports the following configuration.
+
+### `removed` 
+
+The `removed` block instructs Terraform to remove a resource from state. When you remove a resource from state, Terraform no longer manages the actual infrastructure that the configuration represents. 
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+
+### `from`
+
+The `from` argument specifies the address of the resource you want to remove. 
+
+```hcl
+removed {
+  from = <TYPE>.<NAME>
+}
+```
+
+For instructions on how to retrieve the address from state, refer to [Inspect Infrastructure Commands Overview](/terraform/cli/inspect). For information about forming addresses, refer to [Resource addressing](/terraform/cli/state/resource-addressing).
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+- This argument is required. 
+
+### `lifecycle`
+
+The `lifecycle` block defines rules for how Terraform removes the resource. For `removed` blocks, the only supported `lifecycle` argument is `destroy`. 
+
+```hcl
+removed {
+  # …
+  lifecycle { 
+    destroy = <boolean>
+  }
+}
+```
+
+By default, Terraform removes the resource from state and destroys the actual resource. Set `destroy` to `false` to remove the resource from state without destroying the actual resource. This allows you to hand off management responsibilities to another tool or team after using Terraform for the initial provisioning.   
+
+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/meta-arguments) for more information.
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+
+### `connection`
+
+The `connection` block specifies settings that let provisioners connect to resources you are removing.
+
+<Warning>
+
+We recommend using configuration management tools to perform actions on the local or remote machine instead of using provisioners. Refer to [Provisioners](/terraform/language/manage-resource/run-command) for more information.
+
+</Warning>
+
+You can add the `connection` block to either the [`removed`](#removed) block or the [`provisioner`](#provisioner) block nested in the `removed` block. When added to the `removed` block, the `connection` block sets default connection settings for all provisioners defined for the resource you are removing. This lets provisioners connect to the remote resource during removal.
+
+```hcl
+removed {
+  # . . .
+  connection {
+    <settings for all provisioners in the resource>
+  }
+}
+``` 
+
+When added to a `provisioner` block, the `connection` block defines settings specific to the provisioner.
+
+```hcl
+removed {
+  # . . .
+  provisioner "<TYPE>" {
+    # . . .
+    connection {
+      <settings for all provisioners in the resource>
+    }
+  }
+}
+```
+
+For SSH connections, Terraform does not validate SSH host keys by default. To validate SSH host keys, you can establish a separate mechanism for key distribution and explicitly set the `host_key` argument to verify against a specific key or signing CA.
+
+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 resource address. References create dependencies, and referring to a resource by resource address 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"/>
+
+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> |
+| `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> |
+| `timeout` | Specifies how long to wait for the connection to become available. | string | `ssh`<p>`winrm`</p> | `"5m"` |
+| `script_path` | Specifies the path on the remote resource where Terraform copies scripts to. Refer to the [`provisioner` block reference](#provisioner) for more information. Terraform copies scripts to a path that contains random numbers depending on the `target_platform` configuration. | string | `ssh`<p>`winrm`</p> | <p>`/tmp/terraform_%RAND%.sh` when `target_platform` is `unix`</p><p>`C:/windows/temp/`<br/>`terraform_%RAND%.cmd` when `target_platform` is `windows`</p> |
+| `private_key` | Specifies the contents of an SSH key to use for the connection. `private_key` takes precedence over `password` when both are provided. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load keys from file.</p> | `ssh` | none |
+| `certificate` | Specifies the contents of a signed CA certificate. You must also configure a  `private_key` arugment. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load certificates from file.</p> | `ssh` | none |
+| `agent` | Specifies an SSH agent for authentication. Set to `false` to disable using `ssh-agent` to authenticate. On Windows, the only supported SSH authentication agent is [Pageant](http://the.earth.li/\~sgtatham/putty/0.66/htmldoc/Chapter9.html#pageant). | string | `ssh` | `false` |
+| `agent_identity` | Specifies the preferred identity from the SSH agent to use for authentication. | string | `ssh` | none |
+| `host_key` | Specifies the public key from the remote host or the signing CA to verify the connection. | string | `ssh` | none |
+| `target_platform` | Specifies the target platform, which affects the default value for the `script_path` argument. You can specify either `windows` or `unix`. <p>`windows` sets the default `script_path` to `c:\windows\temp\terraform_%RAND%.cmd` if the default SSH shell on the remote resource is `cmd.exe`. Refer to the [Windows documentation](https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_server_configuration#configuring-the-default-shell-for-openssh-in-windows) for more information. If the SSH default shell is PowerShell, set `script_path` to `"c:/windows/temp/terraform_%RAND%.ps1"`.</p><p>`unix` sets the default `script_path` to `/tmp/terraform_%RAND%.sh`. </p> | string | `ssh` |`unix` |
+| `https` | Set to `true` to connect using HTTPS instead of HTTP. | boolean | `winrm` | `false` |
+| `insecure` | Set to `true` to skip validating the HTTPS certificate chain. | boolean | `winrm` | `false` |
+| `use_ntlm` | Set to `true` to use NTLM authentication instead of basic authentication. Using NTLM removes the requirement for basic authentication to be enabled within the target guest. Refer to [Authentication for Remote Connections](https://docs.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections) in the Windows App Development documentation for more details. | boolean | `winrm` | `false` |
+| `cacert` | Specifies the CA certificate to validate against. | string | `winrm` | none |
+| `bastion_host` | Specifies the address of the bastion host. The provisioner connects to `bastion_host` before connecting to `host`. | string | `ssh` | none |
+| `bastion_host_key` | Specifies the public key from the remote host or the signing CA to verify the host connection. | string | `ssh` | none |
+| `bastion_port` | Specifies the port number to use for the bastion host connection. | string | `ssh` | value of the `port` field|
+| `bastion_user`| Specifies the user name for connecting to the bastion host. | string | `ssh` | value of the `user` field |
+| `bastion_password` | Specifies the user password for connecting to the bastion host. | string | `ssh` | value of the `password` field |
+| `bastion_private_key` | Specifies the contents of an SSH key file to use for the bastion host. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load keys from file.</p> | `ssh` | value of the `private_key` field |
+| `bastion_certificate` |  Specifies the contents of a signed CA certificate. You must also configure the `bastion_private_key` argument when providing the certificate for the bastion host. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load certificates from file.</p> | `ssh` | value of the `certificate` field |
+| `proxy_scheme` | Specifies the connection protocol. You can specify one of the following values: <li>`http`</li><li>`https`</li><li> `socks5`</li> | string | `ssh` | none |
+| `proxy_host` | Specifies the address of the proxy host. The provisioner connects to the proxy host first. When `bastion_host` is configured, the provisioner connects to the bastion host next, otherwise the provisioner connects to the host specified in the `host` argument.  | string | `ssh` | none |
+| `proxy_port` | Specifies the port number to use for the proxy host connection. | number | `ssh` | none |
+| `proxy_user_name` | Specifies the user name for connecting to the proxy host. You should only configure this argument when the proxy server requires authentication. | string | `ssh` | none |
+| `proxy_user_password` | Specifies the user password for connecting to the proxy host. You should only configure this argument when the proxy server requires authentication. | string | `ssh` | none |
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+
+### `provisioner`
+
+The `provisioner` block defines actions to perform on the local machine or resource you are removing. 
+
+```hcl
+removed {
+  # . . .
+  provisioner "<TYPE>" {
+    <arguments>
+  }
+}
+```
+
+You can declare either `local-exec` or `remote-exec` as the provisioner type. The `local-exec` provisioner performs operations on the machine where Terraform is running. The `remote-exec` type performs operations on the resource you are removing. 
+
+The [`when`](#when) argument is required to configure a provisioner nested in a `removed` block. The following table describes the arguments you can specify for each type of provisioner:
+
+| Provisioner type | Arguments |
+|---| -- |
+| `local-exec` | <li>[`command`](#command)</li> <li>[`working_dir`](#working_dir)</li> <li>[`interpreter`](#interpreter)</li> <li>[`quiet`](#quiet)</li> <li>[`connection`](#connection)</li>  <li>[`on_failure`](#on_failure)</li> |
+| `remote-exec` | <li>[`inline`](#inline)</li> <li>[`script`](#script)</li> <li>[`scripts`](#scripts)</li> |
+| All types | <li>[`when`](#when). This argument is required to use any other argument in a `provisioner` block nested in a `removed` block. </li> <li>[`connection`](#connection)</li>  <li>[`on_failure`](#on_failure)</li> |
+
+Use the `self` type to reference `provisioner` block values when the provisioner is nested in a `removed` block. Refer to [Block-Local Values](/terraform/language/expressions/references#block-local-values) for more information. 
+
+### `when`
+
+The `when` argument specifies a Terraform command that triggers actions specified in the provisioner. 
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    when = <Terraform command>
+  }
+}
+```
+
+When you run the specified Terraform command, Terraform performs run the command specified in the [`command`](#command) argument. Refer to [Destroy-time provisioners](terraform/language/resources/provisioners/syntax#destroy-time-provisioners) for instructions on using the `when` argument.
+
+#### Summary
+
+- Data type: Terraform command.
+- Default: None.
+- Required to use any other `provisioner` argument. 
+
+
+### `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. 
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    command = "<path>"
+  }
+}
+```
+
+Terraform evaluates the command in a local shell and can use environment variables for variable substitution. We do not recommend using Terraform variables for variable substitution because doing so can lead to shell injection vulnerabilities. Instead, you should pass Terraform variables to a command through the environment parameter and use environment variable substitution instead. Refer to the following OWASP article for more information about injection flaws: [Code Injection](https://owasp.org/www-community/attacks/Code_Injection).
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+- This argument is required in the `provisioner "local-exec"` block.
+
+### `working_dir`
+
+The `working_dir` block specifies the working directory where Terraform executes the command specified in the the [`command`](#command) argument. You can specify a relative path to the current working directory or an absolute path. The directory must already exist.
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    working_dir = "<path>"
+  }
+}
+```
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+
+### `interpreter`
+
+The `interpreter` block specifies a list of interpreter arguments for running the executable specified in the [`command`](#command) argument. 
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    interpreter = [ "<path/to/interpreter>", "<command argument>" ]
+  }
+}
+```
+
+The first argument in the list is a path to the interpreter. You can specify a relative path to the current working directory or an absolute path. If you do not specify an interpreter, Terraform uses operating system defaults.
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+
+#### Summary
+
+- Data type: List.
+- Default: None.
+
+### `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. 
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    environment {
+      <KEY> = <VALUE>
+    }
+  }
+}
+```
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+ 
+#### Summary
+
+- Data type: Block.
+- Default: None.
+
+### `quiet`
+
+The `quiet` argument disables printing the [`command`](#command) argument's output to `stdout`.
+
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    quiet = <boolean>
+  }
+}
+```
+
+When `quiet` is set to `true`, Terraform prints `"Suppressed by quiet=true"` to `stdout`. Terraform still prints the output of the command.
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+
+#### Summary
+
+- Data type: Boolean.
+- Default: None.
+
+### `inline`
+
+Specifies a list of command strings for the remote resource to run.
+
+
+```hcl
+removed {
+  # ...
+  provisioner "remote-exec" {
+    inline = [ "<command>" ]
+  }
+}
+```
+
+The provisioner uses the remote resource's default shell unless you specify a shell as the first command, for example `#!/bin/bash`. You cannot add an `inline` argument in the same provisioner with `script` or `scripts`.
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+
+#### Summary
+
+- Data type: List.
+- Default: None.
+
+### `script`
+
+Specifies the relative or absolute path to a script on the local machine to copy and execute on the remote resource.  
+
+
+```hcl
+removed {
+  # ...
+  provisioner "remote-exec" {
+    scripts = "<path-to-script>"
+  }
+}
+```
+
+You cannot add a `script` argument in the same provisioner with `inline` or `scripts`.
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) <!--URL TBD -->are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+
+### `scripts`
+
+Specifies a list of relative or absolute paths to scripts on the local machine to copy and execute on the remote resource.  
+
+
+```hcl
+removed {
+  # ...
+  provisioner "remote-exec" {
+    scripts = [ "<path-to-script>" ]
+  }
+}
+```
+You cannot add a `scripts` argument in the same provisioner with `inline` or `script`.
+
+Only [destroy-time provisioners](/terraform/language/{TBD}#destroy-time-provisioners) <!--URL TBD -->are supported in `removed` blocks. As a result, you must include the [`when`](#argument) in the `provisioner` block to configure all other provisioner arguments.  
+
+## Example
+
+The following example includes a provisioner that prints a message on the local machine indicating that Terraform has destroyed the resource:
+
+```hcl
+removed {
+  from = aws_instance.example
+
+  lifecycle {
+    destroy = true
+  }
+
+  provisioner "local-exec" {
+    when    = destroy
+    command = "echo 'Instance ${self.id} has been destroyed.'"
+  }
+}
+```
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/block/resource.mdx b/content/terraform/v1.12.x/docs/language/block/resource.mdx
new file mode 100644
index 000000000..849402090
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/resource.mdx
@@ -0,0 +1,1275 @@
+---
+page_title: resource block reference
+description: >-
+   Learn configure `resource` block arguments in Terraform configuration language.
+---
+
+# `resource` block reference
+
+The `resource` block defines a piece of infrastructure and specifies the settings for Terraform to create it with. The arguments that an individual resource supports are determined by the provider. Refer to the provider documentation for more information about specific resource configuration.
+
+## Configuration model
+
+The `resource` block supports the following arguments:
+
+- [`resource "<TYPE>" "<LABEL>"`](#resource) &nbsp; block
+   - [`PROVIDER ARGUMENTS`](#provider-arguments) &nbsp; block | refer to your provider documentation
+   - [`count`](#count) &nbsp; number | mutually exclusive with `for_each`
+   - [`depends_on`](#depends_on) &nbsp; list of references
+   - [`for_each`](#for_each) &nbsp; map or set of strings | mutually exclusive with `count`
+   - [`provider`](#provider) &nbsp; reference
+   - [`lifecycle`](#lifecycle) &nbsp; block
+      - [`create_before_destroy`](#create_before_destroy) &nbsp; boolean
+      - [`prevent_destroy`](#prevent_destroy) &nbsp; boolean
+      - [`ignore_changes`](#ignore_changes) &nbsp; list of attributes
+      - [`replace_triggered_by`](#replace_triggered_by) &nbsp; list of references
+      - [`precondition`](#precondition) &nbsp; block
+        - [`condition`](#precondition) &nbsp; string
+        - [`error_message`](#precondition) &nbsp; string
+      - [`postcondition`](#postcondition) &nbsp; block
+        - [`condition`](#postcondition) &nbsp; string
+        - [`error_message`](#postcondition) &nbsp; string
+   - [`connection`](#connection) &nbsp; block
+        - [`type`](#connection-arguments) &nbsp; string
+        - [`user`](#connection-arguments) &nbsp; string
+        - [`password`](#connection-arguments) &nbsp; string
+        - [`host`](#connection-arguments) &nbsp; string
+        - [`port`](#connection-arguments) &nbsp; string
+        - [`timeout`](#connection-arguments) &nbsp; string
+        - [`script_path`](#connection-arguments) &nbsp; string
+        - [`private_key`](#connection-arguments) &nbsp; string
+        - [`certificate`](#connection-arguments) &nbsp; string
+        - [`agent`](#connection-arguments) &nbsp; string
+        - [`agent_identity`](#connection-arguments) &nbsp; string
+        - [`host_key`](#connection-arguments) &nbsp; string
+        - [`target_platform`](#connection-arguments) &nbsp; string
+        - [`script_path`](#connection-arguments) &nbsp; string
+        - [`https`](#connection-arguments) &nbsp; string
+        - [`insecure`](#connection-arguments) &nbsp; string
+        - [`use_ntlm`](#connection-arguments) &nbsp; string
+        - [`cacert`](#connection-arguments) &nbsp; string
+        - [`bastion_host`](#connection-arguments) &nbsp; string
+        - [`bastion_host_key`](#connection-arguments) &nbsp; string
+        - [`bastion_port`](#connection-arguments) &nbsp; string
+        - [`bastion_user`](#connection-arguments) &nbsp; string
+        - [`bastion_password`](#connection-arguments) &nbsp; string
+        - [`bastion_private_key`](#connection-arguments) &nbsp; string
+        - [`bastion_certificate`](#connection-arguments) &nbsp; string
+        - [`proxy_scheme`](#connection-arguments) &nbsp; string
+        - [`proxy_port`](#connection-arguments) &nbsp; string
+        - [`proxy_user_name`](#connection-arguments) &nbsp; string
+        - [`proxy_user_password`](#connection-arguments) &nbsp; string
+   - [`provisioner "<TYPE>"`](#provisioner) &nbsp; block
+      - [`source`](#source) &nbsp; string
+      - [`destination`](#destination) &nbsp; string
+      - [`content`](#content) &nbsp; string
+      - [`command`](#command) &nbsp; string
+      - [`working_dir`](#working_dir) &nbsp; string
+      - [`interpreter`](#interpreter) &nbsp; string
+      - [`environment`](#command) &nbsp; string
+      - [`when`](#when) &nbsp; keyword
+      - [`quiet`](#quiet) &nbsp; boolean
+      - [`inline`](#inline) &nbsp; list of strings
+      - [`script`](#script) &nbsp; string
+      - [`scripts`](#scripts) &nbsp; string
+      - [`on_failure`](#on_failure) &nbsp; keyword
+      - [`connection`](#connection) &nbsp; block
+
+## Complete configuration
+
+The following `resource` block defines all of the supported built-in arguments you can set on a resource:
+
+```hcl
+resource "<TYPE>" "<LABEL>" {
+  <PROVIDER_ARGUMENTS>
+  count = <NUMBER>      # `for_each` and `count` are mutually exclusive
+  depends_on = [ <RESOURCE.ADDRESS.EXPRESSION> ]
+  for_each = {          # `for_each` and `count` are mutually exclusive
+    <KEY> = <VALUE>
+  }
+  for_each = [	     # `for_each` accepts a map or a set of strings
+    "<VALUE>",
+    "<VALUE>"
+  ]
+  provider = <REFERENCE.TO.ALIAS>
+  lifecycle {
+    create_before_destroy = <true || false>
+    prevent_destroy = <true || false>
+    ignore_changes = [ <ATTRIBUTE> ]
+    replace_triggered_by = [ <RESOURCE.ADDRESS.EXPRESSION> ]
+    precondition {
+      condition = <EXPRESSION>
+      error_message = "<STRING>"
+    }
+    postcondition {
+      condition = <EXPRESSION>
+      error_message = "<STRING>"
+    }
+  }
+  connection {
+    type = <"ssh" or "winrm">
+    host = <EXPRESSION>
+    <DEFAULT_CONNECTION_SETTINGS>
+  }
+  provisioner "<TYPE>" {
+    source = "<PATH>"
+    destination = "<PATH>"
+    content = "<CONTENT TO COPY TO `destination`>"
+    command = <COMMAND>
+    working_dir = "<PATH TO DIR WHERE TERRAFORM EXECUTES `command`>"
+    interpreter = [
+      "<PATH TO INTERPRETER EXECUTABLE>",
+      "<COMMAND> <ARGUMENTS>"
+    ]
+    environment {
+      "<KEY>" = "<VALUE>"
+    }
+    when = <TERRAFORM COMMAND>
+    quiet = <true || false>
+    inline = [ "<COMMAND>" ]
+    script = "<PATH>"
+    scripts = [
+      "<PATH>"
+    ]
+    on_failure = <continue || fail>
+    connection {
+      type = <"ssh" or "winrm">
+      host = <EXPRESSION>
+      <SPECIFIC_CONNECTION_SETTINGS>
+    }
+  }
+}
+```
+
+## Specification
+
+A `resource` block supports the following configuration.
+
+### `resource "<TYPE>" "<LABEL>"`
+
+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.
+
+### `PROVIDER ARGUMENTS`
+
+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.
+
+```hcl
+resource {
+  count = <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`.
+
+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>
+
+You can use the `count` argument as a conditional for creating resources. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the resource when a variable named `creator` is set to `true`. Refer to [​​Conditional Expressions](/terraform/language/expressions/conditionals) for more information.
+
+</Tip>
+
+The `count` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+
+#### Summary
+
+- Data type: Number.
+- Default: None.
+- Example: [Create multiple instances of a resource](#create-multiple-instances-of-a-resource).
+
+### `depends_on`
+
+The `depends_on` meta-argument specifies an upstream resource that the resource depends on. Terraform must complete all operations on the upstream resource before performing operations on the resource containing the `depends_on` argument.
+
+```hcl
+resource {
+  depends_on = [ <resource reference> ]
+}
+```
+
+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.
+
+When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
+
+Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data sources associated with that module. Refer to [Resource dependencies](/terraform/language/manage-resources#resource-dependencies) <!-- placeholder link -->
+and [Data resource dependencies](/terraform/language/configure-data-sources#data-resource-dependencies) for more information.
+
+The `depends_on` 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: List.
+- 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.
+
+<Tabs>
+
+<Tab heading="List of values">
+
+```hcl
+resource {
+  for_each = [ "<VALUE>" ]
+  # . . .
+}
+```
+
+</Tab>
+
+<Tab heading="Map of key-value pairs">
+
+```hcl
+resource {
+  for_each = {
+    "<KEY>" = "<VALUE>"
+  }
+}
+```
+
+</Tab>
+
+</Tabs>
+
+The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
+
+You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
+
+Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
+
+The `for_each` argument does not implicitly convert lists or tuples to sets. To declare resource instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
+
+- [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/block/variable#sensitive), [sensitive outputs](/terraform/language/values/outputs#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.
+
+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.
+
+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.
+
+The `for_each` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+
+#### Summary
+
+- Data type: Map or set of strings.
+- 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.
+
+```hcl
+resource {
+  provider = <provider>.<alias>
+}
+```
+
+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.
+
+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.
+- 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.
+
+```hcl
+resource {
+  lifecycle {
+    <lifecycle>
+  }
+}
+```
+
+You can specify the following lifecycle rules to manage how Terraform performs operations on the resource:
+
+- [`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.
+- [`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.
+
+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.
+
+#### Summary
+
+- Data type: Block.
+- Default: None
+
+### `create_before_destroy`
+
+The `create_before_destroy` argument instructs Terraform to create a replacement resource before destroying the resource it replaces.
+
+```hcl
+resource {
+  lifecycle {
+    create_before_destroy = <boolean>
+  }
+}
+```
+
+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.
+
+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.
+
+#### Summary
+
+- Data type: Boolean
+- Default: None.
+
+### `prevent_destroy`
+
+The `prevent_destroy` argument instructs Terraform to reject plans to destroy the resource.
+
+```hcl
+resource {
+  lifecycle {
+    prevent_destroy = <boolean>
+  }
+}
+```
+
+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.
+
+#### Summary
+
+- Data type: Boolean.
+- Default: None.
+
+### `ignore_changes`
+
+The `ignore_changes` argument specifies a list of resource attributes for Terraform to ignore when planning updates to the resource.
+
+```hcl
+resource {
+  lifecycle {
+    ignore_changes = [ <attribute> ]
+  }
+}
+```
+
+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]`.
+
+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.
+- Example: [Ignore attribute changes](#ignore-attribute-changes).
+
+### `replace_triggered_by`
+
+The `replace_triggered_by` argument instructs Terraform to replace the resource when any of the referenced items change.
+
+```hcl
+resource {
+  lifecycle {
+    replace_triggered_by = [ <address.reference> ]
+  }
+}
+```
+
+You can specify a list of expressions that reference managed resources, instances, or instance attributes. You can only reference managed resources in `replace_triggered_by` expressions. This lets you modify these expressions without forcing replacement.
+
+The trigger is based on the planned actions for all of the given resources. Terraform does not plan actions for plain values, such as local values or input variables, but you can use the `terraform_data` resource type to apply a resource-like lifecycle to them.
+
+References in the argument list trigger a replacement under following conditions:
+
+- When referencing a resource with multiple instances, such as those created by `count` or `for_each`, a `terraform plan` command to update or replace any instance triggers replacement.
+- When referencing a single resource instance, a `terraform plan` command to update or replace that instance triggers replacement.
+- When referencing a single attribute of a resource instance, any change to the attribute value triggers replacement.
+
+Adding the `replace_triggered_by` argument to a resource that uses `count` or `for_each` lets you add the `count.index` or `each.key` resource address to the expression. Use this address segment to reference specific instances of other resources that are configured with the same `count` or collection.
+
+#### Summary
+
+- Data type: List
+- Default: None.
+- 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`.
+
+```hcl
+resource {
+  lifecycle {
+    precondition {
+      condition = <expression>
+      error_message = "<message>"
+    }
+  }
+}
+```
+
+The following arguments in the `precondition` block are required:
+
+| Argument | Description | Data type |
+| --- | --- | --- |
+| `condition` | Expression that must return `true` for Terraform to proceed with an operation. 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 |
+
+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.
+
+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.
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+- Example: [Apply custom conditions](#apply-custom-conditions)
+
+### `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`.
+
+```hcl
+resource {
+  lifecycle {
+    postcondition {
+      condition = <expression>
+      error_message = "<message>"
+    }
+  }
+}
+```
+
+The following arguments in the `precondition` block are required:
+
+| Argument | Description | Data type |
+| --- | --- | --- |
+| `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.
+
+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.
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+- Example: [Apply custom conditions](#apply-custom-conditions)
+
+### `connection`
+
+The `connection` block specifies settings that let provisioners connect to resources so that Terraform can perform operations on the resource after creating it.
+
+<Warning>
+
+We recommend using configuration management tools or other means to perform actions on the local or remote machine instead of using provisioners. Refer to [Perform post-apply action](#)<!--TODO: updated with real link when ready--> for more information.
+
+</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.
+
+```hcl
+resource {
+  # . . .
+  connection {
+    <settings for all provisioners in the resource>
+  }
+}
+```
+
+When added to a `provisioner` block, the `connection` block defines settings specific to the provisioner.
+
+```hcl
+resource {
+  # . . .
+  provisioner {
+    # . . .
+    connection {
+      <settings for all provisioners in the resource>
+    }
+  }
+}
+```
+
+Terraform does not validate SSH host keys by default. You can establish a separate mechanism for key distribution and explicitly set the `host_key` argument to verify against a specific key or signing CA.
+
+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`.
+
+<span id="connection-arguments"/>
+
+<Tip>
+
+You can provide multiple connections so that an initial provisioner can connect as the root user to set up user accounts and subsequent provisioners can connect as less-privileged users to perform more specific operations.
+
+</Tip>
+
+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> |
+| `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> |
+| `timeout` | Specifies how long to wait for the connection to become available. | string | `ssh`<p>`winrm`</p> | `"5m"` |
+| `script_path` | Specifies the path on the remote resource where Terraform copies scripts to. Refer to the [`provisioner` block reference](#provisioner) for more information. Terraform copies scripts to a path that contains random numbers depending on the `target_platform` configuration. | string | `ssh`<p>`winrm`</p> | <p>`/tmp/terraform_%RAND%.sh` when `target_platform` is `unix`</p><p>`C:/windows/temp/`<br/>`terraform_%RAND%.cmd` when `target_platform` is `windows`</p> |
+| `private_key` | Specifies the contents of an SSH key to use for the connection. `private_key` takes precedence over `password` when both are provided. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load keys from file.</p> | `ssh` | none |
+| `certificate` | Specifies the contents of a signed CA certificate. You must also configure a  `private_key` arugment. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load certificates from file.</p> | `ssh` | none |
+| `agent` | Specifies an SSH agent for authentication. Set to `false` to disable using `ssh-agent` to authenticate. On Windows, the only supported SSH authentication agent is [Pageant](http://the.earth.li/\~sgtatham/putty/0.66/htmldoc/Chapter9.html#pageant). | string | `ssh` | `false` |
+| `agent_identity` | Specifies the preferred identity from the SSH agent to use for authentication. | string | `ssh` | none |
+| `host_key` | Specifies the public key from the remote host or the signing CA to verify the connection. | string | `ssh` | none |
+| `target_platform` | Specifies the target platform, which affects the default value for the `script_path` argument. You can specify either `windows` or `unix`. <p>`windows` sets the default `script_path` to `c:\windows\temp\terraform_%RAND%.cmd` if the default SSH shell on the remote resource is `cmd.exe`. Refer to the [Windows documentation](https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_server_configuration#configuring-the-default-shell-for-openssh-in-windows) for more information. If the SSH default shell is PowerShell, set `script_path` to `"c:/windows/temp/terraform_%RAND%.ps1"`.</p><p>`unix` sets the default `script_path` to `/tmp/terraform_%RAND%.sh`. </p> | string | `ssh` |`unix` |
+| `https` | Set to `true` to connect using HTTPS instead of HTTP. | boolean | `winrm` | `false` |
+| `insecure` | Set to `true` to skip validating the HTTPS certificate chain. | boolean | `winrm` | `false` |
+| `use_ntlm` | Set to `true` to use NTLM authentication instead of basic authentication. Using NTLM removes the requirement for basic authentication to be enabled within the target guest. Refer to [Authentication for Remote Connections](https://docs.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections) in the Windows App Development documentation for more details. | boolean | `winrm` | `false` |
+| `cacert` | Specifies the CA certificate to validate against. | string | `winrm` | none |
+| `bastion_host` | Specifies the address of the bastion host. The provisioner connects to `bastion_host` before connecting to `host`. | string | `ssh` | none |
+| `bastion_host_key` | Specifies the public key from the remote host or the signing CA to verify the host connection. | string | `ssh` | none |
+| `bastion_port` | Specifies the port number to use for the bastion host connection. | string | `ssh` | value of the `port` field|
+| `bastion_user`| Specifies the user name for connecting to the bastion host. | string | `ssh` | value of the `user` field |
+| `bastion_password` | Specifies the user password for connecting to the bastion host. | string | `ssh` | value of the `password` field |
+| `bastion_private_key` | Specifies the contents of an SSH key file to use for the bastion host. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load keys from file.</p> | `ssh` | value of the `private_key` field |
+| `bastion_certificate` |  Specifies the contents of a signed CA certificate. You must also configure the `bastion_private_key` argument when providing the certificate for the bastion host. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load certificates from file.</p> | `ssh` | value of the `certificate` field |
+| `proxy_scheme` | Specifies the connection protocol. You can specify one of the following values: <li>`http`</li><li>`https`</li><li> `socks5`</li> | string | `ssh` | none |
+| `proxy_host` | Specifies the address of the proxy host. The provisioner connects to the proxy host first. When `bastion_host` is configured, the provisioner connects to the bastion host next, otherwise the provisioner connects to the host specified in the `host` argument.  | string | `ssh` | none |
+| `proxy_port` | Specifies the port number to use for the proxy host connection. | number | `ssh` | none |
+| `proxy_user_name` | Specifies the user name for connecting to the proxy host. You should only configure this argument when the proxy server requires authentication. | string | `ssh` | none |
+| `proxy_user_password` | Specifies the user password for connecting to the proxy host. You should only configure this argument when the proxy server requires authentication. | string | `ssh` | none |
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+- Example: [Connect to remote resources](#connect-to-remote-resources)
+
+### `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.
+
+```hcl
+resource {
+  provisioner "<TYPE>" {
+    <arguments>
+  }
+}
+```
+
+<Warning>
+
+We recommend using configuration management tools or other means to perform actions on the local or remote machine instead of using the `provisioner` block. Refer to [Perform post-apply action](#)<!--TODO: updated with real link when ready--> for more information.
+
+</Warning>
+
+The `provisioner` block supports the following arguments:
+
+- `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.
+- `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:
+
+| Provisioner type | Arguments |
+| --- | --- |
+| `file` | <li>[`source`](#source)</li><li>[`content`](#content)</li><li>[`destination`](#destination)</li> |
+| `local-exec` | <li>[`command`](#command)</li><li>[`working_dir`](#working_dir)</li><li>[`interpreter`](#interpreter)</li><li>[`environment`](#command)</li><li>[`when`](#when)</li><li>[`quiet`](#quiet)</li> |
+| `remote-exec` | <li>[`inline`](#inline)</li><li>[`script`](#script)</li><li>[`scripts`](#scripts)</li> |
+| All types | <li>[`connection`](#connection)</li> <li>[`on_failure`](#on_failure)</li> |
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+
+### `source`
+
+The `source` specifies the location of a file or directory to copy to the location specified in the [`destination`](#destination) argument.
+
+```hcl
+resource {
+  provisioner "file" {
+    source = "<path>"
+  }
+}
+```
+
+
+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`.
+
+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
+
+- Data type: String.
+- Default: None.
+- Example: [Copy content to new resources](#copy-content-to-new-resources).
+
+### `content`
+
+The `content` argument specifies content to write directly to the location specified in the [`destination`](#destination) argument.
+
+```hcl
+resource {
+  provisioner "file" {
+    content = "<content>"
+  }
+}
+```
+
+
+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.
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+- Example: [Copy content to new resources](#copy-content-to-new-resources).
+
+### `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.
+
+```hcl
+resource {
+  provisioner "file" {
+    destination = "<path>"
+  }
+}
+```
+
+
+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.
+
+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.
+
+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 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.
+
+Modern Windows systems support running an OpenSSH server, so we strongly recommend choosing SSH over WinRM.
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+- Example: [Copy content to new resources](#copy-content-to-new-resources).
+
+### `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.
+```hcl
+resource {
+  provisioner "local-exec" {
+    command = "<path>"
+  }
+}
+```
+
+Terraform evaluates the command in a local shell and can use environment variables for variable substitution. We do not recommend using Terraform variables for variable substitution because doing so can lead to shell injection vulnerabilities. Instead, use the `environment` parameter and environment variable substitution. Refer to the following OWASP article for more information about injection flaws: [Code Injection](https://owasp.org/www-community/attacks/Code_Injection).
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+- This argument is required in the `provisioner "local-exec"` block.
+- Example: [Invoke executables](#invoke-executables).
+
+### `working_dir`
+
+The `working_dir` block specifies the working directory where Terraform executes the command specified in the the [`command`](#command) argument. You can specify a relative path to the current working directory or an absolute path. The directory must already exist.
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    working_dir = "<path>"
+  }
+}
+```
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+- Example: [Invoke executables](#invoke-executables).
+
+### `interpreter`
+
+The `interpreter` block specifies a list of interpreter arguments for running the executable specified in the [`command`](#command) argument.
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    interpreter = [ "<path/to/interpreter>", "<command argument>" ]
+  }
+}
+```
+
+
+The first argument in the list is a path to the interpreter. You can specify a relative path to the current working directory or an absolute path. If you do not specify an interpreter, Terraform uses operating system defaults.
+
+#### Summary
+
+- Data type: List.
+- Default: None.
+- Example: [Invoke executables](#invoke-executables).
+
+### `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.
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    environment {
+      <KEY> = <VALUE>
+    }
+  }
+}
+```
+
+#### Summary
+
+- Data type: Block.
+- Default: None.
+- Example: [Invoke executables](#invoke-executables).
+
+### `when`
+
+The `when` argument specifies a Terraform command that triggers actions specified in the provisioner.
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    when = <Terraform command>
+  }
+}
+```
+
+
+When you run the specified Terraform command, Terraform performs run the command specified in the [`command`](#command) argument. Refer to [Destroy-time provisioners](terraform/language/resources/provisioners/syntax#destroy-time-provisioners) for instructions on using the `when` argument.
+
+#### Summary
+
+- Data type: Terraform command.
+- Default: None.
+- Example: [Invoke executables](#invoke-executables).
+
+### `quiet`
+
+The `quiet` argument disables printing the [`command`](#command) argument's output to `stdout`.
+
+
+```hcl
+resource {
+  provisioner "local-exec" {
+    quiet = <boolean>
+  }
+}
+```
+
+When `quiet` is set to `true`, Terraform prints `"Suppressed by quiet=true"` to `stdout`. Terraform still prints the output of the command.
+
+
+#### Summary
+
+- Data type: Boolean.
+- Default: None.
+
+### `inline`
+
+Specifies a list of command strings to execute on the remote resource.
+
+
+```hcl
+resource {
+  # ...
+  provisioner "remote-exec" {
+    inline = [ "<command>" ]
+  }
+}
+```
+
+The provisioner uses the remote resource's default shell unless you specify a shell as the first command, for example `#!/bin/bash`. You cannot add an `inline` argument in the same provisioner with `script` or `scripts`.
+
+#### Summary
+
+- Data type: List.
+- Default: None.
+
+### `script`
+
+Specifies the relative or absolute path to a script on the local machine to copy and execute on the remote resource.
+
+
+```hcl
+resource {
+  # ...
+  provisioner "remote-exec" {
+    scripts = "<path-to-script>"
+  }
+}
+```
+
+You cannot add a `script` argument in the same provisioner with `inline` or `scripts`.
+
+#### Summary
+
+- Data type: String.
+- Default: None.
+
+### `scripts`
+
+Specifies a list of relative or absolute paths to script files on the local machine to copy and execute on the remote resource.
+
+```hcl
+resource {
+  # ...
+  provisioner "remote-exec" {
+    scripts = [ "<path-to-script>" ]
+  }
+}
+```
+
+You cannot add a `scripts` argument in the same provisioner with `inline` or `script`.
+
+#### Summary
+
+- Data type: List.
+- Default: None.
+
+## Examples
+
+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`.
+
+```hcl
+resource "aws_instance" "web" {
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+}
+```
+
+### Create multiple instances of a resource
+
+You can use either `count` or the `for_each` block to create multiple instances of a resource. The `count` argument is most suitable for creating multiple instances that are identical or nearly identical. The `for_each` argument is most suitable for creating multiple similar instances based on attributes defined in a map or set.
+
+<Tabs>
+
+<Tab heading="count">
+
+The following example creates one instance for each subnet provided in the input variable:
+
+```hcl
+variable "subnet_ids" {
+  type = list(string)
+}
+
+resource "aws_instance" "server" {
+
+  count = length(var.subnet_ids)
+
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+  subnet_id     = var.subnet_ids[count.index]
+
+  tags = {
+    Name = "Server ${count.index}"
+  }
+}
+```
+
+</Tab>
+
+<Tab heading="for_each">
+
+The following example creates two instances that reference a map created using the `tomap()` function:
+
+```hcl
+resource "azurerm_resource_group" "rg" {
+  for_each = tomap({
+    a_group       = "eastus"
+    another_group = "westus2"
+  })
+  name     = each.key
+  location = each.value
+}
+```
+
+The following example creates four instances using a set created with the `toset()` function:
+
+```hcl
+resource "aws_iam_user" "the-accounts" {
+  for_each = toset(["Todd", "James", "Alice", "Dottie"])
+  name     = each.key
+}
+```
+
+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">
+
+```hcl
+module "bucket" {
+  for_each = toset(["assets", "media"])
+  source   = "./publish_bucket"
+  name     = "${each.key}_bucket"
+}
+```
+
+</CodeBlockConfig>
+
+<CodeBlockConfig filename="publish_bucket/bucket-and-cloudfront.tf">
+
+```hcl
+variable "name" {}
+
+resource "aws_s3_bucket" "example" {
+   bucket = var.name
+   #...
+}
+
+resource "aws_iam_user" "deploy_user" {
+   #...
+}
+```
+
+</CodeBlockConfig>
+
+</Tab>
+
+</Tabs>
+
+### Specify a dependency
+
+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:
+
+```hcl
+resource "aws_iam_role" "example" {
+  name = "example"
+  assume_role_policy = "..."
+}
+
+resource "aws_iam_instance_profile" "example" {
+  role = aws_iam_role.example.name
+}
+
+resource "aws_iam_role_policy" "example" {
+  name   = "example"
+  role   = aws_iam_role.example.name
+  policy = jsonencode({
+    "Statement" = [{
+      "Action" = "s3:*",
+      "Effect" = "Allow",
+    }],
+  })
+}
+
+resource "aws_instance" "example" {
+  ami           = "data.aws_ami.example.id"
+  instance_type = "t2.micro"
+  iam_instance_profile = aws_iam_instance_profile.example
+  depends_on = [
+    aws_iam_role_policy.example
+  ]
+}
+
+data "aws_ami" "example" {
+  # AMI configuration
+}
+```
+
+Note that the `aws_iam_role` resource is partially defined. Refer to the [AWS provider documentation](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_role) for all configuration settings.
+
+### Select an alternate provider configuration
+
+In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias.
+
+```hcl
+provider "google" {
+  region = "us-central1"
+}
+
+provider "google" {
+  alias  = "europe"
+  region = "europe-west1"
+}
+
+resource "google_compute_instance" "example" {
+  provider = google.europe
+  # ...
+}
+```
+
+### Ignore attribute changes
+
+In the following example, Terraform ignores changes to the resource's tags:
+
+```hcl
+resource "aws_instance" "example" {
+   # ...
+
+   lifecycle {
+      ignore_changes = [tags]
+   }
+}
+```
+
+### Specify triggers that replace resources
+
+In the following example, Terraform replaces `aws_appautoscaling_target` each time this instance of `aws_ecs_service` is replaced:
+
+```hcl
+resource "aws_appautoscaling_target" "ecs_target" {
+   ...
+   lifecycle {
+   replace_triggered_by = [
+      aws_ecs_service.svc.id
+     ]
+   }
+}
+```
+
+### 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 `data` block instructs Terraform to retrieve the ID of the `ami-abc123` AMI:
+
+```hcl
+data "aws_ami" "example" {
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-abc123"]
+  }
+}
+```
+
+In the following code, the `precondition` block specifies that the AMI ID retrieved from the `data` block must include `x86_64` as its `architecture` attribute. The `postcondition` block specifies that the EC2 instance must be allocated a public DNS hostname. When either condition is not met, Terraform returns the `error_message` for the failed condition:
+
+```hcl
+resource "aws_instance" "example" {
+  instance_type = "t3.micro"
+  ami           = data.aws_ami.example.id
+
+  lifecycle {
+    precondition {
+      condition     = data.aws_ami.example.architecture == "x86_64"
+      error_message = "The selected AMI must be for the x86_64 architecture."
+    }
+
+    postcondition {
+      condition     = self.public_dns != ""
+      error_message = "EC2 instance must be in a VPC that has public DNS hostnames enabled."
+    }
+  }
+}
+```
+
+The following `data` block retrieves the root storage volume connected to the `aws_instance.example` EC2 instance using the `volume_id` attribute. When a `data` resource verifies the result of a managed resource declared in the same configuration, you must define the check in a `postcondition` block in the resource so that Terraform waits for changes to the managed resource to complete before reading the data resource.
+
+```hcl
+data "aws_ebs_volume" "example" {
+  filter {
+    name = "volume-id"
+    values = [aws_instance.example.root_block_device[0].volume_id]
+  }
+  lifecycle {
+    # The EC2 instance will have an encrypted root volume.
+    postcondition {
+      condition     = self.encrypted
+      error_message = "The server's root volume is not encrypted."
+    }
+  }
+}
+output "api_base_url" {
+  value = "https://${aws_instance.example.private_dns}:8433/"
+}
+```
+
+### Copy content to new resources
+
+The following examples use the `file` provisioner type to copy artifacts from the machine where Terraform is running to the newly created resource.
+
+```hcl
+resource "aws_instance" "web" {
+  # ...
+
+  # Copies the myapp.conf file to /etc/myapp.conf
+  provisioner "file" {
+    source      = "conf/myapp.conf"
+    destination = "/etc/myapp.conf"
+  }
+
+  # Copies the string in content into /tmp/file.log
+  provisioner "file" {
+    content     = "ami used: ${self.ami}"
+    destination = "/tmp/file.log"
+  }
+
+  # Copies the configs.d folder to /etc/configs.d
+  provisioner "file" {
+    source      = "conf/configs.d"
+    destination = "/etc"
+  }
+
+  # Copies all files and folders in apps/app1 to D:/IIS/webapp1
+  provisioner "file" {
+    source      = "apps/app1/"
+    destination = "D:/IIS/webapp1"
+  }
+}
+```
+
+### Invoke executables
+
+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:
+
+```hcl
+resource "aws_instance" "web" {
+  # ...
+
+  connection {
+    type     = "ssh"
+    user     = "root"
+    password = var.root_password
+    host     = self.public_ip
+  }
+
+  provisioner "remote-exec" {
+    inline = [
+      "puppet apply",
+      "consul join ${aws_instance.web.private_ip}",
+    ]
+  }
+}
+```
+
+In the following example, Terraform uploads a script to the instance and provides inline commands to run the script:
+
+```hcl
+resource "aws_instance" "web" {
+  # ...
+
+  provisioner "file" {
+    source      = "script.sh"
+    destination = "/tmp/script.sh"
+  }
+
+  provisioner "remote-exec" {
+    inline = [
+      "chmod +x /tmp/script.sh",
+      "/tmp/script.sh args",
+    ]
+  }
+}
+```
+
+### Connect to remote resources
+
+The following example establishes a connection that all provisioners in the `resource` block can use to run commands on the remote resource:
+
+```hcl
+resource "aws_instance" "web" {
+  # ...
+
+
+  connection {
+    type     = "ssh"
+    user     = "root"
+    password = var.root_password
+    host     = self.public_ip
+  }
+
+  provisioner "remote-exec" {
+    inline = [
+      "puppet apply",
+      "consul join ${aws_instance.web.private_ip}",
+    ]
+  }
+}
+```
+
+### Define provisioner failure behaviors
+
+In the following example, Terraform runs the `echo` command on the local machine after creating the `web` resource. Terraform continues with the operation if the command fails:
+
+```hcl
+resource "aws_instance" "web" {
+  # ...
+
+  provisioner "local-exec" {
+    command    = "echo The server's IP address is ${self.private_ip}"
+    on_failure = continue
+  }
+}
+```
diff --git a/content/terraform/v1.12.x/docs/language/block/terraform.mdx b/content/terraform/v1.12.x/docs/language/block/terraform.mdx
new file mode 100644
index 000000000..260d9375c
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/terraform.mdx
@@ -0,0 +1,215 @@
+---
+page_title: Terraform block reference for the Terraform configuration language
+description: >-
+  The `terraform` block allows you to configure Terraform behavior, including the Terraform version, backend, integration with HCP Terraform, and required providers.
+---
+
+# `terraform` block reference
+
+This topic provides reference information about the `terraform` block. The `terraform` block allows you to configure Terraform behavior, including the Terraform version, backend, integration with HCP Terraform, and required providers.
+
+## Configuration model
+
+The following list outlines attribute hierarchy, data types, and requirements in the `terraform` block. Click on an attribute for details.
+
+- [`terraform`](#terraform)
+  - [`required_version`](#terraform-required_version): string
+  - [`required_providers`](#terraform-required_providers): map
+  - [`provider_meta "<LABEL>"`](#terraform-provider_meta): map
+  - [`backend "<BACKEND_TYPE>"`](#terraform-backend): map
+  - [`cloud`](#terraform-cloud): map
+    - [`organization`](#terraform-cloud-organization): string | required when connecting to HCP Terraform
+    - [`workspaces`](#terraform-cloud-workspaces): map | required when connecting to HCP Terraform
+      - [`tags`](#terraform-cloud-workspaces): list of strings or map of strings
+      - [`name`](#terraform-cloud-workspaces): string
+      - [`project`](#terraform-cloud-workspaces): string
+    - [`hostname`](#terraform-cloud-workspaces): string | `app.terraform.io`
+    - [`token`](#terraform-cloud-token): string
+  - [`experiments`](#terraform-experiments): list of strings
+
+## Specification
+
+This section provides details about the fields you can configure in the `terraform` block. Specific providers and backends may support additional fields.
+
+### `terraform`
+
+Parent block that contains configurations that define Terraform behavior. You can only use constant values in the `terraform` block. Arguments in the `terraform` block cannot refer to named objects, such as resources and input variables. Additionally, you cannot use built-in Terraform language functions in the block.
+
+### `terraform{}.required_version`
+
+Specifies which version of the Terraform CLI is allowed to run the configuration. Refer to [Version constraints](/terraform/language/expressions/version-constraints) for details about the supported syntax for specifying version constraints.
+
+Use Terraform version constraints in a collaborative environment to ensure that everyone is using a specific Terraform version, or using at least a minimum Terraform version that has behavior expected by the configuration.
+
+Terraform prints an error and exits without taking actions when you use a version of Terraform that does not meet the version constraints to run the configuration.
+
+Modules associated with a configuration may also specify version constraints. You must use a Terraform version that satisfies all version constraints associated with the configuration, including constraints defined in modules, to perform operations. Refer to [Modules](/terraform/language/modules) for additional information about Terraform modules.
+
+The `required_version` configuration applies only to the version of Terraform CLI and not versions of provider plugins. Refer to [Provider Requirements](/terraform/language/providers/requirements) for additional information.
+
+- Data type: String
+- Default: Latest version of Terraform
+
+### `terraform{}.required_providers`
+
+Specifies all provider plugins required to create and manage resources specified in the configuration. Each local provider name maps to a source address and a version constraint. Refer to each Terraform provider’s documentation in the [public Terraform Registry](https://registry.terraform.io/browse/providers), or your private registry, for instructions on how to configure attributes in the `required_providers` block.
+
+- Data type: Map
+
+### `terraform{}.provider_meta "<LABEL>"`
+
+Specifies metadata fields that a provider may expect. Individual modules can populate the metadata fields independently of any provider configuration. Refer to [Provider Metadata](/terraform/internals/provider-meta) for additional information.
+
+- Data type: Map
+
+### `terraform{}.backend "<BACKEND_TYPE>"`
+
+Specifies a mechanism for storing Terraform state files. The `backend` block takes a backend type as an argument. Refer to [Backend Configuration](/terraform/language/backend) for details about configuring the `backend` block.
+
+You cannot configure a `backend` block when the configuration also contains a [`cloud` configuration](#terraform-cloud) for storing state data.
+
+- Data type: Map
+
+### `terraform{}.cloud`
+
+Specifies a set of attributes that allow the Terraform configuration to connect to either HCP Terraform or a Terraform Enterprise installation. HCP Terraform and Terraform Enterprise provide state storage, remote execution, and other benefits. Refer to the [HCP Terraform](/terraform/cloud-docs) and [Terraform Enterprise](/terraform/enterprise) documentation for additional information.
+
+You can only provide one `cloud` block per configuration.
+
+You cannot configure a `cloud` block when the configuration also contains a [`backend` configuration](#terraform-backend) for storing state data.
+
+The `cloud` block cannot refer to named values, such as input variables, locals, or data source attributes.
+
+- Data type: Map
+
+### `terraform{}.cloud{}.organization`
+
+Specifies the name of the organization you want to connect to. Instead of hardcoding the organization as a string, you can alternatively use the [`TF_CLOUD_ORGANIZATION`](#tf_cloud_organization) environment variable.
+
+- Data type: String
+- Required when connecting to HCP Terraform
+
+### `terraform{}.cloud{}.workspaces`
+
+Specifies metadata for matching workspaces in HCP Terraform. Terraform associates the configuration with workspaces managed in HCP Terraform that match the specified tags, name, or project. You can specify the following metadata in the `workspaces` block:
+
+| Attribute | Description | Data type |
+| --- | --- | --- |
+| `tags` | Specifies either a map of strings as key/value tags or a list of single-value, key-only tags. Terraform associates the configuration with workspaces that have all matching tags. New workspaces created from the working directory inherit the tags. You cannot set this attribute and the `name` attribute in the same configuration. Using a map type with both keys and values requires Terraform 1.10+. | Array of strings or Map of strings |
+| `name` | Specifies an HCP Terraform workspace name to associate the Terraform configuration with. You can only use the working directory with the workspace named in the configuration. You cannot manage the workspace from the Terraform CLI. You cannot set this attribute and the `tags` attribute in the same configuration. <p>Instead of hardcoding a single workspace as a string, you can alternatively use the [`TF_WORKSPACE`](#tf_workspace) environment variable. </p> | String |
+| `project` | Specifies the name of an HCP Terraform project. Terraform creates all workspaces that use this configuration in the project. Using the [`terraform workspace list` command](/terraform/cli/commands/workspace/list) in the working directory returns only workspaces in the specified project. <p>Instead of hardcoding the project as a string, you can alternatively use the [`TF_CLOUD_PROJECT`](#tf_cloud_project) environment variable.</p> | String |
+
+- Data type: Map
+- Required when connecting to HCP Terraform
+
+### `terraform{}.cloud{}.hostname`
+
+Specifies the hostname for a Terraform Enterprise deployment. Instead of hardcoding the hostname of the Terraform Enterprise deployment, you can alternatively use the [`TF_CLOUD_HOSTNAME`](#tf_cloud_hostname) environment variable.
+
+- Data type: String
+- Required when connecting to Terraform Enterprise
+- Default: `app.terraform.io`
+
+### `terraform{}.cloud{}.token`
+
+Specifies a token for authenticating with HCP Terraform. We recommend omitting the token from the configuration and either using the [`terraform login` command](/terraform/cli/commands/login) or manually configuring credentials in the [CLI configuration file](/terraform/cli/config/config-file#credentials) instead.
+
+- Data type: String
+
+### `terraform{}.experiments`
+
+Specifies a list of experimental feature names that you want to opt into. In releases where experimental features are available, you can enable them on a per-module basis.
+
+Experiments are subject to arbitrary changes in later releases and, depending on the outcome of the experiment, may change significantly before final release or may not be released in stable form at all. Breaking changes may appear in minor and patch releases. We do not recommend using experimental features in Terraform modules intended for production.
+
+Modules with experiments enabled generate a warning on every `terraform plan` or `terraform apply` operation. If you want to try experimental features in a shared module, we recommend enabling the experiment only in alpha or beta releases of the module.
+
+Refer to the [Terraform changelog](https://github.com/hashicorp/terraform/blob/main/CHANGELOG.md) for information about experiments and to monitor the release notes about experiment keywords that may be available.
+
+- Data type: List of strings
+
+## Environment variables for the `cloud` block
+
+You can use environment variables to configure one or more `cloud` block attributes. This is helpful when you want to use the same Terraform configuration in different HCP Terraform organizations and projects. Terraform only uses these variables if you do not define  corresponding attributes in your configuration. If you choose to configure the `cloud` block entirely through environment variables, you must still add an empty `cloud` block in your configuration file.
+
+<Warning>
+
+You can use environment variables to automate Terraform operations, which has specific security considerations. Refer to [Non-Interactive Workflows](/terraform/cloud-docs/run/cli#non-interactive-workflows) for details.
+
+</Warning>
+
+Use the following environment variables to configure the `cloud` block:
+
+- `TF_CLOUD_ORGANIZATION` - The name of the organization. Terraform reads this variable when `organization` is omitted from the `cloud` block`. If both are specified, the configuration takes precedence.
+
+- `TF_CLOUD_HOSTNAME` - The hostname of a Terraform Enterprise installation. Terraform reads this when `hostname` is omitted from the `cloud` block. If both are specified, the configuration takes precedence.
+
+- `TF_CLOUD_PROJECT` - The name of an HCP Terraform project. Terraform reads this when `workspaces.project` is omitted from the `cloud` block. If both are specified, the cloud block configuration takes precedence.
+
+- `TF_WORKSPACE` - The name of a single HCP Terraform workspace. Terraform reads this when `workspaces` is omitted from the `cloud` block. HCP Terraform will not create a new workspace from this variable; the workspace must exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, the value of `TF_WORKSPACE` must be included in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](/terraform/cli/config/environment-variables#tf_workspace) for details.
+
+## Examples
+
+The following examples demonstrate common configuration patterns for specific use cases.
+
+### Add a provider
+
+The following configuration requires the `aws` provider version 2.7.0 or later from the public Terraform registry:
+
+```hcl
+terraform {
+  required_providers {
+    aws = {
+      version = ">= 2.7.0"
+      source = "hashicorp/aws"
+    }
+  }
+}
+```
+
+### Connect to HCP Terraform
+
+In the following example, the configuration links the working directory to workspaces in the `example_corp` organization that contain the `layer=app` tag:
+
+```hcl
+terraform {
+  cloud {
+    organization = "example_corp"
+    workspaces {
+      tags = {
+        layer = "app"
+      }
+    }
+  }
+}
+```
+
+### Connect to Terraform Enterprise
+
+In the following example, the configuration links the working directory to workspaces in the `example_corp` organization that contain the `app` key-only tag. Key-only tags must be used with versions of Terraform Enterprise prior to v202411-1 or versions of Terraform prior to v1.10. The `hostname` field is required in the configuration unless you use the `TF_CLOUD_HOSTNAME` environment variable:
+
+```hcl
+terraform {
+  cloud {
+    organization = "example_corp"
+    hostname = "my.terraform-enterprise.host"
+    workspaces {
+      tags = ["app"]
+    }
+  }
+}
+```
+
+### Connect to Terraform Enterprise using environment variables
+
+In the following example, Terraform checks the `TF_CLOUD_ORGANIZATION` and `TF_CLOUD_HOSTNAME` environment variables and automatically populates the `organization` and `hostname` arguments. During initialization, the local Terraform CLI connects the working directory to Terraform Enterprise using those values. As a result, Terraform links the configuration to either HCP Terraform or Terraform Enterprise and allows teams to  reuse the configuration in different continuous integration pipelines:
+
+```hcl
+terraform {
+  cloud {
+    workspaces {
+      tags = ["app"]
+    }
+  }
+}
+```
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/checks/index.mdx b/content/terraform/v1.12.x/docs/language/checks/index.mdx
deleted file mode 100644
index 469c21574..000000000
--- a/content/terraform/v1.12.x/docs/language/checks/index.mdx
+++ /dev/null
@@ -1,121 +0,0 @@
----
-page_title: Checks - Configuration Language
-description: >-
-  Check customized infrastructure requirements to provide ongoing and continuous verification.
----
-
-# Checks
-
--> **Note:** Check blocks are only available in Terraform v1.5.0 and later.
-
-The `check` block can validate your infrastructure outside the usual resource lifecycle. Check blocks address a gap between post-apply and functional validation of infrastructure.
-
-> **Hands-on:** Try the [Validate Infrastructure Using Checks](/terraform/tutorials/configuration-language/checks) tutorial.
-
-Check blocks allow you to define [custom conditions](/terraform/language/expressions/custom-conditions) that execute on every Terraform plan or apply operation without affecting the overall status of an operation. Check blocks execute as the last step of a plan or apply after Terraform has planned or provisioned your infrastructure.
-
-## Syntax
-
-You can declare a `check` block with a local name, zero-to-one scoped [data sources](#scoped-data-sources), and one-to-many [assertions](#assertions).
-
-The following example loads the Terraform website and validates that it returns the expected status code `200`.
-
-```hcl
-check "health_check" {
-  data "http" "terraform_io" {
-    url = "https://www.terraform.io"
-  }
-
-  assert {
-    condition = data.http.terraform_io.status_code == 200
-    error_message = "${data.http.terraform_io.url} returned an unhealthy status code"
-  }
-}
-```
-
-### Scoped data sources
-
-You can use any data source from any provider as a scoped data source within a `check` block.
-
-A `check` block can optionally contain a nested (a.k.a. scoped) data source. This `data` block behaves like an external [data source](/terraform/language/data-sources), except you can not reference it outside its enclosing `check` block. Additionally, if a scoped data source's provider raises any errors, they are masked as warnings and do not prevent Terraform from continuing operation execution.
-
-You can use a scoped data source to validate the status of a piece of infrastructure outside of the usual Terraform resource lifecycle. [In the above example](#checks-syntax), if the `terraform_io` data source fails to load, you receive a warning instead of a blocking error, which would occur if you declared this data source outside of a `check` block.
-
-#### Meta-Arguments
-
-Scoped data sources support the `depends_on` and `provider` [meta-arguments](/terraform/language/resources/syntax#meta-arguments). Scoped data sources do not support the `count` or`for_each` meta-arguments.
-
-##### `depends_on`
-
-The `depends_on` meta-argument can be particularly powerful when used within scoped data sources.
-
-The first time Terraform creates the _initial_ plan for our [previous example](#checks-syntax), the plan fails because Terraform has not applied its configuration yet. Meaning this test fails because Terraform must still create the resources to make this website exist. Therefore, the first time Terraform runs this check, it always throws a potentially distracting error message.
-
-You can fix this by adding [`depends_on`](/terraform/language/meta-arguments/depends_on) to your scoped data source, ensuring it depends on an essential piece of your site's infrastructure, such as the load balancer. The check returns  `known after apply` until that crucial piece of your website is ready. This strategy avoids producing unnecessary warnings during setup, and the check executes during subsequent plans and applies.
-
-One problem with this strategy is that if the resource your scoped data source `depends_on` changes, the check block returns `known after apply` until Terraform has updated that resource. Depending on your use case, this behavior could be acceptable or problematic.
-
-We recommend implementing the `depends_on` meta-argument if your scoped data source depends on the existence of another resource without referencing it directly.
-
-### Assertions
-
-Check blocks validate your custom assertions using `assert` blocks. Each `check` block must have at least one, but potentially many, `assert` blocks. Each `assert` block has a [`condition` attribute](/terraform/language/expressions/custom-conditions#condition-expressions) and an [`error_message` attribute](/terraform/language/expressions/custom-conditions#error-messages).
-
-Unlike other [custom conditions](/terraform/language/expressions/custom-conditions), assertions do not affect Terraform's execution of an operation. A failed assertion reports a warning without halting the ongoing operation. This contrasts with other custom conditions, such as a postcondition, where Terraform produces an error immediately, halting the operation and blocking the application or planning of future resources.
-
-Condition arguments within `assert` blocks can refer to scoped data sources within the enclosing `check` block and any variables, resources, data sources, or module outputs within the current module.
-
-[Learn more about assertions](/terraform/language/expressions/custom-conditions#checks-with-assertions).
-
-### Meta-Arguments
-
-Check blocks do not currently support [meta-arguments](/terraform/language/resources/syntax#meta-arguments). We are still collecting feedback on this feature, so if your use case would benefit from check blocks supporting meta-arguments, please [let us know](https://github.com/hashicorp/terraform/issues/new/choose).
-
-## Continuous validation in HCP Terraform
-
-HCP Terraform can automatically validate whether checks in a workspace’s configuration continue to pass after Terraform provisions new infrastructure. See [Continuous Validation](/terraform/cloud-docs/workspaces/health#continuous-validation) for details.
-
-## Choosing Checks or other Custom Conditions
-
-Check blocks offer the most _flexible_ validation solution within Terraform. You can reference outputs, variables, resources, and data sources within check assertions. You can also use checks to model every alternate [Custom Condition](/terraform/language/expressions/custom-conditions). However, that does not mean you should replace all your custom conditions with check blocks.
-
-There are major behavioral differences between check block assertions and other custom conditions, the main one being that check blocks do _not_ affect Terraform's execution of an operation. You can use this non-blocking behavior to decide the best type of validation for your use case.
-
-### Outputs and variables
-
-[Output preconditions](/terraform/language/expressions/custom-conditions#outputs) and [variable validations](/terraform/language/expressions/custom-conditions#input-variable-validation) both make assertions around inputs and outputs.
-
-This is one of the cases where you might want Terraform to block further execution. 
-
-For example, it is not helpful for Terraform to warn that an input variable is invalid after it applies an entire configuration with that input variable. In this case, a check block would warn of the invalid input variable _without_ interrupting the operation. A validation block for the same input variable would alert you of the invalid variable and halt the plan or apply operation.
-
-### Resource Preconditions and Postconditions
-
-The difference between [preconditions and postconditions](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) and check blocks is more nuanced.
-
-Preconditions are unique amongst the custom conditions in that they execute _before_ a resource change is applied or planned. [Choosing Between Preconditions and Postconditions](/terraform/language/expressions/custom-conditions#choosing-between-preconditions-and-postconditions) offers guidance on choosing between a precondition and a postcondition, and the same topics also apply to choosing between a precondition and a check block.
-
-You can often use postconditions interchangeably with check blocks to validate resources and data sources.
-
-For example, you can [rewrite the above `check` block example](#syntax) to use a postcondition instead. The below code uses a `postcondition` block to validate that the Terraform website returns the expected status code of `200`.
-
-```hcl
-data "http" "terraform_io" {
-  url = "https://www.terraform.io"
-
-  lifecycle {
-    postcondition {
-        condition = self.status_code == 200
-        error_message = "${self.url} returned an unhealthy status code"
-    }
-  }
-}
-```
-
-Both the `check` and `postcondition` block examples validate that the Terraform website returns a `200` status code during a plan or an apply operation. The difference between the two blocks is how each handles failure.
-
-If a `postcondition` block fails, it _blocks_ Terraform from executing the current operation. If a `check` block fails, it _does not_ block Terraform from executing an operation.
-
-If the above example's postcondition fails, it is impossible to recover from. Terraform blocks any future plan or apply operations if your postcondition is unsatisfied during the planning stage. This problem occurs because the postcondition does not directly depend on Terraform configuration, but instead on the complex interactions between multiple resources.
-
-We recommend using check blocks to validate the status of infrastructure as a whole. We only recommend using postconditions when you want a guarantee on a single resource based on that resource's configuration.
diff --git a/content/terraform/v1.12.x/docs/language/data-sources/index.mdx b/content/terraform/v1.12.x/docs/language/data-sources/index.mdx
index f8d652239..a053e392c 100644
--- a/content/terraform/v1.12.x/docs/language/data-sources/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/data-sources/index.mdx
@@ -1,31 +1,83 @@
 ---
-page_title: Data Sources - Configuration Language
-description: >-
-  Data sources allow Terraform to use external data, function output, and data
-  from other configurations. Learn data resource arguments, behavior, and
-  lifecycle.
+page_title: Query data from external sources
+description: You can fetch data from APIs, external Terraform backends, function outputs, and other Terraform configurations. Learn how to query data sources.
 ---
 
-# Data Sources
+# Query infrastructure data
 
-_Data sources_ allow Terraform to use information defined outside of Terraform,
-defined by another separate Terraform configuration, or modified by functions.
+You can instruct Terraform to fetch data from a range of data sources, including APIs, external Terraform workspaces, and function outputs. Dynamically fetching data makes your configuration more flexible. 
 
 > **Hands-on:** Try the [Query Data Sources](/terraform/tutorials/configuration-language/data-sources) tutorial.
 
-Each [provider](/terraform/language/providers) may offer data sources
-alongside its set of [resource](/terraform/language/resources)
-types.
+## Introduction
 
-## Using Data Sources
+Many providers make data sources available when you install the provider. Data sources fetch data from the provider, but do not create or modify resources. To access data from a data source, configure the `data` block and specify its arguments. Refer to your provider's documentation for details about the arguments available for the data source. 
 
-A data source is accessed via a special kind of resource known as a
-_data resource_, declared using a `data` block:
+The provider queries the data source according to the configuration. You can reference the your infrastructure's data using the data source's attributes in other parts of your configuration. 
+
+The `data` block supports expressions and other dynamic Terraform language features. You can also use many of the arguments built into Terraform that control how Terraform creates the data object. Refer to the following topics for details:
+
+- [`data` block reference](/terraform/language/block/data)
+- [Expressions](/terraform/language/expressions)
+- [Meta-arguments](/terraform/language/meta-arguments) 
+
+### Structure
+
+Each data block is associated with a single data source. Terraform can only perform read operations on data sources. 
+
+### Data source behavior
+
+Terraform attempts to query data sources during the planning phase, but depending on details in the configuration it may defer reading until the apply phase. When Terraform must defer reading data sources, it indicates it in the plan output.
+
+Terraform may defer reading the data source to the apply phase when at least one of the arguments refers to a resource attribute or other value that Terraform cannot predict during the plan phase. Terraform may not be able to predict values in the following scenarios:
+
+- The `data` block configuration directly depends on a Terraform-managed resource that is configured to change in the current plan.
+- The `data` block configuration has [custom conditions](#custom-condition-checks) that directly or indirectly depend on a Terraform-managed resource configured to change in the current plan.
+- Arguments in a `data` block refer to values that must be computed during the apply phase.
+
+When the data source depends on other objects, query results are unknown during the plan operation. As a result, Terraform can't provision resources that reference the fetched values until the apply phase. Refer to [Configure dependencies](#dependencies) for more information about dependencies. 
+
+#### References to computed values
+
+When data source arguments refer to computed values, Terraform cannot read from the data source until all of its arguments are defined. In this case, Terraform defers refreshing the data source until the apply phase and all interpolated data source attributes show as `computed` in the plan.
+
+#### References to non-computed values
+
+When arguments in a `data` block refer to values that don't have to be computed, Terraform reads the data source and updates its state during Terraform's refresh phase. By default, Terraform refreshes prior to creating a plan. This ensures that the fetched data is available for use during planning and that the diff shows the real values returned.
+
+### Specialized data sources
+
+Some data sources are specialized utilities that generate data that only exists during the Terraform operation. Terraform re-calculates the data on consecutive plan operations. The following data sources are examples of specialized, local-only data sources: 
+
+- The [`data "template_file"`](https://registry.terraform.io/providers/hashicorp/template/latest/docs/data-sources/file) data source renders a template from a template file. Install the HashiCorp `template` provider to query this data source.   
+- The 
+[`data "local_file"`](https://registry.terraform.io/providers/hashicorp/local/latest/docs/data-sources/file) data source reads local files. Install the HashiCorp `local` provider to query this data source. 
+- The [`data "iam_policy_document"`](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/iam_policy_document) data source renders AWS IAM policies. Install the `aws` provider to query this data source.
+
+## Requirements
+
+We recommend using Terraform 0.13 and newer to add `depends_on` arguments to `data` blocks. In Terraform 0.12 and earlier, adding `depends_on` arguments to `data` blocks forces Terraform to defer the read operation to the apply phase, which may result in unintended behavior.
+
+## Declare a data source
+
+Add a `data` block to your configuration and specify the necessary arguments per the provider documentation. You must include the type of data source and a label to use for the returned data. Refer to the provider documentation for the types of data sources available. The following example declares an `aws_ami` data source named `example`: 
 
 ```hcl
 data "aws_ami" "example" {
-  most_recent = true
+  # . . .
+}
+```
+
+The `data` block instructs Terraform to read from the `aws_ami` data source and export the result to an object named `example`. To reference the returned data, use the `data.<TYPE>.<LABEL>.<ATTRIBUTE>` syntax, for example, `data.aws_ami.example.id`. Refer to [Reference queried data](#referenece-queried-data) for more information.
+
+## Configure query constraints
+
+Configure arguments in the body of the `data` block to define query constraints. Refer to your provider's documentation for available arguments. The following example instructs Terraform to query the [`aws_ami`](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/ami) data source. The query is constrained to the most recent AMI owned by the current user and has a `Name` tag key set to `app-server` and a `Tested` tag key set to `true`.
 
+
+```hcl
+data "aws_ami" "example" {
+  most_recent = true
   owners = ["self"]
   tags = {
     Name   = "app-server"
@@ -34,111 +86,25 @@ data "aws_ami" "example" {
 }
 ```
 
-A `data` block requests that Terraform read from a given data source ("aws_ami")
-and export the result under the given local name ("example"). The name is used
-to refer to this resource from elsewhere in the same Terraform module, but has
-no significance outside of the scope of a module.
-
-The data source and name together serve as an identifier for a given
-resource and so must be unique within a module.
-
-Within the block body (between `{` and `}`) are query constraints defined by
-the data source. Most arguments in this section depend on the
-data source, and indeed in this example `most_recent`, `owners` and `tags` are
-all arguments defined specifically for [the `aws_ami` data source](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/ami).
-
-When distinguishing from data resources, the primary kind of resource (as declared
-by a `resource` block) is known as a _managed resource_. Both kinds of resources
-take arguments and export attributes for use in configuration, but while
-managed resources cause Terraform to create, update, and delete infrastructure
-objects, data resources cause Terraform only to _read_ objects. For brevity,
-managed resources are often referred to just as "resources" when the meaning
-is clear from context.
-
-## Data Source Arguments
-
-Each data resource is associated with a single data source, which determines
-the kind of object (or objects) it reads and what query constraint arguments
-are available.
-
-Each data source in turn belongs to a [provider](/terraform/language/providers),
-which is a plugin for Terraform that offers a collection of resource types and
-data sources that most often belong to a single cloud or on-premises
-infrastructure platform.
-
-Most of the items within the body of a `data` block are defined by and
-specific to the selected data source, and these arguments can make full
-use of [expressions](/terraform/language/expressions) and other dynamic
-Terraform language features.
-
-However, there are some "meta-arguments" that are defined by Terraform itself
-and apply across all data sources. These arguments often have additional
-restrictions on what language features can be used with them, and are described
-in more detail in the following sections.
-
-## Data Resource Behavior
-
-Terraform reads data resources during the planning phase when possible, but
-announces in the plan when it must defer reading resources until the apply
-phase to preserve the order of operations. Terraform defers reading data
-resources in the following situations:
-* At least one of the given arguments is a managed resource attribute or
-  other value that Terraform cannot predict until the apply step.
-* The data resource depends directly on a managed resource that itself has
-  planned changes in the current plan.
-* The data resource has
-  [custom conditions](#custom-condition-checks)
-  and it depends directly or indirectly on a managed resource that itself
-  has planned changes in the current plan.
-
-Refer to [Data Resource Dependencies](#data-resource-dependencies) for details
-on what it means for a data resource to depend on other objects. Any resulting
-attribute of such a data resource will be unknown during planning, so it cannot
-be used in situations where values must be fully known.
-
-## Local-only Data Sources
-
-While many data sources correspond to an infrastructure object type that
-is accessed via a remote network API, some specialized data sources operate
-only within Terraform itself, calculating some results and exposing them
-for use elsewhere.
-
-For example, local-only data sources exist for
-[rendering templates](https://registry.terraform.io/providers/hashicorp/template/latest/docs/data-sources/file),
-[reading local files](https://registry.terraform.io/providers/hashicorp/local/latest/docs/data-sources/file), and
-[rendering AWS IAM policies](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/iam_policy_document).
-
-The behavior of local-only data sources is the same as all other data
-sources, but their result data exists only temporarily during a Terraform
-operation, and is re-calculated each time a new plan is created.
-
-## Data Resource Dependencies
-
-Data resources have the same dependency resolution behavior
-[as defined for managed resources](/terraform/language/resources/behavior#resource-dependencies).
-Setting the `depends_on` meta-argument within `data` blocks defers reading of
-the data source until after all changes to the dependencies have been applied.
-
-In order to ensure that data sources are accessing the most up to date
-information possible in a wide variety of use cases, arguments directly
-referencing managed resources are treated the same as if the resource was
-listed in `depends_on`. This behavior can be avoided when desired by indirectly
-referencing the managed resource values through a `local` value, unless the
-data resource itself has
-[custom conditions](#custom-condition-checks).
-
-~> **NOTE:** **In Terraform 0.12 and earlier**, due to the data resource behavior of deferring the read until the apply phase when depending on values that are not yet known, using `depends_on` with `data` resources will force the read to always be deferred to the apply phase, and therefore a configuration that uses `depends_on` with a `data` resource can never converge. Due to this behavior, we do not recommend using `depends_on` with data resources.
-
-## Custom Condition Checks
-
-You can use `precondition` and `postcondition` blocks to specify assumptions and guarantees about how the data source operates. The following examples creates a postcondition that checks whether the AMI has the correct tags.
+You can use expressions and other dynamic Terraform language features to configure constraints. Refer to [Expressions](/terraform/language/expressions) for more information
+
+## Configure how Terraform creates the data resource
+
+You can use many of the built-in Terrafrom arguments, referred to as [meta-arguments](/terraform/language/meta-arguments), to control how Terraform creates the data source. Refer to the [`data` block reference](/terraform/language/block/data) for information about all `data` block configuration options. 
+
+### Dependencies
+
+Terraform correctly detects dependencies in your configuration, even when indirectly reference a Terraform-managed resource values through a `local` value. There may be times when you want to ensure that Terraform creates resources in a specific order. In those cases, you can add a [`depends_on` argument](/terraform/language/block/data#depends_on) to a `data` block to modify the dependency graph. The `depends_on` argument configures Terraform to defer querying the data source until after it finishes operations for the specified dependency.
+
+### Custom condition checks 
+
+You can add `precondition` and `postcondition` blocks to `data` blocks to specify assumptions and guarantees about how the data source operates. In the following example, the `postcondition` ensures that the AMI data source is tagged with `nomad-server`:
 
 ``` hcl
 data "aws_ami" "example" {
   id = var.aws_ami_id
 
   lifecycle {
-    # The AMI ID must refer to an existing AMI that has the tag "nomad-server".
     postcondition {
       condition     = self.tags["Component"] == "nomad-server"
       error_message = "tags[\"Component\"] must be \"nomad-server\"."
@@ -147,41 +113,56 @@ data "aws_ami" "example" {
 }
 ```
 
-Custom conditions can help capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
+Custom conditions return useful information about errors earlier and in context so that you can more easily diagnose configuration issues. They also help future maintainers understand the configuration design and intent. Refer to [Custom Condition Checks](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
 
-Refer to [Custom Condition Checks](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
+### Multiple instances
 
+You can add [`count`](/terraform/language/block/data#count) and [`for_each`](/terraform/language/block/data#for_each) meta-arguments to `data` blocks  to create multiple instances of the data source. 
 
-## Multiple Resource Instances
+Terraform reads each instance of the data source and indexes the results separately. You can refer to the data returned by each data source independently using the `data.<NAME>[<KEY>]` syntax. The value for `<KEY>` is a number starting at `1` for the `count` meta argument. For the `for_each` argument, the `<KEY>` is the value for each item in the collection.
 
-Data resources support [`count`](/terraform/language/meta-arguments/count)
-and [`for_each`](/terraform/language/meta-arguments/for_each)
-meta-arguments as defined for managed resources, with the same syntax and behavior.
+For example, `data.azurerm_resource_group.rg["a_group"]` refers to an instance of the `data.azurrm_resource_group` data source named `rg` created off of the `a_group` key. Refer to the [`data` block reference](/terraform/language/block/data) for more information.  
 
-As with managed resources, when `count` or `for_each` is present it is important to
-distinguish the resource itself from the multiple resource _instances_ it
-creates. Each instance will separately read from its data source with its
-own variant of the constraint arguments, producing an indexed result.
+### Alternate provider configurations
 
-## Selecting a Non-default Provider Configuration
+You can specify alternate provider configurations with an alias and refer to them in a `data` block. Terraform uses the specified provider configuration when querying the data source. Refer to the [`provider` meta-argument](/terraform/language/block/data#provider) for more information.
 
-Data resources support [the `provider` meta-argument](/terraform/language/meta-arguments/resource-provider)
-as defined for managed resources, with the same syntax and behavior.
+In the following example, the `data` block uses a provider configuration named `aws.west`:
 
-## Lifecycle Customizations
+```hcl
+provider "aws" {
+  region = "us-east-1"
+}
 
-Data resources do not have any customization settings available
-for their lifecycle. Only the `precondition` and `postcondition`
-blocks are allowed in the data resource `lifecycle` block.
+provider "aws" {
+  alias  = "uswest1"
+  region = "us-west-1"
+}
 
-Refer to [Custom Condition Checks](#custom-condition-checks) for more details.
+data "aws_ami" "web" {
+  provider = aws.uswest1
+
+  # ...
+}
+```
+
+## Reference queried data
+
+Use the `data.<TYPE>.<LABEL>.<ATTRIBUTE>` syntax to reference data resource attributes elsewhere in your configuration. In the following example, Terraform creates an AWS instance using the AMI ID fetched from `data.aws_ami.web.id`:
+
+```hcl
+resource "aws_instance" "web" {
+  ami           = data.aws_ami.web.id
+  instance_type = "t1.micro"
+}
+```
 
-## Example
+## Complete example
 
-A data source configuration looks like the following:
+In the following example, the Terraform queries the data source for the latest available AMI that is tagged with `Component = web`:
 
 ```hcl
-# Find the latest available AMI that is tagged with Component = web
+
 data "aws_ami" "web" {
   filter {
     name   = "state"
@@ -197,21 +178,7 @@ data "aws_ami" "web" {
 }
 ```
 
-## Description
-
-The `data` block creates a data instance of the given _type_ (first
-block label) and _name_ (second block label). The combination of the type
-and name must be unique.
-
-Within the block (the `{ }`) is configuration for the data instance. The
-configuration is dependent on the type; as with
-[resources](/terraform/language/resources), each provider on the
-[Terraform Registry](https://registry.terraform.io/browse/providers) has its own
-documentation for configuring and using the data types it provides.
-
-Each data instance will export one or more attributes, which can be
-used in other resources as reference expressions of the form
-`data.<TYPE>.<NAME>.<ATTRIBUTE>`. For example:
+The `data` block creates an `aws_ami` data source named `web`. The combination of type and name must be unique. You can use address prefix `data.aws_ami.web` to reference data fetched from the source. The address is based on the `data.<TYPE>.<NAME>.<ATTRIBUTE>` reference expression syntax. The following example `resource` block uses the ID retrieved from the `aws_ami` in the `ami` argument:
 
 ```hcl
 resource "aws_instance" "web" {
@@ -220,43 +187,4 @@ resource "aws_instance" "web" {
 }
 ```
 
-## Meta-Arguments
-
-As data sources are essentially a read only subset of resources, they also
-support the same [meta-arguments](/terraform/language/resources/syntax#meta-arguments) of resources
-with the exception of the
-[`lifecycle` configuration block](/terraform/language/meta-arguments/lifecycle).
-
-### Non-Default Provider Configurations
-
-Similarly to [resources](/terraform/language/resources), when
-a module has multiple configurations for the same provider you can specify which
-configuration to use with the `provider` meta-argument:
-
-```hcl
-data "aws_ami" "web" {
-  provider = aws.west
-
-  # ...
-}
-```
-
-See
-[The Resource `provider` Meta-Argument](/terraform/language/meta-arguments/resource-provider)
-for more information.
-
-## Data Source Lifecycle
-
-If the arguments of a data instance contain no references to computed values,
-such as attributes of resources that have not yet been created, then the
-data instance will be read and its state updated during Terraform's "refresh"
-phase, which by default runs prior to creating a plan. This ensures that the
-retrieved data is available for use during planning and the diff will show
-the real values obtained.
-
-Data instance arguments may refer to computed values, in which case the
-attributes of the instance itself cannot be resolved until all of its
-arguments are defined. In this case, refreshing the data instance will be
-deferred until the "apply" phase, and all interpolations of the data instance
-attributes will show as "computed" in the plan since the values are not yet
-known.
+The `filter` blocks, and the arguments within them, and the `most_recent` argument are specific to the `aws_ami` provider. Refer to the [AWS provider documenation](https://registry.terraform.io/providers/hashicorp/aws/latest) in the Terraform registry for details. 
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/ephemeral/index.mdx b/content/terraform/v1.12.x/docs/language/ephemeral/index.mdx
index 8a89c1e76..43d32c319 100644
--- a/content/terraform/v1.12.x/docs/language/ephemeral/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/ephemeral/index.mdx
@@ -28,15 +28,8 @@ complete all of their work for the current Terraform run phase. For example, clo
 
 Ephemeral resources form nodes in Terraform's dependency graph, which interact similarly as resources and data sources. For example, when a resource or data source depends on an attribute of an ephemeral resource, Terraform automatically provisions the ephemeral resource first.
 
-## Defer provisioning
-
-If an input argument of an ephemeral resource references a value that Terraform does not know yet, but can learn during or after a plan, Terraform defers executing that resource until the apply stage. Deferring execution lets Terraform ensure it has all of the information it needs to properly provision the ephemeral resource.
-
 ## Configuration model
 
-An `ephemeral` block declares an ephemeral resource of a specific type with a
-specific local name, much like a `resource` block. Terraform uses an ephemeral resource's name to refer to that resource in the same module, but an ephemeral resource's name has no meaning outside that module's scope.
-
 Most of the arguments within the body of an `ephemeral` block are specific to the ephemeral resource you are defining. As with resources and data sources, each provider in the [Terraform Registry](https://registry.terraform.io/browse/providers) includes documentation for the ephemeral resources it supports, if any. An ephemeral resource type's documentation lists which arguments are available and how you should format your resource's values.
 
 The following list outlines general field hierarchy, language-specific data types, and requirements in the `ephemeral` block.
@@ -56,17 +49,16 @@ ephemeral "<resource_type>" "<resource_name>" {
 }
 ```
 
-## Reference ephemeral resources
+## Referencing ephemeral resources
 
 You can only reference ephemeral resources in specific ephemeral contexts or
 Terraform throws an error. The following are valid contexts for referencing
 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 outputs](/terraform/language/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files)
+* In [local values](/terraform/language/block/locals)
+* 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
 
@@ -90,7 +82,7 @@ an ephemeral resource. Since these credentials are managed by an ephemeral resou
 
 ```hcl
 ephemeral "aws_secretsmanager_secret_version" "db_master" {
-  secret_id = aws_secretsmanager_secret_version.db_password.secret_id
+  secret_id = data.aws_db_instance.example.master_user_secret[0].secret_arn
 }
 
 locals {
@@ -98,8 +90,8 @@ locals {
 }
 
 provider "postgresql" {
-  host     = aws_db_instance.example.address
-  port     = aws_db_instance.example.port
+  host     = data.aws_db_instance.example.address
+  port     = data.aws_db_instance.example.port
   username = local.credentials["username"]
   password = local.credentials["password"]
 }
diff --git a/content/terraform/v1.12.x/docs/language/expressions/conditionals.mdx b/content/terraform/v1.12.x/docs/language/expressions/conditionals.mdx
index 28ccc148b..be317e5bd 100644
--- a/content/terraform/v1.12.x/docs/language/expressions/conditionals.mdx
+++ b/content/terraform/v1.12.x/docs/language/expressions/conditionals.mdx
@@ -45,7 +45,7 @@ You can create conditions that produce custom error messages for several types o
 
 Custom conditions can help capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
 
-Refer to [Custom Condition Checks](/terraform/language/expressions/custom-conditions#input-variable-validation) for details.
+Refer to [Validate your configuration](/terraform/language/test-and-validate/validate) for details.
 
 ## Result Types
 
@@ -78,3 +78,135 @@ a string.
 ```hcl
 var.example ? tostring(12) : "hello"
 ```
+
+## Examples
+
+You can use any of Terraform's built-in functions or language operators
+in a condition as long as the expression is valid and returns a boolean result. The following examples demonstrate language features that can help you write condition expressions.
+
+### Logical operator examples
+
+Use the logical operators `&&` (AND), `||` (OR), and `!` (NOT) to combine multiple conditions together.
+
+```hcl
+  condition = var.name != "" && lower(var.name) == var.name
+```
+
+You can also use arithmetic operators, for example `a + b`, equality operators, for example `a == b`, and comparison operators, for example `a < b`. Refer to [Arithmetic and Logical Operators](/terraform/language/expressions/operators) for details.
+
+### `contains` Function
+
+Use the [`contains` function](/terraform/language/functions/contains) to test whether a given value is one of a set of predefined valid values.
+
+```hcl
+  condition = contains(["STAGE", "PROD"], var.environment)
+```
+
+### `length` Function
+
+Use the [`length` function](/terraform/language/functions/length) to test a collection's length and require a non-empty list or map.
+
+```hcl
+  condition = length(var.items) != 0
+```
+
+Using the `length` function is more suitable than using `==` or `!=` when both operands potentially have exactly the same type, which is often ambiguous for empty collections.
+
+### `for` Expressions
+
+Use [`for` expressions](/terraform/language/expressions/for) in conjunction with the functions `alltrue` and `anytrue` to test whether a condition holds for all or for any elements of a collection.
+
+```hcl
+  condition = alltrue([
+    for v in var.instances : contains(["t2.micro", "m3.medium"], v.type)
+  ])
+```
+
+### `can` Function
+
+Use the [`can` function](/terraform/language/functions/can) to concisely use the validity of an expression as a condition. It returns `true` if its given expression evaluates successfully and `false` if it returns any error, so you can use various other functions that typically return errors as a part of your condition expressions.
+
+For example, you can use `can` with `regex` to test if a string matches a particular pattern because `regex` returns an error when given a non-matching string.
+
+```hcl
+  condition = can(regex("^[a-z]+$", var.name))
+```
+
+You can also use `can` with the type conversion functions to test whether a value is convertible to a type or type constraint.
+
+```hcl
+  # This remote output value must have a value that can
+  # be used as a string, which includes strings themselves
+  # but also allows numbers and boolean values.
+  condition = can(tostring(data.terraform_remote_state.example.outputs["name"]))
+```
+
+```hcl
+  # This remote output value must be convertible to a list
+  # type of with element type.
+  condition = can(tolist(data.terraform_remote_state.example.outputs["items"]))
+```
+
+You can also use `can` with attribute access or index operators to test whether a collection or structural value has a particular element or index.
+
+```hcl
+  # var.example must have an attribute named "foo"
+  condition = can(var.example.foo)
+```
+
+```hcl
+  # var.example must be a sequence with at least one element
+  condition = can(var.example[0])
+  # (although it would typically be clearer to write this as a
+  # test like length(var.example) > 0 to better represent the
+  # intent of the condition.)
+```
+
+### `self` Object
+
+Use the `self` object in postcondition blocks to refer to attributes of the instance under evaluation.
+
+```hcl
+resource "aws_instance" "example" {
+  instance_type = "t2.micro"
+  ami           = "ami-abc123"
+
+  lifecycle {
+    postcondition {
+      condition     = self.instance_state == "running"
+      error_message = "EC2 instance must be running."
+    }
+  }
+}
+```
+
+### `each` and `count` Objects
+
+In blocks where [`for_each`](/terraform/language/meta-arguments/for_each) or [`count`](/terraform/language/meta-arguments/count)  are set, use `each` and `count` objects to refer to other resources that are expanded in a chain.
+
+```hcl
+variable "vpc_cidrs" {
+  type = set(string)
+}
+
+data "aws_vpc" "example" {
+  for_each = var.vpc_cidrs
+
+  filter {
+    name   = "cidr"
+    values = [each.key]
+  }
+}
+
+resource "aws_internet_gateway" "example" {
+  for_each = data.aws_vpc.example
+  vpc_id = each.value.id
+
+  lifecycle {
+    precondition {
+      condition     = data.aws_vpc.example[each.key].state == "available"
+      error_message = "VPC ${each.key} must be available."
+    }
+  }
+}
+```
diff --git a/content/terraform/v1.12.x/docs/language/expressions/custom-conditions.mdx b/content/terraform/v1.12.x/docs/language/expressions/custom-conditions.mdx
deleted file mode 100644
index 6f658ad36..000000000
--- a/content/terraform/v1.12.x/docs/language/expressions/custom-conditions.mdx
+++ /dev/null
@@ -1,414 +0,0 @@
----
-page_title: Custom Conditions - Configuration Language
-description: >-
-  Check custom requirements for variables, outputs, data sources, and resources and provide better error messages in context.
----
-
-# Custom Conditions
-
-You can create conditions that produce custom error messages for several types of objects in a configuration. For example, you can add a condition to an input variable that checks whether incoming image IDs are formatted properly. Custom conditions can capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
-
-> **Hands On:** Try the [Validate Infrastructure Using Checks](/terraform/tutorials/configuration-language/checks) tutorial to learn how to use `check` blocks. Try the [Validate Modules with Custom Conditions](/terraform/tutorials/configuration-language/custom-conditions) tutorial to learn how to use other custom conditions.
-
-This page explains the following:
-  - Creating checks with [assertions](#checks-with-assertions) to verify your infrastructure as a whole (Terraform v1.5.0 and later)
-  - Creating [validation conditions](#input-variable-validation) for input variables (Terraform v0.13.0 and later)
-  - Creating [preconditions and postconditions](#preconditions-and-postconditions) for resources, data sources, and outputs (Terraform v1.2.0 and later)
-  - Writing effective [condition expressions](#condition-expressions) and [error messages](#error-messages)
-  - When Terraform [evaluates custom conditions](#conditions-checked-only-during-apply) during the plan and apply cycle
-
-## Selecting a Custom Condition for your use case
-
-Terraform's different custom conditions are best suited to various situations. Use the following broad guidelines to select the best custom condition for your use case:
-1. [Check blocks with assertions](#checks-with-assertions) validate your infrastructure as a whole. Additionally, check blocks do not prevent or block the overall execution of Terraform operations.
-1. [Validation conditions](#input-variable-validation) or [output postconditions](#preconditions-and-postconditions) can ensure your configuration's inputs and outputs meet specific requirements.
-1. Resource [preconditions and postconditions](#preconditions-and-postconditions) can validate that Terraform produces your configuration with predictable results.
-
-For more information on when to use certain custom conditions, see [Choosing Between Preconditions and Postconditions](#choosing-between-preconditions-and-postconditions) and [Choosing Checks or Other Custom Conditions](/terraform/language/checks#choosing-checks-or-other-custom-conditions).
-
-
-## Input Variable Validation
-
--> **Note:** Input variable validation is available in Terraform v0.13.0 and later. Before Terraform v1.9.0, validation rules can refer only to the variable being validated, and not to any other variables.
-
-Add one or more `validation` blocks within the `variable` block to specify custom conditions. Each validation requires a [`condition` argument](#condition-expressions), an expression that must use the value of the variable to return `true` if the value is valid, or `false` if it is invalid. The expression must not cause errors directly itself.
-
-If the condition evaluates to `false`, Terraform produces an [error message](#error-messages) that includes the result of the `error_message` expression. If you declare multiple validations, Terraform returns error messages for all failed conditions.
-
-The following example checks whether the AMI ID has valid 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-\"."
-  }
-}
-```
-
-If the failure of an expression determines the validation decision, use the [`can` function](/terraform/language/functions/can) as demonstrated in the following example.
-
-```hcl
-variable "image_id" {
-  type        = string
-  description = "The id of the machine image (AMI) to use for the server."
-
-  validation {
-    # regex(...) fails if it cannot find a match
-    condition     = can(regex("^ami-", var.image_id))
-    error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"."
-  }
-}
-```
-
-
-## Preconditions and Postconditions
-
--> **Note:** Preconditions and postconditions are available in Terraform v1.2.0 and later.
-
-Use `precondition` and `postcondition` blocks to create custom rules for resources, data sources, and outputs.
-
-Terraform checks a precondition _before_ evaluating the object it is associated with and checks a postcondition _after_ evaluating the object. Terraform evaluates custom conditions as early as possible, but must defer conditions that depend on unknown values until the apply phase. Refer to [Conditions Checked Only During Apply](#conditions-checked-only-during-apply) for more details.
-
-### Usage
-
-Each precondition and postcondition requires a [`condition` argument](#condition-expressions). This is an expression that must return `true` if the conditition is fufilled or `false` if it is invalid. The expression can refer to any other objects in the same module, as long as the references do not create cyclic dependencies. Resource postconditions can also use the [`self` object](#self-object) to refer to attributes of each instance of the resource where they are configured.
-
-If the condition evaluates to `false`, Terraform will produce an [error message](#error-messages) that includes the result of the `error_message` expression. If you declare multiple preconditions or postconditions, Terraform returns error messages for all failed conditions.
-
-The following example uses a postcondition to detect if the caller accidentally provided an AMI intended for the wrong system component.
-
-```hcl
-data "aws_ami" "example" {
-  id = var.aws_ami_id
-
-  lifecycle {
-    # The AMI ID must refer to an existing AMI that has the tag "nomad-server".
-    postcondition {
-      condition     = self.tags["Component"] == "nomad-server"
-      error_message = "tags[\"Component\"] must be \"nomad-server\"."
-    }
-  }
-}
-```
-
-#### Resources and Data Sources
-
-The `lifecycle` block inside a `resource` or `data` block can include both `precondition` and `postcondition` blocks.
-
-- Terraform evaluates `precondition` blocks after evaluating existing `count` and `for_each` arguments. This lets Terraform evaluate the precondition separately for each instance and then make `each.key`, `count.index`, etc. available to those conditions. Terraform also evaluates preconditions before evaluating the resource's configuration arguments. Preconditions can take precedence over argument evaluation errors.
-- Terraform evaluates `postcondition` blocks after planning and applying changes to a managed resource, or after reading from a data source. Postcondition failures prevent changes to other resources that depend on the failing resource.
-
-In most cases, we do not recommend including both a `data` block and a `resource` block that both 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. However, when you need to check a result of a `resource` block that the resource itself does not directly export, you can use a `data` block to check that object safely as long as you place the check as a direct `postcondition` of the `data` block. This tells Terraform that the `data` block is serving as a check of an object defined elsewhere, allowing Terraform to perform actions in the correct order.
-
-#### Outputs
-
-An `output` block can include a `precondition`  block.
-
-Preconditions can serve a symmetrical purpose to input variable `validation` blocks. Whereas input variable validation checks assumptions the module makes about its inputs, preconditions check guarantees that the module makes about its outputs. You can use preconditions to prevent Terraform from saving an invalid new output value in the state. You can also use them to preserve a valid output value from the previous apply, if applicable.
-
-Terraform evaluates output value preconditions before evaluating the `value` expression to finalize the result. Preconditions can take precedence over potential errors in the `value` expression.
-
-### Examples
-
-The following example shows use cases for preconditions and postconditions. The preconditions and postconditions declare the following assumptions and guarantees.
-
-- **The AMI ID must refer to an AMI that contains an operating system for the
-`x86_64` architecture.** The precondition would detect if the caller accidentally built an AMI for a different architecture, which may not be able to run the software this virtual machine is intended to host.
-
-- **The EC2 instance must be allocated a public DNS hostname.** In Amazon Web Services, EC2 instances are assigned public DNS hostnames only if they belong to a virtual network configured in a certain way. The postcondition would detect if the selected virtual network is not configured correctly, prompting the user to debug the network settings.
-
-- **The EC2 instance will have an encrypted root volume.** The postcondition ensures that the root volume is encrypted, even though the software running in this EC2 instance would probably still operate as expected on an unencrypted volume. This lets Terraform produce an error immediately, before any other components rely on the new EC2 instance.
-
-```hcl
-
-data "aws_ami" "example" {
-  owners = ["amazon"]
-
-  filter {
-    name   = "image-id"
-    values = ["ami-abc123"]
-  }
-}
-
-resource "aws_instance" "example" {
-  instance_type = "t3.micro"
-  ami           = data.aws_ami.example.id
-
-  lifecycle {
-    # The AMI ID must refer to an AMI that contains an operating system
-    # for the `x86_64` architecture.
-    precondition {
-      condition     = data.aws_ami.example.architecture == "x86_64"
-      error_message = "The selected AMI must be for the x86_64 architecture."
-    }
-
-    # The EC2 instance must be allocated a public DNS hostname.
-    postcondition {
-      condition     = self.public_dns != ""
-      error_message = "EC2 instance must be in a VPC that has public DNS hostnames enabled."
-    }
-  }
-}
-
-data "aws_ebs_volume" "example" {
-  # Use data resources that refer to other resources to
-  # load extra data that isn't directly exported by a resource.
-  #
-  # Read the details about the root storage volume for the EC2 instance
-  # declared by aws_instance.example, using the exported ID.
-
-  filter {
-    name = "volume-id"
-    values = [aws_instance.example.root_block_device[0].volume_id]
-  }
-
-  # Whenever a data resource is verifying the result of a managed resource
-  # declared in the same configuration, you MUST write the checks as
-  # postconditions of the data resource. This ensures Terraform will wait
-  # to read the data resource until after any changes to the managed resource
-  # have completed.
-  lifecycle {
-    # The EC2 instance will have an encrypted root volume.
-    postcondition {
-      condition     = self.encrypted
-      error_message = "The server's root volume is not encrypted."
-    }
-  }
-}
-
-output "api_base_url" {
-  value = "https://${aws_instance.example.private_dns}:8433/"
-}
-```
-
-### Choosing Between Preconditions and Postconditions
-
-You can often implement a validation check as either a postcondition of the resource producing the data or as a precondition of a resource or output value using the data. To decide which is most appropriate, consider whether the check is representing either an assumption or a guarantee.
-
-#### Use Preconditions for Assumptions
-
-An assumption is a condition that must be true in order for the configuration of a particular resource to be usable. For example, an `aws_instance` configuration can have the assumption that the given AMI will always be configured for the `x86_64` CPU architecture.
-
-We recommend using preconditions for assumptions, so that future maintainers can find them close to the other expressions that rely on that condition. This lets them understand more about what that resource is intended to allow.
-
-#### Use Postconditions for Guarantees
-
-A guarantee is a characteristic or behavior of an object that the rest of the configuration should be able to rely on. For example, an `aws_instance` configuration can have the guarantee that an EC2 instance will be running in a network that assigns it a private DNS record.
-
-We recommend using postconditions for guarantees, so that future maintainers can find them close to the resource configuration that is responsible for implementing those guarantees. This lets them more easily determine which behaviors they should preserve when changing the configuration.
-
-#### Additional Decision Factors
-
-You should also consider the following questions when creating preconditions and postconditions.
-
-- Which resource or output value would be most helpful to report in the error message? Terraform will always report errors in the location where the condition was declared.
-- Which approach is more convenient? If a particular resource has many dependencies that all make an assumption about that resource, it can be pragmatic to declare that once as a post-condition of the resource, rather than declaring it many times as preconditions on each of the dependencies.
-- Is it helpful to declare the same or similar conditions as both preconditions and postconditions? This can be useful if the postcondition is in a different module than the precondition because it lets the modules verify one another as they evolve independently.
-
-## Checks with Assertions
-
--> **Note:** Check blocks and their assertions are only available in Terraform v1.5.0 and later.
-
-[Check blocks](/terraform/language/checks) can validate your infrastructure outside the usual resource lifecycle. You can add custom conditions via `assert` blocks, which execute at the end of the plan and apply stages and produce warnings to notify you of problems within your infrastructure.
-
-You can add one or more `assert` blocks within a `check` block to verify custom conditions. Each assertion requires a [`condition` argument](#condition-expressions), a boolean expression that should return `true` if the intended assumption or guarantee is fulfilled or `false` if it does not. Your `condition` expression can refer to any resource, data source, or variable available to the surrounding `check` block.
-
-The following example uses a check block with an assertion to verify the Terraform website is healthy.
-
-```hcl
-check "health_check" {
-  data "http" "terraform_io" {
-    url = "https://www.terraform.io"
-  }
-
-  assert {
-    condition = data.http.terraform_io.status_code == 200
-    error_message = "${data.http.terraform_io.url} returned an unhealthy status code"
-  }
-}
-```
-
-If the condition evaluates to `false`, Terraform produces an [error message](#error-messages) that includes the result of the `error_message` expression. If you declare multiple assertions, Terraform returns error messages for all failed conditions.
-
-### Continuous Validation in HCP Terraform
-
-HCP Terraform can automatically check whether the checks in a workspace’s configuration continue to pass after Terraform provisions the infrastructure. For example, you can write a `check` to continuously monitor the validity of an API gateway certificate. Continuous validation alerts you when the condition fails, so you can update the certificate and avoid errors the next time you want to update your infrastructure. Refer to [Continuous Validation](/terraform/cloud-docs/workspaces/health#continuous-validation) in the HCP Terraform documentation for details.
-
-## Condition Expressions
-
-Check assertions, input variable validation, preconditions, and postconditions all require a `condition` argument. This is a boolean expression that should return `true` if the intended assumption or guarantee is fulfilled or `false` if it does not.
-
-You can use any of Terraform's built-in functions or language operators
-in a condition as long as the expression is valid and returns a boolean result. The following language features are particularly useful when writing condition expressions.
-
-### Logical Operators
-
-Use the logical operators `&&` (AND), `||` (OR), and `!` (NOT) to combine multiple conditions together.
-
-```hcl
-  condition = var.name != "" && lower(var.name) == var.name
-```
-
-You can also use arithmetic operators (e.g. `a + b`), equality operators (eg., `a == b`) and comparison operators (e.g., `a < b`). Refer to [Arithmetic and Logical Operators](/terraform/language/expressions/operators) for details.
-
-### `contains` Function
-
-Use the [`contains` function](/terraform/language/functions/contains) to test whether a given value is one of a set of predefined valid values.
-
-```hcl
-  condition = contains(["STAGE", "PROD"], var.environment)
-```
-
-### `length` Function
-
-Use the [`length` function](/terraform/language/functions/length) to test a collection's length and require a non-empty list or map.
-
-```hcl
-  condition = length(var.items) != 0
-```
-This is a better approach than directly comparing with another collection using `==` or `!=`. This is because the comparison operators can only return `true` if both operands have exactly the same type, which is often ambiguous for empty collections.
-
-### `for` Expressions
-
-Use [`for` expressions](/terraform/language/expressions/for) in conjunction with the functions `alltrue` and `anytrue` to test whether a condition holds for all or for any elements of a collection.
-
-```hcl
-  condition = alltrue([
-    for v in var.instances : contains(["t2.micro", "m3.medium"], v.type)
-  ])
-```
-
-### `can` Function
-
-Use the [`can` function](/terraform/language/functions/can) to concisely use the validity of an expression as a condition. It returns `true` if its given expression evaluates successfully and `false` if it returns any error, so you can use various other functions that typically return errors as a part of your condition expressions.
-
-For example, you can use `can` with `regex` to test if a string matches a particular pattern because `regex` returns an error when given a non-matching string.
-
-```hcl
-  condition = can(regex("^[a-z]+$", var.name))
-```
-
-You can also use `can` with the type conversion functions to test whether a value is convertible to a type or type constraint.
-
-```hcl
-  # This remote output value must have a value that can
-  # be used as a string, which includes strings themselves
-  # but also allows numbers and boolean values.
-  condition = can(tostring(data.terraform_remote_state.example.outputs["name"]))
-```
-
-```hcl
-  # This remote output value must be convertible to a list
-  # type of with element type.
-  condition = can(tolist(data.terraform_remote_state.example.outputs["items"]))
-```
-
-You can also use `can` with attribute access or index operators to test whether a collection or structural value has a particular element or index.
-
-```hcl
-  # var.example must have an attribute named "foo"
-  condition = can(var.example.foo)
-```
-
-```hcl
-  # var.example must be a sequence with at least one element
-  condition = can(var.example[0])
-  # (although it would typically be clearer to write this as a
-  # test like length(var.example) > 0 to better represent the
-  # intent of the condition.)
-```
-
-### `self` Object
-
-Use the `self` object in postcondition blocks to refer to attributes of the instance under evaluation.
-
-```hcl
-resource "aws_instance" "example" {
-  instance_type = "t2.micro"
-  ami           = "ami-abc123"
-
-  lifecycle {
-    postcondition {
-      condition     = self.instance_state == "running"
-      error_message = "EC2 instance must be running."
-    }
-  }
-}
-```
-
-### `each` and `count` Objects
-
-In blocks where [`for_each`](/terraform/language/meta-arguments/for_each) or [`count`](/terraform/language/meta-arguments/count)  are set, use `each` and `count` objects to refer to other resources that are expanded in a chain.
-
-```hcl
-variable "vpc_cidrs" {
-  type = set(string)
-}
-
-data "aws_vpc" "example" {
-  for_each = var.vpc_cidrs
-
-  filter {
-    name   = "cidr"
-    values = [each.key]
-  }
-}
-
-resource "aws_internet_gateway" "example" {
-  for_each = data.aws_vpc.example
-  vpc_id = each.value.id
-
-  lifecycle {
-    precondition {
-      condition     = data.aws_vpc.example[each.key].state == "available"
-      error_message = "VPC ${each.key} must be available."
-    }
-  }
-}
-```
-
-## Error Messages
-
-Input variable validations, preconditions, and postconditions all must include the `error_message` argument. This contains the text that Terraform will include as part of error messages when it detects an unmet condition.
-
-```
-Error: Resource postcondition failed
-
-  with data.aws_ami.example,
-  on ec2.tf line 19, in data "aws_ami" "example":
-  72:       condition     = self.tags["Component"] == "nomad-server"
-    |----------------
-    | self.tags["Component"] is "consul-server"
-
-The selected AMI must be tagged with the Component value "nomad-server".
-```
-
-The `error_message` argument can be any expression that evaluates to a string.
-This includes literal strings, heredocs, and template expressions. You can use the [`format` function](/terraform/language/functions/format) to convert items of `null`, `list`, or `map` types into a formatted string. Multi-line
-error messages are supported, and lines with leading whitespace will not be
-word wrapped.
-
-We recommend writing error messages as one or more full sentences in a
-style similar to Terraform's own error messages. Terraform will show the
-message alongside the name of the resource that detected the problem and any
-external values included in the condition expression.
-
-## Conditions Checked Only During Apply
-
-Terraform evaluates custom conditions as early as possible.
-
-Input variable validations can only refer to the variable value, so Terraform always evaluates them immediately. Check assertions, preconditions, and postconditions depend on Terraform evaluating whether the value(s) associated with the condition are known before or after applying the configuration.
-
-- **Known before apply:** Terraform checks the condition during the planning phase. For example, Terraform can know the value of an image ID during planning as long as it is not generated from another resource.
-- **Known after apply:** Terraform delays checking that condition until the apply phase. For example, AWS only assigns the root volume ID when it starts an EC2 instance, so Terraform cannot know this value until apply.
-
-During the apply phase, a failed _precondition_
-will prevent Terraform from implementing planned actions for the associated resource. However, a failed _postcondition_ will halt processing after Terraform has already implemented these actions. The failed postcondition prevents any further downstream actions that rely on the resource, but does not undo the actions Terraform has already taken.
-
-Terraform typically has less information during the initial creation of a
-full configuration than when applying subsequent changes. Therefore, Terraform may check conditions during apply for initial creation and then check them during planning for subsequent updates.
-
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 b12f66741..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,8 +52,8 @@ 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)
-or [an output defined](/terraform/language/values/outputs#sensitive-suppressing-values-in-cli-output) as sensitive
+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.
 
 This is a conservative behavior that is true irrespective of the function being
diff --git a/content/terraform/v1.12.x/docs/language/expressions/index.mdx b/content/terraform/v1.12.x/docs/language/expressions/index.mdx
index 12a7cead1..6e2942df3 100644
--- a/content/terraform/v1.12.x/docs/language/expressions/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/expressions/index.mdx
@@ -62,8 +62,8 @@ expression syntax.
   documents a way to create multiple repeatable nested blocks within a resource
   or other construct.
 
-- [Custom Conditions](/terraform/language/expressions/custom-conditions)
-  documents conditions, checks blocks, and resource preconditions and postconditions.
+- [Validate your configuration](/terraform/language/test-and-validate/validate)
+  to verify variable conditions, check blocks, and resource preconditions and postconditions.
 
 - [Type Constraints](/terraform/language/expressions/type-constraints)
   documents the syntax for referring to a type, rather than a value of that
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 f3febc16e..0e1a7d3c3 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
@@ -79,7 +79,7 @@ constraint all of the attributes you intend to use elsewhere in your module.
 
 ### Local Values
 
-`local.<NAME>` is the value of the [local value](/terraform/language/values/locals) of the given name.
+`local.<NAME>` is the value of the [local value](/terraform/language/block/locals) of the given name.
 
 Local values can refer to other local values, even within the same `locals`
 block, as long as you don't introduce circular dependencies.
@@ -92,7 +92,7 @@ block, as long as you don't introduce circular dependencies.
 If the corresponding `module` block does not have either `count` nor `for_each`
 set then the value will be an object with one attribute for each output value
 defined in the child module. To access one of the module's
-[output values](/terraform/language/values/outputs), use `module.<MODULE NAME>.<OUTPUT NAME>`.
+[output values](/terraform/language/block/output), use `module.<MODULE NAME>.<OUTPUT NAME>`.
 
 If the corresponding `module` uses `for_each` then the value will be a map
 of objects whose keys correspond with the keys in the `for_each` expression,
@@ -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,15 +295,16 @@ 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/values/outputs) then Terraform will require
+[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.
 
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 7e2092e63..4a000cef4 100644
--- a/content/terraform/v1.12.x/docs/language/functions/ephemeralasnull.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/ephemeralasnull.mdx
@@ -1,14 +1,14 @@
 ---
-page_title: ephemeralasnull function reference - Functions - Configuration Language  
-description: |-  
-  The `ephemeralasnull` function accepts an ephemeral value and returns null.  
+page_title: ephemeralasnull function reference - Functions - Configuration Language
+description: |-
+  The `ephemeralasnull` function accepts an ephemeral value and returns null.
 ---
 
 # `ephemeralasnull` function reference
 
 -> **Note**: The `ephemeralasnull` function is available in Terraform v1.10 and later.
 
-This topic provides reference information about the `ephemeralasnull` function. The `ephemeralasnull` function accepts an ephemeral value and returns `null`. 
+This topic provides reference information about the `ephemeralasnull` function. The `ephemeralasnull` function accepts an ephemeral value and returns `null`.
 
 ## Introduction
 
@@ -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/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files), 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
 
@@ -57,7 +57,7 @@ variable "configuration" {
   }
 }
 
-# This is a contrived example, but this pattern works with any object that is a mix of ephemeral and non-ephemeral values. 
+# This is a contrived example, but this pattern works with any object that is a mix of ephemeral and non-ephemeral values.
 locals {
   configuration_with_token = merge(
     var.configuration,
@@ -82,4 +82,4 @@ configuration_settings = {
   "env" = "development"
   "session_token" = tostring(null)
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.12.x/docs/language/functions/format.mdx b/content/terraform/v1.12.x/docs/language/functions/format.mdx
index 0bf30208d..70d40b706 100644
--- a/content/terraform/v1.12.x/docs/language/functions/format.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/format.mdx
@@ -41,7 +41,7 @@ We can specify an argument position number
 "/path/file.tf"
 ```
 
-The formatting verb `%#v` accepts a value of any type and presents it using JSON encoding, similar to jsonencode. This can be useful for describing the values given to a module in [custom condition check](/terraform/language/expressions/custom-conditions#error-messages) error messages.
+The formatting verb `%#v` accepts a value of any type and presents it using JSON encoding. This can be useful for describing the values given to a module in error messages while [validating your configuration](/terraform/language/test-and-validate/validate#error-messages).
 
 ```
 > format("%#v", "hello")
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/plantimestamp.mdx b/content/terraform/v1.12.x/docs/language/functions/plantimestamp.mdx
index 7b3a41e0d..c76e9c399 100644
--- a/content/terraform/v1.12.x/docs/language/functions/plantimestamp.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/plantimestamp.mdx
@@ -16,9 +16,8 @@ strings using [RFC 3339](https://tools.ietf.org/html/rfc3339)
 "Date and Time format" syntax, and so `plantimestamp` returns a string
 in this format.
 
-The result of this function will change for every plan operation. It is intended
-for use within [Custom Conditions](/terraform/language/expressions/custom-conditions)
-as a way to validate time sensitive resources such as TLS certificates.
+The result of this function changes during every plan operation. You can use `plantimestamp` to validate time sensitive resources, such as TLS certificates,
+while [Validating your configuration](/terraform/language/test-and-validate/validate).
 
 There are circumstances, such as during a Terraform [Refresh-only](/terraform/cli/commands/plan#planning-modes) plan, where
 the value for this function will be recomputed but not propagated to resources
@@ -51,4 +50,4 @@ check "terraform_io_certificate" {
 ## Related Functions
 
 * [`timestamp`](/terraform/language/functions/timestamp) returns the current timestamp when it is evaluated
-during the apply step.
\ No newline at end of file
+during the apply step.
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/templatestring.mdx b/content/terraform/v1.12.x/docs/language/functions/templatestring.mdx
index 843325c92..ce9c72024 100644
--- a/content/terraform/v1.12.x/docs/language/functions/templatestring.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/templatestring.mdx
@@ -10,7 +10,7 @@ This topic provides reference information about the `templatestring` function. T
 
 ## Introduction
 
-The primary use case for the `templatestring` function is to render templates fetched as a single string from remote locations. The function enables advanced use cases where a [string template expression](/terraform/language/expressions/strings#string-templates) is insufficient, such as when the template is available from a named object declared in the current module. Refer to [Dynamic template construction](#dynamic-template-construction) for additional information. 
+The primary use case for the `templatestring` function is to render templates fetched as a single string from remote locations. The function enables advanced use cases where a [string template expression](/terraform/language/expressions/strings#string-templates) is insufficient, such as when the template is available from a named object declared in the current module. Refer to [Dynamic template construction](#dynamic-template-construction) for additional information.
 
 To render a template from a file, use the [`templatefile` function](/terraform/language/functions/templatefile).
 
@@ -26,7 +26,7 @@ Specify the following arguments:
 
 - The first argument is always a reference to an object defined in the module. You cannot supply the template expression directly as the first argument.
 - The second argument is an object that specifies a variable to use for rendering the template.
-- You can specify additional arguments to use multiple variables for the template.  
+- You can specify additional arguments to use multiple variables for the template.
 
 In the following example, the function renders the string value located at `data.aws_s3_object.example.body` as the template:
 
@@ -59,7 +59,7 @@ For more examples of how to use templates, refer to the documentation for [the `
 
 ## Dynamic template construction
 
-You can write an expression that builds a template dynamically and then assigns it to a [local value](/terraform/language/values/locals). You can then use a reference to that local value as the first argument to the `templatestring` function.
+You can write an expression that builds a template dynamically and then assigns it to a [local value](/terraform/language/block/locals). You can then use a reference to that local value as the first argument to the `templatestring` function.
 
 Note that you should only dynamically construct templates in this way when no other alternative is feasible. This is because the result can be difficult to understand and maintain and is susceptible to unexpected inputs. Built-in Terraform functions may interact with the local filesystem. As a result, the inputs may produce a template that includes data from arbitrary files on the system where Terraform is running.
 
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 cd26f2247..fc881591c 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,9 +35,9 @@ 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 [local values](/terraform/language/values/locals#ephemeral-values)
+- In [ephemeral variables](/terraform/language/block/variable#ephemeral)
+- In [local values](/terraform/language/block/locals)
 - In [ephemeral resources](/terraform/language/resources/ephemeral)
-- In [ephemeral outputs](/terraform/language/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files)
+- 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/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/functions/timecmp.mdx b/content/terraform/v1.12.x/docs/language/functions/timecmp.mdx
index 2c078a9b4..6311edcfa 100644
--- a/content/terraform/v1.12.x/docs/language/functions/timecmp.mdx
+++ b/content/terraform/v1.12.x/docs/language/functions/timecmp.mdx
@@ -43,12 +43,9 @@ both be strings conforming to this syntax.
 0
 ```
 
-`timecmp` can be particularly useful in defining
-[custom condition checks](/terraform/language/expressions/custom-conditions) that
-involve a specified timestamp being within a particular range. For example,
-the following resource postcondition would raise an error if a TLS certificate
-(or other expiring object) expires sooner than 30 days from the time of
-the "apply" step:
+The `timecmp` function is suitable for validations that verify that a specified timestamp is within a particular range. Refer to [Validating your configuration](/terraform/language/test-and-validate/validate) to learn more about validating your configuration.
+
+For example, the following resource postcondition would raise an error if a TLS certificate (or other expiring object) expires sooner than 30 days from the time of the "apply" step:
 
 ```hcl
   lifecycle {
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 7001fd08f..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,8 +109,8 @@ 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 outputs](/terraform/language/values/outputs#sensitive-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
 to identify the resource instance and will always be disclosed in UI output,
@@ -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/meta-arguments/lifecycle.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/lifecycle.mdx
index b62bb5131..47b056cf6 100644
--- a/content/terraform/v1.12.x/docs/language/meta-arguments/lifecycle.mdx
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/lifecycle.mdx
@@ -50,12 +50,12 @@ The arguments available within a `lifecycle` block are `create_before_destroy`,
   type before using `create_before_destroy` with it.
 
   Note that Terraform propagates and applies the `create_before_destroy` meta-attribute
-  behaviour 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 
+  behaviour 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 by default and stores it to the state file. You cannot override `create_before_destroy`
   to `false` on resource B because that would imply dependency cycles in the graph.
 
   Destroy provisioners of this resource do not run if `create_before_destroy`
-  is set to `true`. 
+  is set to `true`.
 
 * `prevent_destroy` (bool) - This meta-argument, when set to `true`, will
   cause Terraform to reject with an error any plan that would destroy the
@@ -173,7 +173,7 @@ resource "aws_instance" "example" {
 
 Custom conditions can help capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
 
-Refer to [Custom Conditions](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
+Refer to [Validate your configuration](/terraform/language/test-and-validate/validate#preconditions-and-postconditions) for details.
 
 ## Literal Values Only
 
diff --git a/content/terraform/v1.12.x/docs/language/modules/develop/composition.mdx b/content/terraform/v1.12.x/docs/language/modules/develop/composition.mdx
index d50679f41..3b7530380 100644
--- a/content/terraform/v1.12.x/docs/language/modules/develop/composition.mdx
+++ b/content/terraform/v1.12.x/docs/language/modules/develop/composition.mdx
@@ -193,7 +193,7 @@ Every module has implicit assumptions and guarantees that define what data it ex
 - **Assumption:** A condition that must be true in order for the configuration of a particular resource to be usable. For example, an `aws_instance` configuration can have the assumption that the given AMI will always be configured for the `x86_64` CPU architecture.
 - **Guarantee:** A characteristic or behavior of an object that the rest of the configuration should be able to rely on. For example, an `aws_instance` configuration can have the guarantee that an EC2 instance will be running in a network that assigns it a private DNS record.
 
-We recommend using [custom conditions](/terraform/language/expressions/custom-conditions) to help capture and test for assumptions and guarantees. This helps future maintainers understand the configuration design and intent. Custom conditions also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
+We recommend [validating your configuration](/terraform/language/test-and-validate/validate) to help capture and test for assumptions and guarantees. This helps future maintainers understand the configuration design and intent. Configuration validation returns useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
 
 The following examples creates a precondition that checks whether the EC2 instance has an encrypted root volume.
 
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 aee54ee9e..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,9 +30,9 @@ 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/values/outputs) to return results to the
+* [Output values](/terraform/language/block/output) to return results to the
   calling module, which it can then use to populate arguments elsewhere.
 * [Resources](/terraform/language/resources) to define one or more
   infrastructure objects that the module will manage.
diff --git a/content/terraform/v1.12.x/docs/language/modules/develop/refactoring.mdx b/content/terraform/v1.12.x/docs/language/modules/develop/refactoring.mdx
index 1344b0d79..bfdd34844 100644
--- a/content/terraform/v1.12.x/docs/language/modules/develop/refactoring.mdx
+++ b/content/terraform/v1.12.x/docs/language/modules/develop/refactoring.mdx
@@ -1,33 +1,41 @@
 ---
-page_title: Refactoring
+page_title: Refactor modules
 description: How to make backward-compatible changes to modules already in use.
 ---
 
-# Refactoring
+# Refactor modules
 
--> **Note:** Explicit refactoring declarations with `moved` blocks is available in Terraform v1.1 and later. For earlier Terraform versions or for refactoring actions too complex to express as `moved` blocks, you can
-use the [`terraform state mv` CLI command](/terraform/cli/commands/state/mv)
-as a separate step.
+By default, Terraform interprets a change as an instruction to destroy the existing resource and create a new resource at the new address. You can use a `moved` block to update a resource address without destroying it. 
 
-In shared modules and long-lived configurations, you may eventually outgrow
-your initial module structure and resource names. For example, you might decide
-that what was previously one child module makes more sense as two separate
-modules and move a subset of the existing resources to the new one.
 
-Terraform compares previous state with new configuration, correlating by
-each module or resource's unique address. Therefore _by default_ Terraform
-understands moving or renaming an object as an intent to destroy the object
-at the old address and to create a new object at the new address.
+> **Hands On:** Try the [Use Configuration to Move Resources](/terraform/tutorials/configuration-language/move-config) tutorial.
 
-When you add `moved` blocks in your configuration to record where you've
-historically moved or renamed an object, Terraform treats an existing object at
-the old address as if it now belongs to the new address.
+## Overview
 
-> **Hands On:** Try the [Use Configuration to Move Resources](/terraform/tutorials/configuration-language/move-config) tutorial.
+Add a `moved` block to your configuration to move or rename an object. Before creating a new plan for the resource specified in the `to` argument, Terraform checks the state for an existing resource at the `from` address. Terraform includes the update to the resource address in the next execution plan. The address change does not destroy the resource.
+
+You can use `moved` blocks for the following use cases:
+
+- [Move a resource or module](#move-a-resource-or-module)
+- [Rename a resource](#rename-a-resource)
+- [Create multiple instances](#create-multiple-instances`)
+- [Rename a module call](#rename-a-module-call)
+- [Split a module](#split-a-module)
+
+When the module or resource is no longer necessary, you can [remove `moved` blocks](#remove-a-move-block) from the configuration. Note that removing a `moved` block is a breaking change.
 
-## `moved` Block Syntax
+## Requirements
 
-A `moved` block expects no labels and contains only `from` and `to` arguments:
+Terraform v1.1 and later is required to use `moved` blocks to explicitly refactor module addresses. Instead, use the [`terraform state mv` CLI command](/terraform/cli/commands/state/mv).
+
+## Move a resource or module
+
+Add a [`moved` block](/terraform/language/block/moved) to your configuration and specify the following arguments:
+
+- `from`: The previous address of the module or resource.
+- `to`: The new address of the module or resource.
+
+In the following example, the resource named `aws_instance.a` has been moved to `aws_instance.b`:
 
 ```hcl
 moved {
@@ -36,9 +44,6 @@ moved {
 }
 ```
 
-The example above records that the resource currently known as `aws_instance.b`
-was known as `aws_instance.a` in a previous version of this module.
-
 Before creating a new plan for `aws_instance.b`, Terraform first checks
 whether there is an existing object for `aws_instance.a` recorded in the state.
 If there is an existing object, Terraform renames that object to
@@ -47,18 +52,9 @@ as if the object had originally been created at `aws_instance.b`, avoiding any
 need to destroy it during apply.
 
 The `from` and `to` addresses both use a special addressing syntax that allows
-selecting modules, resources, and resources inside child modules. Below, we
-describe several refactoring use-cases and the appropriate addressing syntax
-for each situation.
+selecting modules, resources, and resources inside child modules.
 
-* [Renaming a Resource](#renaming-a-resource)
-* [Enabling `count` or `for_each` For a Resource](#enabling-count-or-for_each-for-a-resource)
-* [Renaming a Module Call](#renaming-a-module-call)
-* [Enabling `count` or `for_each` For a Module Call](#enabling-count-or-for_each-for-a-module-call)
-* [Splitting One Module into Multiple](#splitting-one-module-into-multiple)
-* [Removing `moved` blocks](#removing-moved-blocks)
-
-## Renaming a Resource
+## Rename a resource
 
 Consider this example module with a resource configuration:
 
@@ -111,9 +107,13 @@ on which resources can move between types. You _cannot_ use the `moved`
 block to change a managed resource (a `resource` block) into a data 
 resource (a `data` block).
 
-## Enabling `count` or `for_each` For a Resource
+## Create multiple instances
+
+You can use a `moved` block when creating mulitple instances of a resource or module call while preserving the original instance.
+
+### Enable `count` or `for_each` for a resource
 
-Consider this example module containing a single-instance resource:
+The following example module contains a single-instance resource bound to the address `aws_instance.a`:
 
 ```hcl
 resource "aws_instance" "a" {
@@ -121,14 +121,15 @@ resource "aws_instance" "a" {
 }
 ```
 
-Applying this configuration would lead to Terraform creating an object
-bound to the address `aws_instance.a`.
-
 Later, you use [`for_each`](/terraform/language/meta-arguments/for_each) with this
 resource to systematically declare multiple instances. To preserve an object
-that was previously associated with `aws_instance.a` alone, you must add a
+that was previously associated with `aws_instance.a`, you must add a
 `moved` block to specify which instance key the object will take in the new
-configuration:
+configuration. 
+
+In the following example, Terraform does not plan to destroy any existing object at
+`aws_instance.a`. Instead, Terraform treats that object as if it were originally
+created as `aws_instance.a["small"]`:
 
 ```hcl
 locals {
@@ -155,17 +156,14 @@ moved {
 }
 ```
 
-The above will keep Terraform from planning to destroy any existing object at
-`aws_instance.a`, treating that object instead as if it were originally
-created as `aws_instance.a["small"]`.
 
-When at least one of the two addresses includes an instance key, like
-`["small"]` in the above example, Terraform understands both addresses as
-referring to specific _instances_ of a resource rather than the resource as a
+When at least one of the two addresses includes an instance key, such as
+`["small"]` in the previous example, Terraform understands both addresses as
+referring to specific instances of a resource rather than the resource as a
 whole. That means you can use `moved` to switch between keys and to add and
 remove keys as you switch between `count`, `for_each`, or neither.
 
-The following are some other examples of valid `moved` blocks that record
+The following examples are also valid `moved` blocks that record
 changes to resource instance keys in a similar way:
 
 ```hcl
@@ -197,16 +195,17 @@ moved {
 }
 ```
 
--> **Note:** When you add `count` to an existing resource that didn't use it,
-Terraform automatically proposes to move the original object to instance zero,
-unless you write an `moved` block explicitly mentioning that resource.
-However, we recommend still writing out the corresponding `moved` block
-explicitly, to make the change clearer to future readers of the module.
+When you add `count` to an existing resource that didn't previously have the argument,
+Terraform automatically proposes moving the original object to instance `0`
+unless you write a `moved` block that explicitly mentions that resource.
+However, we recommend writing out the corresponding `moved` block
+explicitly to make the change clearer to future readers of the module.
 
-## Renaming a Module Call
+### Enable `count` or `for_each` for a module call
+
+The following example is a single-instance module that creates objects whose
+addresses begin with `module.a`:
 
-You can rename a call to a module in a similar way as renaming a resource.
-Consider the following original module version:
 
 ```hcl
 module "a" {
@@ -216,40 +215,40 @@ module "a" {
 }
 ```
 
-When applying this configuration, Terraform would prefix the addresses for
-any resources declared in this module with the module path `module.a`.
-For example, a resource `aws_instance.example` would have the full address
-`module.a.aws_instance.example`.
+In later module versions, you may need to use
+[`count`](/terraform/language/meta-arguments/count) with this resource to systematically
+declare multiple instances. To preserve an object that was previously associated
+with `aws_instance.a` alone, you can add a `moved` block to specify which
+instance key that object will take in the new configuration.
 
-If you later choose a better name for this module call, then you can change the
-name label in the `module` block and record the old name inside a `moved` block:
+The following configuration above directs Terraform to treat all objects in `module.a` as
+if they were originally created in `module.a[2]`. As a result, Terraform plans
+to create new objects only for `module.a[0]` and `module.a[1]`:
 
 ```hcl
-module "b" {
+module "a" {
   source = "../modules/example"
+  count  = 3
 
   # (module arguments)
 }
 
 moved {
   from = module.a
-  to   = module.b
+  to   = module.a[2]
 }
 ```
 
-When creating the next plan for each configuration using this module, Terraform
-will treat any existing object addresses beginning with `module.a` as if
-they had instead been created in `module.b`. `module.a.aws_instance.example`
-would be treated as `module.b.aws_instance.example`.
-
-Both of the addresses in this example referred to a module call as a whole, and
-so Terraform recognizes the move for all instances of the call. If this
-module call used `count` or `for_each` then it would apply to all of the
-instances, without the need to specify each one separately.
+When at least one of the two addresses includes an instance key, such as
+`[2]` in the previous example, Terraform understands both addresses as
+referring to specific instances of a module call rather than the module
+call as a whole. That means you can use `moved` to switch between keys and to
+add and remove keys as you switch between `count`, `for_each`, or neither.
 
-## Enabling `count` or `for_each` For a Module Call
+## Rename a module call
 
-Consider this example of a single-instance module:
+You can rename a call to a module in a similar way as renaming a resource.
+Consider the following original module version:
 
 ```hcl
 module "a" {
@@ -259,44 +258,40 @@ module "a" {
 }
 ```
 
-Applying this configuration would cause Terraform to create objects whose
-addresses begin with `module.a`.
+When applying this configuration, Terraform would prefix the addresses for
+any resources declared in this module with the module path `module.a`.
+For example, a resource `aws_instance.example` would have the full address
+`module.a.aws_instance.example`.
 
-In later module versions, you may need to use
-[`count`](/terraform/language/meta-arguments/count) with this resource to systematically
-declare multiple instances. To preserve an object that was previously associated
-with `aws_instance.a` alone, you can add a `moved` block to specify which
-instance key that object will take in the new configuration:
+If you later choose a better name for this module call, then you can change the
+name label in the `module` block and record the old name inside a `moved` block:
 
 ```hcl
-module "a" {
+module "b" {
   source = "../modules/example"
-  count  = 3
 
   # (module arguments)
 }
 
 moved {
   from = module.a
-  to   = module.a[2]
+  to   = module.b
 }
 ```
 
-The configuration above directs Terraform to treat all objects in `module.a` as
-if they were originally created in `module.a[2]`. As a result, Terraform plans
-to create new objects only for `module.a[0]` and `module.a[1]`.
+When creating the next plan for each configuration using this module, Terraform
+will treat any existing object addresses beginning with `module.a` as if
+they had instead been created in `module.b`. `module.a.aws_instance.example`
+would be treated as `module.b.aws_instance.example`.
+
+Both of the addresses in this example referred to a module call as a whole, and
+so Terraform recognizes the move for all instances of the call. If this
+module call used `count` or `for_each` then it would apply to all of the
+instances, without the need to specify each one separately.
 
-When at least one of the two addresses includes an instance key, like
-`[2]` in the above example, Terraform will understand both addresses as
-referring to specific _instances_ of a module call rather than the module
-call as a whole. That means you can use `moved` to switch between keys and to
-add and remove keys as you switch between `count`, `for_each`, or neither.
 
-For more examples of recording moves associated with instances, refer to
-the similar section
-[Enabling `count` and `for_each` For a Resource](#enabling-count-or-for_each-for-a-resource).
 
-# Splitting One Module into Multiple
+## Split a module
 
 As a module grows to support new requirements, it might eventually grow big
 enough to warrant splitting into two separate modules.
@@ -421,16 +416,15 @@ moved {
 }
 ```
 
-## Removing `moved` Blocks
+## Remove a `move` block
 
 Over time, a long-lasting module may accumulate many `moved` blocks.
 
-Removing a `moved` block is a generally breaking change because any configurations that refer to the old address will plan to delete that existing object instead of move it. We strongly recommend that you retain all historical `moved` blocks from earlier versions of your modules to preserve the upgrade path for users of any previous version.
+Removing a `moved` block is a breaking change because any configurations that refer to the old address will plan to delete the existing object instead of move it. We strongly recommend that you retain all historical `moved` blocks from earlier versions of your modules to preserve the upgrade path for users of any previous version.
 
 If you do decide to remove `moved` blocks, proceed with caution. It can be safe to remove `moved` blocks when you are maintaining private modules within an organization and you are certain that all users have successfully run `terraform apply` with your new module version.
 
-If you need to rename or move the same object twice, we recommend documenting the full history
-using _chained_ `moved` blocks, where the new block refers to the existing block:
+If you need to rename or move the same object twice, we recommend chaining `moved` blocks to document the full change history:
 
 ```hcl
 moved {
@@ -445,6 +439,6 @@ moved {
 ```
 
 Recording a sequence of moves in this way allows for successful upgrades for
-both configurations with objects at `aws_instance.a` _and_ configurations with
+both configurations with objects at `aws_instance.a` and configurations with
 objects at `aws_instance.b`. In both cases, Terraform treats the existing
 object as if it had been originally created as `aws_instance.c`.
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 20ba5c945..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,8 +55,8 @@ 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
-  [output configuration](/terraform/language/values/outputs) for more details.
+  [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/`
   subdirectory. Any nested module with a `README.md` is considered usable
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 e23e26ada..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.)
 
@@ -140,7 +140,7 @@ Terraform does not use the `lifecycle` argument. However, the `lifecycle` block
 
 The resources defined in a module are encapsulated, so the calling module
 cannot access their attributes directly. However, the child module can
-declare [output values](/terraform/language/values/outputs) to selectively
+declare [output values](/terraform/language/block/output) to selectively
 export certain values to be accessed by the calling module.
 
 For example, if the `./app-cluster` module referenced in the example above
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 333b58e4c..85c592e67 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
@@ -40,10 +40,10 @@ 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`
+local values](/terraform/language/block/locals), [`ephemeral`
+variables](/terraform/language/block/variable#ephemeral), or [`ephemeral`
 output
-values](/terraform/language/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files).
+values](/terraform/language/block/output#ephemeral).
 
 Terraform will not store these values in your plan or state, or output them in
 logs.
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 cf73194a1..5e33c14b4 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
@@ -97,7 +97,7 @@ remote access credentials to be provided.
 
 ### Provisioning files using cloud-config
 
-You can add the [`cloudinit_config`](https://registry.terraform.io/providers/hashicorp/cloudinit/latest/docs) data source to your Terraform configuration and specify the files you want to provision as `text/cloud-config` content. The `cloudinit_config` data source renders multi-part MIME configurations for use with [cloud-init](https://cloudinit.readthedocs.io/en/latest/). Pass the files in the `content` field as YAML-encoded configurations using the `write_files` block. 
+You can add the [`cloudinit_config`](https://registry.terraform.io/providers/hashicorp/cloudinit/latest/docs) data source to your Terraform configuration and specify the files you want to provision as `text/cloud-config` content. The `cloudinit_config` data source renders multi-part MIME configurations for use with [cloud-init](https://cloudinit.readthedocs.io/en/latest/). Pass the files in the `content` field as YAML-encoded configurations using the `write_files` block.
 
 In the following example, the `my_cloud_config` data source specifies a `text/cloud-config` MIME part named `cloud.conf`. The `part.content` field is set to [`yamlencode`](/terraform/language/functions/yamlencode), which encodes the `write_files` JSON object as YAML so that the system can provision the referenced files.
 
@@ -230,10 +230,10 @@ 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`
+local values](/terraform/language/block/locals), [`ephemeral`
+variables](/terraform/language/block/variable#ephemeral), or [`ephemeral`
 output
-values](/terraform/language/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files).
+values](/terraform/language/block/output#ephemeral).
 
 Terraform does not store these values in your plan or state, or output them in
 logs.
@@ -241,8 +241,8 @@ 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)
-or [`sensitive` output values](/terraform/language/values/outputs#sensitive-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.
 
 ## Creation-Time Provisioners
diff --git a/content/terraform/v1.12.x/docs/language/resources/syntax.mdx b/content/terraform/v1.12.x/docs/language/resources/syntax.mdx
index 9cdf9b141..8fda3efaa 100644
--- a/content/terraform/v1.12.x/docs/language/resources/syntax.mdx
+++ b/content/terraform/v1.12.x/docs/language/resources/syntax.mdx
@@ -20,8 +20,8 @@ For information about how Terraform manages resources after applying a configura
 
 ## Resource Syntax
 
-A `resource` block declares a resource of a specific type 
-with a specific local name. Terraform uses the name when referring to the resource 
+A `resource` block declares a resource of a specific type
+with a specific local name. Terraform uses the name when referring to the resource
 in the same module, but it has no meaning outside that module's scope.
 
 In the following example,  the `aws_instance` resource type is named `web`. The resource type and name must be unique within a module because they serve as an identifier for a given resource.
@@ -35,15 +35,15 @@ resource "aws_instance" "web" {
 
 Within the block body (between `{` and `}`) are the configuration arguments
 for the resource itself. The arguments often depend on the
-resource type. In this example, both `ami` and `instance_type` are special 
+resource type. In this example, both `ami` and `instance_type` are special
 arguments for [the `aws_instance` resource type](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance).
 
 -> **Note:** Resource names must start with a letter or underscore, and may
 contain only letters, digits, underscores, and dashes.
 
-Resource declarations can include more advanced features, such as single 
+Resource declarations can include more advanced features, such as single
 resource declarations that produce multiple similar remote objects, but only
-a small subset is required for initial use. 
+a small subset is required for initial use.
 
 ## Resource Types
 
@@ -53,24 +53,24 @@ attributes the resource supports.
 
 ### Providers
 
-A [provider](/terraform/language/providers/requirements) is a plugin for Terraform 
+A [provider](/terraform/language/providers/requirements) is a plugin for Terraform
 that offers a collection of resource types. Each resource type is implemented by a provider. A
 provider provides resources to manage a single cloud or on-premises
-infrastructure platform. Providers are distributed separately from Terraform, 
+infrastructure platform. Providers are distributed separately from Terraform,
 but Terraform can automatically install most providers when initializing
 a working directory.
 
-To manage resources, a Terraform module must specify the required providers. Refer to 
+To manage resources, a Terraform module must specify the required providers. Refer to
 [Provider Requirements](/terraform/language/providers/requirements) for additional information.
 
-Most providers need some configuration to access their remote API, 
-which is provided by the root module. Refer to 
+Most providers need some configuration to access their remote API,
+which is provided by the root module. Refer to
 [Provider Configuration](/terraform/language/providers/configuration) for additional information.
 
-Based on a resource type's name, Terraform can usually determine which provider to use. 
+Based on a resource type's name, Terraform can usually determine which provider to use.
 By convention, resource type names start with their provider's preferred local name.
-When using multiple configurations of a provider or non-preferred local provider names, 
-you must use [the `provider` meta-argument](/terraform/language/meta-arguments/resource-provider) 
+When using multiple configurations of a provider or non-preferred local provider names,
+you must use [the `provider` meta-argument](/terraform/language/meta-arguments/resource-provider)
 to manually choose a provider configuration.
 
 ### Resource Arguments
@@ -84,15 +84,15 @@ The values for resource arguments can make full use of
 language features.
 
 [Meta-arguments](#meta-arguments) are defined by Terraform
-and apply across all resource types. 
+and apply across all resource types.
 
 ### Documentation for Resource Types
 
 Every Terraform provider has its own documentation, describing its resource
 types and their arguments.
 
-Some provider documentation is still part of Terraform's core documentation, 
-but the [Terraform Registry](https://registry.terraform.io/browse/providers) 
+Some provider documentation is still part of Terraform's core documentation,
+but the [Terraform Registry](https://registry.terraform.io/browse/providers)
 is the main home for all publicly available provider docs.
 
 When viewing a provider's page on the Terraform
@@ -176,11 +176,7 @@ resource "aws_instance" "example" {
 }
 ```
 
-[Custom condition checks](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) 
-can help capture assumptions so that future maintainers 
-understand the configuration design and intent. They also return useful 
-information about errors earlier and in context, helping consumers to diagnose 
-issues in their configuration.
+You can write preconditions for resources in your configuration to help capture assumptions to help future maintainers understand your configuration design and intent. Validations return useful information about errors with context, helping consumers to diagnose issues in their configuration. Refer to [Validate your configuration](/terraform/language/test-and-validate/validate#preconditions-and-postconditions) for more details.
 
 ## Operation Timeouts
 
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..455daf1cb 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/block/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/design.mdx b/content/terraform/v1.12.x/docs/language/stacks/design.mdx
index 480d05852..d22157bd4 100644
--- a/content/terraform/v1.12.x/docs/language/stacks/design.mdx
+++ b/content/terraform/v1.12.x/docs/language/stacks/design.mdx
@@ -5,16 +5,16 @@ description: Learn how to design a Stack that aligns with your existing infrastr
 
 # Design a Stack
 
-Stacks allow you to break down your existing infrastructure into logical components, making it easier to deploy and manage as a cohesive system. Designing a Stack begins with planning how to structure your infrastructure and thinking about how you intend to deploy the resources your Stack defines. 
+Stacks allow you to break down your existing infrastructure into logical components, making it easier to deploy and manage as a cohesive system. Designing a Stack begins with planning how to structure your infrastructure and thinking about how you intend to deploy the resources your Stack defines.
 
 ## Background
 
-Every Stack requires two files: a Stack configuration file and a deployment configuration file. The Stack configuration file defines the infrastructure your Stack will provision when you deploy it. The deployment configuration files are where you define how many times to deploy the infrastructure your Stack defines. 
+Every Stack requires two files: a Stack configuration file and a deployment configuration file. The Stack configuration file defines the infrastructure your Stack will provision when you deploy it. The deployment configuration files are where you define how many times to deploy the infrastructure your Stack defines.
 
 Before writing your Stack configuration, we recommend planning and designing how you want to use your new Stack:
 
-* Understand your existing infrastructure and break it down into manageable components.  
-* Understand how you want to deploy the infrastructure your Stack defines.  
+* Understand your existing infrastructure and break it down into manageable components.
+* Understand how you want to deploy the infrastructure your Stack defines.
 * Align your Stack’s component organization with your deployment strategy.
 
 You aim to create a flexible and reusable Stack configuration, enabling you to manage your infrastructure lifecycle efficiently.
@@ -25,13 +25,13 @@ Before writing your Stack configuration, we recommend assessing your current inf
 
 ### Break down your infrastructure
 
-Each Stack should represent a single system or application with a shared lifecycle. Start by analyzing your current infrastructure and identifying the components HCP Terraform should manage together. Components are typically groups of related resources, such as an application’s backend, frontend, or database layer, deployed and scaled together. 
+Each Stack should represent a single system or application with a shared lifecycle. Start by analyzing your current infrastructure and identifying the components HCP Terraform should manage together. Components are typically groups of related resources, such as an application’s backend, frontend, or database layer, deployed and scaled together.
 
 We recommend structuring your Stacks along technical boundaries to keep them modular and manageable. For example, you can create a dedicated Stack for shared services, such as networking infrastructure for VPCs, subnets, or routing tables, and separate Stacks for application components that consume those shared services. This separation allows you to manage shared services independently while passing information between Stacks. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
 
 ### Sketch out your configuration
 
-We recommend sticking to technical boundaries when structuring a Stack configuration. A single Stack should represent a single system with a shared lifecycle. 
+We recommend sticking to technical boundaries when structuring a Stack configuration. A single Stack should represent a single system with a shared lifecycle.
 
 While keeping a Stack as self-contained as possible is ideal, there are valid cases where a Stack must consume outputs from another Stack. For example, a shared networking Stack can publish outputs, such as `vpc_id` or subnet IDs, that downstream application Stacks can consume as inputs. This approach ensures modularity and allows you to manage dependencies between Stacks using well-defined interfaces. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
 
@@ -47,7 +47,7 @@ If your deployment process requires automation, such as auto-approving specific
 
 When designing your Stack, consider how it should scale as your infrastructure grows. For example, if you anticipate adding more environments or regions, design your Stack to accommodate these changes.
 
-To keep your Stack configuration concise, you can use the [locals block](/terraform/language/values/locals) to share values across your deployments.
+To keep your Stack configuration concise, you can use the [`locals` block](/terraform/language/block/locals) to share values across your deployments.
 
 ```hcl
 # deployments.tfdeploy.hcl
@@ -63,4 +63,4 @@ Additionally, using meta-arguments like `for_each` in your configuration can hel
 
 ## Next steps
 
-After planning out your Stack, learn how to make your design a reality by [defining a Stack configuration](/terraform/language/stacks/create/config). 
+After planning out your Stack, learn how to make your design a reality by [defining a Stack configuration](/terraform/language/stacks/create/config).
diff --git a/content/terraform/v1.12.x/docs/language/stacks/reference/tfdeploy.mdx b/content/terraform/v1.12.x/docs/language/stacks/reference/tfdeploy.mdx
index dd899b9c4..c667475be 100644
--- a/content/terraform/v1.12.x/docs/language/stacks/reference/tfdeploy.mdx
+++ b/content/terraform/v1.12.x/docs/language/stacks/reference/tfdeploy.mdx
@@ -318,7 +318,7 @@ You cannot access an entire store and must specifically access individual keys w
 
 ## `locals` block configuration
 
-A local value assigns a name to an expression, so you can use the name multiple times within your Stack configuration instead of repeating the expression. The `locals` block works exactly as it does in traditional Terraform configurations. Learn more about [the `locals` block](/terraform/language/values/locals).
+A local value assigns a name to an expression, so you can use the name multiple times within your Stack configuration instead of repeating the expression. The `locals` block works exactly as it does in traditional Terraform configurations. Learn more about [the `locals` block](/terraform/language/block/locals).
 
 ## `publish_output` block configuration
 
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 d77683412..f61fa82aa 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
@@ -5,7 +5,7 @@ description: Stacks help you provision and coordinate your infrastructure lifecy
 
 # Stack configuration file reference
 
-A Stack configuration file defines all the infrastructure pieces included in a Stack. Every Stack needs a configuration file, `tfstack.hcl`, and this page describes all the blocks you can use within a Stack configuration file. 
+A Stack configuration file defines all the infrastructure pieces included in a Stack. Every Stack needs a configuration file, `tfstack.hcl`, and this page describes all the blocks you can use within a Stack configuration file.
 
 ## `component` block configuration
 
@@ -66,11 +66,11 @@ component "s3" {
 
 To learn more about breaking down your infrastructure into components, refer to [Define Stack configuration](/terraform/language/stacks/create/config).
 
-## `variable` block configuration 
+## `variable` block configuration
 
 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,13 +96,13 @@ 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
 
-Use the `output` block to make information about your infrastructure available in the HCP Terraform UI to expose information about your Stack. The `output` block functions the same way in Stack configuration as it does in traditional Terraform configurations with a few small differences. 
+Use the `output` block to make information about your infrastructure available in the HCP Terraform UI to expose information about your Stack. The `output` block functions the same way in Stack configuration as it does in traditional Terraform configurations with a few small differences.
 
-In Stack configurations, `output` blocks require the `type` argument, and they do not support the `preconditions` block. Learn more about [Outputs](/terraform/language/values/outputs).
+In Stack configurations, `output` blocks require the `type` argument, and they do not support the `preconditions` block. Learn more about [Outputs](/terraform/language/block/output).
 
 ### Complete configuration
 
@@ -131,14 +131,14 @@ This section provides details about the fields you can configure in the `output`
 
 ## `required_providers` and `provider` block configuration
 
-Terraform relies on plugins called providers to interact with cloud providers, SaaS providers, and other APIs. 
+Terraform relies on plugins called providers to interact with cloud providers, SaaS providers, and other APIs.
 
-The `required_providers` block works exactly as it does in traditional Terraform configurations. Learn more about [the `required_providers` block](/terraform/language/providers/requirements). The `provider` block functions mostly the same way in Stack configuration as it does in traditional Terraform configurations, with a few differences. 
+The `required_providers` block works exactly as it does in traditional Terraform configurations. Learn more about [the `required_providers` block](/terraform/language/providers/requirements). The `provider` block functions mostly the same way in Stack configuration as it does in traditional Terraform configurations, with a few differences.
 
 The `provider` block differs in Stack configurations in the following ways:
 
-* Supports the `for_each` [meta-argument](/terraform/language/meta-arguments/for_each)  
-* Defines aliases in the `provider` block header rather than as an argument  
+* Supports the `for_each` [meta-argument](/terraform/language/meta-arguments/for_each)
+* Defines aliases in the `provider` block header rather than as an argument
 * Accepts arguments using a config block
 
 You must also define your providers at the top level of your Stack configuration in a `tfstack.hcl` file. You cannot define providers within the modules your component blocks source.
@@ -194,14 +194,14 @@ For more information on declaring providers in Stacks, refer to [Declare provide
 
 ## `locals` block configuration
 
-A local value assigns a name to an expression, so you can use the name multiple times within your Stack configuration instead of repeating the expression. The `locals` block works exactly as it does in traditional Terraform configurations. Learn more about [the `locals` block](/terraform/language/values/locals).
+A local value assigns a name to an expression, so you can use the name multiple times within your Stack configuration instead of repeating the expression. The `locals` block works exactly as it does in traditional Terraform configurations. Learn more about [the `locals` block](/terraform/language/block/locals).
 
 
 ## `removed` block configuration
 
-Stacks take a systematic approach to removing components. To remove a component from a Stack, you must use the `removed` block to ensure HCP Terraform knows which components to remove and which providers it requires to remove that component. 
+Stacks take a systematic approach to removing components. To remove a component from a Stack, you must use the `removed` block to ensure HCP Terraform knows which components to remove and which providers it requires to remove that component.
 
-Do not remove providers from your stack configuration without first removing the components that require those providers. HCP Terraform requires a component's providers to ensure it can successfully remove that component. 
+Do not remove providers from your stack configuration without first removing the components that require those providers. HCP Terraform requires a component's providers to ensure it can successfully remove that component.
 
 
 ### Complete configuration
diff --git a/content/terraform/v1.12.x/docs/language/state/remote-state-data.mdx b/content/terraform/v1.12.x/docs/language/state/remote-state-data.mdx
index c3c230e6b..dfee255a0 100644
--- a/content/terraform/v1.12.x/docs/language/state/remote-state-data.mdx
+++ b/content/terraform/v1.12.x/docs/language/state/remote-state-data.mdx
@@ -167,8 +167,8 @@ The following arguments are supported:
 In addition to the above, the following attributes are exported:
 
 * (v0.12+) `outputs` - An object containing every root-level
-  [output](/terraform/language/values/outputs) in the remote state.
-* (<= v0.11) `<OUTPUT NAME>` - Each root-level [output](/terraform/language/values/outputs)
+  [output](/terraform/language/block/output) in the remote state.
+* (<= v0.11) `<OUTPUT NAME>` - Each root-level [output](/terraform/language/block/output)
   in the remote state appears as a top level attribute on the data source.
 
 ## Root Outputs Only
diff --git a/content/terraform/v1.12.x/docs/language/state/remote.mdx b/content/terraform/v1.12.x/docs/language/state/remote.mdx
index 73875a2c1..45cc5847f 100644
--- a/content/terraform/v1.12.x/docs/language/state/remote.mdx
+++ b/content/terraform/v1.12.x/docs/language/state/remote.mdx
@@ -24,7 +24,7 @@ HCP Terraform, both of which you can configure in your configuration's root modu
 ## Delegation and Teamwork
 
 Remote state allows you to share
-[output values](/terraform/language/values/outputs) with other configurations.
+[output values](/terraform/language/block/output) with other configurations.
 This allows your infrastructure to be decomposed into smaller components.
 
 Put another way, remote state also allows teams to share infrastructure
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 788654a0d..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/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files), 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..6af7d6edb 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 [`locals` block](/terraform/language/block/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.
 
diff --git a/content/terraform/v1.12.x/docs/language/terraform.mdx b/content/terraform/v1.12.x/docs/language/terraform.mdx
deleted file mode 100644
index 704fb87c0..000000000
--- a/content/terraform/v1.12.x/docs/language/terraform.mdx
+++ /dev/null
@@ -1,430 +0,0 @@
----
-page_title: Terraform block configuration reference
-description: >-
-  The `terraform` block allows you to configure Terraform behavior, including the Terraform version, backend, integration with HCP Terraform, and required providers.
----
-
-# `terraform` block reference
-
-This topic provides reference information about the `terraform` block. The `terraform` block allows you to configure Terraform behavior, including the Terraform version, backend, integration with HCP Terraform, and required providers.
-
-## Configuration model
-
-The `terraform` block supports the following arguments:
-
-- [`terraform`](#terraform)
-  - [`required_version`](#required_version): &nbsp string 
-  - [`required_providers`](#required_providers): &nbsp block
-    - [`<PROVIDER>`](#provider): &nbsp block
-      - [`version`](#provider): &nbsp string
-      - [`source`](#provider): &nbsp string
-  - [`provider_meta "<LABEL>"`](#provider_meta): &nbsp block
-  - [`backend "<BACKEND_TYPE>"`](#backend): &nbsp block | mutually exclusive with `cloud`
-  - [`cloud`](#cloud): &nbsp block | mutually exclusive with `backend`
-    - [`organization`](#organization): &nbsp string | required when connecting to HCP Terraform
-    - [`workspaces`](#workspaces): &nbsp block | required when connecting to HCP Terraform
-      - [`tags`](#workspaces): &nbsp list | mutually exclusive with `name`
-      - [`name`](#workspaces): &nbsp string | mutually exclusive with `tags`
-      - [`project`](#workspaces): &nbsp string
-    - [`hostname`](#hostname): &nbsp string | `app.terraform.io`
-    - [`token`](#token): &nbsp string
-  - [`experiments`](#experiments): &nbsp list
-
-## Complete configuration
-
-The following `terraform` block defines all of the supported built-in arguments you can set:
-
-```hcl
-
-terraform {
-  required_version = "<version>"
-  required_providers {
-    <PROVIDER> {
-      version = "<version-constraint>"
-      source = "<provider-address>"
-    }
-  }
-  provider_meta "<LABEL>" { 
-    # Shown for completeness but only used for specific cases     
-  }
-  backend "<TYPE>" {        
-    # `backend` is mutually exclusive with `cloud` 
-    "<ARGUMENTS>"
-  }
-  cloud {                   
-    # `cloud` is mutually exclusive with `backend` 
-    organization = "<organization-name>"
-    workspaces {
-      tags = [ "<tag>" ]
-      name = "<workspace-name>"
-      project = "<project-name>"
-    }
-    hostname = "app.terraform.io"
-    token - "<TOKEN>"
-  }
-  experiments = [ "<feature-name>" ]
-}
-```
-
-## Specification
-
-The `terraform` block supports the following configuration.
-
-### `terraform` block
-
-Parent block that contains configurations that define Terraform behavior. You can only use constant values in the `terraform` block. Arguments in the `terraform` block cannot refer to named objects, such as resources and input variables. Additionally, you cannot use built-in Terraform language functions in the block.
-
-### `required_version`
-
-Specifies which version of the Terraform CLI is allowed to run the configuration. 
-
-```hcl
-terraform {
-  required_version = "<Terraform version>"
-  # . . .
-}
-```
-
-Refer to [Version constraints](/terraform/language/expressions/version-constraints) for details about the supported syntax for specifying version constraints.
-
-Use Terraform version constraints in a collaborative environment to ensure that everyone is using a specific Terraform version, or using at least a minimum Terraform version that has behavior expected by the configuration.
-
-Terraform prints an error and exits without taking actions when you use a version of Terraform that does not meet the version constraints to run the configuration.
-
-Modules associated with a configuration may also specify version constraints. You must use a Terraform version that satisfies all version constraints associated with the configuration, including constraints defined in modules, to perform operations. Refer to [Modules](/terraform/language/modules) for additional information about Terraform modules.
-
-The `required_version` configuration applies only to the version of Terraform CLI and not versions of provider plugins. Refer to [Provider Requirements](/terraform/language/providers/requirements) for additional information.
-
-#### Summary
-
-- Data type: String.
-- Default: None.
-- Example:[Add a provider](#add-a-provider)
-
-### `required_providers`
-
-Specifies all provider plugins required to create and manage resources specified in the configuration. 
-
-```hcl
-terraform {
-  required_providers {
-    <PROVIDER> {}
-  }
-  # . . .
-}
-```
-
-Each local provider name maps to a source address and a version constraint. Refer to each Terraform provider’s documentation in the [public Terraform Registry](https://registry.terraform.io/browse/providers), or your private registry, for instructions on how to configure attributes in the `required_providers` block.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example:[Add a provider](#add-a-provider)
-
-### Provider-specific settings
-
-Specifies the name of the provider you want to require. Refer to [Provide Configuration](/terraform/language/providers/configuration) for instructions on how to configure providers.
-
-```hcl
-terraform {
-  required_providers {
-    <PROVIDER> {
-      version = "<version-constraint>"
-      source = "<address>"      
-    }
-  }
-  # . . .
-}
-```
-
-You can specify the following arguments:
-
-| Argument | Description | Data type | Default |
-| --- | --- | --- | --- |
-| `version` | Specifies the version of the provider that this configuration must use. You can use operators to constrain version to specify a range of versions. Refer to [Version constraints](/terraform/language/expressions/version-constraints) for additional information. | String | Terraform installs the newest version by default. |
-| `source` | Specifies the global source address for the provider. Refer to [Requiring Providers](/terraform/language/providers/requirements) for additional information. | String | None |
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example:[Add a provider](#add-a-provider)
-
-
-### `provider_meta "<LABEL>"`
-
-Specifies metadata fields that a provider may expect. 
-
-```hcl
-terraform {
-  provider_meta {
-    <DATA>
-  }
-  # . . .
-}
-```
-
-Individual modules can populate the metadata fields independently of any provider configuration. Refer to [Provider Metadata](/terraform/internals/provider-meta) for additional information.
-
-#### Summary 
-
-- Data type: Block.
-- Default: None.
-
-### `backend "<BACKEND_TYPE>"`
-
-Specifies a mechanism for storing Terraform state files. 
-
-```hcl
-terraform {
-  backend "<TYPE>" {
-    <backend-configuration>
-  }
-  # . . .
-}
-```
-
-
-The `backend` block takes a backend type as an argument. Refer to [Backend Configuration](/terraform/language/backend) for details about configuring the `backend` block.
-
-You cannot configure a `backend` block when the configuration also contains a [`cloud` configuration](#terraform-cloud) for storing state data.
-
-#### Summary
-
-- Data type: Block.
-- Default: [`local`](/terraform/language/backend/local)
-
-### `cloud`
-
-Specifies a set of attributes that allow the Terraform configuration to connect to either HCP Terraform or a Terraform Enterprise installation. 
-
-```hcl
-terraform {
-  cloud  {
-    <cloud-configuration>
-  }
-  # . . .
-}
-```
-
-HCP Terraform and Terraform Enterprise provide state storage, remote execution, and other benefits. Refer to the [HCP Terraform](/terraform/cloud-docs) and [Terraform Enterprise](/terraform/enterprise) documentation for additional information.
-
-You can only provide one `cloud` block per configuration.
-
-You cannot configure a `cloud` block when the configuration also contains a [`backend` configuration](#terraform-backend) for storing state data.
-
-The `cloud` block cannot refer to named values, such as input variables, locals, or data source attributes.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Connect to HCP Terraform](#connect-to-hcp-terraform)
-
-### `organization`
-
-Specifies the name of the organization you want to connect to. 
-
-```hcl
-terraform {
-  cloud  {
-    organization = "<organization-name>"
-  }
-  # . . .
-}
-```
-
-Instead of hardcoding the organization as a string, you can alternatively use the [`TF_CLOUD_ORGANIZATION`](#tf_cloud_organization) environment variable.
-
-#### Summary
-
-- Data type: String
-- Required when connecting to HCP Terraform
-- Example: [Connect to HCP Terraform](#connect-to-hcp-terraform)
-
-### `workspaces`
-
-Specifies metadata for matching workspaces in HCP Terraform. 
-
-
-```hcl
-terraform {
-  cloud  {
-    workspaces {
-      tags = [ "<workspace-tag>" ] # Mutually exclusive with `name`
-      name = "<workspace-name>" # Mutually exclusive with `tags`
-      project = "<project-name>"
-    }            
-  }
-  # . . .
-}
-```
-
-Terraform associates the configuration with workspaces managed in HCP Terraform that match the specified tags, name, or project. You can specify the following metadata in the `workspaces` block:
-
-| Attribute | Description | Data type |
-| --- | --- | --- |
-| `tags` | Specifies either a map of strings as key-value tags or a list of single-value, key-only tags. Terraform associates the configuration with workspaces that match all tags. New workspaces created from the working directory inherit the tags. You cannot set this attribute and the `name` attribute in the same configuration. Using a map type with both keys and values requires Terraform 1.10+. | Array of strings or map of strings |
-| `name` | Specifies an HCP Terraform workspace name to associate the Terraform configuration with. You can only use the working directory with the workspace named in the configuration. You cannot manage the workspace from the Terraform CLI. You cannot set this attribute and the `tags` attribute in the same configuration. <p>Instead of hardcoding a single workspace as a string, you can alternatively use the [`TF_WORKSPACE`](#tf_workspace) environment variable. </p> | String |
-| `project` | Specifies the name of an HCP Terraform project. Terraform creates all workspaces that use this configuration in the project. Using the [`terraform workspace list` command](/terraform/cli/commands/workspace/list) in the working directory returns only workspaces in the specified project. <p>Instead of hardcoding the project as a string, you can alternatively use the [`TF_CLOUD_PROJECT`](#tf_cloud_project) environment variable.</p> | String |
-
-#### Summary
-
-- Data type: Block.
-- Required when connecting to HCP Terraform
-- Example: [Connect to HCP Terraform](#connect-to-hcp-terraform)
-
-### `hostname`
-
-Specifies the hostname for a Terraform Enterprise deployment. 
-
-```hcl
-terraform {
-  cloud  {
-    hostname = "app.terraform.io"
-  }
-  # . . .
-}
-```
-
-Instead of hardcoding the hostname of the Terraform Enterprise deployment, you can alternatively use the [`TF_CLOUD_HOSTNAME`](#tf_cloud_hostname) environment variable.
-
-#### Summary
-
-- Data type: String.
-- Required when connecting to Terraform Enterprise.
-- Default: `app.terraform.io`
-- Example: [Connect to Terraform Enterprise](#connect-to-terraform-enterprise)
-
-### `token`
-
-Specifies a token for authenticating with HCP Terraform. 
-
-```hcl
-terraform {
-  cloud  {
-    token = "<token>"
-  }
-  # . . .
-}
-```
-
-We recommend omitting the token from the configuration and either using the [`terraform login` command](/terraform/cli/commands/login) or manually configuring credentials in the [CLI configuration file](/terraform/cli/config/config-file#credentials) instead.
-
-#### Summary
-
-- Data type: String.
-- Default: None.
-- Example: [Connect to Terraform Enterprise](#connect-to-terraform-enterprise)
-
-
-### `experiments`
-
-Specifies a list of experimental feature names that you want to opt into. 
-
-```hcl
-terraform {
-  experiments = [ "<feature-name>" ]
-  # . . .
-}
-```
-
-In releases where experimental features are available, you can enable them on a per-module basis.
-
-Experiments are subject to arbitrary changes in later releases and, depending on the outcome of the experiment, may change significantly before final release or may not be released in stable form at all. Breaking changes may appear in minor and patch releases. We do not recommend using experimental features in Terraform modules intended for production.
-
-Modules with experiments enabled generate a warning on every `terraform plan` or `terraform apply` operation. If you want to try experimental features in a shared module, we recommend enabling the experiment only in alpha or beta releases of the module.
-
-Refer to the [Terraform changelog](https://github.com/hashicorp/terraform/blob/main/CHANGELOG.md) for information about experiments and to monitor the release notes about experiment keywords that may be available.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-
-## Environment variables for the `cloud` block
-
-You can use environment variables to configure one or more `cloud` block attributes. This is helpful when you want to use the same Terraform configuration in different HCP Terraform organizations and projects. Terraform only uses these variables if you do not define  corresponding attributes in your configuration. If you choose to configure the `cloud` block entirely through environment variables, you must still add an empty `cloud` block in your configuration file.
-
-<Warning>
-
-You can use environment variables to automate Terraform operations, which has specific security considerations. Refer to [Non-Interactive Workflows](/terraform/cloud-docs/run/cli#non-interactive-workflows) for details.
-
-</Warning>
-
-Use the following environment variables to configure the `cloud` block:
-
-- `TF_CLOUD_ORGANIZATION`: Specifies the name of the organization. Terraform reads this variable when `organization` is omitted from the `cloud` block`. If both are specified, the configuration takes precedence.
-
-- `TF_CLOUD_HOSTNAME`: Specifies the hostname of a Terraform Enterprise installation. Terraform reads this when `hostname` is omitted from the `cloud` block. If both are specified, the configuration takes precedence.
-
-- `TF_CLOUD_PROJECT`: Specifies the name of an HCP Terraform project. Terraform reads this when `workspaces.project` is omitted from the `cloud` block. If both are specified, the cloud block configuration takes precedence.
-
-- `TF_WORKSPACE`: Specifies the name of a single HCP Terraform workspace. Terraform reads this when `workspaces` is omitted from the `cloud` block. HCP Terraform does not create a new workspace from this variable. The workspace must already exist in the specified organization. You can set `TF_WORKSPACE` if the `cloud` block uses tags. However, you must include the value of `TF_WORKSPACE` in the set of tags. This variable also selects the workspace in your local environment. Refer to [TF_WORKSPACE](/terraform/cli/config/environment-variables#tf_workspace) for details.
-
-## Examples
-
-The following examples show how to write configuration for common use cases.
-
-### Add a provider
-
-The following configuration requires the `aws` provider version 2.7.0 or later from the public Terraform registry:
-
-```hcl
-terraform {
-  required_providers {
-    aws = {
-      version = ">= 2.7.0"
-      source = "hashicorp/aws"
-    }
-  }
-}
-```
-
-### Connect to HCP Terraform
-
-In the following example, the configuration links the working directory to workspaces in the `example_corp` organization that contain the `layer=app` tag:
-
-```hcl
-terraform {
-  cloud {
-    organization = "example_corp"
-    workspaces {
-      tags = {
-        layer = "app"
-      }
-    }
-  }
-}
-```
-
-### Connect to Terraform Enterprise
-
-In the following example, the configuration links the working directory to workspaces in the `example_corp` organization that contain the `app` key-only tag. Key-only tags must be used with versions of Terraform Enterprise prior to v202411-1 or versions of Terraform prior to v1.10. The `hostname` field is required in the configuration unless you use the `TF_CLOUD_HOSTNAME` environment variable:
-
-```hcl
-terraform {
-  cloud {
-    organization = "example_corp"
-    hostname = "my.terraform-enterprise.host"
-    workspaces {
-      tags = ["app"]
-    }
-  }
-}
-```
-
-### Connect to Terraform Enterprise using environment variables
-
-In the following example, Terraform checks the `TF_CLOUD_ORGANIZATION` and `TF_CLOUD_HOSTNAME` environment variables and automatically populates the `organization` and `hostname` arguments. During initialization, the local Terraform CLI connects the working directory to Terraform Enterprise using those values. As a result, Terraform links the configuration to either HCP Terraform or Terraform Enterprise and allows teams to  reuse the configuration in different continuous integration pipelines:
-
-```hcl
-terraform {
-  cloud {
-    workspaces {
-      tags = ["app"]
-    }
-  }
-}
-```
\ No newline at end of file
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
new file mode 100644
index 000000000..43ad1dae2
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/test-and-validate/validate.mdx
@@ -0,0 +1,245 @@
+---
+page_title: Validate your infrastructure in Terraform’s configuration language
+description: >-
+  Configuration-level validation lets you enforce rules, validate resources, and detect errors as part of your infrastructure provisioning process.
+---
+
+# Validate your configuration
+
+Validate your configuration to improve your module consumer's troubleshooting, make your runs more predictable, and help your maintainers understand your configuration's intent.
+
+## Introduction
+
+Validation helps you verify that your Terraform configuration works as you intend. Using different types of validation you can:
+
+- Verify input variables meet specific requirements.
+- Prevent incorrect outputs from writing to your state.
+- Ensure resources and data sources are configured correctly after Terraform applies them.
+- Verify the broader behavior of your infrastructure.
+- Document assumptions about your infrastructure.
+- Use HCP Terraform to regularly verify your infrastructure.
+
+When a validation fails, Terraform provides context that you can use in your error messages to help users understand and fix their issue. Terraform evaluates different ways of validation at [different stages of Terraform's execution cycle](#order-of-validation), and they can either block further operation execution or continue execution with warnings.
+
+For authors, adding validation to your configuration enforces your module's standards and requirements, helping module consumers understand and use your configuration.
+
+## Requirements
+
+- Terraform v0.13.0 or later for [input variable validation](#input-variable-validation)
+- Terraform v1.2.0 or later for [preconditions and postconditions](#preconditions-and-postconditions)
+- Terraform v1.5.0 or later for [`check` blocks](#checks)
+
+## Choose a validation for your use case
+
+> **Hands On:** Try the [Validate Modules with Custom Conditions](/terraform/tutorials/configuration-language/custom-conditions) tutorial to learn how to use variable validation, preconditions, and postconditions. Try the [Validate Infrastructure Using Checks](/terraform/tutorials/configuration-language/checks) tutorial to learn how to use `check` blocks.
+
+Terraform offers several ways of validating configuration:
+
+* Input variable validations verify your configuration's parameters when Terraform creates a plan.
+* Preconditions ensure individual resources, data sources, and outputs meet your requirements before Terraform tries to create them.
+* Postconditions verifies that Terraform produced your resources and data sources with the expected and desired settings.
+* Checks let you validate that your resources work as expected without blocking Terraform operations based on the check's result.
+
+Validating your configuration is flexible, and you can often use different kinds of validation to achieve the same result. When choosing a way of validating, consider whether or not you want the validation to block your operations, and during which phase of the Terraform workflow it should run.
+
+### Input variable validation
+
+Use input variable validation to perform the following tasks:
+- Verify input variables meet specific format requirements.
+- Verify input values fall within acceptable ranges.
+- Prevent Terraform operations if a variable is misconfigured.
+
+For example, you can validate whether a variable value has valid AMI ID 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-\"."
+  }
+}
+```
+
+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/block/variable#validation).
+
+### Preconditions and postconditions
+
+Use `precondition` blocks when you want to verify your configuration's assumptions for resources, data sources, and outputs before Terraform creates them. Use `postcondition` blocks to validate the guarantees your resources and data sources must meet for your configuration to run.
+
+#### Preconditions
+
+Terraform evaluates preconditions on resources, data sources, and outputs when Terraform creates a plan. Preconditions take precedence over any argument errors raised by providers on incorrectly configured resources, data sources, and outputs.
+
+The following example uses a precondition to verify that the AMI configured for an`aws_instance` uses the `x86_64` CPU architecture.
+
+```hcl
+resource "aws_instance" "example" {
+  instance_type = "t3.micro"
+  ami           = data.aws_ami.example.id
+
+  lifecycle {
+    # The AMI ID must refer to an AMI that contains an operating system
+    # for the `x86_64` architecture.
+    precondition {
+      condition     = data.aws_ami.example.architecture == "x86_64"
+      error_message = "The selected AMI must be for the x86_64 architecture."
+    }
+  }
+}
+```
+
+The precondition detects if the caller accidentally selected an AMI for a different architecture, which may not be able to run the software this instance hosts. Terraform evaluates the precondition while it builds its plan, and if the precondition fails Terraform throws an error with the `error_message` argument and stops the current operation. Refer to the [resource configuration reference](/terraform/language/block/resource) for more examples of using a precondition block.
+
+An `output` block can also include a precondition to verify a module's output. Use preconditions on outputs to validate that your output values meets your requirements before Terraform exposes them or stores their values in state.
+
+For example, you can use a precondition to ensure a server's security group has at least one ingress rule to allow traffic on ports `80` or `443`:
+
+```hcl
+output "instance_public_ip" {
+  value = aws_instance.web.public_ip
+
+  precondition {
+    condition     = length([for rule in aws_security_group.web.ingress : rule if rule.to_port == 80 || rule.to_port == 443]) > 0
+    error_message = "Security group must allow HTTP (port 80) or HTTPS (port 443) traffic."
+  }
+}
+```
+
+If the `precondition` fails, Terraform throws an error with the `error_message` and stops the current operation. Refer to the [`output` block reference](/terraform/language/block/output) for more details.
+
+#### Postconditions
+
+Terraform evaluates `postcondition` blocks after planning and applying changes to a resource, or after reading from a data source.
+
+For example, you can use a `postcondition` to detect if a user accidentally provided an AMI intended for the wrong system component.
+
+```hcl
+data "aws_ami" "example" {
+  id = var.aws_ami_id
+
+  lifecycle {
+    # The AMI ID must refer to an existing AMI that has the tag "nomad-server".
+    postcondition {
+      condition     = self.tags["Component"] == "nomad-server"
+      error_message = "tags[\"Component\"] must be \"nomad-server\"."
+    }
+  }
+}
+```
+
+Unless the component has the `"nomad-server"` tag, the postcondition fails, which prevents using the incorrect AMI to provision a server. If the postcondition fails, Terraform throws an error with the `error_message` argument and stops the current operation.
+
+Adding postconditions can prevent cascading changes to other dependent resources. Refer to the [`resource` configuration reference](/terraform/language/resources/syntax) for more examples of using a `postcondition` block.
+
+Postconditions can serve as static guardrails to enforce mandatory configuration aspects on your `data` and `resource` blocks. For verifying infrastructure dynamically against external or changing conditions, we recommend using the `check` blocks, which run as the final step of a Terraform operation after postconditions. Learn more about the [`check` block](#checks).
+
+#### Choose between a precondition or postcondition
+
+You can often implement similar verification with different kinds of validation to achieve the same result. For example, you could add a postcondition on a resource that produces data, or add a precondition to a resource or output that references that same data. To decide between a precondition or a postcondition, consider whether the rule you are setting represents an assumption you need to make about the configuration, or a guarantee on the resulting resource, and when it should run.
+
+Use preconditions for assumptions that you want to verify before Terraform creates the target block. For example, you may want to verify that the AMI selected for an `aws_instance` has x86_64 CPU architecture before trying to create the instance. Using preconditions for assumptions helps future maintainers understand the values a resource, output, or data source should allow.
+
+Use postconditions for guarantees that you need to verify after Terraform creates the resource or reads from the data source. For example, you may want to ensure that an `aws_instance` is launched in a network that assigns it a private DNS record. Use postconditions for guarantees to help future maintainers understand which behaviors they must preserve when changing configuration.
+
+Use the following considerations to help you decide between preconditions and postconditions:
+- Determine which block would most clearly report error messages. For example, if a resource has many dependencies, it can be pragmatic to declare one postcondition on that resource rather than preconditions on each dependency.
+- Determine whether the precondition and postcondition should you declare the same conditions. If your postcondition is in a different module from your precondition, it can be beneficial to have both, because each module verifies one another as each evolves independently.
+
+### Checks
+
+> **Hands On:** Try the [Validate Infrastructure Using Checks](/terraform/tutorials/configuration-language/checks) tutorial to learn how to use `check` blocks.
+
+Use the `check` block to validate your infrastructure outside of the typical resource lifecycle.
+
+The `check` block executes as the last step of plan or apply operation, after Terraform has planned or provisioned your infrastructure. When a `check` block's assertion fails, Terraform reports a warning and continues executing the current operation.
+
+Use `check` blocks to complete the following tasks:
+- Validate resources, data sources, variables, or outputs in your configuration.
+- Validate the behavior of your infrastructure as a whole.
+- Verify infrastructure configuration without blocking operations.
+- Perform [continuous validation in HCP Terraform](#continuous-validation-in-hcp-terraform).
+
+The following example uses a `check` block to verify the Terraform website is healthy.
+
+```hcl
+check "health_check" {
+  data "http" "terraform_io" {
+    url = "https://www.terraform.io"
+  }
+
+  assert {
+    condition = data.http.terraform_io.status_code == 200
+    error_message = "${data.http.terraform_io.url} returned an unhealthy status code"
+  }
+}
+```
+
+If the website's endpoint returns a `200` status code, then the website is healthy and the check passes. Unlike other ways of validating your configuration, `check` blocks do not block operations. If the assertion evaluates to `false`, Terraform throws a warning that includes the result of the `error_message` expression and continues the operation.
+
+For more details, refer to the [`check` configuration reference](/terraform/language/block/check).
+
+## Continuous validation in HCP Terraform
+
+If you enable health checks on a workspace, HCP Terraform continuously validates any `check` blocks, preconditions, and postconditions in your workspace's configuration to regularly verify your infrastructure. For example, you can use a `check` block to continuously monitor the validity of an API gateway certificate. Continuous validation alerts you when the condition fails, so you can update the certificate and avoid errors the next time you want to update your infrastructure.
+
+Refer to [Continuous validation](/terraform/cloud-docs/workspaces/health#continuous-validation) for more details.
+
+## Order of validation
+
+Terraform validates different aspects of your configuration as early as it can. Generally, Terraform executes evaluations in the following order:
+
+1. Terraform executes input variable validations immediately, before generating a plan.
+1. Terraform executes preconditions after generating a plan but before creating the resource, data source, or output.
+1. Terraform executes postconditions after planning and applying changes.
+1. Terraform executes checks at the end of plan and apply operations and every time health assessments run on a workspace in HCP Terraform.
+
+![Order of operations for when validations run](/img/docs/validation-order-of-operations-dark.jpg#light-theme-only)
+
+![Order of operations for when validations run](/img/docs/validation-order-of-operations-dark.jpg#dark-theme-only)
+
+The precise order that Terraform executes `check` blocks, preconditions, and postconditions can depend on whether Terraform has information about a condition's value before or after applying your configuration. If the relevant value is available before an apply operation, then Terraform performs the validation during the planning phase. For example, if Terraform has access to a resource's image ID during planning, it can execute any validations that rely on that ID.
+
+If Terraform only knows the value after applying, then Terraform delays checking that validation until the apply phase. For example, AWS assigns the root volume ID when it starts an EC2 instance, so Terraform cannot reference the root volume ID until the apply is complete.
+
+During the apply phase, a failed precondition prevents Terraform from implementing planned actions for the associated resource, data source, or output. A failed postcondition halts processing and prevents further downstream actions that rely on the resource or data source, but does not undo any actions Terraform has already taken.
+
+## Error Messages
+
+<>{/* TODO: remove once we have an input variable validation page, because then we'll have error_message described on each reference page and don't need this  */}</>
+
+Input variable validations, preconditions, postconditions, and checks all must include the `error_message` argument. This contains the text that Terraform includes as part of error messages when it detects an unmet condition.
+
+```
+Error: Resource postcondition failed
+
+  with data.aws_ami.example,
+  on ec2.tf line 19, in data "aws_ami" "example":
+  72:       condition     = self.tags["Component"] == "nomad-server"
+    |----------------
+    | self.tags["Component"] is "consul-server"
+
+The selected AMI must be tagged with the Component value "nomad-server".
+```
+
+The `error_message` argument supports any expression that evaluates to a string.
+This includes literal strings, heredocs, and template expressions. You can use the [`format` function](/terraform/language/functions/format) to convert items of `null`, `list`, or `map` types into a formatted string. Multi-line error messages are supported, and Terraform does not wrap lines with leading whitespace.
+
+We recommend writing error messages as one or more full sentences in a
+style similar to Terraform's own error messages. Terraform shows the
+message alongside the name of the resource that detected the problem and any
+external values included in the condition expression.
+
+## Conditions
+
+To learn more about the conditions you can use in validations, refer to [Conditional Expressions](/terraform/language/expressions/conditionals).
+
+## Next steps
+
+Validating your configuration is the first step to mitigating risk in your infrastructure. Refer to the following topics for additional information about mitigating risk in your infrastructure lifecycle:
+- [Tests](/terraform/language/tests) help authors validate that module configuration updates do not introduce breaking changes.
+- [Policy features](/terraform/cloud-docs/policy-enforcement) in HCP Terraform enforce compliance with your organization's security rules and best practices when running Terraform plans.
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 e15ef8af2..9dc47bb30 100644
--- a/content/terraform/v1.12.x/docs/language/tests/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/tests/index.mdx
@@ -162,19 +162,19 @@ In the above example, the `first` and `second` `run` blocks implicitly have `par
 
 ### Assertions
 
-Terraform run block assertions are [Custom Conditions](/terraform/language/expressions/custom-conditions), consisting of a [condition](/terraform/language/expressions/custom-conditions#condition-expressions) and an [error message](/terraform/language/expressions/custom-conditions#error-messages).
+Assertion arguments in Terraform `run` blocks help your [validate your configuration](/terraform/language/test-and-validate/validate). Each `run` block contains a [`condition` argument](/terraform/language/expressions/conditionals) and an [`error_message` argument](/terraform/language/test-and-validate/validate#error-messages).
 
 At the conclusion of a Terraform test command execution, Terraform presents any failed assertions as part of a tests passed or failed status.
 
 #### Assertion References
 
-Assertions within tests can reference any existing [named values](/terraform/language/expressions/references) that are available to other custom conditions within the main Terraform configuration.
+Assertions within tests can reference any existing [named values](/terraform/language/expressions/references) that are available within the main Terraform configuration.
 
 Additionally, test assertions can directly reference outputs from current and previous `run` blocks. Pulling from the [previous example](#example), this is a valid condition: `condition = output.bucket_name == "test_bucket"`.
 
 ## 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.
 
@@ -757,13 +759,13 @@ If you use a single setup module as an alternate module, and it executes first,
 
 ## Expecting failures
 
-By default, if any [Custom Conditions](/terraform/language/expressions/custom-conditions), including `check` block assertions, fail during the execution of a Terraform test file then the overall command reports the test as a failure.
+By default, if any [validation](/terraform/language/test-and-validate/validate), including `check` block assertions, fails during the execution of a Terraform test file then the overall command reports the test as a failure.
 
 However, it is a common testing paradigm to want to test failure cases. Terraform supports the `expect_failures` attribute for this use case.
 
 In each `run` block the `expect_failures` attribute can provide a list of checkable objects (resources, data sources, check blocks, input variables, and outputs) that should fail their custom conditions. The test passes if the checkable objects you specify report an issue, and the test fails overall if they do not.
 
-You can still write assertions alongside an `expect_failures` block, but you should be mindful that all custom conditions, except check block assertions, halt the execution of Terraform. This still applies during test execution, so your assertions should only consider values that you are sure will be computed before the checkable object is due to fail. You can manage this using references, or the `depends_on` meta-argument within your main configuration.
+You can use assertions alongside an `expect_failures` block, but consider that all validation features, except `check` blocks, halt Terraform execution on failure. This applies during test execution, so your assertions should only evaluate values that are certain to be computed before the checkable object is due to fail. You can manage this using references, or the `depends_on` meta-argument within your main configuration.
 
 This also means that, with the exception of `check` blocks, you can only reliably include a single checkable object. We support a list of checkable objects within the `expect_failures` attribute purely for `check` blocks.
 
@@ -984,7 +986,7 @@ run "same_state" {
 }
 
 run "site_eight" {
-  // This run block is entirely unrelated to the other run blocks, however, because `site_four`, 
+  // This run block is entirely unrelated to the other run blocks, however, because `site_four`,
   // which is one of its preceding runs has the `parallel` attribute set to `false`,
   // it cannot run until site_four is completed. It can be executed in parallel with `site_five` and `site_six`.
   state_key = "unique_7"
@@ -1009,4 +1011,4 @@ Run D (parallel: true)
 Run E (parallel: true)
 ```
 
-Runs A and B execute simultaneously. Run C waits until both A and B are done before starting. Finally, runs D and E run in parallel, but only after C completes.
\ No newline at end of file
+Runs A and B execute simultaneously. Run C waits until both A and B are finished before starting. Finally, runs D and E run in parallel, but only after C completes.
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 75d560069..3a3b35f56 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,9 +78,9 @@ 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),
-  [`output`](/terraform/language/values/outputs#declaring-an-output-value), and
-  [`locals`](/terraform/language/values/locals#declaring-a-local-value) blocks
+* [`variable`](/terraform/language/block/variable),
+  [`output`](/terraform/language/block/output), and
+  [`locals`](/terraform/language/block/locals) blocks
   for declaring the various kinds of named values in a module.
 * [`terraform`](/terraform/language/terraform) blocks, including the nested
   [`required_version`](/terraform/language/terraform#terraform-required_version)
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 bd207554b..26404fa13 100644
--- a/content/terraform/v1.12.x/docs/language/values/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/values/index.mdx
@@ -10,11 +10,11 @@ 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/values/outputs) are like return values for a
+- [Output Values](/terraform/language/block/output) are like return values for a
   Terraform module.
 
-- [Local Values](/terraform/language/values/locals) are a convenience feature for
+- [The `locals` block](/terraform/language/block/locals) is a convenience feature for
   assigning a short name to an expression.
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 e831cba02..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,8 +16,8 @@ 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.
-- [Output values](/terraform/language/values/outputs) are like function return values.
+- [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.
 
 -> **Note:** For brevity, local values are often referred to as just "locals"
diff --git a/content/terraform/v1.12.x/docs/language/values/outputs.mdx b/content/terraform/v1.12.x/docs/language/values/outputs.mdx
deleted file mode 100644
index 858700414..000000000
--- a/content/terraform/v1.12.x/docs/language/values/outputs.mdx
+++ /dev/null
@@ -1,243 +0,0 @@
----
-page_title: Output Values - Configuration Language
-description: Output values are the return values of a Terraform module.
----
-
-# Output Values
-
-Output values make information about your infrastructure available on the
-command line, and can expose information for other Terraform configurations to
-use. Output values are similar to return values in programming languages.
-
-> **Hands-on:** Try the [Output Data From
-> Terraform](/terraform/tutorials/configuration-language/outputs)
-> tutorial.
-
-Output values have several uses:
-
-- A child module can use outputs to expose a subset of its resource attributes
-  to a parent module.
-- A root module can use outputs to print certain values in the CLI output after
-  running `terraform apply`.
-- When using [remote state](/terraform/language/state/remote), root module outputs can be
-  accessed by other configurations via a
-  [`terraform_remote_state` data source](/terraform/language/state/remote-state-data).
-
-Resource instances managed by Terraform each export attributes whose values
-can be used elsewhere in configuration. Output values are a way to expose some
-of that information to the user of your module.
-
--> **Note:** For brevity, output values are often referred to as just "outputs"
-when the meaning is clear from context.
-
-## Declaring an Output Value
-
-Each output value exported by a module must be declared using an `output`
-block:
-
-```hcl
-output "instance_ip_addr" {
-  value = aws_instance.server.private_ip
-}
-```
-
-The label immediately after the `output` keyword is the name, which must be a
-valid [identifier](/terraform/language/syntax/configuration#identifiers). In a root module, this name is
-displayed to the user; in a child module, it can be used to access the output's
-value.
-
-The `value` argument takes an [expression](/terraform/language/expressions)
-whose result is to be returned to the user. In this example, the expression
-refers to the `private_ip` attribute exposed by an `aws_instance` resource
-defined elsewhere in this module (not shown). Any valid expression is allowed
-as an output value.
-
--> **Note:** Outputs are only rendered when Terraform applies your plan. Running
-`terraform plan` will not render outputs.
-
-## Accessing Child Module Outputs
-
-In a parent module, outputs of child modules are available in expressions as
-`module.<MODULE NAME>.<OUTPUT NAME>`. For example, if a child module named
-`web_server` declared an output named `instance_ip_addr`, you could access that
-value as `module.web_server.instance_ip_addr`.
-
-
-## Custom Condition Checks
-
-You can use `precondition` blocks to specify guarantees about output data. The following examples creates a precondition that checks whether the EC2 instance has an encrypted root volume.
-
-```hcl
-output "api_base_url" {
-  value = "https://${aws_instance.example.private_dns}:8433/"
-
-  # The EC2 instance must have an encrypted root volume.
-  precondition {
-    condition     = data.aws_ebs_volume.example.encrypted
-    error_message = "The server's root volume is not encrypted."
-  }
-}
-```
-
-Custom conditions can help capture assumptions, helping future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context, helping consumers more easily diagnose issues in their configurations.
-
-Refer to [Custom Condition Checks](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
-
-## Optional Arguments
-
-`output` blocks can optionally include `description`, `sensitive`, `ephemeral`, and `depends_on` arguments, which are described in the following sections.
-
-<a id="description"></a>
-
-### `description` — Output Value Documentation
-
-Because the output values of a module are part of its user interface, you can
-briefly describe the purpose of each value using the optional `description`
-argument:
-
-```hcl
-output "instance_ip_addr" {
-  value       = aws_instance.server.private_ip
-  description = "The private IP address of the main server instance."
-}
-```
-
-The description should concisely explain the
-purpose of the output 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.
-
-<a id="ephemeral"></a>
-
-### `ephemeral` — Avoid storing values in state or plan files
-
--> **Note**: Ephemeral outputs are available in Terraform v1.10 and later.
-
-You can mark `output` values as `ephemeral` in child modules to pass ephemeral values between modules while avoiding persisting those values to state or plan files. This is useful for managing credentials, tokens, or other temporary resources you do not want to store in Terraform state files.
-
-You can mark an `output` in a child module as ephemeral by setting the `ephemeral` attribute to `true`:
-
-```hcl
-# modules/db/main.tf
-
-output "secret_id" {
-  value       = aws_secretsmanager_secret.secret_id
-  description = "Temporary secret ID for accessing database in AWS."
-  ephemeral   = true
-}
-```
-
-Terraform has access to the value of `output` blocks during plan and apply operations. At the end of a plan or apply operation, Terraform does not persist the value of any ephemeral outputs.
-
-You can only reference ephemeral outputs in specific contexts or Terraform throws an error. The following are valid contexts for referencing ephemeral outputs:
-
-* In a [write-only argument](/terraform/language/resources/ephemeral/write-only)
-* In another child module's ephemeral `output` block
-* In [ephemeral variables](/terraform/language/values/variables#exclude-values-from-state)
-* In [ephemeral resources](/terraform/language/resources/ephemeral)
-
-Note that you cannot set an `output` value as `ephemeral` in the root module.
-
-
-<a id="sensitive"></a>
-
-### `sensitive` — Suppressing Values in CLI Output
-
-An output can be marked as containing sensitive material using the optional
-`sensitive` argument:
-
-```hcl
-output "db_password" {
-  value       = aws_db_instance.db.password
-  description = "The password for logging in to the database."
-  sensitive   = true
-}
-```
-
-Terraform will hide values marked as sensitive in the messages from
-`terraform plan` and `terraform apply`. In the following scenario, our root
-module has an output declared as sensitive and a module call with a
-sensitive output, which we then use in a resource attribute.
-
-```hcl
-# main.tf
-
-module "foo" {
-  source = "./mod"
-}
-
-resource "test_instance" "x" {
-  some_attribute = module.foo.a # resource attribute references a sensitive output
-}
-
-output "out" {
-  value     = "xyz"
-  sensitive = true
-}
-
-# mod/main.tf, our module containing a sensitive output
-
-output "a" {
-  value     = "secret"
-  sensitive = true
-}
-```
-
-When we run a plan or apply, the sensitive value is redacted from output:
-
-```
-Terraform will perform the following actions:
-
-  # test_instance.x will be created
-  + resource "test_instance" "x" {
-      + some_attribute    = (sensitive value)
-    }
-
-Plan: 1 to add, 0 to change, 0 to destroy.
-
-Changes to Outputs:
-  + out = (sensitive value)
-```
-
-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. For more information, see
-[Sensitive Data in State](/terraform/language/state/sensitive-data).
-
-<a id="depends_on"></a>
-
-### `depends_on` — Explicit Output Dependencies
-
-Since output values are just a means for passing data out of a module, it is
-usually not necessary to worry about their relationships with other nodes in
-the dependency graph.
-
-However, when a parent module accesses an output value exported by one of its
-child modules, the dependencies of that output value allow Terraform to
-correctly determine the dependencies between resources defined in different
-modules.
-
-Just as with
-[resource dependencies](/terraform/language/resources/behavior#resource-dependencies),
-Terraform analyzes the `value` expression for an output value and automatically
-determines a set of dependencies, but in less-common cases there are
-dependencies that cannot be recognized implicitly. In these rare cases, the
-`depends_on` argument can be used to create additional explicit dependencies:
-
-```hcl
-output "instance_ip_addr" {
-  value       = aws_instance.server.private_ip
-  description = "The private IP address of the main server instance."
-
-  depends_on = [
-    # Security group rule must be created before this IP address could
-    # actually be used, otherwise the services will be unreachable.
-    aws_security_group_rule.local_access,
-  ]
-}
-```
-
-The `depends_on` argument should be used only as a last resort. When using it,
-always include a comment explaining why it is being used, to help future
-maintainers understand the purpose of the additional dependency.
diff --git a/content/terraform/v1.12.x/docs/language/values/variables.mdx b/content/terraform/v1.12.x/docs/language/values/variables.mdx
index 28769f72d..a6738f370 100644
--- a/content/terraform/v1.12.x/docs/language/values/variables.mdx
+++ b/content/terraform/v1.12.x/docs/language/values/variables.mdx
@@ -22,7 +22,7 @@ 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/values/outputs) are like function return values.
+* [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
@@ -174,7 +174,8 @@ variable "image_id" {
   }
 }
 ```
-Refer to [Custom Condition Checks](/terraform/language/expressions/custom-conditions#input-variable-validation) for more details.
+
+Refer to [Validate your configuration](/terraform/language/test-and-validate/validate#input-variable-validation) for more details.
 
 ### Exclude values from state
 
@@ -201,7 +202,7 @@ You can only reference ephemeral variables in specific contexts or Terraform thr
 * Another ephemeral variable
 * In [local values](/terraform/language/values/locals#ephemeral-values)
 * In [ephemeral resources](/terraform/language/resources/ephemeral)
-* In [ephemeral outputs](/terraform/language/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files)
+* 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
 
@@ -214,7 +215,7 @@ variable "password" {
 }
 
 locals {
-  # local.database_password is implicitly ephemeral because 
+  # local.database_password is implicitly ephemeral because
   # var.password is ephemeral.
   database_password = var.password
 }
@@ -292,7 +293,7 @@ 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/values/outputs) then Terraform will require
+[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.
 
diff --git a/content/terraform/v1.12.x/docs/partials/provisioner-connnection-settings.mdx b/content/terraform/v1.12.x/docs/partials/provisioner-connnection-settings.mdx
new file mode 100644
index 000000000..f204ebc5f
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/partials/provisioner-connnection-settings.mdx
@@ -0,0 +1,31 @@
+| 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> |
+| `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> |
+| `timeout` | Specifies how long to wait for the connection to become available. | string | `ssh`<p>`winrm`</p> | `"5m"` |
+| `script_path` | Specifies the path on the remote resource where Terraform copies scripts to. Refer to the [`provisioner` block reference](#provisioner) for more information. Terraform copies scripts to a path that contains random numbers depending on the `target_platform` configuration. | string | `ssh`<p>`winrm`</p> | <p>`/tmp/terraform_%RAND%.sh` when `target_platform` is `unix`</p><p>`C:/windows/temp/`<br/>`terraform_%RAND%.cmd` when `target_platform` is `windows`</p> |
+| `private_key` | Specifies the contents of an SSH key to use for the connection. `private_key` takes precedence over `password` when both are provided. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load keys from file.</p> | `ssh` | none |
+| `certificate` | Specifies the contents of a signed CA certificate. You must also configure a  `private_key` arugment. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load certificates from file.</p> | `ssh` | none |
+| `agent` | Specifies an SSH agent for authentication. Set to `false` to disable using `ssh-agent` to authenticate. On Windows, the only supported SSH authentication agent is [Pageant](http://the.earth.li/\~sgtatham/putty/0.66/htmldoc/Chapter9.html#pageant). | string | `ssh` | `false` |
+| `agent_identity` | Specifies the preferred identity from the SSH agent to use for authentication. | string | `ssh` | none |
+| `host_key` | Specifies the public key from the remote host or the signing CA to verify the connection. | string | `ssh` | none |
+| `target_platform` | Specifies the target platform, which affects the default value for the `script_path` argument. You can specify either `windows` or `unix`. <p>`windows` sets the default `script_path` to `c:\windows\temp\terraform_%RAND%.cmd` if the default SSH shell on the remote resource is `cmd.exe`. Refer to the [Windows documentation](https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_server_configuration#configuring-the-default-shell-for-openssh-in-windows) for more information. If the SSH default shell is PowerShell, set `script_path` to `"c:/windows/temp/terraform_%RAND%.ps1"`.</p><p>`unix` sets the default `script_path` to `/tmp/terraform_%RAND%.sh`. </p> | string | `ssh` |`unix` |
+| `https` | Set to `true` to connect using HTTPS instead of HTTP. | boolean | `winrm` | `false` |
+| `insecure` | Set to `true` to skip validating the HTTPS certificate chain. | boolean | `winrm` | `false` |
+| `use_ntlm` | Set to `true` to use NTLM authentication instead of basic authentication. Using NTLM removes the requirement for basic authentication to be enabled within the target guest. Refer to [Authentication for Remote Connections](https://docs.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections) in the Windows App Development documentation for more details. | boolean | `winrm` | `false` |
+| `cacert` | Specifies the CA certificate to validate against. | string | `winrm` | none |
+| `bastion_host` | Specifies the address of the bastion host. The provisioner connects to `bastion_host` before connecting to `host`. | string | `ssh` | none |
+| `bastion_host_key` | Specifies the public key from the remote host or the signing CA to verify the host connection. | string | `ssh` | none |
+| `bastion_port` | Specifies the port number to use for the bastion host connection. | string | `ssh` | value of the `port` field|
+| `bastion_user`| Specifies the user name for connecting to the bastion host. | string | `ssh` | value of the `user` field |
+| `bastion_password` | Specifies the user password for connecting to the bastion host. | string | `ssh` | value of the `password` field |
+| `bastion_private_key` | Specifies the contents of an SSH key file to use for the bastion host. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load keys from file.</p> | `ssh` | value of the `private_key` field |
+| `bastion_certificate` |  Specifies the contents of a signed CA certificate. You must also configure the `bastion_private_key` argument when providing the certificate for the bastion host. | <p>string</p><p>Use a [`file` function](/terraform/language/functions/file) to load certificates from file.</p> | `ssh` | value of the `certificate` field |
+| `proxy_scheme` | Specifies the connection protocol. You can specify one of the following values: <li>`http`</li><li>`https`</li><li> `socks5`</li> | string | `ssh` | none |
+| `proxy_host` | Specifies the address of the proxy host. The provisioner connects to the proxy host first. When `bastion_host` is configured, the provisioner connects to the bastion host next, otherwise the provisioner connects to the host specified in the `host` argument.  | string | `ssh` | none |
+| `proxy_port` | Specifies the port number to use for the proxy host connection. | number | `ssh` | none |
+| `proxy_user_name` | Specifies the user name for connecting to the proxy host. You should only configure this argument when the proxy server requires authentication. | string | `ssh` | none |
+| `proxy_user_password` | Specifies the user password for connecting to the proxy host. You should only configure this argument when the proxy server requires authentication. | string | `ssh` | none |
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/img/docs/validation-order-of-operations-dark.jpg b/content/terraform/v1.12.x/img/docs/validation-order-of-operations-dark.jpg
new file mode 100644
index 000000000..b747d2fe8
Binary files /dev/null and b/content/terraform/v1.12.x/img/docs/validation-order-of-operations-dark.jpg differ
diff --git a/content/terraform/v1.12.x/img/docs/validation-order-of-operations-light.jpg b/content/terraform/v1.12.x/img/docs/validation-order-of-operations-light.jpg
new file mode 100644
index 000000000..9c60ce210
Binary files /dev/null and b/content/terraform/v1.12.x/img/docs/validation-order-of-operations-light.jpg differ