diff --git a/website/data/language-nav-data.json b/website/data/language-nav-data.json
index 06b7b94b65a7..f5a255621f7f 100644
--- a/website/data/language-nav-data.json
+++ b/website/data/language-nav-data.json
@@ -6,9 +6,9 @@
     "path": "attr-as-blocks",
     "hidden": true
   },
-  { 
-    "title": "Style Guide", 
-    "path": "style" 
+  {
+    "title": "Style Guide",
+    "path": "style"
   },
   {
     "title": "Stacks",
@@ -211,7 +211,7 @@
     "routes": [
       { "title": "Overview", "path": "values" },
       { "title": "Input Variables", "path": "values/variables" },
-      { "title": "Output Values", "path": "values/outputs" },
+      { "title": "Output block", "href": "/terraform/language/block/output" },
       { "title": "Local Values", "path": "values/locals" }
     ]
   },
@@ -273,11 +273,11 @@
   },
   {
     "title": "Moved block",
-    "path": "moved"
+    "href": "/terraform/language/block/moved"
   },
   {
     "title": "Terraform block",
-    "path": "terraform"
+    "href": "/terraform/language/block/terraform"
   },
   {
     "title": "Backend block",
@@ -332,7 +332,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": [
@@ -375,10 +381,6 @@
         "title": "Dynamic Blocks",
         "path": "expressions/dynamic-blocks"
       },
-      {
-        "title": "Custom Conditions",
-        "path": "expressions/custom-conditions"
-      },
       {
         "title": "Type Constraints",
         "path": "expressions/type-constraints"
@@ -1109,5 +1111,32 @@
     "path": "v1-compatibility-promises"
   },
   { "divider": true },
+  { "heading": "REFERENCE" },
+  {
+    "title": "Configuration blocks",
+    "routes": [
+      {
+        "title": "resource",
+        "path": "block/resource"
+      },    
+      {
+        "title": "check",
+        "path": "block/check"
+      },
+      {
+        "title": "Moved block",
+        "path": "block/moved"
+      },
+      {
+        "title": "Output block",
+        "path": "block/output"
+      },
+      {
+        "title": "Terraform block",
+        "path": "block/terraform"
+      }
+    ]
+  },
+  { "divider": true },
   { "title": "Terraform Internals", "href": "/internals" }
 ]
diff --git a/website/docs/cli/inspect/index.mdx b/website/docs/cli/inspect/index.mdx
index cd323c1724b1..63c1d2f73d86 100644
--- a/website/docs/cli/inspect/index.mdx
+++ b/website/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/website/docs/cli/test/index.mdx b/website/docs/cli/test/index.mdx
index 08177edce984..564e1ef22b7c 100644
--- a/website/docs/cli/test/index.mdx
+++ b/website/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/website/docs/language/block/check.mdx b/website/docs/language/block/check.mdx
new file mode 100644
index 000000000000..235af6acb627
--- /dev/null
+++ b/website/docs/language/block/check.mdx
@@ -0,0 +1,236 @@
+---
+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/mitigate-risk/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/website/docs/language/moved.mdx b/website/docs/language/block/moved.mdx
similarity index 94%
rename from website/docs/language/moved.mdx
rename to website/docs/language/block/moved.mdx
index b5dbc79ab56c..20ab9e103b23 100644
--- a/website/docs/language/moved.mdx
+++ b/website/docs/language/block/moved.mdx
@@ -1,5 +1,5 @@
 ---
-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.
 ---
 
@@ -28,7 +28,7 @@ moved {
 
 ## Specification
 
-A `moved` block supports the following configuration. 
+A `moved` block supports the following configuration.
 
 ### `moved`
 
@@ -50,4 +50,4 @@ moved {
   from = aws_instance.a
   to   = aws_instance.b
 }
-```
\ No newline at end of file
+```
diff --git a/website/docs/language/block/output.mdx b/website/docs/language/block/output.mdx
new file mode 100644
index 000000000000..0f6c0fbb49af
--- /dev/null
+++ b/website/docs/language/block/output.mdx
@@ -0,0 +1,295 @@
+---
+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/values/variables#exclude-values-from-state)
+- [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/website/docs/language/block/resource.mdx b/website/docs/language/block/resource.mdx
new file mode 100644
index 000000000000..3dccd07704aa
--- /dev/null
+++ b/website/docs/language/block/resource.mdx
@@ -0,0 +1,1279 @@
+---
+page_title: resource block reference
+description: >-
+   Learn configure `resource` block arguments in Terraform configuration language.
+---
+
+# `resource` block
+
+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 one 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/values/variables#suppressing-values-in-cli-output), [sensitive outputs](/terraform/language/values/outputs#sensitive-suppressing-values-in-cli-output), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
+
+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" "<LABEL>" {
+    source = "<path>"
+  }
+}
+```
+
+
+You can specify a string value that contains an expression. You cannot 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" "<LABEL>" {
+    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 canot 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" "<LABEL>" {
+    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" "<LABEL>" {
+    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" "<LABEL>" {
+    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" "<LABEL>" {
+    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" "<LABEL>" {
+    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" "<LABEL>" {
+    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" "<LABEL>" {
+    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/website/docs/language/terraform.mdx b/website/docs/language/block/terraform.mdx
similarity index 94%
rename from website/docs/language/terraform.mdx
rename to website/docs/language/block/terraform.mdx
index 704fb87c0373..f0097fd53f71 100644
--- a/website/docs/language/terraform.mdx
+++ b/website/docs/language/block/terraform.mdx
@@ -1,5 +1,5 @@
 ---
-page_title: Terraform block configuration reference
+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.
 ---
@@ -13,7 +13,7 @@ This topic provides reference information about the `terraform` block. The `terr
 The `terraform` block supports the following arguments:
 
 - [`terraform`](#terraform)
-  - [`required_version`](#required_version): &nbsp string 
+  - [`required_version`](#required_version): &nbsp string
   - [`required_providers`](#required_providers): &nbsp block
     - [`<PROVIDER>`](#provider): &nbsp block
       - [`version`](#provider): &nbsp string
@@ -44,15 +44,15 @@ terraform {
       source = "<provider-address>"
     }
   }
-  provider_meta "<LABEL>" { 
-    # Shown for completeness but only used for specific cases     
+  provider_meta "<LABEL>" {
+    # Shown for completeness but only used for specific cases
   }
-  backend "<TYPE>" {        
-    # `backend` is mutually exclusive with `cloud` 
+  backend "<TYPE>" {
+    # `backend` is mutually exclusive with `cloud`
     "<ARGUMENTS>"
   }
-  cloud {                   
-    # `cloud` is mutually exclusive with `backend` 
+  cloud {
+    # `cloud` is mutually exclusive with `backend`
     organization = "<organization-name>"
     workspaces {
       tags = [ "<tag>" ]
@@ -76,7 +76,7 @@ Parent block that contains configurations that define Terraform behavior. You ca
 
 ### `required_version`
 
-Specifies which version of the Terraform CLI is allowed to run the configuration. 
+Specifies which version of the Terraform CLI is allowed to run the configuration.
 
 ```hcl
 terraform {
@@ -103,7 +103,7 @@ The `required_version` configuration applies only to the version of Terraform CL
 
 ### `required_providers`
 
-Specifies all provider plugins required to create and manage resources specified in the configuration. 
+Specifies all provider plugins required to create and manage resources specified in the configuration.
 
 ```hcl
 terraform {
@@ -131,7 +131,7 @@ terraform {
   required_providers {
     <PROVIDER> {
       version = "<version-constraint>"
-      source = "<address>"      
+      source = "<address>"
     }
   }
   # . . .
@@ -154,7 +154,7 @@ You can specify the following arguments:
 
 ### `provider_meta "<LABEL>"`
 
-Specifies metadata fields that a provider may expect. 
+Specifies metadata fields that a provider may expect.
 
 ```hcl
 terraform {
@@ -167,14 +167,14 @@ terraform {
 
 Individual modules can populate the metadata fields independently of any provider configuration. Refer to [Provider Metadata](/terraform/internals/provider-meta) for additional information.
 
-#### Summary 
+#### Summary
 
 - Data type: Block.
 - Default: None.
 
 ### `backend "<BACKEND_TYPE>"`
 
-Specifies a mechanism for storing Terraform state files. 
+Specifies a mechanism for storing Terraform state files.
 
 ```hcl
 terraform {
@@ -197,7 +197,7 @@ You cannot configure a `backend` block when the configuration also contains a [`
 
 ### `cloud`
 
-Specifies a set of attributes that allow the Terraform configuration to connect to either HCP Terraform or a Terraform Enterprise installation. 
+Specifies a set of attributes that allow the Terraform configuration to connect to either HCP Terraform or a Terraform Enterprise installation.
 
 ```hcl
 terraform {
@@ -224,7 +224,7 @@ The `cloud` block cannot refer to named values, such as input variables, locals,
 
 ### `organization`
 
-Specifies the name of the organization you want to connect to. 
+Specifies the name of the organization you want to connect to.
 
 ```hcl
 terraform {
@@ -245,7 +245,7 @@ Instead of hardcoding the organization as a string, you can alternatively use th
 
 ### `workspaces`
 
-Specifies metadata for matching workspaces in HCP Terraform. 
+Specifies metadata for matching workspaces in HCP Terraform.
 
 
 ```hcl
@@ -255,7 +255,7 @@ terraform {
       tags = [ "<workspace-tag>" ] # Mutually exclusive with `name`
       name = "<workspace-name>" # Mutually exclusive with `tags`
       project = "<project-name>"
-    }            
+    }
   }
   # . . .
 }
@@ -277,7 +277,7 @@ Terraform associates the configuration with workspaces managed in HCP Terraform
 
 ### `hostname`
 
-Specifies the hostname for a Terraform Enterprise deployment. 
+Specifies the hostname for a Terraform Enterprise deployment.
 
 ```hcl
 terraform {
@@ -299,7 +299,7 @@ Instead of hardcoding the hostname of the Terraform Enterprise deployment, you c
 
 ### `token`
 
-Specifies a token for authenticating with HCP Terraform. 
+Specifies a token for authenticating with HCP Terraform.
 
 ```hcl
 terraform {
@@ -321,7 +321,7 @@ We recommend omitting the token from the configuration and either using the [`te
 
 ### `experiments`
 
-Specifies a list of experimental feature names that you want to opt into. 
+Specifies a list of experimental feature names that you want to opt into.
 
 ```hcl
 terraform {
@@ -427,4 +427,4 @@ terraform {
     }
   }
 }
-```
\ No newline at end of file
+```
diff --git a/website/docs/language/checks/index.mdx b/website/docs/language/checks/index.mdx
deleted file mode 100644
index 021ee582c1cd..000000000000
--- a/website/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 postconditions](/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/website/docs/language/data-sources/index.mdx b/website/docs/language/data-sources/index.mdx
index f8d65223953f..3c65b35e0fc0 100644
--- a/website/docs/language/data-sources/index.mdx
+++ b/website/docs/language/data-sources/index.mdx
@@ -149,7 +149,7 @@ 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.
 
-Refer to [Custom Condition Checks](/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 more details.
 
 
 ## Multiple Resource Instances
diff --git a/website/docs/language/expressions/conditionals.mdx b/website/docs/language/expressions/conditionals.mdx
index 28ccc148b354..db9de465c5c9 100644
--- a/website/docs/language/expressions/conditionals.mdx
+++ b/website/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#input-variable-validation) 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/website/docs/language/expressions/custom-conditions.mdx b/website/docs/language/expressions/custom-conditions.mdx
deleted file mode 100644
index 6f658ad36ba4..000000000000
--- a/website/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/website/docs/language/expressions/function-calls.mdx b/website/docs/language/expressions/function-calls.mdx
index b12f6674138e..556db72d6cb4 100644
--- a/website/docs/language/expressions/function-calls.mdx
+++ b/website/docs/language/expressions/function-calls.mdx
@@ -53,7 +53,7 @@ The expansion symbol is three periods (`...`), not a Unicode ellipsis character
 ## Using Sensitive Data as Function Arguments
 
 When using sensitive data, such as [an input variable](/terraform/language/values/variables#suppressing-values-in-cli-output)
-or [an output defined](/terraform/language/values/outputs#sensitive-suppressing-values-in-cli-output) as 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/website/docs/language/expressions/references.mdx b/website/docs/language/expressions/references.mdx
index f3febc16e0aa..954efdc828bb 100644
--- a/website/docs/language/expressions/references.mdx
+++ b/website/docs/language/expressions/references.mdx
@@ -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,
@@ -303,7 +303,7 @@ 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).
 
 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/website/docs/language/functions/ephemeralasnull.mdx b/website/docs/language/functions/ephemeralasnull.mdx
index 7e2092e63ed4..4c937983691a 100644
--- a/website/docs/language/functions/ephemeralasnull.mdx
+++ b/website/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/values/variables#exclude-values-from-state), [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/website/docs/language/functions/format.mdx b/website/docs/language/functions/format.mdx
index 0bf30208d508..70d40b70631e 100644
--- a/website/docs/language/functions/format.mdx
+++ b/website/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/website/docs/language/functions/plantimestamp.mdx b/website/docs/language/functions/plantimestamp.mdx
index 7b3a41e0d030..c76e9c399975 100644
--- a/website/docs/language/functions/plantimestamp.mdx
+++ b/website/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/website/docs/language/functions/terraform-applying.mdx b/website/docs/language/functions/terraform-applying.mdx
index 078bfc8c2f04..64d670a9c78a 100644
--- a/website/docs/language/functions/terraform-applying.mdx
+++ b/website/docs/language/functions/terraform-applying.mdx
@@ -1,7 +1,7 @@
 ---
-page_title: terraform.applying reference - Functions - Configuration Language  
-description: |-  
-  The terraform.applying symbol enables you to determine if Terraform is currently running an apply operation.  
+page_title: terraform.applying reference - Functions - Configuration Language
+description: |-
+  The terraform.applying symbol enables you to determine if Terraform is currently running an apply operation.
 ---
 
 # The `terraform.applying` symbol
@@ -19,7 +19,7 @@ locals {
   aws_read_role_arn  = "arn:aws:iam::XXXXX:role/terraform-read"
   aws_write_role_arn = "arn:aws:iam::XXXXX:role/terraform-full"
 
-  # We only need read-only credentials to plan, so if Terraform is applying 
+  # We only need read-only credentials to plan, so if Terraform is applying
   # we want to use our AWS role that allows us to write.
   role_arn = terraform.applying ? local.aws_write_role_arn : local.aws_read_role_arn
 }
@@ -28,7 +28,7 @@ locals {
 The `terraform.applying` symbol is an ephemeral value, meaning it is only available during Terraform operations and Terraform does not write this value to plan or state files. Additionally, you can only reference `terraform.applying` in 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 resources](/terraform/language/resources/ephemeral)  
-* In [ephemeral outputs](/terraform/language/values/outputs#ephemeral-avoid-storing-values-in-state-or-plan-files)
\ No newline at end of file
+* In [ephemeral variables](/terraform/language/values/variables#exclude-values-from-state)
+* In [local values](/terraform/language/values/locals#ephemeral-values)
+* In [ephemeral resources](/terraform/language/resources/ephemeral)
+* In [ephemeral outputs](/terraform/language/block/output#ephemeral)
diff --git a/website/docs/language/functions/timecmp.mdx b/website/docs/language/functions/timecmp.mdx
index 2c078a9b4e12..0d21b3210f43 100644
--- a/website/docs/language/functions/timecmp.mdx
+++ b/website/docs/language/functions/timecmp.mdx
@@ -43,9 +43,8 @@ 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 `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:
diff --git a/website/docs/language/meta-arguments/for_each.mdx b/website/docs/language/meta-arguments/for_each.mdx
index 7001fd08fdd4..a7db1fcfd1a6 100644
--- a/website/docs/language/meta-arguments/for_each.mdx
+++ b/website/docs/language/meta-arguments/for_each.mdx
@@ -110,7 +110,7 @@ including `uuid`, `bcrypt`, or `timestamp`, as their evaluation is deferred duri
 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 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,
diff --git a/website/docs/language/meta-arguments/lifecycle.mdx b/website/docs/language/meta-arguments/lifecycle.mdx
index b62bb5131fe5..3ae9fa4b7773 100644
--- a/website/docs/language/meta-arguments/lifecycle.mdx
+++ b/website/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#preconditions-and-postconditions) to learn more.
 
 ## Literal Values Only
 
diff --git a/website/docs/language/modules/develop/composition.mdx b/website/docs/language/modules/develop/composition.mdx
index d50679f41135..3b753038063b 100644
--- a/website/docs/language/modules/develop/composition.mdx
+++ b/website/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/website/docs/language/modules/develop/index.mdx b/website/docs/language/modules/develop/index.mdx
index aee54ee9e5ac..5081eb6d8570 100644
--- a/website/docs/language/modules/develop/index.mdx
+++ b/website/docs/language/modules/develop/index.mdx
@@ -32,7 +32,7 @@ Most commonly, modules use:
 
 * [Input variables](/terraform/language/values/variables) 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/website/docs/language/modules/develop/structure.mdx b/website/docs/language/modules/develop/structure.mdx
index 20ba5c945881..df07d7cd1e07 100644
--- a/website/docs/language/modules/develop/structure.mdx
+++ b/website/docs/language/modules/develop/structure.mdx
@@ -56,7 +56,7 @@ don't need to do any extra work to follow the standard structure.
   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.
+  [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/website/docs/language/modules/syntax.mdx b/website/docs/language/modules/syntax.mdx
index e23e26ada9bf..ca4facc2bbd8 100644
--- a/website/docs/language/modules/syntax.mdx
+++ b/website/docs/language/modules/syntax.mdx
@@ -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/website/docs/language/resources/ephemeral/reference.mdx b/website/docs/language/resources/ephemeral/reference.mdx
index 8c2324c854cb..7842e12ad611 100644
--- a/website/docs/language/resources/ephemeral/reference.mdx
+++ b/website/docs/language/resources/ephemeral/reference.mdx
@@ -5,7 +5,7 @@ description: Learn to define ephemeral blocks in Terraform configurations to kee
 
 # Ephemeral block configuration reference
 
-This topic provides reference information for the `ephemeral` block. 
+This topic provides reference information for the `ephemeral` block.
 
 -> **Note**: Ephemeral resources are available in Terraform v1.10 and later.
 
@@ -26,9 +26,9 @@ If an input argument of an ephemeral resource references a value that Terraform
 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. 
+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. 
+The following list outlines general field hierarchy, language-specific data types, and requirements in the `ephemeral` block.
 
 - [`ephemeral`](#ephemeral): map
   - [`attributes`](#ephemeral)
@@ -55,7 +55,7 @@ ephemeral resources:
 * 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 [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/website/docs/language/resources/provisioners/connection.mdx b/website/docs/language/resources/provisioners/connection.mdx
index 333b58e4c164..8822f7188c35 100644
--- a/website/docs/language/resources/provisioners/connection.mdx
+++ b/website/docs/language/resources/provisioners/connection.mdx
@@ -43,7 +43,7 @@ The configuration for a `connection` block may use ephemeral values, such as
 local values](/terraform/language/values/locals#ephemeral-values), [`ephemeral`
 variables](/terraform/language/values/variables#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/website/docs/language/resources/provisioners/syntax.mdx b/website/docs/language/resources/provisioners/syntax.mdx
index cf73194a1098..9e06a657e2c7 100644
--- a/website/docs/language/resources/provisioners/syntax.mdx
+++ b/website/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.
 
@@ -233,7 +233,7 @@ The configuration for a `provisioner` block may use ephemeral values, such as
 local values](/terraform/language/values/locals#ephemeral-values), [`ephemeral`
 variables](/terraform/language/values/variables#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.
@@ -242,7 +242,7 @@ logs.
 
 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).
+or [`sensitive` output values](/terraform/language/block/output#sensitive).
 Terraform suppresses sensitive values in all log output.
 
 ## Creation-Time Provisioners
diff --git a/website/docs/language/resources/syntax.mdx b/website/docs/language/resources/syntax.mdx
index 9cdf9b14105a..83a51f5a0811 100644
--- a/website/docs/language/resources/syntax.mdx
+++ b/website/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,10 +176,10 @@ 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 
+[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.
 
 ## Operation Timeouts
diff --git a/website/docs/language/stacks/reference/tfstack.mdx b/website/docs/language/stacks/reference/tfstack.mdx
index d7768341260d..4f6d1ce52684 100644
--- a/website/docs/language/stacks/reference/tfstack.mdx
+++ b/website/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,7 +66,7 @@ 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.
 
@@ -100,9 +100,9 @@ This section provides details about the fields you can configure in the `variabl
 
 ## `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.
@@ -199,9 +199,9 @@ A local value assigns a name to an expression, so you can use the name multiple
 
 ## `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/website/docs/language/state/remote-state-data.mdx b/website/docs/language/state/remote-state-data.mdx
index c3c230e6b274..dfee255a0773 100644
--- a/website/docs/language/state/remote-state-data.mdx
+++ b/website/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/website/docs/language/state/remote.mdx b/website/docs/language/state/remote.mdx
index 73875a2c17bc..45cc5847f8e8 100644
--- a/website/docs/language/state/remote.mdx
+++ b/website/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/website/docs/language/state/sensitive-data.mdx b/website/docs/language/state/sensitive-data.mdx
index 788654a0d61c..fd758b4215b2 100644
--- a/website/docs/language/state/sensitive-data.mdx
+++ b/website/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/values/variables#exclude-values-from-state), [outputs](/terraform/language/block/output#ephemeral), and [resources](/terraform/language/resources/ephemeral).
 
 ## Recommendations
 
diff --git a/website/docs/language/test-and-validate/validate.mdx b/website/docs/language/test-and-validate/validate.mdx
new file mode 100644
index 000000000000..1b864b7ed374
--- /dev/null
+++ b/website/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/values/variables).
+
+### 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/conditions).
+
+## 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/website/docs/language/tests/index.mdx b/website/docs/language/tests/index.mdx
index e15ef8af22aa..140e0d3c4d37 100644
--- a/website/docs/language/tests/index.mdx
+++ b/website/docs/language/tests/index.mdx
@@ -14,7 +14,7 @@ Terraform tests let authors validate that module configuration updates do not in
 
 By default, tests within Terraform create real infrastructure and can run assertions and validations against that infrastructure. This is analogous to integration testing because you are testing Terraform's core functionality by executing operations and validating the infrastructure Terraform creates.
 
-You can override the normal testing behavior by updating the `command` attribute within a [`run`](#run-blocks) block (examples below). By default, each `run` block executes with `command = apply` instructing Terraform to execute a complete `apply` operation against your configuration. Replacing the `command` value with `command = plan` instructs Terraform to _not_ create new infrastructure for this `run` block. This allows test authors to validate logical operations and custom conditions within their infrastructure in a process analogous to unit testing.
+You can override the normal testing behavior by updating the `command` attribute within a [`run`](#run-blocks) block (examples below). By default, each `run` block executes with `command = apply` instructing Terraform to execute a complete `apply` operation against your configuration. Replacing the `command` value with `command = plan` instructs Terraform to _not_ create new infrastructure for this `run` block. This allows test authors to validate logical operations and other conditions within their infrastructure in a process analogous to unit testing.
 
 Terraform v1.7.0 introduced the ability to mock data returned by the providers during a `terraform test` execution. This can be used to write more detailed and complete unit tests.
 
@@ -162,13 +162,13 @@ 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"`.
 
@@ -757,13 +757,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 +984,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 +1009,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/website/docs/language/v1-compatibility-promises.mdx b/website/docs/language/v1-compatibility-promises.mdx
index 75d560069532..d578b3f12960 100644
--- a/website/docs/language/v1-compatibility-promises.mdx
+++ b/website/docs/language/v1-compatibility-promises.mdx
@@ -79,7 +79,7 @@ providers) will retain their current functionality:
 * [`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
+  [`output`](/terraform/language/block/output), and
   [`locals`](/terraform/language/values/locals#declaring-a-local-value) blocks
   for declaring the various kinds of named values in a module.
 * [`terraform`](/terraform/language/terraform) blocks, including the nested
diff --git a/website/docs/language/values/index.mdx b/website/docs/language/values/index.mdx
index bd207554bfae..caa9354434c2 100644
--- a/website/docs/language/values/index.mdx
+++ b/website/docs/language/values/index.mdx
@@ -13,7 +13,7 @@ publishing named values.
 - [Input Variables](/terraform/language/values/variables) 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
diff --git a/website/docs/language/values/locals.mdx b/website/docs/language/values/locals.mdx
index e831cba02cf3..d659d9f2c6a7 100644
--- a/website/docs/language/values/locals.mdx
+++ b/website/docs/language/values/locals.mdx
@@ -17,7 +17,7 @@ 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.
+- [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/website/docs/language/values/outputs.mdx b/website/docs/language/values/outputs.mdx
deleted file mode 100644
index 858700414766..000000000000
--- a/website/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/website/docs/language/values/variables.mdx b/website/docs/language/values/variables.mdx
index 28769f72dc4e..a6738f370531 100644
--- a/website/docs/language/values/variables.mdx
+++ b/website/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/website/img/docs/validation-order-of-operations-dark.jpg b/website/img/docs/validation-order-of-operations-dark.jpg
new file mode 100644
index 000000000000..b747d2fe8fec
Binary files /dev/null and b/website/img/docs/validation-order-of-operations-dark.jpg differ
diff --git a/website/img/docs/validation-order-of-operations-light.jpg b/website/img/docs/validation-order-of-operations-light.jpg
new file mode 100644
index 000000000000..9c60ce210c03
Binary files /dev/null and b/website/img/docs/validation-order-of-operations-light.jpg differ