diff --git a/content/terraform-docs-common/redirects.jsonc b/content/terraform-docs-common/redirects.jsonc
index 5c8c395996..3b8388c663 100644
--- a/content/terraform-docs-common/redirects.jsonc
+++ b/content/terraform-docs-common/redirects.jsonc
@@ -427,22 +427,10 @@
     "destination": "/terraform/language/v:version/modules/configuration",
     "permanent": true
   },
-  // Moving meta-arguments content to dedicated meta-arguments reference page
-  {
-    "source": "/terraform/language/meta-arguments/:slug",
-    "destination": "/terraform/language/meta-arguments",
-    "permanent": true
-  },
-  // meta-arguments content pre PR-530 (anything 1.11 and older)
+  // add meta-arguments landing page for 1.11 and older
   {
     "source": "/terraform/language/v:version(1\\.(?:[1-9]|1[01])\\.x)/meta-arguments",
-    "destination": "/terraform/language/v:version/meta-arguments/depends_on",
-    "permanent": true
-  },
-    // meta-arguments content post PR-530 (anything 1.12 and above)
-  {
-    "source": "/terraform/language/v:version((?:1\\.(?:1[2-9]|[2-9]\\d)|[2-9]\\d*\\.\\d+)\\.x)/meta-arguments/:slug",
-    "destination": "/terraform/language/v:version/meta-arguments",
+    "destination": "/terraform/language/v:version/resources/syntax#meta-arguments",
     "permanent": true
   },
   // Reference rewrites phase 1 - latest
diff --git a/content/terraform/v1.12.x/data/language-nav-data.json b/content/terraform/v1.12.x/data/language-nav-data.json
index 0743392450..c9dd491491 100644
--- a/content/terraform/v1.12.x/data/language-nav-data.json
+++ b/content/terraform/v1.12.x/data/language-nav-data.json
@@ -328,7 +328,37 @@
   },
   {
     "title": "Meta-arguments",
-    "path": "meta-arguments"
+    "routes": [
+      {
+        "title": "Overview",
+        "path": "meta-arguments",
+        "alias": "actions"
+      },
+      {
+        "title": "count",
+        "path": "meta-arguments/count"
+      },
+      {
+        "title": "depends_on",
+        "path": "meta-arguments/depends_on"
+      },
+      {
+        "title": "for_each",
+        "path": "meta-arguments/for_each"
+      },
+      {
+        "title": "lifecycle",
+        "path": "meta-arguments/lifecycle"
+      },
+      {
+        "title": "provider",
+        "path": "meta-arguments/provider"
+      },
+      {
+        "title": "providers",
+        "path": "meta-arguments/providers"
+      }
+    ]
   },
   {
     "title": "Built-in resources",
diff --git a/content/terraform/v1.12.x/docs/language/block/check.mdx b/content/terraform/v1.12.x/docs/language/block/check.mdx
index 61bf3dcf66..26375c17d5 100644
--- a/content/terraform/v1.12.x/docs/language/block/check.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/check.mdx
@@ -122,7 +122,7 @@ The arguments within a `data` block are provider-specific. Refer to the [registr
 
 ### `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.
+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" {
@@ -135,13 +135,7 @@ check "unique_name" {
 }
 ```
 
-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) for additional information.
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `provider`
 
@@ -158,16 +152,7 @@ check "unique_name" {
 }
 ```
 
-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) for additional information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Supported meta-arguments: `depends_on` and `provider`.
-- Example: [Resource dependency](#resource-dependency).
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ## Examples
 
@@ -210,22 +195,4 @@ check "service_validation" {
    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"
- }
-}
-```
+```
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/block/data.mdx b/content/terraform/v1.12.x/docs/language/block/data.mdx
index c980349cdc..70e4b90fd1 100644
--- a/content/terraform/v1.12.x/docs/language/block/data.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/data.mdx
@@ -22,7 +22,7 @@ The `data` block supports the following configuration:
   - [`lifecycle`](#lifecycle) &nbsp block
     - [`precondition`](#precondition) &nbsp block
       - [`condition`](#precondition) &nbsp string
-      - [`error_message`](#precondition) & nbsp string
+      - [`error_message`](#precondition) &nbsp string
     - [`postcondition`](#postcondition) &nbsp block
       - [`condition`](#postcondition) &nbsp string
       - [`error_message`](#postcondition) &nbsp string
@@ -74,7 +74,7 @@ The provider developer determines which arguments you can define for a data sour
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -82,24 +82,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number.
-
-In blocks where `count` is set, Terraform exposes an additional `count` object. You can reference the object to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual instance of a data source created using the `count` meta-argument, use the `<TYPE>.<NAME>[INDEX]` syntax. For example, `data.aws_instance.server[0]` refers to the first instance of the `aws_instance` data source named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional for creating data sources. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the data source when a variable named `creator` is set to `true`. Refer to [​​Conditional Expressions]/terraform/language/expressions/conditionals) for more information.
-
-</Tip>
-
-The `count` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Number.
-- Default: None.
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
@@ -111,21 +94,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-When a data source configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create one resource before creating a data source, even though the resource and the data source are configured independently.
-
-Use the `depends_on` argument when the resource and data source do not reference each other. We recommend always including a comment to explain dependencies when using a `depends_on` argument.
-
-When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
-
-Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data sources associated with that module. Refer to [Resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and [Data resource dependencies](/terraform/language/resources/configure#specify-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency).
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -158,41 +127,12 @@ data "<TYPE>" "<LABEL>" {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
-
-Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
-
-The `for_each` argument does not implicitly convert lists or tuples to sets. To declare data source instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the data source instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-sensitive-data) for more information.
-
-The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the data source. The object has the following attributes:
-
-- `each.key`: Map key or list member that corresponds to an instance.
-- `each.value`: Map value that corresponds to an instance.
-
-Use the `<TYPE>.<NAME>[<KEY>]` syntax to access an instance of a data source created using `for_each`. For example, `data.azurerm_resource_group.rg["a_group"]` refers to an instance of the `data.azurrm_resource_group` resource named `rg` created off of the `a_group` key.
-
-The `for_each` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-
-#### Summary
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
-- Data type: Map or set of strings.
-- Default: None.
 
 ### `provider`
 
-The `provider` argument instructs Terraform to use an alternate provider configuration.
+The `provider` argument instructs Terraform to use an alternate provider configuration to provision the nested data source.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -200,16 +140,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the data source type, but you can create multiple provider configurations and use a non-default configuration for specific data sources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Using an alternate provider configuration](/terraform/language/block/provider#using-an-alternate-provider-configuration) for an example of 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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Reference.
-- Default: None.
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -230,12 +161,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 Configurations defined in the `lifecycle` block affect how Terraform constructs and traverses the dependency graph. You can only use literal values in the lifecycle block because Terraform processes them before it evaluates arbitrary expressions for a run.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates data sources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -252,26 +178,7 @@ resource {
 }
 ```
 
-The following arguments in the `precondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to proceed with an operation. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `precondition` blocks before evaluating the resource's configuration arguments. The `precondition` can take precedence over argument evaluation errors.
-
-Terraform evaluates precondition blocks after evaluating [`count`](#count) and [`for_each`](#for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
-
-You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
-
-Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
- #### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions).
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -288,140 +195,4 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-The following arguments in the `precondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. Postcondition failures prevent changes to other resources that depend on the failing resource.
-
-You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
-
-Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions).
-
-## Examples
-
-The following examples show how to write configuration for common use cases.
-
-### Specify a dependency
-
-In the following example, Terraform gets an AMI for use in the `aws_instance` resource after creating the `aws_subnet.example_subnet` resource:
-
-```hcl
-resource "aws_vpc" "example_vpc" {
-  cidr_block = "10.0.0.0/16"
-}
-
-resource "aws_subnet" "example_subnet" {
-  vpc_id     = aws_vpc.example_vpc.id
-  cidr_block = "10.0.1.0/24"
-}
-
-data "aws_ami" "example_ami" {
-  most_recent = true
-  owners      = ["amazon"]
-  filter {
-    name   = "name"
-    values = ["amzn2-ami-hvm-*"]
-  }
-  filter {
-    name   = "architecture"
-    values = ["x86_64"]
-  }
-  depends_on = [aws_subnet.example_subnet]
-}
-
-resource "aws_instance" "example_instance" {
-  ami           = data.aws_ami.example_ami.id
-  instance_type = "t2.micro"
-  subnet_id     = aws_subnet.example_subnet.id
-}
-```
-
-Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.
-
-### Select an alternate provider configuration
-
-In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
-
-```hcl
-provider "google" {
-  region = "us-central1"
-}
-
-provider "google" {
-  alias  = "europe"
-  region = "europe-west1"
-}
-
-data "google_compute_instance" "example" {
-  provider = google.europe
-  # ...
-}
-```
-
-### Apply custom conditions
-
-The following example includes several configurations that illustrate how to define `precondition` and `postcondition` arguments in the `lifecycle` meta-argument.
-
-The following `data` block instructs Terraform to retrieve the ID of the `ami-abc123` AMI:
-
-```hcl
-data "aws_ami" "example" {
-  owners = ["amazon"]
-  filter {
-    name   = "image-id"
-    values = ["ami-abc123"]
-  }
-}
-```
-
-In the following code, the `precondition` block specifies that the AMI ID retrieved from the `data` block must include `x86_64` as its `architecture` attribute. The `postcondition` block specifies that the EC2 instance must be allocated a public DNS hostname. When either condition is not met, Terraform returns the `error_message` for the failed condition:
-
-```hcl
-resource "aws_instance" "example" {
-  instance_type = "t3.micro"
-  ami           = data.aws_ami.example.id
-
-  lifecycle {
-    precondition {
-      condition     = data.aws_ami.example.architecture == "x86_64"
-      error_message = "The selected AMI must be for the x86_64 architecture."
-    }
-
-    postcondition {
-      condition     = self.public_dns != ""
-      error_message = "EC2 instance must be in a VPC that has public DNS hostnames enabled."
-    }
-  }
-}
-```
-
-The following `data` block retrieves the root storage volume connected to the `aws_instance.example` EC2 instance using the `volume_id` attribute. When a `data` resource verifies the result of a managed resource declared in the same configuration, you must define the check in a `postcondition` block in the resource so that Terraform waits for changes to the managed resource to complete before reading the data resource.
-
-```hcl
-data "aws_ebs_volume" "example" {
-  filter {
-    name = "volume-id"
-    values = [aws_instance.example.root_block_device[0].volume_id]
-  }
-  lifecycle {
-    # The EC2 instance will have an encrypted root volume.
-    postcondition {
-      condition     = self.encrypted
-      error_message = "The server's root volume is not encrypted."
-    }
-  }
-}
-output "api_base_url" {
-  value = "https://${aws_instance.example.private_dns}:8433/"
-}
-```
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
diff --git a/content/terraform/v1.12.x/docs/language/block/ephemeral.mdx b/content/terraform/v1.12.x/docs/language/block/ephemeral.mdx
index fe675daa56..feb7764397 100644
--- a/content/terraform/v1.12.x/docs/language/block/ephemeral.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/ephemeral.mdx
@@ -119,7 +119,7 @@ The provider developer determines which arguments you can define for an ephemera
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same ephemeral resource with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same ephemeral resource with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 <CodeBlockConfig hideClipboard>
 
@@ -131,25 +131,12 @@ ephemeral "<TYPE>" "<LABEL>" {
 
 </CodeBlockConfig>
 
-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 you set `count`, Terraform exposes an additional `count` object. You can reference the object within the ephemeral block to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual instance of an ephemeral resource created using the `count` meta-argument, use the `ephemeral.<TYPE>.<LABEL>[INDEX]` syntax. For example, `ephemeral.random_password.db_password[0]` refers to the first instance of the `random_password` ephemeral resource named `db_password`.
-
-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 ephemeral resources](#create-multiple-ephemeral-resources)
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
 The `depends_on` meta-argument specifies an upstream resource that the ephemeral resource depends on. When it creates a plan, Terraform sequences all operations on the upstream resource before performing operations on the ephemeral resource configured with the `depends_on` meta-argument.
 
-<CodeBlockConfig hideClipboard>
 
 ```hcl
 ephemeral "<TYPE>" "<LABEL>" {
@@ -157,20 +144,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-</CodeBlockConfig>
-
-When an ephemeral resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating an ephemeral resource, 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 in the same root module or its child modules. 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.
-
-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -196,34 +170,14 @@ ephemeral "<TYPE>" "<LABEL>" {
   for_each = {
     "<KEY>" = "<VALUE>"
   }
+}
 ```
 
 </Tab>
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct ephemeral resource. 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 of the values must be known when Terraform creates a plan. 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.
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the ephemeral resource instance and always discloses it in UI output, so sensitive values are not allowed.
-
-The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the ephemeral 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 `ephemeral.<TYPE>.<LABEL>[<KEY>]` syntax to access an instance of an ephemeral resource created using `for_each`. For example, `ephemeral.random_password.passwords["admin"]` refers to an instance of the `random_password` ephemeral resource named `passwords` created from the `admin` 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 ephemeral resources](#create-multiple-ephemeral-resources)
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -239,17 +193,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 
 </CodeBlockConfig>
 
-By default, Terraform automatically selects a provider based on the ephemeral resource type, but you can create multiple provider configurations and use a non-default configuration for specific ephemeral resources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument.
-
-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) for more information.
-
-#### Summary
-
-- Data type: Reference
-- Default: None
-- Example: [Use alternate provider configurations](#use-alternate-provider-configurations)
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -274,12 +218,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 You can include both `precondition` and `postcondition` blocks in the same `lifecycle` block, and you can define multiple `precondition` and `postcondition` blocks in the same `lifecycle` block.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block
-- Default: None
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -296,26 +235,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-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 ephemeral resource's configuration arguments. The `precondition` block errors 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 ephemeral resource.
-
-Refer to [Test and validate](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block
-- Default: None
-- Example: [Validate ephemeral resources](#validate-ephemeral-resources)
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -332,24 +252,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-The following arguments in the `postcondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `postcondition` blocks after planning and applying changes to the ephemeral resource. Postcondition failures prevent changes to other resources that depend on the failing ephemeral resource.
-
-You can include a `postcondition` and [`precondition` block](#precondition) in the same ephemeral resource.
-
-Refer to [Test and validate](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block
-- Default: None
-- Example: [Validate ephemeral resources](#validate-ephemeral-resources)
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.12.x/docs/language/block/import.mdx b/content/terraform/v1.12.x/docs/language/block/import.mdx
index 6409ec5e69..89b56ee268 100644
--- a/content/terraform/v1.12.x/docs/language/block/import.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/import.mdx
@@ -129,7 +129,6 @@ You cannot use the `identity` argument and [`id` argument](#id) in the same `imp
 - Default: None
 - Example: [Import a single resource](#import-a-single-resource)
 
-
 ### `for_each`
 
 The `for_each` meta-argument instructs Terraform to import similar resources without requiring separate configuration blocks.
@@ -161,17 +160,7 @@ import {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and imports an instance for each item in that map or set and produces an `each` object. You can use the values stored in `each.key` and `each.value` for the [`id` argument expression](#id). You can also use them in index expressions in the [`to` argument](#to). This allows Terraform to import multiple instances of a resource configuration.
-
-The inputs for the `for_each` argument must be known for the import plan operation to succeed. You cannot use a `for_each` argument when running `terraform plan` with the `-generate-config-out` option. Refer to [Generate configuration](/terraform/language/import/generating-configuration) for more information.
-
-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: [Import multiple resources](#import-multiple-resources) 
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -184,17 +173,7 @@ import {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the resource type, but you can configure multiple instances of the same provider with aliases and use a non-default configuration to import specific resources. 
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. 
-
-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) for more information.
-
-#### Summary
-
-- Data type: String
-- Default: None
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration) 
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.12.x/docs/language/block/module.mdx b/content/terraform/v1.12.x/docs/language/block/module.mdx
index 6267f4ade2..2ca383b177 100644
--- a/content/terraform/v1.12.x/docs/language/block/module.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/module.mdx
@@ -398,7 +398,7 @@ Refer to the documentation for the module for versioning mechanisms specific to
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same module with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same module with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 module "<LABEL>" {
@@ -406,31 +406,12 @@ module "<LABEL>" {
 }
 ```
 
-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 module created using the `count` meta-argument, use the `module.<NAME>[INDEX]` syntax. For example, `module.server[0]` refers to the first instance of the module named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional for creating modules. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the module resources 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 version of module resources](#create-multiple-versions-of-module-resources)
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `for_each`
 
 The `for_each` meta-argument instructs Terraform to provision similar modules without requiring separate configuration blocks for each resource.
 
-
 <Tabs>
 
 <Tab heading="List of values">
@@ -457,38 +438,7 @@ module "<LABEL>" {
 
 </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 modules based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the module instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-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 module. 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 `module.<NAME>[<KEY>]` syntax to access an instance of a module created using `for_each`. For example, `module.rg["a_group"]` refers to a module 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 version of module resources](#create-multiple-versions-of-module-resources)
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `providers`
 
@@ -502,18 +452,7 @@ module "<LABEL>" {
 }
 ```
 
-By default, a child module inherits the default provider configuration from its parent module, but you can create multiple provider configurations and use an alternate configuration for each module. Because a module is collection of different resources, some modules also let you specify an alternate configuration for different resources in the module. Refer to the module documentation for details.
-
-The `providers` argument is a map of key-value pairs that reference provider configurations. The key references the provider configuration name used in the child module. Refer to the module documentation for details on how to define keys. The value references the provider configuration name from the parent module. Use the `<PROVIDER>.<ALIAS>` syntax to reference alternate provider configurations in key values.
-
-The `providers` 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.
-- Default: None.
-- Example: [Apply different provider configurations for module resources](#apply-different-provider-configurations-for-module-resource)
-
+`providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
 
 ### `depends_on`
 
@@ -525,21 +464,7 @@ module "<LABEL>" {
 }
 ```
 
-When a module configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create one resource before creating a module, even though the resource and the module are configured independently.
-
-Use the `depends_on` argument when the resource and module do not reference each other. We recommend always including a comment to explain dependencies when using a `depends_on` argument.
-
-When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
-
-Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data modules associated with that module. Refer to [Specify resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and the [data resource dependencies documentation](/terraform/language/data-sources#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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency)
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.12.x/docs/language/block/output.mdx b/content/terraform/v1.12.x/docs/language/block/output.mdx
index 48f7ebf0f1..2415ccb8ba 100644
--- a/content/terraform/v1.12.x/docs/language/block/output.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/output.mdx
@@ -182,14 +182,7 @@ output "unique_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) for additional information.
-
-#### Summary
-
-- Data type: List of references
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `precondition`
 
diff --git a/content/terraform/v1.12.x/docs/language/block/removed.mdx b/content/terraform/v1.12.x/docs/language/block/removed.mdx
index b62c97c04a..a1d2241da1 100644
--- a/content/terraform/v1.12.x/docs/language/block/removed.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/removed.mdx
@@ -94,7 +94,7 @@ removed {
 
 By default, Terraform removes the resource from state and destroys the actual resource. Set `destroy` to `false` to remove the resource from state without destroying the actual resource. This allows you to hand off management responsibilities to another tool or team after using Terraform for the initial provisioning.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 #### Summary
 
diff --git a/content/terraform/v1.12.x/docs/language/block/resource.mdx b/content/terraform/v1.12.x/docs/language/block/resource.mdx
index f0cde37be8..358c62d5ff 100644
--- a/content/terraform/v1.12.x/docs/language/block/resource.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/resource.mdx
@@ -160,7 +160,7 @@ The provider developer determines which arguments you can define for a resource.
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 resource {
@@ -168,25 +168,7 @@ resource {
 }
 ```
 
-The value must be a whole number. You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number.
-
-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).
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
@@ -198,22 +180,7 @@ resource {
 }
 ```
 
-When a resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating another, even though the resources are configured independently.
-
-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/resources/configure#specify-resource-dependencies) <!-- placeholder link -->
-and [Data resource dependencies](/terraform/language/resources/configure#specify-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency).
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -246,37 +213,7 @@ resource {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
-
-Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
-
-The `for_each` argument does not implicitly convert lists or tuples to sets. To declare resource instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, be aware that most functions in Terraform will return a sensitive result if given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-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).
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -288,17 +225,7 @@ resource {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the resource type, but you can create multiple provider configurations and use a non-default configuration for specific resources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument.
-
-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) for more information.
-
-#### Summary
-
-- Data type: Reference.
-- Default: None.
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration).
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -323,12 +250,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `create_before_destroy`
 
@@ -342,18 +264,7 @@ resource {
 }
 ```
 
-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.
+`create_before_destroy` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `prevent_destroy`
 
@@ -367,16 +278,7 @@ resource {
 }
 ```
 
-Use this argument to prevent team members from accidentally replacing critical infrastructure, such as database instances.
-
-When `prevent_destroy` is enabled, 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.
-
-This rule doesn't prevent Terraform from destroying the resource if you remove the resource configuration. For instructions on how to remove a resource from state without destroying the actual resource, refer to [Remove a resource from state](/terraform/language/state/remove).
-
-#### Summary
-
-- Data type: Boolean.
-- Default: None.
+`prevent_destroy` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `ignore_changes`
 
@@ -390,19 +292,7 @@ resource {
 }
 ```
 
-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).
+`ignore_changes` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `replace_triggered_by`
 
@@ -416,23 +306,7 @@ resource {
 }
 ```
 
-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)
+`replace_triggered_by` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -449,26 +323,7 @@ resource {
 }
 ```
 
-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 [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions)
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -485,24 +340,7 @@ resource {
 }
 ```
 
-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 [Validate your configuration](/terraform/language/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)
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `connection`
 
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments.mdx
deleted file mode 100644
index 6a5f3fbf5f..0000000000
--- a/content/terraform/v1.12.x/docs/language/meta-arguments.mdx
+++ /dev/null
@@ -1,210 +0,0 @@
----
-page_title: Meta-arguments
-description: Meta-arguments are built-in Terraform arguments that determine how Terraform creates and manages resources.
----
-
-# Meta-arguments
-
-Meta-arguments are a class of arguments built into the Terraform configuration language that control how Terraform creates your infrastructure. This page provides an overview of the meta-arguments included with Terraform.
-
-## Introduction
-
-You can use meta-arguments in any type of resource, including resources created with `data` blocks. You can also use most meta-arguments in `module` blocks.
-
-The provider developer determines resource-specific arguments, but all resources support meta-arguments that let you manage resources' infrastructure lifecycle, including destruction behavior, preventing destruction, and establishing dependencies between resources. Terraform provides the following meta-arguments.
-
-## `depends_on`
-
-The `depends_on` meta-argument establishes dependencies between resources that do not directly reference one another. Use the `depends_on` argument to explicitly set the order in which Terraform creates resources.
-
-### Tutorials
-
-- [Create resource dependencies](/terraform/tutorials/configuration-language/dependencies)
-
-### Examples
-
-- [Specify a dependency during validation](/terraform/language/block/check#resource-dependency)
-- [Specify a dependency when querying a data source](/terraform/language/block/data#specify-a-dependency)
-- [Specify a dependency when calling a module](/terraform/language/block/module#specify-dependencies)
-- [Specify a dependency when outputting values](/terraform/language/block/output#explicit-dependencies)
-- [Specify a dependency during resource creation](/terraform/language/block/resource#specify-a-dependency)
-
-### Guidance
-
- - [Add dependencies](/terraform/language/data-sources#dependencies) when querying a data source
- - [Set dependencies](/terraform/language/modules/configuration#set-dependencies) in your module configuration
-
-### References
-
-- [`depends_on` argument in `check` blocks](/terraform/language/block/check#depends_on)
-- [`depends_on` argument in `data` blocks](/terraform/language/block/data#depends_on)
-- [`depends_on` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#depends_on)
-- [`depends_on` argument in `module` blocks](/terraform/language/block/module#depends_on)
-- [`depends_on` argument in `output` blocks](/terraform/language/block/output#depends_on)
-- [`depends_on` argument in `resource` blocks](/terraform/language/block/resource#depends_on)
-
-## `count`
-
-By default, Terraform manages one infrastructure object for each `resource` block. Terraform also creates single instances of a module per `module` block. You can use the `count` argument in `resource` and `module` blocks to create and manage multiple instances of each without writing a separate block for each instance.
-
-### How to choose between `count` and `for_each`
-
-The [`for_each` meta-argument](#for_each) performs a similar function to `count`, but lets you reference different values for each instance you create. Use the `count` argument when you want to create nearly identical instances. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
-Integer index. You cannot use both a `count` and ` for_each` argument in the same `resource` or `module` block.
-
-### Tutorials
-
-- [Manage similar resources with count](/terraform/tutorials/0-13/count)
-
-### Examples
-
-- [Create multiple ephemeral resources](/terraform/language/block/ephemeral#create-multiple-ephemeral-resources)
-- [Create multiple instances of module resources](/terraform/language/block/module#create-multiple-instances-of-module-resources)
-- [Create multiple instances of a resource](/terraform/language/block/resource#create-multiple-instances-of-a-resource)
-
-### Guidance
-
- - [Create multiple instances](/terraform/language/data-sources#multiple-instances) when querying a data source
- - [Create multiple instances](/terraform/language/modules/configuration#create-multiple-copies-of-modules) when calling modules
-
-### References
-
-- [`count` argument in `data` blocks](/terraform/language/block/data#count)
-- [`count` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#count)
-- [`count` argument in `module` blocks](/terraform/language/block/module#count)
-- [`count` argument in `resource` block ](/terraform/language/block/resource#count)
-
-## `for_each`
-
-By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. You can add the `for_each` block to your `resource`, `data`, `module`, and `ephemeral` blocks to create and manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each instance.
-
-The `for_each` accepts a map or a set that resolves to string values, but you can specify pure functions, such as `toset()` and `tomap()`, to create a map or set of string key-value pairs. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-Whether iterating over the keys of a map or set of strings, all values must be known.
-
-### How to choose between `for_each` and `count`
-
-The [`count` meta-argument](#count) performs a similar operation to `for_each`. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
-integer. Use the `count` argument when you want to create nearly identical instances.
-
-You cannot use both a `count` and ` for_each` argument in the same block.
-
-### Tutorials
-
-- [Manage similar resources with for each](/terraform/tutorials/configuration-language/for-each)
-
-### Examples
-
-- [Create multiple ephemeral resources](/terraform/language/block/ephemeral#create-multiple-ephemeral-resources)
-- [Import multiple existing resources](/terraform/language/block/import#import-multiple-resources)
-- [Create multiple instances of module resources](/terraform/language/block/module#create-multiple-instances-of-module-resources)
-- [Create multiple instances of a resource](/terraform/language/block/resource#create-multiple-instances-of-a-resource)
-
-### Guidance
-
-- [Creat multiple instances](/terraform/language/data-sources#multiple-instances) when querying a data source
-- [Create multiple instances](/terraform/language/modules/configuration#create-multiple-copies-of-modules) when calling modules
-
-### References
-
-- [`for_each` argument in `data` blocks](/terraform/language/block/data#for_each)
-- [`for_each` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#for_each)
-- [`for_each` argument in `module` blocks](/terraform/language/block/module#for_each)
-- [`for_each` argument in. `resource` blocks](/terraform/language/block/resource#for_each)
-
-## `provider`
-
-By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider .
-
-You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services.
-
-The `provider` argument is distinct from the `provider` block, which contains provider configuration settings. Refer to [Providers](/terraform/language/providers) for more information about the `provider` block.
-
-### Examples
-
-- [Specify an alternate provider configuration](/terraform/language/block/data#select-an-alternate-provider-configuration) for a data source
-- [Specify an alternate provider configuration](/terraform/language/block/ephemeral#use-alternate-provider-configurations) for an ephemeral resource
-- [Select an alternate provider configuration](/terraform/language/block/import#select-an-alternate-provider-configuration) for imported resources
-- [Select a provider without a default configuration](/terraform/language/block/provider#provider-without-a-default-configuration)
-- [Select an alternative provider configuration](/terraform/language/block/resource#select-an-alternate-provider-configuration) for resources
-
-### Guidance
-
-- [Providers](/terraform/language/providers)
-- [Select an alternate provider configuration](/terraform/language/data-sources#alternate-provider-configurations) when querying a data source
-
-### References
-
-- [`provider` argument in `check` blocks](/terraform/language/block/check#provider)
-- [`provider` argument in `data` blocks](/terraform/language/block/data#provider)
-- [`provider` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#provider)
-- [`provider` argument in `import` block ](/terraform/language/block/import#provider)
-- [`provider` argument in `resource` blocks](/terraform/language/block/resource#provider)
-
-## `providers`
-
-By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources.
-
-Some modules may contain resources that require different providers. As a result, you can specify alternate configurations for each provider supported by the module. Refer to the module documentation for details about the providers it supports.
-
-When you add a `providers` argument, child modules only have access to the provider configurations you specify. Use the `providers` argument in the following scenarios:
-
-- To use an alternate provider configuration for a child module.
-- To configure a module that requires multiple configurations of the same provider.
-
-### Examples
-
-- [Apply different provider configurations](/terraform/language/block/module#apply-different-provider-configurations-for-module-resources)  for module resources
-
-### Guidance
-
-- [Provider Aliases Within Modules](/terraform/language/modules/develop/providers#provider-aliases-within-modules)
-
-### Reference
-
-- [`providers` argument in `module` blocks](/terraform/language/block/module#providers)
-- [Providers module development documentation](/terraform/language/modules/develop/providers)
-
-## `lifecycle`
-
-Terraform performs the following operations when you apply a configuration:
-
-1. Creates resources defined in the configuration that are not associated with a real infrastructure object in the state.
-1. Destroys resources that exist in the state but not in the configuration.
-1. Updates in-place resources whose arguments have changed.
-1. Destroys and re-create resources whose arguments have changed but that Terraform cannot update in-place because of remote API limitations.
-
-The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details. The following table describes support for each `lifecycle` rule:
-
-
-| Rule | Description | Terraform block |
-| --- | --- | --- |
-| `create_before_destroy` | Terraform creates a replacement resource before destroying the current resource. | `resource` |
-| `prevent_destroy` | Terraform rejects operations to destroy the resource and returns an error. This rule doesn't prevent Terraform from destroying the resource if you remove the resource configuration. For instructions on how to remove a resource from state without destroying the actual resource, refer to [Remove a resource from state](/terraform/language/state/remove). | `resource` |
-| `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. | `resource` |
-| `replace_triggered_by` | Terraform replaces the resource when any of the referenced resources or specified attributes change. | `resource` |
-| `precondition` | Specifies a condition that Terraform evaluates before creating the resource. | `data`, `ephemeral`, `resource` |
-| `postcondition` | Specifies a condition that Terraform evaluates after creating the resource. | `data`, `ephemeral`, `resource` |
-| `destroy` | Set to `false` to remove a resource from state without destroying the actual infrastructure resource. You can only use this rule in the `removed` block. | `removed` |
-
-### Tutorials
-
-- [Manage resource lifecycle](/terraform/tutorials/state/resource-lifecycle)
-
-### Examples
-
-- [Apply custom conditions to data sources](/terraform/language/block/data#apply-custom-conditions)
-- [Ignore attribute changes](/terraform/language/block/resource#ignore-attribute-changes)
-- [Specify triggers that replace resource](/terraform/language/block/resource#specify-triggers-that-replace-resources)
-- [Apply custom conditions to resources](/terraform/language/block/resource#apply-custom-conditions)
-
-### Guidance
-
-- [Validate your configuration](/terraform/language/validate#preconditions-and-postconditions)
-
-### References
-
-- [`lifecycle` argument in `data` blocks](/terraform/language/block/data#lifecycle)
-- [`lifecycle` argument in `ephemeral` block ](/terraform/language/block/ephemeral#lifecycle)
-- [`lifecycle` argument in `removed` blocks](/terraform/language/block/removed#lifecycle)
-- [`lifecycle` argument in `resource` blocks](/terraform/language/block/resource#lifecycle)
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/count.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/count.mdx
new file mode 100644
index 0000000000..7feef02f72
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/count.mdx
@@ -0,0 +1,125 @@
+---
+page_title: count meta-argument reference
+description: Learn how the `count` meta-argument works in Terraform configuration.
+---
+
+# `count` reference
+
+By default, each [`resource` block](/terraform/language/block/resource) and [`ephemeral` block](/terraform/language/block/ephemeral) configures one real infrastructure object. Similarly, a [`module` block](/terraform/language/block/module) includes a child module's contents into the configuration one time. 
+
+Use the `count` meta-argument to manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each object. When a `resource` or `module` block includes a `count` argument whose value is a whole number, Terraform creates that many instances.
+
+## Usage
+
+The `count` meta-argument accepts a whole number and creates that many instances of the resource or module. Each instance has a distinct infrastructure object associated with it, and each is separately created, updated, or destroyed when the configuration is applied. 
+
+<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>
+
+
+In the folllowing example, Terraform creates four `aws_instance.server` resources that use the same AMI and instance type. The `count.index` attribute gives each `aws_instance` a unique `Name` tag:
+
+```hcl
+resource "aws_instance" "server" {
+  count = 4 # create four similar EC2 instances
+
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+
+  tags = {
+    Name = "Server ${count.index}"
+  }
+}
+```
+
+### Expressions in `count`
+
+The `count` meta-argument accepts numeric [expressions](/terraform/language/expressions), but unlike most arguments, the `count` value must be known before Terraform performs any remote resource operations. `count` cannot refer to any resource attributes that are only known after a configuration is applied, such as a unique ID generated by the remote API when an object is created.
+
+### Referring to instances
+
+In blocks where `count` is set, Terraform creates an additional `count` object that you can use in expressions to modify the configuration of each instance. This object has the following attribute:
+
+- `count.index`: The distinct index number starting with `0` corresponding to this instance.
+
+Terraform makes a distinction between the block containing the `count` argument and the instances associated with it. Terraform identifies instances index number starting at `0`.
+
+- `<TYPE>.<NAME>` or `module.<NAME>`, for example, `aws_instance.server` refers to the resource block.
+- `<TYPE>.<NAME>[<INDEX>]` or `module.<NAME>[<INDEX>]`, for example, `aws_instance.server[0]` and
+  `aws_instance.server[1]` refer to individual instances.
+
+This is different from resources and modules without `count` or [`for_each`](/terraform/language/meta-arguments/for_each), which can be referenced without an index or key.
+
+Similarly, resources from child modules with multiple instances are prefixed
+with `module.<NAME>[<KEY>]` when displayed in plan output and elsewhere in the UI.
+For a module without `count` or `for_each`, the address will not contain
+the module index as the module's name suffices to reference the module.
+
+Within nested [`provisioner`](/terraform/language/block/resource#provisioner) or [`connection`](/terraform/language/block/resource#connection) blocks, the special `self` object refers to the current resource instance, not the `resource` block as a whole.
+
+### How to choose between `count` and `for_each`
+
+`count` and [`for_each`](/terraform/language/meta-arguments/for_each) perform a similar function. Use the `count` argument when you want to create nearly identical instances. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
+integer index. You cannot use both a `count` and ` for_each` argument in the same `resource` or `module` block.
+
+## Supported constucts
+
+You can use `count` in the following Terraform configuration blocks:
+
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Example use cases
+
+The following use cases describe common patterns for the `count` argument.
+
+### Create multiple instances of module resources
+
+In the following example, Terraform creates three EC2 instances, each with a unique name from the `instance_names` list:
+
+```hcl
+locals {
+  instance_names = ["web", "api", "batch"]
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  count   = length(local.instance_names)
+
+  name           = local.instance_names[count.index]
+  ami            = data.aws_ami.latest_amazon_linux.id
+  instance_type  = "t2.micro"
+
+  depends_on = [aws_s3_bucket.example]
+}
+
+```
+
+### Create multiple instances of a resource
+
+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}"
+  }
+}
+```
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/depends_on.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/depends_on.mdx
new file mode 100644
index 0000000000..46a5366397
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/depends_on.mdx
@@ -0,0 +1,194 @@
+---
+page_title: depends_on meta-argument reference
+description: Learn how the `depends_on` meta-argument works in Terraform configuration.
+---
+
+# `depends_on` reference
+
+Use the `depends_on` meta-argument to handle hidden resource or module dependencies that Terraform cannot automatically infer. You only need to explicitly specify a dependency when a resource or module relies on another resource's behavior but does not access any of that resource's data in its arguments. 
+
+## Usage
+
+You can use the `depends_on` meta-argument in `module` blocks and in all `resource` blocks, regardless of resource type. 
+
+It requires a list of references to other resources or child modules in the same calling module. This list cannot include arbitrary expressions because the `depends_on` value must be known before Terraform knows resource relationships and thus before it can safely evaluate expressions. 
+
+In the following example, the `depends_on` argument instructs Terraform to handle a hidden dependency on the `aws_iam_instance_profile.example` resource.
+
+```hcl
+resource "aws_iam_role" "example" {
+  name = "example"
+
+  # assume_role_policy is omitted for brevity in this example. Refer to the
+  # documentation for aws_iam_role for a complete example.
+  assume_role_policy = "..."
+}
+
+resource "aws_iam_instance_profile" "example" {
+  # Because this expression refers to the role, Terraform automatically
+  # infers that the role must be created first.
+  role = aws_iam_role.example.name
+}
+
+resource "aws_iam_role_policy" "example" {
+  name   = "example"
+  role   = aws_iam_role.example.name
+  policy = jsonencode({
+    "Statement" = [{
+      # This policy allows software running on the EC2 instance to
+      # access the S3 API.
+      "Action" = "s3:*",
+      "Effect" = "Allow",
+    }],
+  })
+}
+
+resource "aws_instance" "example" {
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+
+  # Terraform can infer from this that the instance profile must
+  # be created before the EC2 instance.
+  iam_instance_profile = aws_iam_instance_profile.example
+
+  # However, if software running in this EC2 instance needs access
+  # to the S3 API in order to boot properly, there is also a 
+  # dependency on the aws_iam_role_policy that Terraform cannot
+  # automatically infer, so you must declare it explicitly:
+  depends_on = [
+    aws_iam_role_policy.example
+  ]
+}
+```
+
+## Processing and planning consequences
+
+The `depends_on` meta-argument instructs Terraform to complete all actions on the dependency object, including read operations, before performing operations on the object declaring the dependency. When the dependency object is an entire module, `depends_on` affects the order in which Terraform processes all of the resources and data sources associated with that module. Refer to the documentation on [specifying resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and [data resource dependencies](/terraform/language/data-sources#dependencies) for more details.
+
+You should only use `depends_on` as a last resort because it can cause Terraform to create more conservative plans that replace more resources than necessary. For example, Terraform may treat more values as unknown `"(known after apply)"` because it is uncertain what changes will occur on the upstream object. This is especially likely when you use `depends_on` for modules.
+
+Instead of `depends_on`, we recommend using [expression references](/terraform/language/expressions/references) to imply dependencies when possible. Expression references let Terraform understand which value the reference derives from and avoid planning changes if that particular value hasn’t changed, even if other parts of the upstream object have planned changes.
+
+## Supported constructs
+
+You can use `depends_on` in the following Terraform configuration blocks:
+
+- [`check` blocks](/terraform/language/block/resource)
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`output` blocks](/terraform/language/block/output)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Example use cases 
+
+The following use cases describe common patterns for the `depends_on` argument.
+
+### Specify a dependency during validation
+
+Add a `depends_on` argument to a `data` block nested in a [`check` block](/terraform/language/block/check) validation when the data source depends on another resource but doesn't reference the resource directly.  
+
+`check` blocks validate infrastructure outside of the typical resource lifecycle. You can nest a `data` block inside a `check` block to fetch information that you can reference in an `assert` block. By adding a `depends_on` argument to the `data` block nested in a `check` block requires, Terraform retrieves the necessary data before running the validation.
+
+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. 
+
+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"
+ }
+}
+```
+
+### Create a database service that other services depend on 
+
+In the following example, Terraform must launch the `aws_db_instance` service first so that `aws_instance` can connect to it:
+
+```hcl
+provider "aws" {
+  region = "us-east-2"
+}
+
+data "aws_ami" "ubuntu" {
+  most_recent = true
+
+  filter {
+    name   = "name"
+    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
+  }
+
+  filter {
+    name   = "virtualization-type"
+    values = ["hvm"]
+  }
+
+  owners = ["099720109477"] # Canonical
+}
+
+resource "aws_db_instance" "api" {
+  allocated_storage   = 10
+  db_name             = "api_db"
+  engine              = "postgres"
+  engine_version      = "17.4"
+  instance_class      = "db.t3.micro"
+  username            = "foo"
+  password            = "foobarbaz"
+  skip_final_snapshot = true
+}
+
+resource "aws_instance" "api" {
+  ami           = data.aws_ami.ubuntu.id
+  instance_type = "t3.micro"
+
+  depends_on = [aws_db_instance.api]
+}
+```
+
+### Specify a dependency on the parent module
+
+In the following example, Terraform only creates the EC2 instance module after creating the S3 bucket resource:
+
+```hcl
+resource "aws_s3_bucket" "example" {
+  bucket = "my-example-bucket-12345"
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  name    = "example-instance"
+  ami           = data.aws_ami.latest_amazon_linux.id
+  instance_type = "t2.micro"
+
+  depends_on = [aws_s3_bucket.example]
+}
+```
+
+### Specify a dependency when outputting values
+
+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.
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/for_each.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/for_each.mdx
new file mode 100644
index 0000000000..3b4d3c6a8f
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/for_each.mdx
@@ -0,0 +1,304 @@
+---
+page_title: for_each meta-argument reference
+description: Learn how the `for_each` meta-argument works in Terraform configuration.
+---
+
+# `for_each` reference
+
+By default, [`resource` block](/terraform/language/block/resource) configures one real infrastructure object. Similarly, a [`module` block](/terraform/language/block/module) includes a child module's contents into the configuration one time. 
+
+Use the `for_each` meta-argument to manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each object. When a `resource`, `module`, or `ephemeral` block includes a `for_each` argument, Terraform creates an instance for each member of the list or map specified as the value.
+
+## Usage
+
+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. All values that the `for_each` argument iterates over must be known before Terraform performs any remote resource operations. Specifying references to resource attributes that are only known after a configuration is applied, such as a unique ID generated by the remote API when an object is created, will result in an error.
+
+The following example creates two `azurerm_resource_group` resources 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 `aws_iam_user` resources 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
+}
+```
+
+### Limitations on values
+
+The keys of the map or all values in a set of strings must be known values. Otherwise, Terraform returns an error message that `for_each` has dependencies that cannot be determined before apply and that a `-target` may be needed.
+
+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.
+
+You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Sensitive values are not allowed because Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
+
+If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. Refer to [Using sensitive data as function arguments](/terraform/language/expressions/function-calls#using-sensitive-data-as-function-arguments) for more information.
+
+In many cases, you can use a `for` expression to achieve similar results. 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` with `toset([for k,v in local.map : k])`. Refer to [Manage sensitive data](/terraform/language/manage-sensitive-data) for more information.
+
+### Expressions in `for_each`
+
+The `for_each` meta-argument accepts map or set [expressions](/terraform/language/expressions), but unlike most arguments, the value must be known before Terraform performs any remote resource actions. As a result, `for_each` can't refer to any resource attributes that aren't known until after a
+configuration is applied, such as a unique ID generated by the remote API when
+an object is created.
+
+The `for_each` value must be a map or set with one element per desired resource
+instance. To use a sequence as the `for_each` value, you must use an expression
+that explicitly returns a set value, such as the [`toset` function](/terraform/language/functions/toset). 
+
+To prevent unexpected behavior during conversion, 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).
+
+### Referring to instances
+
+In blocks where `for_each` is set, Terraform creates an additional `each` object that you can use in expressions to modify the configuration of each instance.
+This object has the following attributes:
+
+- `each.key`: The map key or set member corresponding to this instance.
+- `each.value`: The map value corresponding to this instance. If a set is provided, this is the same as `each.key`.
+
+Terraform makes a distinction between the block containing the `for_each` argument and the instances associated with it. Terraform identifies instances by the map key or set member using the value provided to `for_each`.
+
+- `<TYPE>.<NAME>` or `module.<NAME>`: For example, `azurerm_resource_group.rg` refers to the block.
+- `<TYPE>.<NAME>[<KEY>]` or `module.<NAME>[<KEY>]`: For example, `azurerm_resource_group.rg["a_group"]` and `azurerm_resource_group.rg["another_group"]` refer to individual instances.
+
+This is different from resources and modules without [`count`](/terraform/language/meta-arguments/count) or `for_each`, which can be
+referenced without an index or key.
+
+Similarly, resources from child modules with multiple instances are prefixed
+with `module.<NAME>[<KEY>]` when displayed in plan output and elsewhere in the UI.
+For a module without `count` or `for_each`, the address does not contain
+the module index as the module's name suffices to reference the module.
+
+Within nested [`provisioner`](/terraform/language/block/resource#provisioner) or [`connection`](/terraform/language/block/resource#connection) blocks, the special `self` object refers to the current resource instance, not the resource block as a whole.
+
+### Chain `for_each` between resources
+
+Because a resource using `for_each` appears as a map of objects when used in
+expressions elsewhere, you can directly use one resource as the `for_each`
+of another in situations where there is a one-to-one relationship between
+two sets of objects.
+
+For example, in AWS an `aws_vpc` object is commonly associated with a number
+of other objects that provide additional services to that VPC, such as an
+internet gateway. If you are declaring multiple VPC instances using `for_each`
+then you can chain that `for_each` into another resource to declare an
+internet gateway for each VPC:
+
+```hcl
+variable "vpcs" {
+  type = map(object({
+    cidr_block = string
+  }))
+}
+
+resource "aws_vpc" "example" {
+  # One VPC for each element of var.vpcs
+  for_each = var.vpcs
+
+  # each.value here is a value from var.vpcs
+  cidr_block = each.value.cidr_block
+}
+
+resource "aws_internet_gateway" "example" {
+  # One Internet Gateway per VPC
+  for_each = aws_vpc.example
+
+  # each.value here is a full aws_vpc object
+  vpc_id = each.value.id
+}
+
+output "vpc_ids" {
+  value = {
+    for k, v in aws_vpc.example : k => v.id
+  }
+
+  # The VPCs aren't fully functional until their
+  # internet gateways are running.
+  depends_on = [aws_internet_gateway.example]
+}
+```
+
+This chain pattern explicitly and concisely declares the relationship
+between the internet gateway instances and the VPC instances, which tells
+Terraform to expect the instance keys for both to always change together,
+and typically also makes the configuration easier to understand for human
+maintainers.
+
+### Using sets
+
+The Terraform language doesn't have a literal syntax for [set values](/terraform/language/expressions/type-constraints#collection-types), but you can use the [`toset` function](/terraform/language/functions/toset) to explicitly convert a list of strings to a set:
+
+```hcl
+locals {
+  subnet_ids = toset([
+    "subnet-abcdef",
+    "subnet-012345",
+  ])
+}
+
+resource "aws_instance" "server" {
+  for_each = local.subnet_ids
+
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+  subnet_id     = each.key # note: each.key and each.value are the same for a set
+
+  tags = {
+    Name = "Server ${each.key}"
+  }
+}
+```
+
+Conversion from list to set discards the ordering of the items in the list and
+removes any duplicate elements. For example, `toset(["b", "a", "b"])` produces a set
+containing only `"a"` and `"b"` in no particular order and discards the second `"b"`.
+
+If you are writing a module with an [input variable](/terraform/language/values/variables) that
+will be used as a set of strings for `for_each`, you can set its type to
+`set(string)` so that you don't need an explicit type conversion:
+
+```hcl
+variable "subnet_ids" {
+  type = set(string)
+}
+
+resource "aws_instance" "server" {
+  for_each = var.subnet_ids
+  #...
+}
+```
+
+### How to choose between `for_each` and `count`
+
+The [`count` meta-argument](#count) performs a similar operation to `for_each`. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
+integer. Use the `count` argument when you want to create nearly identical instances.
+
+You cannot use both a `count` and ` for_each` argument in the same block.
+
+## Supported constucts
+
+You can use `for_each` in the following Terraform configuration blocks:
+
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Examples
+
+The following use cases describe common patterns for the `for_each` argument.
+
+### Create multiple ephemeral resources
+
+In the following example, the `for_each` argument creates multiple passwords for different database environments:
+
+<CodeBlockConfig highlight="6, 18">
+
+```hcl
+locals {
+  environments = toset(["dev", "staging", "prod"])
+}
+
+ephemeral "random_password" "db_passwords" {
+  for_each = local.environments
+
+  length           = 16
+  override_special = "!#$%&*()-_=+[]{}<>:?"
+}
+
+resource "aws_db_instance" "databases" {
+  for_each = local.environments
+
+  identifier                = "${each.key}-database"
+  db_name                   = "${each.key}db"
+  username                  = "dbadmin"
+  password_wo               = ephemeral.random_password.db_passwords[each.key].result
+ # …
+}
+```
+
+</CodeBlockConfig>
+
+The `ephemeral` block creates a `random_password` ephemeral resource for each environment in the `local.environments` set. The `aws_db_instance` resource then uses the generated passwords for each database instance.
+
+Terraform does not store the generated `db_passwords` values, but you can capture them in another resource to ensure those values are not lost. For an example of generating, storing, retrieving, and using an ephemeral password, refer to [write-only arguments](/terraform/language/manage-sensitive-data/write-only#set-and-store-an-ephemeral-password-in-aws-secrets-manager).
+
+### Create multiple instances of module resources
+
+In the following example, Terraform creates one EC2 instance for each key in `local.instance_configs`, allowing you to customize properties per instance:
+
+```hcl
+locals {
+  instance_configs = {
+    "example-instance-1" = { instance_type = "t2.micro" }
+    "example-instance-2" = { instance_type = "t2.small" }
+    "example-instance-3" = { instance_type = "t2.medium" }
+  }
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  for_each = local.instance_configs
+
+  name           = each.key
+  ami            = data.aws_ami.latest_amazon_linux.id
+  instance_type  = each.value.instance_type
+
+  depends_on = [aws_s3_bucket.example]
+}
+```
+
+### Create multiple instances of a resource
+
+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>
+
+### Import multiple resources
+
+You can use `for_each` to import multiple resources. Refer to the [`import` block documentation](/terraform/language/block/import#import-multiple-resources) for an example.
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/index.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/index.mdx
new file mode 100644
index 0000000000..0cf212dcd5
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/index.mdx
@@ -0,0 +1,43 @@
+---
+page_title: Meta-arguments
+description: Meta-arguments are built-in Terraform arguments that determine how Terraform creates and manages resources.
+---
+
+# Meta-arguments
+
+Meta-arguments are a class of arguments built into the Terraform configuration language that control how Terraform creates and manages your infrastructure. You can use meta-arguments in any type of resource. You can also use most meta-arguments in `module` blocks.
+
+The provider developer determines resource-specific arguments, but all resources support meta-arguments that let you manage resources' infrastructure lifecycle, including destruction behavior, preventing destruction, and establishing dependencies between resources. Terraform provides the following meta-arguments.
+
+## `depends_on`
+
+The `depends_on` meta-argument instructs Terraform to complete all actions on the dependency object, including `read` operations, before performing actions on the object declaring the dependency. Use the `depends_on` argument to explicitly set the order in which Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details.
+
+> **Hands-on**: Complete the [Create resource dependencies](/terraform/tutorials/configuration-language/dependencies) tutorial to learn how to declare dependencies.
+
+## `count`
+
+By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. Terraform also creates single instances of a module per `module` block. You can add the `count` argument to `resource`, `module`, and `ephemeral` blocks to create and manage multiple instances of each without writing a separate block for each instance. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details.
+
+> **Hands-on**: Complete the [Manage similar resources with count](/terraform/tutorials/0-13/count) tutorial to learn how to create multiple instances of a resource.
+
+## `for_each`
+
+By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. You can add the `for_each` block to your `resource`, `data`, `module`, and `ephemeral` blocks to create and manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each instance. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details.
+
+> **Hands-on**: Complete the [Manage similar resources with for each](/terraform/tutorials/configuration-language/for-each) tutorial to learn how to create multiple instances of a resource.
+
+## `lifecycle`
+
+The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details. 
+
+> **Hands-on**: Complete the [Manage resource lifecycle](/terraform/tutorials/state/resource-lifecycle) tutorial to learn how to manage the lifecycle of your infrastructure resources. 
+
+## `provider`
+
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details.
+
+## `providers`
+
+By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details.
+
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/lifecycle.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/lifecycle.mdx
new file mode 100644
index 0000000000..2b96af2b04
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/lifecycle.mdx
@@ -0,0 +1,329 @@
+---
+page_title: lifecycle meta-argument reference
+description: How to configure the lifecycle meta-argument rules in Terraform--create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by, precondition, postcondition, destroy
+---
+
+# `lifecycle` reference
+ 
+Terraform performs the following operations when you apply a configuration:
+
+1. Creates resources defined in the configuration that are not associated with a real infrastructure object in the state.
+1. Destroys resources that exist in the state but not in the configuration.
+1. Updates resources in-place whose arguments have changed.
+1. Destroys and re-create resources whose arguments have changed but that Terraform cannot update in-place because of remote API limitations.
+
+The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. 
+
+## Usage
+
+All `lifecycle` settings affect how Terraform constructs and traverses
+the dependency graph. As a result, only literal values can be used because
+the processing happens too early for arbitrary expression evaluation.
+
+Support for each lifecycle rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details. 
+
+Depending on the block you are configuring, you may be able to use one or more of the following rules.
+
+### `create_before_destroy` 
+
+By default, when Terraform must change a resource argument that cannot be updated in-place due to remote API limitations, Terraform destroys the existing object and then create a new replacement object with the new configured arguments. Use the `create_before_destroy` rule to instruct Terraform to create a replacement resource before destroying the current resource. 
+
+This is an opt-in behavior because many remote object types have unique name requirements or other constraints that must be accommodated for both a new and an old object to exist concurrently. Some resource types offer special options to append a random suffix onto each object name to avoid collisions, for example. Terraform CLI cannot automatically activate such features, so you must understand the constraints for each resource type before using `create_before_destroy` with it.
+
+#### `create_before_destroy` and resource dependencies
+
+Terraform propagates and applies `create_before_destroy` behavior to all resource dependencies. For example: 
+
+- `create_before_destroy` is enabled on resource `A` but not on resource `B`.
+- Because resource `A` is dependent on resource `B`, Terraform enables `create_before_destroy` for resource `B` implicitly by default and stores it to the state file. 
+
+As a result, you cannot override `create_before_destroy`
+to `false` on resource `B` because that would imply dependency cycles in the graph.
+
+When the resource contains a provisioner that runs during the `destroy` operation,  setting `create_before_destroy` to `true` also prevents the provisioner from running. 
+
+You can use `create_before_destroy` in [`resource`](/terraform/language/block/resource) blocks. 
+
+
+### `prevent_destroy` 
+
+When `prevent_destroy` is set to `true`, Terraform rejects plans that would destroy the infrastructure object associated with the resource and returns an error. The argument must be present in the configuration. This rule doesn't prevent Terraform from destroying a resource if you remove its configuration. Refer to [Remove a resource from state](/terraform/language/state/remove) for instructions on how to remove a resource from state without destroying the actual resource.
+
+Use this rule as protection against accidentally replacing objects that may be costly to reproduce, such as database instances. Enabling `prevent_destory`, however, makes certain configuration changes impossible to apply
+and prevents the `terraform destroy` command from operating once such objects are created. Use `prevent_destroy` sparingly.
+
+You can use `prevent_destroy` in in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `ignore_changes` 
+
+By default, Terraform detects any difference in the current settings of a real infrastructure object and plans to update the remote object to match configuration. Use the `ignore_changes` argument when a resource is created with references to data that may change in the future, but should not affect the resource after its creation. 
+
+In some rare cases, a remote object's settings are modified by processes outside of Terraform, which Terraform attempts to resolve on the next run. To let Terraform share management responsibilities of a single object with a separate process, the `ignore_changes` meta-argument specifies resource attributes that Terraform should ignore when planning updates to the associated remote object.
+
+Terraform considers the arguments corresponding to the given attribute names when planning a `create` operation, but are ignored when planning an
+`update` operation. The arguments are the relative address of the attributes in the resource. You can reference map and list elements using index notation,
+such as `tags["Name"]` and `list[0]`.
+
+In the following example, Terraform ignores changes to `tags` so that a management agent can update them based on a rule set managed elsewhere:
+
+```hcl
+resource "aws_instance" "example" {
+   # ...
+   lifecycle {
+      ignore_changes = [
+         tags
+      ]  
+   }
+}
+```
+
+Instead of a list of items, you can use the `all` keyword to instruct
+Terraform to ignore all attributes. As a result, Terraform can
+create and destroy the remote object but will never propose updates to it.
+
+Terraform only ignores attributes defined by the resource type. You can't apply 
+`ignore_changes` to itself or to any other meta-arguments.
+
+You can use `ignore_changes` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `replace_triggered_by` 
+
+Terraform replaces the resource when any of the referenced resources or specified attributes change. Supply a list of expressions that reference managed resources, instances, or instance attributes. 
+
+When used in a resource that uses [`count`](/terraform/language/meta-arguments/count) or [`for_each`](/terraform/language/meta-arguments/for_each), you can use `count.index` or `each.key` in the expression to reference specific instances of other resources that are configured with the same count or collection.
+
+References trigger replacement in the following conditions:
+
+- If the reference is to a resource with multiple instances, a plan to
+   update or replace any instance triggers a replacement.
+- If the reference is to a single resource instance, a plan to update or
+   replace that instance triggers a replacement.
+- If the reference is to a single attribute of a resource instance, any
+   change to the attribute value triggers a replacement.
+
+You can only reference managed resources in `replace_triggered_by`
+expressions. This lets you modify these expressions without forcing
+replacement. 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
+      ]
+   }
+}
+```
+
+`replace_triggered_by` allows only resource addresses because the decision is based on the planned actions for all of the given resources. Plain values, such as local values or input variables, do not have planned actions of their own, but you can treat them with a resource-like lifecycle by using them with the [`terraform_data` resource](/terraform/language/resources/terraform-data).
+
+You can use `replace_triggered_by` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `precondition` 
+
+Specifies a condition that Terraform evaluates before creating the resource. 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`](/terraform/language/meta-arguments/count) and [`for_each`](/terraform/language/meta-arguments/for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
+
+You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
+
+Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration. 
+
+You can use `precondition` in the following Terraform configuration blocks:
+
+- [`data`](/terraform/language/block/data)
+- [`ephemeral`](/terraform/language/block/ephemeral)
+- [`resource`](/terraform/language/block/resource) 
+
+### `postcondition` 
+
+Specifies a condition that Terraform evaluates after creating the resource. The following arguments in the `precondition` block are required:
+
+| Argument | Description | Data type |
+| --- | --- | --- |
+| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
+| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
+
+Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. Postcondition failures prevent changes to other resources that depend on the failing resource.
+
+You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
+
+Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
+
+You can use `precondition` in the following Terraform configuration blocks:
+
+- [`data`](/terraform/language/block/data) 
+- [`ephemeral`](/terraform/language/block/ephemeral)
+- [`resource`](/terraform/language/block/resource) 
+
+### `destroy` 
+
+Set to `false` to remove a resource from state without destroying the actual infrastructure resource. You can only use this rule in [`removed`](/terraform/language/block/removed) block.
+
+## Supported constructs
+
+Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details.
+
+
+## Example use cases
+
+The following use cases describe common patterns for the `lifecycle` argument.
+
+
+### 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
+     ]
+   }
+}
+```
+
+### Validate the AMI for creating instances
+
+In the following example, the `precondition` block ensures that the AMI ID retrieved from the `data` block includes `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
+data "aws_ami" "example" {
+  most_recent= true
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-*"]
+  }
+}
+
+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."
+    }
+  }
+}
+```
+### Validate that a root storage volume is encrypted
+
+In the following example, the `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."
+    }
+  }
+}
+
+data "aws_ami" "example" {
+  most_recent= true
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-*"]
+  }
+}
+
+resource "aws_instance" "example" {
+  instance_type = "t3.micro"
+  ami           = data.aws_ami.example.id
+}
+
+output "api_base_url" {
+  value = "https://${aws_instance.example.private_dns}:8433/"
+}
+```
+
+The validation fails in this example, so Terraform prints the following message to the console:
+
+```shell-session
+│ Error: Resource postcondition failed
+│
+│   on main.tf line 31, in data "aws_ebs_volume" "example":
+│   31:       condition     = self.encrypted
+│     ├────────────────
+│     │ self.encrypted is false
+│
+│ The server's root volume is not encrypted.
+```
+
+### Validate ephemeral resources
+
+In the following example, the `aws_ssm_parameter` ephemeral resource has a `precondition` to ensure that compliance mode is enabled to secure production secrets, and a `postcondition` to ensure the generated password meets password requirements:
+
+<CodeBlockConfig highlight="15-25">
+
+```hcl
+variable "environment" {
+  description = "Deployment environment"
+  type        = string
+}
+
+variable "compliance_mode" {
+  description = "Enable compliance requirements for production"
+  type        = bool
+  default     = false
+}
+
+ephemeral "aws_ssm_parameter" "database_password" {
+  name = "/secrets/${var.environment}/database/password"
+
+  lifecycle {
+    precondition {
+      condition     = var.environment != "prod" || var.compliance_mode == true
+      error_message = "Enable compliance mode to assess production secrets."
+    }
+
+    postcondition {
+      condition     = can(regex("^[A-Za-z0-9!@#$%^&*()_+=-]{16,}$", self.value))
+      error_message = "Password from external source must meet security requirements."
+    }
+  }
+}
+```
+
+</CodeBlockConfig>
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/provider.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/provider.mdx
new file mode 100644
index 0000000000..717b2056b3
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/provider.mdx
@@ -0,0 +1,117 @@
+---
+page_title: provider meta-argument reference
+description: Learn how the `provider` meta-argument works in Terraform configuration.
+---
+
+# `provider` reference
+
+The `provider` meta-argument specifies which provider configuration to use for a resource,
+overriding Terraform's default behavior of selecting one based on the resource
+type name. Note that the `provider` argument is distinct from the [`provider` block](/terraform/language/block/provider), which contains provider configuration settings. Refer to [Providers](/terraform/language/providers) for more information.
+
+## Usage
+
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider. 
+
+You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. For its value, the `provider` argument expects a reference formatted as `<PROVIDER>.<ALIAS>`. 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
+  # ...
+}
+```
+
+Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions. 
+
+A resource always has an implicit dependency on its associated provider. This ensures that the provider is fully configured before Terraform takes any actions on resources.
+
+Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services. 
+
+## Supported constructs
+
+You can use `provider` in the following Terraform configuration blocks:
+
+- [`check` blocks](/terraform/language/block/check)
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`import` block ](/terraform/language/block/import)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Example use cases
+
+The following use cases describe common patterns for the `provider` argument. Refer to the [examples in the `provider` block reference](/terraform/language/block/provider#examples) for more use cases.
+
+### Query a data source in different region
+
+In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
+
+```hcl
+provider "google" {
+  region = "us-central1"
+}
+
+provider "google" {
+  alias  = "europe"
+  region = "europe-west1"
+}
+
+data "google_compute_instance" "example" {
+  provider = google.europe
+  # ...
+}
+```
+
+### Use alternate provider for an ephemeral resource
+
+In the following example, Terraform uses the `aws.west` provider configuration to create the `aws_secretsmanager_secret_version` resource in the `us-west-2` region:
+
+```hcl
+provider "aws" {
+  region = "us-east-1"
+}
+
+provider "aws" {
+  alias  = "west"
+  region = "us-west-2"
+}
+
+ephemeral "aws_secretsmanager_secret_version" "db_password" {
+  provider  = aws.west
+  secret_id = aws_secretsmanager_secret.db_password.id
+}
+```
+
+### Import resources using an alternate provider configuration
+
+In the following example, Terraform imports the AWS instance with the ID `i-096fba6d03d36d262` to the `aws_instance.web` resource according to the `east` alias.
+
+```hcl
+provider "aws" {
+  region = "us-westl-1"
+}
+
+provider "aws" {
+  alias  = "east"
+  region = "us-east-1"
+}
+
+import {
+  id = "i-096fba6d03d36d262"
+  to = aws_instance.web
+  provider = aws.east
+}
+
+resource "aws_instance" "web" {
+  # ...
+}
+```
\ No newline at end of file
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/providers.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/providers.mdx
new file mode 100644
index 0000000000..eef39f1b6e
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/providers.mdx
@@ -0,0 +1,120 @@
+---
+page_title: providers meta-argument reference
+description: Learn how the `providers` meta-argument works in Terraform configuration.
+---
+
+# `providers` reference
+
+By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources.
+
+## Usage
+
+In a [`module` block](/terraform/language/block/module), you can add the optional `providers` meta-argument to specify which [provider configurations](/terraform/language/modules/configuration) from the parent module is available inside the child module.
+
+The value of `providers` is a map, where the keys are the provider configuration names used inside the child module and the values are provider configuration names from the parent module.
+
+Keys and values are unquoted references to provider configurations.
+For default configurations, the reference is the local name of the provider. For
+alternate configurations, the reference uses a `<PROVIDER>.<ALIAS>` format.
+
+Within a child module, either Terraform chooses a default based on the name of the resource
+type, or the resource specifies an alternate configuration with the `provider`
+argument. If the module receives a `providers` map when it's called, the
+provider configuration names used within the module are effectively remapped to
+refer the specified configurations from the parent module.
+
+In the following example, Terraform uses the default `aws` configuration for AWS resources in the root module where no explicit provider instance is selected, but the example child moduleuses the alternate configuration with the alias `usw2`. As a result, any AWS resources the module defines uses the `us-west-2` region.
+
+
+```hcl
+provider "aws" {
+  region = "us-west-1"
+}
+
+provider "aws" {
+  alias  = "usw2"
+  region = "us-west-2"
+}
+
+module "example" {
+  source    = "./example"
+  providers = {
+    aws = aws.usw2
+  }
+}
+```
+
+### Default behavior
+
+The `providers` argument is optional when the child module does not declare a [`configuration_aliases`](/terraform/language/modules/develop/providers#provider-aliases-within-modules). When you omit the argument, a child module inherits all of the default provider configurations from its parent module. Default provider configurations are configurations that don't have an `alias` argument.
+
+Specifying a `providers` argument cancels the default behavior. As a result, the child module only has access to the provider configurations you specify.
+
+### When to specify `providers`
+
+Add the `providers` argument when one of the following conditions apply:
+
+- Using different default provider configurations for a child module.
+- Configuring a module that requires multiple configurations of the same provider.
+
+### Change default provider configurations
+
+Most re-usable modules only use default provider configurations, which they can
+automatically inherit from their caller when `providers` is omitted.
+
+However, in Terraform configurations that use multiple configurations of the same provider, you might want some child modules to use the default provider configuration and others to use an alternate. 
+A common use case is using one configuration to manage resources in multiple different regions of the same cloud provider.
+
+Using `providers` argument lets you accommodate this without needing to edit the child module. Although the code
+within the child module always refers to the default provider configuration, the
+actual configuration of that default can be different for each instance.
+
+
+## Information for module developers
+
+For more details and guidance about working with providers inside a re-usable
+child module, refer to [Providers Within Modules](/terraform/language/modules/develop/providers).
+
+## Supported constructs
+
+You can use `providers` in the following Terraform configuration blocks:
+
+- [`module` blocks](/terraform/language/block/module)
+
+### Example use cases
+
+The following use cases describe common patterns for the `providers` argument.
+
+### Modules with alternate provider configurations
+
+In rare cases, a single re-usable module might require multiple configurations
+of the same provider. For example, a module that configures connectivity between
+networks in two AWS regions is likely to need both a `source` and a `destination`
+region. 
+
+In the following example, the `tunnel` module includes resources that support their own provider configuration. As a result, each resource alias maps to a different provider configurations declared in the root module:
+
+```hcl
+provider "aws" {
+  alias  = "usw1"
+  region = "us-west-1"
+}
+
+provider "aws" {
+  alias  = "usw2"
+  region = "us-west-2"
+}
+
+module "tunnel" {
+  source    = "./tunnel"
+  providers = {
+    aws.src = aws.usw1
+    aws.dst = aws.usw2
+  }
+}
+```
+
+Non-default provider configurations are never automatically inherited, so any
+module that works in this manner always requires a `providers` argument. The
+documentation for the module should specify all of the provider configuration
+names it needs.
diff --git a/content/terraform/v1.13.x/data/language-nav-data.json b/content/terraform/v1.13.x/data/language-nav-data.json
index af340c727d..682767795b 100644
--- a/content/terraform/v1.13.x/data/language-nav-data.json
+++ b/content/terraform/v1.13.x/data/language-nav-data.json
@@ -355,8 +355,37 @@
     },
   {
     "title": "Meta-arguments",
-    "path": "meta-arguments",
-    "alias": "actions"
+    "routes": [
+      {
+        "title": "Overview",
+        "path": "meta-arguments",
+        "alias": "actions"
+      },
+      {
+        "title": "count",
+        "path": "meta-arguments/count"
+      },
+      {
+        "title": "depends_on",
+        "path": "meta-arguments/depends_on"
+      },
+      {
+        "title": "for_each",
+        "path": "meta-arguments/for_each"
+      },
+      {
+        "title": "lifecycle",
+        "path": "meta-arguments/lifecycle"
+      },
+      {
+        "title": "provider",
+        "path": "meta-arguments/provider"
+      },
+      {
+        "title": "providers",
+        "path": "meta-arguments/providers"
+      }
+    ]
   },
   {
     "title": "Built-in resources",
diff --git a/content/terraform/v1.13.x/docs/language/block/check.mdx b/content/terraform/v1.13.x/docs/language/block/check.mdx
index 61bf3dcf66..e70268d189 100644
--- a/content/terraform/v1.13.x/docs/language/block/check.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/check.mdx
@@ -27,8 +27,8 @@ The `check` block supports the following arguments:
       - [`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
+      - [`depends_on`](#depends_on) &nbsp; list of references
+      - [`provider`](#provider) &nbsp; reference
 
 ## Complete configuration
 
@@ -122,7 +122,7 @@ The arguments within a `data` block are provider-specific. Refer to the [registr
 
 ### `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.
+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" {
@@ -135,13 +135,7 @@ check "unique_name" {
 }
 ```
 
-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) for additional information.
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `provider`
 
@@ -158,16 +152,7 @@ check "unique_name" {
 }
 ```
 
-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) for additional information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Supported meta-arguments: `depends_on` and `provider`.
-- Example: [Resource dependency](#resource-dependency).
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ## Examples
 
@@ -210,22 +195,4 @@ check "service_validation" {
    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"
- }
-}
-```
+```
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/block/data.mdx b/content/terraform/v1.13.x/docs/language/block/data.mdx
index c980349cdc..fc16d58c95 100644
--- a/content/terraform/v1.13.x/docs/language/block/data.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/data.mdx
@@ -22,7 +22,7 @@ The `data` block supports the following configuration:
   - [`lifecycle`](#lifecycle) &nbsp block
     - [`precondition`](#precondition) &nbsp block
       - [`condition`](#precondition) &nbsp string
-      - [`error_message`](#precondition) & nbsp string
+      - [`error_message`](#precondition) &nbsp string
     - [`postcondition`](#postcondition) &nbsp block
       - [`condition`](#postcondition) &nbsp string
       - [`error_message`](#postcondition) &nbsp string
@@ -74,7 +74,7 @@ The provider developer determines which arguments you can define for a data sour
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -82,24 +82,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number.
-
-In blocks where `count` is set, Terraform exposes an additional `count` object. You can reference the object to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual instance of a data source created using the `count` meta-argument, use the `<TYPE>.<NAME>[INDEX]` syntax. For example, `data.aws_instance.server[0]` refers to the first instance of the `aws_instance` data source named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional for creating data sources. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the data source when a variable named `creator` is set to `true`. Refer to [​​Conditional Expressions]/terraform/language/expressions/conditionals) for more information.
-
-</Tip>
-
-The `count` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Number.
-- Default: None.
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
@@ -111,21 +94,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-When a data source configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create one resource before creating a data source, even though the resource and the data source are configured independently.
-
-Use the `depends_on` argument when the resource and data source do not reference each other. We recommend always including a comment to explain dependencies when using a `depends_on` argument.
-
-When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
-
-Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data sources associated with that module. Refer to [Resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and [Data resource dependencies](/terraform/language/resources/configure#specify-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency).
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -158,41 +127,11 @@ data "<TYPE>" "<LABEL>" {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
-
-Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
-
-The `for_each` argument does not implicitly convert lists or tuples to sets. To declare data source instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the data source instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-sensitive-data) for more information.
-
-The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the data source. The object has the following attributes:
-
-- `each.key`: Map key or list member that corresponds to an instance.
-- `each.value`: Map value that corresponds to an instance.
-
-Use the `<TYPE>.<NAME>[<KEY>]` syntax to access an instance of a data source created using `for_each`. For example, `data.azurerm_resource_group.rg["a_group"]` refers to an instance of the `data.azurrm_resource_group` resource named `rg` created off of the `a_group` key.
-
-The `for_each` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-
-#### Summary
-
-- Data type: Map or set of strings.
-- Default: None.
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
-The `provider` argument instructs Terraform to use an alternate provider configuration.
+The `provider` argument instructs Terraform to use an alternate provider configuration to provision the nested data source.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -200,16 +139,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the data source type, but you can create multiple provider configurations and use a non-default configuration for specific data sources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Using an alternate provider configuration](/terraform/language/block/provider#using-an-alternate-provider-configuration) for an example of 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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Reference.
-- Default: None.
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -230,12 +160,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 Configurations defined in the `lifecycle` block affect how Terraform constructs and traverses the dependency graph. You can only use literal values in the lifecycle block because Terraform processes them before it evaluates arbitrary expressions for a run.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates data sources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -252,26 +177,7 @@ resource {
 }
 ```
 
-The following arguments in the `precondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to proceed with an operation. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `precondition` blocks before evaluating the resource's configuration arguments. The `precondition` can take precedence over argument evaluation errors.
-
-Terraform evaluates precondition blocks after evaluating [`count`](#count) and [`for_each`](#for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
-
-You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
-
-Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
- #### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions).
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -288,140 +194,4 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-The following arguments in the `precondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. Postcondition failures prevent changes to other resources that depend on the failing resource.
-
-You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
-
-Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions).
-
-## Examples
-
-The following examples show how to write configuration for common use cases.
-
-### Specify a dependency
-
-In the following example, Terraform gets an AMI for use in the `aws_instance` resource after creating the `aws_subnet.example_subnet` resource:
-
-```hcl
-resource "aws_vpc" "example_vpc" {
-  cidr_block = "10.0.0.0/16"
-}
-
-resource "aws_subnet" "example_subnet" {
-  vpc_id     = aws_vpc.example_vpc.id
-  cidr_block = "10.0.1.0/24"
-}
-
-data "aws_ami" "example_ami" {
-  most_recent = true
-  owners      = ["amazon"]
-  filter {
-    name   = "name"
-    values = ["amzn2-ami-hvm-*"]
-  }
-  filter {
-    name   = "architecture"
-    values = ["x86_64"]
-  }
-  depends_on = [aws_subnet.example_subnet]
-}
-
-resource "aws_instance" "example_instance" {
-  ami           = data.aws_ami.example_ami.id
-  instance_type = "t2.micro"
-  subnet_id     = aws_subnet.example_subnet.id
-}
-```
-
-Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.
-
-### Select an alternate provider configuration
-
-In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
-
-```hcl
-provider "google" {
-  region = "us-central1"
-}
-
-provider "google" {
-  alias  = "europe"
-  region = "europe-west1"
-}
-
-data "google_compute_instance" "example" {
-  provider = google.europe
-  # ...
-}
-```
-
-### Apply custom conditions
-
-The following example includes several configurations that illustrate how to define `precondition` and `postcondition` arguments in the `lifecycle` meta-argument.
-
-The following `data` block instructs Terraform to retrieve the ID of the `ami-abc123` AMI:
-
-```hcl
-data "aws_ami" "example" {
-  owners = ["amazon"]
-  filter {
-    name   = "image-id"
-    values = ["ami-abc123"]
-  }
-}
-```
-
-In the following code, the `precondition` block specifies that the AMI ID retrieved from the `data` block must include `x86_64` as its `architecture` attribute. The `postcondition` block specifies that the EC2 instance must be allocated a public DNS hostname. When either condition is not met, Terraform returns the `error_message` for the failed condition:
-
-```hcl
-resource "aws_instance" "example" {
-  instance_type = "t3.micro"
-  ami           = data.aws_ami.example.id
-
-  lifecycle {
-    precondition {
-      condition     = data.aws_ami.example.architecture == "x86_64"
-      error_message = "The selected AMI must be for the x86_64 architecture."
-    }
-
-    postcondition {
-      condition     = self.public_dns != ""
-      error_message = "EC2 instance must be in a VPC that has public DNS hostnames enabled."
-    }
-  }
-}
-```
-
-The following `data` block retrieves the root storage volume connected to the `aws_instance.example` EC2 instance using the `volume_id` attribute. When a `data` resource verifies the result of a managed resource declared in the same configuration, you must define the check in a `postcondition` block in the resource so that Terraform waits for changes to the managed resource to complete before reading the data resource.
-
-```hcl
-data "aws_ebs_volume" "example" {
-  filter {
-    name = "volume-id"
-    values = [aws_instance.example.root_block_device[0].volume_id]
-  }
-  lifecycle {
-    # The EC2 instance will have an encrypted root volume.
-    postcondition {
-      condition     = self.encrypted
-      error_message = "The server's root volume is not encrypted."
-    }
-  }
-}
-output "api_base_url" {
-  value = "https://${aws_instance.example.private_dns}:8433/"
-}
-```
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/block/ephemeral.mdx b/content/terraform/v1.13.x/docs/language/block/ephemeral.mdx
index fe675daa56..7816c24909 100644
--- a/content/terraform/v1.13.x/docs/language/block/ephemeral.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/ephemeral.mdx
@@ -119,7 +119,7 @@ The provider developer determines which arguments you can define for an ephemera
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same ephemeral resource with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same ephemeral resource with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 <CodeBlockConfig hideClipboard>
 
@@ -131,25 +131,12 @@ ephemeral "<TYPE>" "<LABEL>" {
 
 </CodeBlockConfig>
 
-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 you set `count`, Terraform exposes an additional `count` object. You can reference the object within the ephemeral block to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual instance of an ephemeral resource created using the `count` meta-argument, use the `ephemeral.<TYPE>.<LABEL>[INDEX]` syntax. For example, `ephemeral.random_password.db_password[0]` refers to the first instance of the `random_password` ephemeral resource named `db_password`.
-
-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 ephemeral resources](#create-multiple-ephemeral-resources)
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
 The `depends_on` meta-argument specifies an upstream resource that the ephemeral resource depends on. When it creates a plan, Terraform sequences all operations on the upstream resource before performing operations on the ephemeral resource configured with the `depends_on` meta-argument.
 
-<CodeBlockConfig hideClipboard>
 
 ```hcl
 ephemeral "<TYPE>" "<LABEL>" {
@@ -157,20 +144,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-</CodeBlockConfig>
-
-When an ephemeral resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating an ephemeral resource, 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 in the same root module or its child modules. 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.
-
-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -196,34 +170,14 @@ ephemeral "<TYPE>" "<LABEL>" {
   for_each = {
     "<KEY>" = "<VALUE>"
   }
+}
 ```
 
 </Tab>
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct ephemeral resource. 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 of the values must be known when Terraform creates a plan. 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.
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the ephemeral resource instance and always discloses it in UI output, so sensitive values are not allowed.
-
-The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the ephemeral 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 `ephemeral.<TYPE>.<LABEL>[<KEY>]` syntax to access an instance of an ephemeral resource created using `for_each`. For example, `ephemeral.random_password.passwords["admin"]` refers to an instance of the `random_password` ephemeral resource named `passwords` created from the `admin` 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 ephemeral resources](#create-multiple-ephemeral-resources)
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -239,17 +193,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 
 </CodeBlockConfig>
 
-By default, Terraform automatically selects a provider based on the ephemeral resource type, but you can create multiple provider configurations and use a non-default configuration for specific ephemeral resources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument.
-
-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) for more information.
-
-#### Summary
-
-- Data type: Reference
-- Default: None
-- Example: [Use alternate provider configurations](#use-alternate-provider-configurations)
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -274,12 +218,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 You can include both `precondition` and `postcondition` blocks in the same `lifecycle` block, and you can define multiple `precondition` and `postcondition` blocks in the same `lifecycle` block.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block
-- Default: None
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -296,26 +235,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-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 ephemeral resource's configuration arguments. The `precondition` block errors 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 ephemeral resource.
-
-Refer to [Test and validate](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block
-- Default: None
-- Example: [Validate ephemeral resources](#validate-ephemeral-resources)
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -332,24 +252,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-The following arguments in the `postcondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `postcondition` blocks after planning and applying changes to the ephemeral resource. Postcondition failures prevent changes to other resources that depend on the failing ephemeral resource.
-
-You can include a `postcondition` and [`precondition` block](#precondition) in the same ephemeral resource.
-
-Refer to [Test and validate](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block
-- Default: None
-- Example: [Validate ephemeral resources](#validate-ephemeral-resources)
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ## Examples
 
@@ -414,102 +317,4 @@ resource "aws_db_instance" "example" {
 
 Neither write-only arguments nor `ephemeral` resources are persisted outside of the current Terraform run, ensuring that the `ephemeral.random_password.db_password.result` value is completely omitted from state and plan files.
 
-Terraform does not store the generated value of `ephemeral.random_password.db_password.result`, but you can capture it in another resource to ensure the value is not lost. For an example of generating, storing, retrieving, and using an ephemeral password, refer to [write-only arguments](/terraform/language/manage-sensitive-data/write-only#set-and-store-an-ephemeral-password-in-aws-secrets-manager).
-
-### Create multiple ephemeral resources
-
-In the following example, the `for_each` argument creates multiple passwords for different database environments:
-
-<CodeBlockConfig highlight="6, 18">
-
-```hcl
-locals {
-  environments = toset(["dev", "staging", "prod"])
-}
-
-ephemeral "random_password" "db_passwords" {
-  for_each = local.environments
-
-  length           = 16
-  override_special = "!#$%&*()-_=+[]{}<>:?"
-}
-
-resource "aws_db_instance" "databases" {
-  for_each = local.environments
-
-  identifier                = "${each.key}-database-${var.environment_suffix}"
-  db_name                   = "${each.key}db"
-  username                  = "dbadmin"
-  password_wo               = ephemeral.random_password.db_passwords[each.key].result
- # …
-}
-```
-
-</CodeBlockConfig>
-
-The `ephemeral` block creates a `random_password` ephemeral resource for each environment in the `local.environments` set. The `aws_db_instance` resource then uses the generated passwords for each database instance.
-
-Terraform does not store the generated `db_passwords` values, but you can capture them in another resource to ensure those values are not lost. For an example of generating, storing, retrieving, and using an ephemeral password, refer to [write-only arguments](/terraform/language/manage-sensitive-data/write-only#set-and-store-an-ephemeral-password-in-aws-secrets-manager).
-
-### Use alternate provider configurations
-
-In the following example, the ephemeral resource uses an alternate AWS provider configuration:
-
-<CodeBlockConfig highlight="11">
-
-```hcl
-provider "aws" {
-  region = "us-east-1"
-}
-
-provider "aws" {
-  alias  = "west"
-  region = "us-west-2"
-}
-
-ephemeral "aws_secretsmanager_secret_version" "db_password" {
-  provider  = aws.west
-  secret_id = aws_secretsmanager_secret.db_password.id
-}
-```
-
-</CodeBlockConfig>
-
-Terraform uses the `aws.west` provider configuration to create the `aws_secretsmanager_secret_version` resource in the `us-west-2` region.
-
-### Validate ephemeral resources
-
-In the following example, the `aws_ssm_parameter` ephemeral resource has a precondition to ensure that compliance mode is enabled to secure production secrets, and a postcondition to ensure the generated password meets password requirements:
-
-<CodeBlockConfig highlight="15-25">
-
-```hcl
-variable "environment" {
-  description = "Deployment environment"
-  type        = string
-}
-
-variable "compliance_mode" {
-  description = "Enable compliance requirements for production"
-  type        = bool
-  default     = false
-}
-
-ephemeral "aws_ssm_parameter" "database_password" {
-  name = "/secrets/${var.environment}/database/password"
-
-  lifecycle {
-    precondition {
-      condition     = var.environment != "prod" || var.compliance_mode == true
-      error_message = "Enable compliance mode to assess production secrets."
-    }
-
-    postcondition {
-      condition     = can(regex("^[A-Za-z0-9!@#$%^&*()_+=-]{16,}$", self.value))
-      error_message = "Password from external source must meet security requirements."
-    }
-  }
-}
-```
-
-</CodeBlockConfig>
+Terraform does not store the generated value of `ephemeral.random_password.db_password.result`, but you can capture it in another resource to ensure the value is not lost. For an example of generating, storing, retrieving, and using an ephemeral password, refer to [write-only arguments](/terraform/language/manage-sensitive-data/write-only#set-and-store-an-ephemeral-password-in-aws-secrets-manager).
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/block/import.mdx b/content/terraform/v1.13.x/docs/language/block/import.mdx
index 7264481f85..0de496019c 100644
--- a/content/terraform/v1.13.x/docs/language/block/import.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/import.mdx
@@ -135,7 +135,6 @@ You cannot use the `identity` argument and [`id` argument](#id) in the same `imp
 - Default: None
 - Example: [Import a single resource](#import-a-single-resource)
 
-
 ### `for_each`
 
 The `for_each` meta-argument instructs Terraform to import similar resources without requiring separate configuration blocks.
@@ -167,17 +166,7 @@ import {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and imports an instance for each item in that map or set and produces an `each` object. You can use the values stored in `each.key` and `each.value` for the [`id` argument expression](#id). You can also use them in index expressions in the [`to` argument](#to). This allows Terraform to import multiple instances of a resource configuration.
-
-The inputs for the `for_each` argument must be known for the import plan operation to succeed. You cannot use a `for_each` argument when running `terraform plan` with the `-generate-config-out` option. Refer to [Generate configuration](/terraform/language/import/generating-configuration) for more information.
-
-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: [Import multiple resources](#import-multiple-resources) 
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -190,17 +179,7 @@ import {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the resource type, but you can configure multiple instances of the same provider with aliases and use a non-default configuration to import specific resources. 
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. 
-
-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) for more information.
-
-#### Summary
-
-- Data type: String
-- Default: None
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration) 
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ## Examples
 
@@ -308,28 +287,4 @@ import {
   id = each.value.id
   to = module.group[each.value.group].aws_s3_bucket.this[each.value.key]
 }
-```
-
-### Select an alternate provider configuration
-
-In the following example, Terraform imports the AWS instance with the ID `i-096fba6d03d36d262` to the `aws_instance.web` resource according to the `east` alias.
-
-```hcl
-provider "aws" {
-  region = "us-westl-1"
-}
-
-provider "aws" {
-  alias  = "east"
-  region = "us-east-1"
-}
-
-import {
-  id = "i-096fba6d03d36d262"
-  to = aws_instance.web
-  provider = aws.east
-}
-
-resource "aws_instance" "web" {
-  # ...
-}
\ No newline at end of file
+```
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/block/module.mdx b/content/terraform/v1.13.x/docs/language/block/module.mdx
index 6267f4ade2..828f744b58 100644
--- a/content/terraform/v1.13.x/docs/language/block/module.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/module.mdx
@@ -398,7 +398,7 @@ Refer to the documentation for the module for versioning mechanisms specific to
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same module with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same module with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 module "<LABEL>" {
@@ -406,31 +406,12 @@ module "<LABEL>" {
 }
 ```
 
-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 module created using the `count` meta-argument, use the `module.<NAME>[INDEX]` syntax. For example, `module.server[0]` refers to the first instance of the module named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional for creating modules. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the module resources 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 version of module resources](#create-multiple-versions-of-module-resources)
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `for_each`
 
 The `for_each` meta-argument instructs Terraform to provision similar modules without requiring separate configuration blocks for each resource.
 
-
 <Tabs>
 
 <Tab heading="List of values">
@@ -457,38 +438,7 @@ module "<LABEL>" {
 
 </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 modules based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the module instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-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 module. 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 `module.<NAME>[<KEY>]` syntax to access an instance of a module created using `for_each`. For example, `module.rg["a_group"]` refers to a module 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 version of module resources](#create-multiple-versions-of-module-resources)
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `providers`
 
@@ -502,18 +452,7 @@ module "<LABEL>" {
 }
 ```
 
-By default, a child module inherits the default provider configuration from its parent module, but you can create multiple provider configurations and use an alternate configuration for each module. Because a module is collection of different resources, some modules also let you specify an alternate configuration for different resources in the module. Refer to the module documentation for details.
-
-The `providers` argument is a map of key-value pairs that reference provider configurations. The key references the provider configuration name used in the child module. Refer to the module documentation for details on how to define keys. The value references the provider configuration name from the parent module. Use the `<PROVIDER>.<ALIAS>` syntax to reference alternate provider configurations in key values.
-
-The `providers` 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.
-- Default: None.
-- Example: [Apply different provider configurations for module resources](#apply-different-provider-configurations-for-module-resource)
-
+`providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
 
 ### `depends_on`
 
@@ -525,21 +464,7 @@ module "<LABEL>" {
 }
 ```
 
-When a module configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create one resource before creating a module, even though the resource and the module are configured independently.
-
-Use the `depends_on` argument when the resource and module do not reference each other. We recommend always including a comment to explain dependencies when using a `depends_on` argument.
-
-When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
-
-Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data modules associated with that module. Refer to [Specify resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and the [data resource dependencies documentation](/terraform/language/data-sources#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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency)
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ## Examples
 
@@ -794,109 +719,3 @@ module "vpc" {
 }
 ```
 
-### Create multiple instances of module resources
-
-You can use either `count` or the `for_each` block to create multiple instances of module resources. 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 instances with varying configuration from a map or set.
-
-<Tabs>
-
-<Tab heading="count">
-
-In the following example, Terraform creates three EC2 instances, each with a unique name from the `instance_names` list:
-
-```hcl
-locals {
-  instance_names = ["example-instance-1", "example-instance-2", "example-instance-3"]
-}
-
-module "ec2_instance" {
-  source  = "terraform-aws-modules/ec2-instance/aws"
-  version = "6.0.2"
-  count   = length(local.instance_names)
-
-  name           = local.instance_names[count.index]
-  ami            = data.aws_ami.latest_amazon_linux.id
-  instance_type  = "t2.micro"
-
-  depends_on = [aws_s3_bucket.example]
-}
-
-```
-
-</Tab>
-
-<Tab heading="for_each">
-
-In the following example, Terraform creates one EC2 instance for each key in `local.instance_configs`, allowing you to customize properties per instance:
-
-```hcl
-locals {
-  instance_configs = {
-    "example-instance-1" = { instance_type = "t2.micro" }
-    "example-instance-2" = { instance_type = "t2.small" }
-    "example-instance-3" = { instance_type = "t2.medium" }
-  }
-}
-
-module "ec2_instance" {
-  source  = "terraform-aws-modules/ec2-instance/aws"
-  version = "6.0.2"
-  for_each = local.instance_configs
-
-  name           = each.key
-  ami            = data.aws_ami.latest_amazon_linux.id
-  instance_type  = each.value.instance_type
-
-  depends_on = [aws_s3_bucket.example]
-}
-
-```
-
-</Tab>
-
-</Tabs>
-
-### Specify dependencies
-
-In the following example, Terraform only creates the EC2 instance module after creating the S3 bucket resource:
-
-
-```hcl
-resource "aws_s3_bucket" "example" {
-  bucket = "my-example-bucket-12345"
-}
-
-module "ec2_instance" {
-  source  = "terraform-aws-modules/ec2-instance/aws"
-  version = "6.0.2"
-  name    = "example-instance"
-  ami           = data.aws_ami.latest_amazon_linux.id
-  instance_type = "t2.micro"
-
-  depends_on = [aws_s3_bucket.example]
-}
-```
-
-### Apply different provider configurations for module resources
-
-In the following example, the `tunnel` module includes resources that support their own provider configuration. As a result, each resource alias maps to a different provider configurations declared in the root module:
-
-```hcl
-provider "aws" {
-  alias  = "usw1"
-  region = "us-west-1"
-}
-
-provider "aws" {
-  alias  = "usw2"
-  region = "us-west-2"
-}
-
-module "tunnel" {
-  source    = "./tunnel"
-  providers = {
-    aws.src = aws.usw1
-    aws.dst = aws.usw2
-  }
-}
-```
diff --git a/content/terraform/v1.13.x/docs/language/block/output.mdx b/content/terraform/v1.13.x/docs/language/block/output.mdx
index 48f7ebf0f1..44bc730ae8 100644
--- a/content/terraform/v1.13.x/docs/language/block/output.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/output.mdx
@@ -173,7 +173,7 @@ The following ephemeral contexts can set values for output blocks with the `ephe
 
 ### `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.
+The `depends_on` argument specifies an explicit dependency on another upstream resource for an `output` block. Terraform must complete all operations on the upstream resource before it computes the value of an `output` block that depends on it.
 
 ```hcl
 output "unique_name" {
@@ -182,14 +182,7 @@ output "unique_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) for additional information.
-
-#### Summary
-
-- Data type: List of references
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `precondition`
 
@@ -275,23 +268,4 @@ output "instance_public_ip" {
   }
 }
 ```
-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.
+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.
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/block/removed.mdx b/content/terraform/v1.13.x/docs/language/block/removed.mdx
index b62c97c04a..a1d2241da1 100644
--- a/content/terraform/v1.13.x/docs/language/block/removed.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/removed.mdx
@@ -94,7 +94,7 @@ removed {
 
 By default, Terraform removes the resource from state and destroys the actual resource. Set `destroy` to `false` to remove the resource from state without destroying the actual resource. This allows you to hand off management responsibilities to another tool or team after using Terraform for the initial provisioning.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 #### Summary
 
diff --git a/content/terraform/v1.13.x/docs/language/block/resource.mdx b/content/terraform/v1.13.x/docs/language/block/resource.mdx
index 7b83432241..2d780df1f5 100644
--- a/content/terraform/v1.13.x/docs/language/block/resource.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/resource.mdx
@@ -166,7 +166,7 @@ The provider developer determines which arguments you can define for a resource.
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 resource {
@@ -174,25 +174,7 @@ resource {
 }
 ```
 
-The value must be a whole number. You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number.
-
-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).
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
@@ -204,22 +186,7 @@ resource {
 }
 ```
 
-When a resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating another, even though the resources are configured independently.
-
-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/resources/configure#specify-resource-dependencies) <!-- placeholder link -->
-and [Data resource dependencies](/terraform/language/resources/configure#specify-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency).
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -252,37 +219,7 @@ resource {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
-
-Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
-
-The `for_each` argument does not implicitly convert lists or tuples to sets. To declare resource instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, be aware that most functions in Terraform will return a sensitive result if given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-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).
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -294,17 +231,7 @@ resource {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the resource type, but you can create multiple provider configurations and use a non-default configuration for specific resources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument.
-
-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) for more information.
-
-#### Summary
-
-- Data type: Reference.
-- Default: None.
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration).
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -329,12 +256,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `create_before_destroy`
 
@@ -348,18 +270,7 @@ resource {
 }
 ```
 
-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.
+`create_before_destroy` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `prevent_destroy`
 
@@ -373,16 +284,7 @@ resource {
 }
 ```
 
-Use this argument to prevent team members from accidentally replacing critical infrastructure, such as database instances.
-
-When `prevent_destroy` is enabled, 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.
-
-This rule doesn't prevent Terraform from destroying the resource if you remove the resource configuration. For instructions on how to remove a resource from state without destroying the actual resource, refer to [Remove a resource from state](/terraform/language/state/remove).
-
-#### Summary
-
-- Data type: Boolean.
-- Default: None.
+`prevent_destroy` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `ignore_changes`
 
@@ -396,19 +298,7 @@ resource {
 }
 ```
 
-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).
+`ignore_changes` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `replace_triggered_by`
 
@@ -422,23 +312,7 @@ resource {
 }
 ```
 
-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)
+`replace_triggered_by` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -455,26 +329,7 @@ resource {
 }
 ```
 
-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 [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions)
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -491,24 +346,7 @@ resource {
 }
 ```
 
-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 [Validate your configuration](/terraform/language/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)
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `connection`
 
@@ -922,246 +760,6 @@ resource "aws_instance" "web" {
 }
 ```
 
-### 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.
diff --git a/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/component.mdx b/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/component.mdx
index 0fe2f2b4e2..f37cbec8b0 100644
--- a/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/component.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/component.mdx
@@ -128,6 +128,8 @@ component "storage" {
 
 The keys in the `providers` map must match the provider names that the source module expects, and the values must reference providers declared in your component configuration. Learn more about [Declaring providers in Stacks](/terraform/language/stacks/component/declare-providers).
 
+`providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
+
 #### Summary
 
 - Data type: Map
@@ -178,10 +180,7 @@ component "app_server" {
 
 You do not need to include the dependant component’s outputs in the `depends_on` list because Terraform automatically recognizes those dependencies.
 
-#### Summary
-
-- Data type: List of references
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -217,10 +216,7 @@ component "<LABEL>" {
 
 When you use `for_each`, Terraform creates one component instance for each item in the collection. You can reference individual instances using `component.<LABEL>[<KEY>]` syntax.
 
-#### Summary
-
-- Data type: Map or Set
-- Default: None
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/provider.mdx b/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/provider.mdx
index c181603761..31f8d6626d 100644
--- a/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/provider.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/provider.mdx
@@ -111,10 +111,7 @@ provider "<NAME>" "<ALIAS>" {
 
 When you use `for_each`, you can reference individual provider instances using `provider.<PROVIDER_NAME>.<ALIAS>[<KEY>]` syntax in your `component` blocks.
 
-#### Summary
-
-- Data type: Map or Set
-- Default: None
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/removed.mdx b/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/removed.mdx
index ee910233b7..c83bc7e0f4 100644
--- a/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/removed.mdx
+++ b/content/terraform/v1.13.x/docs/language/block/stack/tfcomponent/removed.mdx
@@ -104,7 +104,7 @@ removed {
 
 ### `providers`
 
-The `providers` argument maps provider names to the providers that the component you want to remove uses. HCP Terraform needs these provider configurations to properly remove the component's resources.
+The `providers` argument is required. It maps provider names to the providers that the component you want to remove uses. HCP Terraform needs these provider configurations to properly remove the component's resources.
 
 ```hcl
 removed {
@@ -119,11 +119,7 @@ removed {
 
 The provider mapping must include every provider that the component's module requires for resource destruction.
 
-#### Summary
-
-- Data type: Map
-- Default: None
-- Required: Yes
+`providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
 
 ### `for_each`
 
@@ -161,6 +157,8 @@ removed {
 
 The `for_each` meta-argument is useful when you want to remove components from specific regions or environments.
 
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
+
 #### Summary
 
 - Data type: Map or Set
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments.mdx
deleted file mode 100644
index c6dbb8a24c..0000000000
--- a/content/terraform/v1.13.x/docs/language/meta-arguments.mdx
+++ /dev/null
@@ -1,216 +0,0 @@
----
-page_title: Meta-arguments
-description: Meta-arguments are built-in Terraform arguments that determine how Terraform creates and manages resources.
----
-
-# Meta-arguments
-
-Meta-arguments are a class of arguments built into the Terraform configuration language that control how Terraform creates your infrastructure. This page provides an overview of the meta-arguments included with Terraform.
-
-<Note>
-
-Terraform `v1.14.x (beta)` adds the `action_trigger` meta-argument, which lets you trigger actions that extend Terraform CRUD operations. Refer to the [Invoke an action](/terraform/language/v1.14.x/invoke-actions) beta documentation for more information.
-
-</Note>
-
-## Introduction
-
-You can use meta-arguments in any type of resource, including resources created with `data` blocks. You can also use most meta-arguments in `module` blocks.
-
-The provider developer determines resource-specific arguments, but all resources support meta-arguments that let you manage resources' infrastructure lifecycle, including destruction behavior, preventing destruction, and establishing dependencies between resources. Terraform provides the following meta-arguments.
-
-## `depends_on`
-
-The `depends_on` meta-argument establishes dependencies between resources that do not directly reference one another. Use the `depends_on` argument to explicitly set the order in which Terraform creates resources.
-
-### Tutorials
-
-- [Create resource dependencies](/terraform/tutorials/configuration-language/dependencies)
-
-### Examples
-
-- [Specify a dependency during validation](/terraform/language/block/check#resource-dependency)
-- [Specify a dependency when querying a data source](/terraform/language/block/data#specify-a-dependency)
-- [Specify a dependency when calling a module](/terraform/language/block/module#specify-dependencies)
-- [Specify a dependency when outputting values](/terraform/language/block/output#explicit-dependencies)
-- [Specify a dependency during resource creation](/terraform/language/block/resource#specify-a-dependency)
-
-### Guidance
-
- - [Add dependencies](/terraform/language/data-sources#dependencies) when querying a data source
- - [Set dependencies](/terraform/language/modules/configuration#set-dependencies) in your module configuration
-
-### References
-
-- [`depends_on` argument in `check` blocks](/terraform/language/block/check#depends_on)
-- [`depends_on` argument in `data` blocks](/terraform/language/block/data#depends_on)
-- [`depends_on` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#depends_on)
-- [`depends_on` argument in `module` blocks](/terraform/language/block/module#depends_on)
-- [`depends_on` argument in `output` blocks](/terraform/language/block/output#depends_on)
-- [`depends_on` argument in `resource` blocks](/terraform/language/block/resource#depends_on)
-
-## `count`
-
-By default, Terraform manages one infrastructure object for each `resource` block. Terraform also creates single instances of a module per `module` block. You can use the `count` argument in `resource` and `module` blocks to create and manage multiple instances of each without writing a separate block for each instance.
-
-### How to choose between `count` and `for_each`
-
-The [`for_each` meta-argument](#for_each) performs a similar function to `count`, but lets you reference different values for each instance you create. Use the `count` argument when you want to create nearly identical instances. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
-Integer index. You cannot use both a `count` and ` for_each` argument in the same `resource` or `module` block.
-
-### Tutorials
-
-- [Manage similar resources with count](/terraform/tutorials/0-13/count)
-
-### Examples
-
-- [Create multiple ephemeral resources](/terraform/language/block/ephemeral#create-multiple-ephemeral-resources)
-- [Create multiple instances of module resources](/terraform/language/block/module#create-multiple-instances-of-module-resources)
-- [Create multiple instances of a resource](/terraform/language/block/resource#create-multiple-instances-of-a-resource)
-
-### Guidance
-
- - [Create multiple instances](/terraform/language/data-sources#multiple-instances) when querying a data source
- - [Create multiple instances](/terraform/language/modules/configuration#create-multiple-copies-of-modules) when calling modules
-
-### References
-
-- [`count` argument in `data` blocks](/terraform/language/block/data#count)
-- [`count` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#count)
-- [`count` argument in `module` blocks](/terraform/language/block/module#count)
-- [`count` argument in `resource` block ](/terraform/language/block/resource#count)
-
-## `for_each`
-
-By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. You can add the `for_each` block to your `resource`, `data`, `module`, and `ephemeral` blocks to create and manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each instance.
-
-The `for_each` accepts a map or a set that resolves to string values, but you can specify pure functions, such as `toset()` and `tomap()`, to create a map or set of string key-value pairs. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-Whether iterating over the keys of a map or set of strings, all values must be known.
-
-### How to choose between `for_each` and `count`
-
-The [`count` meta-argument](#count) performs a similar operation to `for_each`. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
-integer. Use the `count` argument when you want to create nearly identical instances.
-
-You cannot use both a `count` and ` for_each` argument in the same block.
-
-### Tutorials
-
-- [Manage similar resources with for each](/terraform/tutorials/configuration-language/for-each)
-
-### Examples
-
-- [Create multiple ephemeral resources](/terraform/language/block/ephemeral#create-multiple-ephemeral-resources)
-- [Import multiple existing resources](/terraform/language/block/import#import-multiple-resources)
-- [Create multiple instances of module resources](/terraform/language/block/module#create-multiple-instances-of-module-resources)
-- [Create multiple instances of a resource](/terraform/language/block/resource#create-multiple-instances-of-a-resource)
-
-### Guidance
-
-- [Creat multiple instances](/terraform/language/data-sources#multiple-instances) when querying a data source
-- [Create multiple instances](/terraform/language/modules/configuration#create-multiple-copies-of-modules) when calling modules
-
-### References
-
-- [`for_each` argument in `data` blocks](/terraform/language/block/data#for_each)
-- [`for_each` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#for_each)
-- [`for_each` argument in `module` blocks](/terraform/language/block/module#for_each)
-- [`for_each` argument in. `resource` blocks](/terraform/language/block/resource#for_each)
-
-## `provider`
-
-By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider .
-
-You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services.
-
-The `provider` argument is distinct from the `provider` block, which contains provider configuration settings. Refer to [Providers](/terraform/language/providers) for more information about the `provider` block.
-
-### Examples
-
-- [Specify an alternate provider configuration](/terraform/language/block/data#select-an-alternate-provider-configuration) for a data source
-- [Specify an alternate provider configuration](/terraform/language/block/ephemeral#use-alternate-provider-configurations) for an ephemeral resource
-- [Select an alternate provider configuration](/terraform/language/block/import#select-an-alternate-provider-configuration) for imported resources
-- [Select a provider without a default configuration](/terraform/language/block/provider#provider-without-a-default-configuration)
-- [Select an alternative provider configuration](/terraform/language/block/resource#select-an-alternate-provider-configuration) for resources
-
-### Guidance
-
-- [Providers](/terraform/language/providers)
-- [Select an alternate provider configuration](/terraform/language/data-sources#alternate-provider-configurations) when querying a data source
-
-### References
-
-- [`provider` argument in `check` blocks](/terraform/language/block/check#provider)
-- [`provider` argument in `data` blocks](/terraform/language/block/data#provider)
-- [`provider` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#provider)
-- [`provider` argument in `import` block ](/terraform/language/block/import#provider)
-- [`provider` argument in `resource` blocks](/terraform/language/block/resource#provider)
-
-## `providers`
-
-By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources.
-
-Some modules may contain resources that require different providers. As a result, you can specify alternate configurations for each provider supported by the module. Refer to the module documentation for details about the providers it supports.
-
-When you add a `providers` argument, child modules only have access to the provider configurations you specify. Use the `providers` argument in the following scenarios:
-
-- To use an alternate provider configuration for a child module.
-- To configure a module that requires multiple configurations of the same provider.
-
-### Examples
-
-- [Apply different provider configurations](/terraform/language/block/module#apply-different-provider-configurations-for-module-resources)  for module resources
-
-### Guidance
-
-- [Provider Aliases Within Modules](/terraform/language/modules/develop/providers#provider-aliases-within-modules)
-
-### Reference
-
-- [`providers` argument in `module` blocks](/terraform/language/block/module#providers)
-- [Providers module development documentation](/terraform/language/modules/develop/providers)
-
-## `lifecycle`
-
-Terraform performs the following operations when you apply a configuration:
-
-1. Creates resources defined in the configuration that are not associated with a real infrastructure object in the state.
-1. Destroys resources that exist in the state but not in the configuration.
-1. Updates in-place resources whose arguments have changed.
-1. Destroys and re-create resources whose arguments have changed but that Terraform cannot update in-place because of remote API limitations.
-
-The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details. The following table describes support for each `lifecycle` rule:
-
-
-| Rule | Description | Terraform block |
-| --- | --- | --- |
-| `create_before_destroy` | Terraform creates a replacement resource before destroying the current resource. | `resource` |
-| `prevent_destroy` | Terraform rejects operations to destroy the resource and returns an error. This rule doesn't prevent Terraform from destroying a resource if you remove its configuration. Refer to [Remove a resource from state](/terraform/language/state/remove) for instructions on how to remove a resource from state without destroying the actual resource. | `resource` |
-| `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. | `resource` |
-| `replace_triggered_by` | Terraform replaces the resource when any of the referenced resources or specified attributes change. | `resource` |
-| `precondition` | Specifies a condition that Terraform evaluates before creating the resource. | `data`, `ephemeral`, `resource` |
-| `postcondition` | Specifies a condition that Terraform evaluates after creating the resource. | `data`, `ephemeral`, `resource` |
-| `destroy` | Set to `false` to remove a resource from state without destroying the actual infrastructure resource. You can only use this rule in the `removed` block. | `removed` |
-
-### Tutorials
-
-- [Manage resource lifecycle](/terraform/tutorials/state/resource-lifecycle)
-
-### Examples
-
-- [Apply custom conditions to data sources](/terraform/language/block/data#apply-custom-conditions)
-- [Ignore attribute changes](/terraform/language/block/resource#ignore-attribute-changes)
-- [Specify triggers that replace resource](/terraform/language/block/resource#specify-triggers-that-replace-resources)
-- [Apply custom conditions to resources](/terraform/language/block/resource#apply-custom-conditions)
-
-### Guidance
-
-- [Validate your configuration](/terraform/language/validate#preconditions-and-postconditions)
-
-### References
-
-- [`lifecycle` argument in `data` blocks](/terraform/language/block/data#lifecycle)
-- [`lifecycle` argument in `ephemeral` block ](/terraform/language/block/ephemeral#lifecycle)
-- [`lifecycle` argument in `removed` blocks](/terraform/language/block/removed#lifecycle)
-- [`lifecycle` argument in `resource` blocks](/terraform/language/block/resource#lifecycle)
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/count.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/count.mdx
new file mode 100644
index 0000000000..7feef02f72
--- /dev/null
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/count.mdx
@@ -0,0 +1,125 @@
+---
+page_title: count meta-argument reference
+description: Learn how the `count` meta-argument works in Terraform configuration.
+---
+
+# `count` reference
+
+By default, each [`resource` block](/terraform/language/block/resource) and [`ephemeral` block](/terraform/language/block/ephemeral) configures one real infrastructure object. Similarly, a [`module` block](/terraform/language/block/module) includes a child module's contents into the configuration one time. 
+
+Use the `count` meta-argument to manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each object. When a `resource` or `module` block includes a `count` argument whose value is a whole number, Terraform creates that many instances.
+
+## Usage
+
+The `count` meta-argument accepts a whole number and creates that many instances of the resource or module. Each instance has a distinct infrastructure object associated with it, and each is separately created, updated, or destroyed when the configuration is applied. 
+
+<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>
+
+
+In the folllowing example, Terraform creates four `aws_instance.server` resources that use the same AMI and instance type. The `count.index` attribute gives each `aws_instance` a unique `Name` tag:
+
+```hcl
+resource "aws_instance" "server" {
+  count = 4 # create four similar EC2 instances
+
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+
+  tags = {
+    Name = "Server ${count.index}"
+  }
+}
+```
+
+### Expressions in `count`
+
+The `count` meta-argument accepts numeric [expressions](/terraform/language/expressions), but unlike most arguments, the `count` value must be known before Terraform performs any remote resource operations. `count` cannot refer to any resource attributes that are only known after a configuration is applied, such as a unique ID generated by the remote API when an object is created.
+
+### Referring to instances
+
+In blocks where `count` is set, Terraform creates an additional `count` object that you can use in expressions to modify the configuration of each instance. This object has the following attribute:
+
+- `count.index`: The distinct index number starting with `0` corresponding to this instance.
+
+Terraform makes a distinction between the block containing the `count` argument and the instances associated with it. Terraform identifies instances index number starting at `0`.
+
+- `<TYPE>.<NAME>` or `module.<NAME>`, for example, `aws_instance.server` refers to the resource block.
+- `<TYPE>.<NAME>[<INDEX>]` or `module.<NAME>[<INDEX>]`, for example, `aws_instance.server[0]` and
+  `aws_instance.server[1]` refer to individual instances.
+
+This is different from resources and modules without `count` or [`for_each`](/terraform/language/meta-arguments/for_each), which can be referenced without an index or key.
+
+Similarly, resources from child modules with multiple instances are prefixed
+with `module.<NAME>[<KEY>]` when displayed in plan output and elsewhere in the UI.
+For a module without `count` or `for_each`, the address will not contain
+the module index as the module's name suffices to reference the module.
+
+Within nested [`provisioner`](/terraform/language/block/resource#provisioner) or [`connection`](/terraform/language/block/resource#connection) blocks, the special `self` object refers to the current resource instance, not the `resource` block as a whole.
+
+### How to choose between `count` and `for_each`
+
+`count` and [`for_each`](/terraform/language/meta-arguments/for_each) perform a similar function. Use the `count` argument when you want to create nearly identical instances. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
+integer index. You cannot use both a `count` and ` for_each` argument in the same `resource` or `module` block.
+
+## Supported constucts
+
+You can use `count` in the following Terraform configuration blocks:
+
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Example use cases
+
+The following use cases describe common patterns for the `count` argument.
+
+### Create multiple instances of module resources
+
+In the following example, Terraform creates three EC2 instances, each with a unique name from the `instance_names` list:
+
+```hcl
+locals {
+  instance_names = ["web", "api", "batch"]
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  count   = length(local.instance_names)
+
+  name           = local.instance_names[count.index]
+  ami            = data.aws_ami.latest_amazon_linux.id
+  instance_type  = "t2.micro"
+
+  depends_on = [aws_s3_bucket.example]
+}
+
+```
+
+### Create multiple instances of a resource
+
+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}"
+  }
+}
+```
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/depends_on.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/depends_on.mdx
new file mode 100644
index 0000000000..46a5366397
--- /dev/null
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/depends_on.mdx
@@ -0,0 +1,194 @@
+---
+page_title: depends_on meta-argument reference
+description: Learn how the `depends_on` meta-argument works in Terraform configuration.
+---
+
+# `depends_on` reference
+
+Use the `depends_on` meta-argument to handle hidden resource or module dependencies that Terraform cannot automatically infer. You only need to explicitly specify a dependency when a resource or module relies on another resource's behavior but does not access any of that resource's data in its arguments. 
+
+## Usage
+
+You can use the `depends_on` meta-argument in `module` blocks and in all `resource` blocks, regardless of resource type. 
+
+It requires a list of references to other resources or child modules in the same calling module. This list cannot include arbitrary expressions because the `depends_on` value must be known before Terraform knows resource relationships and thus before it can safely evaluate expressions. 
+
+In the following example, the `depends_on` argument instructs Terraform to handle a hidden dependency on the `aws_iam_instance_profile.example` resource.
+
+```hcl
+resource "aws_iam_role" "example" {
+  name = "example"
+
+  # assume_role_policy is omitted for brevity in this example. Refer to the
+  # documentation for aws_iam_role for a complete example.
+  assume_role_policy = "..."
+}
+
+resource "aws_iam_instance_profile" "example" {
+  # Because this expression refers to the role, Terraform automatically
+  # infers that the role must be created first.
+  role = aws_iam_role.example.name
+}
+
+resource "aws_iam_role_policy" "example" {
+  name   = "example"
+  role   = aws_iam_role.example.name
+  policy = jsonencode({
+    "Statement" = [{
+      # This policy allows software running on the EC2 instance to
+      # access the S3 API.
+      "Action" = "s3:*",
+      "Effect" = "Allow",
+    }],
+  })
+}
+
+resource "aws_instance" "example" {
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+
+  # Terraform can infer from this that the instance profile must
+  # be created before the EC2 instance.
+  iam_instance_profile = aws_iam_instance_profile.example
+
+  # However, if software running in this EC2 instance needs access
+  # to the S3 API in order to boot properly, there is also a 
+  # dependency on the aws_iam_role_policy that Terraform cannot
+  # automatically infer, so you must declare it explicitly:
+  depends_on = [
+    aws_iam_role_policy.example
+  ]
+}
+```
+
+## Processing and planning consequences
+
+The `depends_on` meta-argument instructs Terraform to complete all actions on the dependency object, including read operations, before performing operations on the object declaring the dependency. When the dependency object is an entire module, `depends_on` affects the order in which Terraform processes all of the resources and data sources associated with that module. Refer to the documentation on [specifying resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and [data resource dependencies](/terraform/language/data-sources#dependencies) for more details.
+
+You should only use `depends_on` as a last resort because it can cause Terraform to create more conservative plans that replace more resources than necessary. For example, Terraform may treat more values as unknown `"(known after apply)"` because it is uncertain what changes will occur on the upstream object. This is especially likely when you use `depends_on` for modules.
+
+Instead of `depends_on`, we recommend using [expression references](/terraform/language/expressions/references) to imply dependencies when possible. Expression references let Terraform understand which value the reference derives from and avoid planning changes if that particular value hasn’t changed, even if other parts of the upstream object have planned changes.
+
+## Supported constructs
+
+You can use `depends_on` in the following Terraform configuration blocks:
+
+- [`check` blocks](/terraform/language/block/resource)
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`output` blocks](/terraform/language/block/output)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Example use cases 
+
+The following use cases describe common patterns for the `depends_on` argument.
+
+### Specify a dependency during validation
+
+Add a `depends_on` argument to a `data` block nested in a [`check` block](/terraform/language/block/check) validation when the data source depends on another resource but doesn't reference the resource directly.  
+
+`check` blocks validate infrastructure outside of the typical resource lifecycle. You can nest a `data` block inside a `check` block to fetch information that you can reference in an `assert` block. By adding a `depends_on` argument to the `data` block nested in a `check` block requires, Terraform retrieves the necessary data before running the validation.
+
+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. 
+
+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"
+ }
+}
+```
+
+### Create a database service that other services depend on 
+
+In the following example, Terraform must launch the `aws_db_instance` service first so that `aws_instance` can connect to it:
+
+```hcl
+provider "aws" {
+  region = "us-east-2"
+}
+
+data "aws_ami" "ubuntu" {
+  most_recent = true
+
+  filter {
+    name   = "name"
+    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
+  }
+
+  filter {
+    name   = "virtualization-type"
+    values = ["hvm"]
+  }
+
+  owners = ["099720109477"] # Canonical
+}
+
+resource "aws_db_instance" "api" {
+  allocated_storage   = 10
+  db_name             = "api_db"
+  engine              = "postgres"
+  engine_version      = "17.4"
+  instance_class      = "db.t3.micro"
+  username            = "foo"
+  password            = "foobarbaz"
+  skip_final_snapshot = true
+}
+
+resource "aws_instance" "api" {
+  ami           = data.aws_ami.ubuntu.id
+  instance_type = "t3.micro"
+
+  depends_on = [aws_db_instance.api]
+}
+```
+
+### Specify a dependency on the parent module
+
+In the following example, Terraform only creates the EC2 instance module after creating the S3 bucket resource:
+
+```hcl
+resource "aws_s3_bucket" "example" {
+  bucket = "my-example-bucket-12345"
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  name    = "example-instance"
+  ami           = data.aws_ami.latest_amazon_linux.id
+  instance_type = "t2.micro"
+
+  depends_on = [aws_s3_bucket.example]
+}
+```
+
+### Specify a dependency when outputting values
+
+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.
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/for_each.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/for_each.mdx
new file mode 100644
index 0000000000..3b4d3c6a8f
--- /dev/null
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/for_each.mdx
@@ -0,0 +1,304 @@
+---
+page_title: for_each meta-argument reference
+description: Learn how the `for_each` meta-argument works in Terraform configuration.
+---
+
+# `for_each` reference
+
+By default, [`resource` block](/terraform/language/block/resource) configures one real infrastructure object. Similarly, a [`module` block](/terraform/language/block/module) includes a child module's contents into the configuration one time. 
+
+Use the `for_each` meta-argument to manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each object. When a `resource`, `module`, or `ephemeral` block includes a `for_each` argument, Terraform creates an instance for each member of the list or map specified as the value.
+
+## Usage
+
+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. All values that the `for_each` argument iterates over must be known before Terraform performs any remote resource operations. Specifying references to resource attributes that are only known after a configuration is applied, such as a unique ID generated by the remote API when an object is created, will result in an error.
+
+The following example creates two `azurerm_resource_group` resources 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 `aws_iam_user` resources 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
+}
+```
+
+### Limitations on values
+
+The keys of the map or all values in a set of strings must be known values. Otherwise, Terraform returns an error message that `for_each` has dependencies that cannot be determined before apply and that a `-target` may be needed.
+
+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.
+
+You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Sensitive values are not allowed because Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
+
+If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. Refer to [Using sensitive data as function arguments](/terraform/language/expressions/function-calls#using-sensitive-data-as-function-arguments) for more information.
+
+In many cases, you can use a `for` expression to achieve similar results. 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` with `toset([for k,v in local.map : k])`. Refer to [Manage sensitive data](/terraform/language/manage-sensitive-data) for more information.
+
+### Expressions in `for_each`
+
+The `for_each` meta-argument accepts map or set [expressions](/terraform/language/expressions), but unlike most arguments, the value must be known before Terraform performs any remote resource actions. As a result, `for_each` can't refer to any resource attributes that aren't known until after a
+configuration is applied, such as a unique ID generated by the remote API when
+an object is created.
+
+The `for_each` value must be a map or set with one element per desired resource
+instance. To use a sequence as the `for_each` value, you must use an expression
+that explicitly returns a set value, such as the [`toset` function](/terraform/language/functions/toset). 
+
+To prevent unexpected behavior during conversion, 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).
+
+### Referring to instances
+
+In blocks where `for_each` is set, Terraform creates an additional `each` object that you can use in expressions to modify the configuration of each instance.
+This object has the following attributes:
+
+- `each.key`: The map key or set member corresponding to this instance.
+- `each.value`: The map value corresponding to this instance. If a set is provided, this is the same as `each.key`.
+
+Terraform makes a distinction between the block containing the `for_each` argument and the instances associated with it. Terraform identifies instances by the map key or set member using the value provided to `for_each`.
+
+- `<TYPE>.<NAME>` or `module.<NAME>`: For example, `azurerm_resource_group.rg` refers to the block.
+- `<TYPE>.<NAME>[<KEY>]` or `module.<NAME>[<KEY>]`: For example, `azurerm_resource_group.rg["a_group"]` and `azurerm_resource_group.rg["another_group"]` refer to individual instances.
+
+This is different from resources and modules without [`count`](/terraform/language/meta-arguments/count) or `for_each`, which can be
+referenced without an index or key.
+
+Similarly, resources from child modules with multiple instances are prefixed
+with `module.<NAME>[<KEY>]` when displayed in plan output and elsewhere in the UI.
+For a module without `count` or `for_each`, the address does not contain
+the module index as the module's name suffices to reference the module.
+
+Within nested [`provisioner`](/terraform/language/block/resource#provisioner) or [`connection`](/terraform/language/block/resource#connection) blocks, the special `self` object refers to the current resource instance, not the resource block as a whole.
+
+### Chain `for_each` between resources
+
+Because a resource using `for_each` appears as a map of objects when used in
+expressions elsewhere, you can directly use one resource as the `for_each`
+of another in situations where there is a one-to-one relationship between
+two sets of objects.
+
+For example, in AWS an `aws_vpc` object is commonly associated with a number
+of other objects that provide additional services to that VPC, such as an
+internet gateway. If you are declaring multiple VPC instances using `for_each`
+then you can chain that `for_each` into another resource to declare an
+internet gateway for each VPC:
+
+```hcl
+variable "vpcs" {
+  type = map(object({
+    cidr_block = string
+  }))
+}
+
+resource "aws_vpc" "example" {
+  # One VPC for each element of var.vpcs
+  for_each = var.vpcs
+
+  # each.value here is a value from var.vpcs
+  cidr_block = each.value.cidr_block
+}
+
+resource "aws_internet_gateway" "example" {
+  # One Internet Gateway per VPC
+  for_each = aws_vpc.example
+
+  # each.value here is a full aws_vpc object
+  vpc_id = each.value.id
+}
+
+output "vpc_ids" {
+  value = {
+    for k, v in aws_vpc.example : k => v.id
+  }
+
+  # The VPCs aren't fully functional until their
+  # internet gateways are running.
+  depends_on = [aws_internet_gateway.example]
+}
+```
+
+This chain pattern explicitly and concisely declares the relationship
+between the internet gateway instances and the VPC instances, which tells
+Terraform to expect the instance keys for both to always change together,
+and typically also makes the configuration easier to understand for human
+maintainers.
+
+### Using sets
+
+The Terraform language doesn't have a literal syntax for [set values](/terraform/language/expressions/type-constraints#collection-types), but you can use the [`toset` function](/terraform/language/functions/toset) to explicitly convert a list of strings to a set:
+
+```hcl
+locals {
+  subnet_ids = toset([
+    "subnet-abcdef",
+    "subnet-012345",
+  ])
+}
+
+resource "aws_instance" "server" {
+  for_each = local.subnet_ids
+
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+  subnet_id     = each.key # note: each.key and each.value are the same for a set
+
+  tags = {
+    Name = "Server ${each.key}"
+  }
+}
+```
+
+Conversion from list to set discards the ordering of the items in the list and
+removes any duplicate elements. For example, `toset(["b", "a", "b"])` produces a set
+containing only `"a"` and `"b"` in no particular order and discards the second `"b"`.
+
+If you are writing a module with an [input variable](/terraform/language/values/variables) that
+will be used as a set of strings for `for_each`, you can set its type to
+`set(string)` so that you don't need an explicit type conversion:
+
+```hcl
+variable "subnet_ids" {
+  type = set(string)
+}
+
+resource "aws_instance" "server" {
+  for_each = var.subnet_ids
+  #...
+}
+```
+
+### How to choose between `for_each` and `count`
+
+The [`count` meta-argument](#count) performs a similar operation to `for_each`. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
+integer. Use the `count` argument when you want to create nearly identical instances.
+
+You cannot use both a `count` and ` for_each` argument in the same block.
+
+## Supported constucts
+
+You can use `for_each` in the following Terraform configuration blocks:
+
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Examples
+
+The following use cases describe common patterns for the `for_each` argument.
+
+### Create multiple ephemeral resources
+
+In the following example, the `for_each` argument creates multiple passwords for different database environments:
+
+<CodeBlockConfig highlight="6, 18">
+
+```hcl
+locals {
+  environments = toset(["dev", "staging", "prod"])
+}
+
+ephemeral "random_password" "db_passwords" {
+  for_each = local.environments
+
+  length           = 16
+  override_special = "!#$%&*()-_=+[]{}<>:?"
+}
+
+resource "aws_db_instance" "databases" {
+  for_each = local.environments
+
+  identifier                = "${each.key}-database"
+  db_name                   = "${each.key}db"
+  username                  = "dbadmin"
+  password_wo               = ephemeral.random_password.db_passwords[each.key].result
+ # …
+}
+```
+
+</CodeBlockConfig>
+
+The `ephemeral` block creates a `random_password` ephemeral resource for each environment in the `local.environments` set. The `aws_db_instance` resource then uses the generated passwords for each database instance.
+
+Terraform does not store the generated `db_passwords` values, but you can capture them in another resource to ensure those values are not lost. For an example of generating, storing, retrieving, and using an ephemeral password, refer to [write-only arguments](/terraform/language/manage-sensitive-data/write-only#set-and-store-an-ephemeral-password-in-aws-secrets-manager).
+
+### Create multiple instances of module resources
+
+In the following example, Terraform creates one EC2 instance for each key in `local.instance_configs`, allowing you to customize properties per instance:
+
+```hcl
+locals {
+  instance_configs = {
+    "example-instance-1" = { instance_type = "t2.micro" }
+    "example-instance-2" = { instance_type = "t2.small" }
+    "example-instance-3" = { instance_type = "t2.medium" }
+  }
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  for_each = local.instance_configs
+
+  name           = each.key
+  ami            = data.aws_ami.latest_amazon_linux.id
+  instance_type  = each.value.instance_type
+
+  depends_on = [aws_s3_bucket.example]
+}
+```
+
+### Create multiple instances of a resource
+
+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>
+
+### Import multiple resources
+
+You can use `for_each` to import multiple resources. Refer to the [`import` block documentation](/terraform/language/block/import#import-multiple-resources) for an example.
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/index.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/index.mdx
new file mode 100644
index 0000000000..60221d6c63
--- /dev/null
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/index.mdx
@@ -0,0 +1,49 @@
+---
+page_title: Meta-arguments
+description: Meta-arguments are built-in Terraform arguments that determine how Terraform creates and manages resources.
+---
+
+# Meta-arguments
+
+Meta-arguments are a class of arguments built into the Terraform configuration language that control how Terraform creates and manages your infrastructure. You can use meta-arguments in any type of resource. You can also use most meta-arguments in `module` blocks.
+
+The provider developer determines resource-specific arguments, but all resources support meta-arguments that let you manage resources' infrastructure lifecycle, including destruction behavior, preventing destruction, and establishing dependencies between resources. Terraform provides the following meta-arguments.
+
+<Note>
+
+Terraform `v1.14.x (beta)` adds the `action_trigger` meta-argument, which lets you trigger actions that extend Terraform CRUD operations. Refer to the [Invoke an action](/terraform/language/v1.14.x/invoke-actions) beta documentation for more information.
+
+</Note>
+
+## `depends_on`
+
+The `depends_on` meta-argument instructs Terraform to complete all actions on the dependency object, including `read` operations, before performing actions on the object declaring the dependency. Use the `depends_on` argument to explicitly set the order in which Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details.
+
+> **Hands-on**: Complete the [Create resource dependencies](/terraform/tutorials/configuration-language/dependencies) tutorial to learn how to declare dependencies.
+
+## `count`
+
+By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. Terraform also creates single instances of a module per `module` block. You can add the `count` argument to `resource`, `module`, and `ephemeral` blocks to create and manage multiple instances of each without writing a separate block for each instance. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details.
+
+> **Hands-on**: Complete the [Manage similar resources with count](/terraform/tutorials/0-13/count) tutorial to learn how to create multiple instances of a resource.
+
+## `for_each`
+
+By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. You can add the `for_each` block to your `resource`, `data`, `module`, and `ephemeral` blocks to create and manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each instance. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details.
+
+> **Hands-on**: Complete the [Manage similar resources with for each](/terraform/tutorials/configuration-language/for-each) tutorial to learn how to create multiple instances of a resource.
+
+## `lifecycle`
+
+The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details. 
+
+> **Hands-on**: Complete the [Manage resource lifecycle](/terraform/tutorials/state/resource-lifecycle) tutorial to learn how to manage the lifecycle of your infrastructure resources. 
+
+## `provider`
+
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details.
+
+## `providers`
+
+By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details.
+
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/lifecycle.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/lifecycle.mdx
new file mode 100644
index 0000000000..2b96af2b04
--- /dev/null
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/lifecycle.mdx
@@ -0,0 +1,329 @@
+---
+page_title: lifecycle meta-argument reference
+description: How to configure the lifecycle meta-argument rules in Terraform--create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by, precondition, postcondition, destroy
+---
+
+# `lifecycle` reference
+ 
+Terraform performs the following operations when you apply a configuration:
+
+1. Creates resources defined in the configuration that are not associated with a real infrastructure object in the state.
+1. Destroys resources that exist in the state but not in the configuration.
+1. Updates resources in-place whose arguments have changed.
+1. Destroys and re-create resources whose arguments have changed but that Terraform cannot update in-place because of remote API limitations.
+
+The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. 
+
+## Usage
+
+All `lifecycle` settings affect how Terraform constructs and traverses
+the dependency graph. As a result, only literal values can be used because
+the processing happens too early for arbitrary expression evaluation.
+
+Support for each lifecycle rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details. 
+
+Depending on the block you are configuring, you may be able to use one or more of the following rules.
+
+### `create_before_destroy` 
+
+By default, when Terraform must change a resource argument that cannot be updated in-place due to remote API limitations, Terraform destroys the existing object and then create a new replacement object with the new configured arguments. Use the `create_before_destroy` rule to instruct Terraform to create a replacement resource before destroying the current resource. 
+
+This is an opt-in behavior because many remote object types have unique name requirements or other constraints that must be accommodated for both a new and an old object to exist concurrently. Some resource types offer special options to append a random suffix onto each object name to avoid collisions, for example. Terraform CLI cannot automatically activate such features, so you must understand the constraints for each resource type before using `create_before_destroy` with it.
+
+#### `create_before_destroy` and resource dependencies
+
+Terraform propagates and applies `create_before_destroy` behavior to all resource dependencies. For example: 
+
+- `create_before_destroy` is enabled on resource `A` but not on resource `B`.
+- Because resource `A` is dependent on resource `B`, Terraform enables `create_before_destroy` for resource `B` implicitly by default and stores it to the state file. 
+
+As a result, you cannot override `create_before_destroy`
+to `false` on resource `B` because that would imply dependency cycles in the graph.
+
+When the resource contains a provisioner that runs during the `destroy` operation,  setting `create_before_destroy` to `true` also prevents the provisioner from running. 
+
+You can use `create_before_destroy` in [`resource`](/terraform/language/block/resource) blocks. 
+
+
+### `prevent_destroy` 
+
+When `prevent_destroy` is set to `true`, Terraform rejects plans that would destroy the infrastructure object associated with the resource and returns an error. The argument must be present in the configuration. This rule doesn't prevent Terraform from destroying a resource if you remove its configuration. Refer to [Remove a resource from state](/terraform/language/state/remove) for instructions on how to remove a resource from state without destroying the actual resource.
+
+Use this rule as protection against accidentally replacing objects that may be costly to reproduce, such as database instances. Enabling `prevent_destory`, however, makes certain configuration changes impossible to apply
+and prevents the `terraform destroy` command from operating once such objects are created. Use `prevent_destroy` sparingly.
+
+You can use `prevent_destroy` in in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `ignore_changes` 
+
+By default, Terraform detects any difference in the current settings of a real infrastructure object and plans to update the remote object to match configuration. Use the `ignore_changes` argument when a resource is created with references to data that may change in the future, but should not affect the resource after its creation. 
+
+In some rare cases, a remote object's settings are modified by processes outside of Terraform, which Terraform attempts to resolve on the next run. To let Terraform share management responsibilities of a single object with a separate process, the `ignore_changes` meta-argument specifies resource attributes that Terraform should ignore when planning updates to the associated remote object.
+
+Terraform considers the arguments corresponding to the given attribute names when planning a `create` operation, but are ignored when planning an
+`update` operation. The arguments are the relative address of the attributes in the resource. You can reference map and list elements using index notation,
+such as `tags["Name"]` and `list[0]`.
+
+In the following example, Terraform ignores changes to `tags` so that a management agent can update them based on a rule set managed elsewhere:
+
+```hcl
+resource "aws_instance" "example" {
+   # ...
+   lifecycle {
+      ignore_changes = [
+         tags
+      ]  
+   }
+}
+```
+
+Instead of a list of items, you can use the `all` keyword to instruct
+Terraform to ignore all attributes. As a result, Terraform can
+create and destroy the remote object but will never propose updates to it.
+
+Terraform only ignores attributes defined by the resource type. You can't apply 
+`ignore_changes` to itself or to any other meta-arguments.
+
+You can use `ignore_changes` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `replace_triggered_by` 
+
+Terraform replaces the resource when any of the referenced resources or specified attributes change. Supply a list of expressions that reference managed resources, instances, or instance attributes. 
+
+When used in a resource that uses [`count`](/terraform/language/meta-arguments/count) or [`for_each`](/terraform/language/meta-arguments/for_each), you can use `count.index` or `each.key` in the expression to reference specific instances of other resources that are configured with the same count or collection.
+
+References trigger replacement in the following conditions:
+
+- If the reference is to a resource with multiple instances, a plan to
+   update or replace any instance triggers a replacement.
+- If the reference is to a single resource instance, a plan to update or
+   replace that instance triggers a replacement.
+- If the reference is to a single attribute of a resource instance, any
+   change to the attribute value triggers a replacement.
+
+You can only reference managed resources in `replace_triggered_by`
+expressions. This lets you modify these expressions without forcing
+replacement. 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
+      ]
+   }
+}
+```
+
+`replace_triggered_by` allows only resource addresses because the decision is based on the planned actions for all of the given resources. Plain values, such as local values or input variables, do not have planned actions of their own, but you can treat them with a resource-like lifecycle by using them with the [`terraform_data` resource](/terraform/language/resources/terraform-data).
+
+You can use `replace_triggered_by` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `precondition` 
+
+Specifies a condition that Terraform evaluates before creating the resource. 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`](/terraform/language/meta-arguments/count) and [`for_each`](/terraform/language/meta-arguments/for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
+
+You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
+
+Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration. 
+
+You can use `precondition` in the following Terraform configuration blocks:
+
+- [`data`](/terraform/language/block/data)
+- [`ephemeral`](/terraform/language/block/ephemeral)
+- [`resource`](/terraform/language/block/resource) 
+
+### `postcondition` 
+
+Specifies a condition that Terraform evaluates after creating the resource. The following arguments in the `precondition` block are required:
+
+| Argument | Description | Data type |
+| --- | --- | --- |
+| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
+| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
+
+Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. Postcondition failures prevent changes to other resources that depend on the failing resource.
+
+You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
+
+Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
+
+You can use `precondition` in the following Terraform configuration blocks:
+
+- [`data`](/terraform/language/block/data) 
+- [`ephemeral`](/terraform/language/block/ephemeral)
+- [`resource`](/terraform/language/block/resource) 
+
+### `destroy` 
+
+Set to `false` to remove a resource from state without destroying the actual infrastructure resource. You can only use this rule in [`removed`](/terraform/language/block/removed) block.
+
+## Supported constructs
+
+Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details.
+
+
+## Example use cases
+
+The following use cases describe common patterns for the `lifecycle` argument.
+
+
+### 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
+     ]
+   }
+}
+```
+
+### Validate the AMI for creating instances
+
+In the following example, the `precondition` block ensures that the AMI ID retrieved from the `data` block includes `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
+data "aws_ami" "example" {
+  most_recent= true
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-*"]
+  }
+}
+
+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."
+    }
+  }
+}
+```
+### Validate that a root storage volume is encrypted
+
+In the following example, the `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."
+    }
+  }
+}
+
+data "aws_ami" "example" {
+  most_recent= true
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-*"]
+  }
+}
+
+resource "aws_instance" "example" {
+  instance_type = "t3.micro"
+  ami           = data.aws_ami.example.id
+}
+
+output "api_base_url" {
+  value = "https://${aws_instance.example.private_dns}:8433/"
+}
+```
+
+The validation fails in this example, so Terraform prints the following message to the console:
+
+```shell-session
+│ Error: Resource postcondition failed
+│
+│   on main.tf line 31, in data "aws_ebs_volume" "example":
+│   31:       condition     = self.encrypted
+│     ├────────────────
+│     │ self.encrypted is false
+│
+│ The server's root volume is not encrypted.
+```
+
+### Validate ephemeral resources
+
+In the following example, the `aws_ssm_parameter` ephemeral resource has a `precondition` to ensure that compliance mode is enabled to secure production secrets, and a `postcondition` to ensure the generated password meets password requirements:
+
+<CodeBlockConfig highlight="15-25">
+
+```hcl
+variable "environment" {
+  description = "Deployment environment"
+  type        = string
+}
+
+variable "compliance_mode" {
+  description = "Enable compliance requirements for production"
+  type        = bool
+  default     = false
+}
+
+ephemeral "aws_ssm_parameter" "database_password" {
+  name = "/secrets/${var.environment}/database/password"
+
+  lifecycle {
+    precondition {
+      condition     = var.environment != "prod" || var.compliance_mode == true
+      error_message = "Enable compliance mode to assess production secrets."
+    }
+
+    postcondition {
+      condition     = can(regex("^[A-Za-z0-9!@#$%^&*()_+=-]{16,}$", self.value))
+      error_message = "Password from external source must meet security requirements."
+    }
+  }
+}
+```
+
+</CodeBlockConfig>
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx
new file mode 100644
index 0000000000..717b2056b3
--- /dev/null
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx
@@ -0,0 +1,117 @@
+---
+page_title: provider meta-argument reference
+description: Learn how the `provider` meta-argument works in Terraform configuration.
+---
+
+# `provider` reference
+
+The `provider` meta-argument specifies which provider configuration to use for a resource,
+overriding Terraform's default behavior of selecting one based on the resource
+type name. Note that the `provider` argument is distinct from the [`provider` block](/terraform/language/block/provider), which contains provider configuration settings. Refer to [Providers](/terraform/language/providers) for more information.
+
+## Usage
+
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider. 
+
+You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. For its value, the `provider` argument expects a reference formatted as `<PROVIDER>.<ALIAS>`. 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
+  # ...
+}
+```
+
+Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions. 
+
+A resource always has an implicit dependency on its associated provider. This ensures that the provider is fully configured before Terraform takes any actions on resources.
+
+Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services. 
+
+## Supported constructs
+
+You can use `provider` in the following Terraform configuration blocks:
+
+- [`check` blocks](/terraform/language/block/check)
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`import` block ](/terraform/language/block/import)
+- [`resource` blocks](/terraform/language/block/resource)
+
+## Example use cases
+
+The following use cases describe common patterns for the `provider` argument. Refer to the [examples in the `provider` block reference](/terraform/language/block/provider#examples) for more use cases.
+
+### Query a data source in different region
+
+In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
+
+```hcl
+provider "google" {
+  region = "us-central1"
+}
+
+provider "google" {
+  alias  = "europe"
+  region = "europe-west1"
+}
+
+data "google_compute_instance" "example" {
+  provider = google.europe
+  # ...
+}
+```
+
+### Use alternate provider for an ephemeral resource
+
+In the following example, Terraform uses the `aws.west` provider configuration to create the `aws_secretsmanager_secret_version` resource in the `us-west-2` region:
+
+```hcl
+provider "aws" {
+  region = "us-east-1"
+}
+
+provider "aws" {
+  alias  = "west"
+  region = "us-west-2"
+}
+
+ephemeral "aws_secretsmanager_secret_version" "db_password" {
+  provider  = aws.west
+  secret_id = aws_secretsmanager_secret.db_password.id
+}
+```
+
+### Import resources using an alternate provider configuration
+
+In the following example, Terraform imports the AWS instance with the ID `i-096fba6d03d36d262` to the `aws_instance.web` resource according to the `east` alias.
+
+```hcl
+provider "aws" {
+  region = "us-westl-1"
+}
+
+provider "aws" {
+  alias  = "east"
+  region = "us-east-1"
+}
+
+import {
+  id = "i-096fba6d03d36d262"
+  to = aws_instance.web
+  provider = aws.east
+}
+
+resource "aws_instance" "web" {
+  # ...
+}
+```
\ No newline at end of file
diff --git a/content/terraform/v1.13.x/docs/language/meta-arguments/providers.mdx b/content/terraform/v1.13.x/docs/language/meta-arguments/providers.mdx
new file mode 100644
index 0000000000..eef39f1b6e
--- /dev/null
+++ b/content/terraform/v1.13.x/docs/language/meta-arguments/providers.mdx
@@ -0,0 +1,120 @@
+---
+page_title: providers meta-argument reference
+description: Learn how the `providers` meta-argument works in Terraform configuration.
+---
+
+# `providers` reference
+
+By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources.
+
+## Usage
+
+In a [`module` block](/terraform/language/block/module), you can add the optional `providers` meta-argument to specify which [provider configurations](/terraform/language/modules/configuration) from the parent module is available inside the child module.
+
+The value of `providers` is a map, where the keys are the provider configuration names used inside the child module and the values are provider configuration names from the parent module.
+
+Keys and values are unquoted references to provider configurations.
+For default configurations, the reference is the local name of the provider. For
+alternate configurations, the reference uses a `<PROVIDER>.<ALIAS>` format.
+
+Within a child module, either Terraform chooses a default based on the name of the resource
+type, or the resource specifies an alternate configuration with the `provider`
+argument. If the module receives a `providers` map when it's called, the
+provider configuration names used within the module are effectively remapped to
+refer the specified configurations from the parent module.
+
+In the following example, Terraform uses the default `aws` configuration for AWS resources in the root module where no explicit provider instance is selected, but the example child moduleuses the alternate configuration with the alias `usw2`. As a result, any AWS resources the module defines uses the `us-west-2` region.
+
+
+```hcl
+provider "aws" {
+  region = "us-west-1"
+}
+
+provider "aws" {
+  alias  = "usw2"
+  region = "us-west-2"
+}
+
+module "example" {
+  source    = "./example"
+  providers = {
+    aws = aws.usw2
+  }
+}
+```
+
+### Default behavior
+
+The `providers` argument is optional when the child module does not declare a [`configuration_aliases`](/terraform/language/modules/develop/providers#provider-aliases-within-modules). When you omit the argument, a child module inherits all of the default provider configurations from its parent module. Default provider configurations are configurations that don't have an `alias` argument.
+
+Specifying a `providers` argument cancels the default behavior. As a result, the child module only has access to the provider configurations you specify.
+
+### When to specify `providers`
+
+Add the `providers` argument when one of the following conditions apply:
+
+- Using different default provider configurations for a child module.
+- Configuring a module that requires multiple configurations of the same provider.
+
+### Change default provider configurations
+
+Most re-usable modules only use default provider configurations, which they can
+automatically inherit from their caller when `providers` is omitted.
+
+However, in Terraform configurations that use multiple configurations of the same provider, you might want some child modules to use the default provider configuration and others to use an alternate. 
+A common use case is using one configuration to manage resources in multiple different regions of the same cloud provider.
+
+Using `providers` argument lets you accommodate this without needing to edit the child module. Although the code
+within the child module always refers to the default provider configuration, the
+actual configuration of that default can be different for each instance.
+
+
+## Information for module developers
+
+For more details and guidance about working with providers inside a re-usable
+child module, refer to [Providers Within Modules](/terraform/language/modules/develop/providers).
+
+## Supported constructs
+
+You can use `providers` in the following Terraform configuration blocks:
+
+- [`module` blocks](/terraform/language/block/module)
+
+### Example use cases
+
+The following use cases describe common patterns for the `providers` argument.
+
+### Modules with alternate provider configurations
+
+In rare cases, a single re-usable module might require multiple configurations
+of the same provider. For example, a module that configures connectivity between
+networks in two AWS regions is likely to need both a `source` and a `destination`
+region. 
+
+In the following example, the `tunnel` module includes resources that support their own provider configuration. As a result, each resource alias maps to a different provider configurations declared in the root module:
+
+```hcl
+provider "aws" {
+  alias  = "usw1"
+  region = "us-west-1"
+}
+
+provider "aws" {
+  alias  = "usw2"
+  region = "us-west-2"
+}
+
+module "tunnel" {
+  source    = "./tunnel"
+  providers = {
+    aws.src = aws.usw1
+    aws.dst = aws.usw2
+  }
+}
+```
+
+Non-default provider configurations are never automatically inherited, so any
+module that works in this manner always requires a `providers` argument. The
+documentation for the module should specify all of the provider configuration
+names it needs.
diff --git a/content/terraform/v1.14.x (beta)/data/language-nav-data.json b/content/terraform/v1.14.x (beta)/data/language-nav-data.json
index a88636531f..f1a088ce7f 100644
--- a/content/terraform/v1.14.x (beta)/data/language-nav-data.json	
+++ b/content/terraform/v1.14.x (beta)/data/language-nav-data.json	
@@ -389,7 +389,37 @@
   },
   {
     "title": "Meta-arguments",
-    "path": "meta-arguments"
+    "routes": [
+      {
+        "title": "Overview",
+        "path": "meta-arguments",
+        "alias": "actions"
+      },
+      {
+        "title": "count",
+        "path": "meta-arguments/count"
+      },
+      {
+        "title": "depends_on",
+        "path": "meta-arguments/depends_on"
+      },
+      {
+        "title": "for_each",
+        "path": "meta-arguments/for_each"
+      },
+      {
+        "title": "lifecycle",
+        "path": "meta-arguments/lifecycle"
+      },
+      {
+        "title": "provider",
+        "path": "meta-arguments/provider"
+      },
+      {
+        "title": "providers",
+        "path": "meta-arguments/providers"
+      }
+    ]
   },
   {
     "title": "Built-in resources",
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/action.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/action.mdx
index 9b89d09937..3a9c54d2de 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/action.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/action.mdx	
@@ -14,8 +14,8 @@ The `action` block supports the following configuration:
 - [`action "<TYPE>" "<LABEL>"`](#action) &nbsp block
    - [`config`](#config) &nbsp; map of arguments or nested blocks
       - [`PROVIDER ARGUMENTS`](#config)
-  - [`for_each`](#for_each) &nbsp; map or set of strings | mutually exclusive with `count`
   - [`count`](#count) &nbsp; number | mutually exclusive with `for_each`
+  - [`for_each`](#for_each) &nbsp; map or set of strings | mutually exclusive with `count`
   - [`provider`](#provider) &nbsp; reference 
 
 ## Complete configuration
@@ -72,6 +72,18 @@ The `config` block may contain arguments, nested blocks, or a combination of bot
 - Data type: Map of arguments or nested blocks
 - Example: [Define an action](#define-an-action)
 
+### `count`
+
+The `count` meta-argument instructs Terraform to invoke an action multiple times using the same configuration.
+
+```hcl
+resource {
+  count = <number>
+}
+```
+
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
+
 ### `for_each` 
 
 The `for_each` meta-argument instructs Terraform to invoke the action once for each member of a list or key-value pair in a map.
@@ -103,67 +115,7 @@ action "<TYPE>" "<LABEL>" {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and invokes the action once for each item in that map or set. Each invocation is associated with a distinct infrastructure object. 
-
-You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. All values must be known when Terraform plans your action, whether iterating over the keys of a map or set of strings. 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, such as `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
-
-The `for_each` argument does not implicitly convert lists or tuples to sets. To declare resource instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Because Terraform uses the value in `for_each` to identify the action instance and always discloses it in UI output, 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 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 [Manage sensitive data](/terraform/language/manage-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 action. 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, `aws_lambda_invoke.server["a_group"]` refers to an invocation of the `aws_lambda_invoke` action named `server` from a key named `a_group`.
-
-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: [Invoke an action multiple times](#invoke-an-action-multiple-times).
-
-### `count`
-
-The `count` meta-argument instructs Terraform to invoke an action multiple times using the same 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 invocation. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual instance of an invocation using the `count` meta-argument, use the `<TYPE>.<NAME>[INDEX]` syntax. For example, `aws_lambda_invoke.server[0]` refers to the first invocation of the `aws_lambda_invoke` action named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to invoke an action three times when a variable named `creator` is set to `true`. When `creator` is set to `false`, Terraform does not invoke the action. 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: [Invoke an action multiple times](#invoke-an-action-multiple-times).
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -175,17 +127,7 @@ action "<TYPE>" "<LABEL>" {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the action type, but you can create multiple provider configurations and use a non-default configuration for specific actions.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument.
-
-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) for more information.
-
-#### Summary
-
-- Data type: Reference.
-- Default: None.
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration).
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/check.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/check.mdx
index 61bf3dcf66..8f03965e02 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/check.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/check.mdx	
@@ -122,7 +122,7 @@ The arguments within a `data` block are provider-specific. Refer to the [registr
 
 ### `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.
+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" {
@@ -135,13 +135,7 @@ check "unique_name" {
 }
 ```
 
-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) for additional information.
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `provider`
 
@@ -158,16 +152,7 @@ check "unique_name" {
 }
 ```
 
-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) for additional information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Supported meta-arguments: `depends_on` and `provider`.
-- Example: [Resource dependency](#resource-dependency).
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/data.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/data.mdx
index c980349cdc..ce9e8248f9 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/data.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/data.mdx	
@@ -74,7 +74,7 @@ The provider developer determines which arguments you can define for a data sour
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same data source with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -82,24 +82,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number.
-
-In blocks where `count` is set, Terraform exposes an additional `count` object. You can reference the object to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual instance of a data source created using the `count` meta-argument, use the `<TYPE>.<NAME>[INDEX]` syntax. For example, `data.aws_instance.server[0]` refers to the first instance of the `aws_instance` data source named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional for creating data sources. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the data source when a variable named `creator` is set to `true`. Refer to [​​Conditional Expressions]/terraform/language/expressions/conditionals) for more information.
-
-</Tip>
-
-The `count` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Number.
-- Default: None.
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
@@ -111,21 +94,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-When a data source configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create one resource before creating a data source, even though the resource and the data source are configured independently.
-
-Use the `depends_on` argument when the resource and data source do not reference each other. We recommend always including a comment to explain dependencies when using a `depends_on` argument.
-
-When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
-
-Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data sources associated with that module. Refer to [Resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and [Data resource dependencies](/terraform/language/resources/configure#specify-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency).
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -158,41 +127,11 @@ data "<TYPE>" "<LABEL>" {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
-
-Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
-
-The `for_each` argument does not implicitly convert lists or tuples to sets. To declare data source instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the data source instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-sensitive-data) for more information.
-
-The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the data source. The object has the following attributes:
-
-- `each.key`: Map key or list member that corresponds to an instance.
-- `each.value`: Map value that corresponds to an instance.
-
-Use the `<TYPE>.<NAME>[<KEY>]` syntax to access an instance of a data source created using `for_each`. For example, `data.azurerm_resource_group.rg["a_group"]` refers to an instance of the `data.azurrm_resource_group` resource named `rg` created off of the `a_group` key.
-
-The `for_each` argument is a meta-argument, which is built into Terraform and controls the way that Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-
-#### Summary
-
-- Data type: Map or set of strings.
-- Default: None.
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
-The `provider` argument instructs Terraform to use an alternate provider configuration.
+The `provider` argument instructs Terraform to use an alternate provider configuration to provision the nested data source.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -200,16 +139,7 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the data source type, but you can create multiple provider configurations and use a non-default configuration for specific data sources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Using an alternate provider configuration](/terraform/language/block/provider#using-an-alternate-provider-configuration) for an example of 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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Reference.
-- Default: None.
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -230,12 +160,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 Configurations defined in the `lifecycle` block affect how Terraform constructs and traverses the dependency graph. You can only use literal values in the lifecycle block because Terraform processes them before it evaluates arbitrary expressions for a run.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates data sources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -252,26 +177,7 @@ resource {
 }
 ```
 
-The following arguments in the `precondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to proceed with an operation. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `precondition` blocks before evaluating the resource's configuration arguments. The `precondition` can take precedence over argument evaluation errors.
-
-Terraform evaluates precondition blocks after evaluating [`count`](#count) and [`for_each`](#for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
-
-You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
-
-Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
- #### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions).
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -288,140 +194,4 @@ data "<TYPE>" "<LABEL>" {
 }
 ```
 
-The following arguments in the `precondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. Postcondition failures prevent changes to other resources that depend on the failing resource.
-
-You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
-
-Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions).
-
-## Examples
-
-The following examples show how to write configuration for common use cases.
-
-### Specify a dependency
-
-In the following example, Terraform gets an AMI for use in the `aws_instance` resource after creating the `aws_subnet.example_subnet` resource:
-
-```hcl
-resource "aws_vpc" "example_vpc" {
-  cidr_block = "10.0.0.0/16"
-}
-
-resource "aws_subnet" "example_subnet" {
-  vpc_id     = aws_vpc.example_vpc.id
-  cidr_block = "10.0.1.0/24"
-}
-
-data "aws_ami" "example_ami" {
-  most_recent = true
-  owners      = ["amazon"]
-  filter {
-    name   = "name"
-    values = ["amzn2-ami-hvm-*"]
-  }
-  filter {
-    name   = "architecture"
-    values = ["x86_64"]
-  }
-  depends_on = [aws_subnet.example_subnet]
-}
-
-resource "aws_instance" "example_instance" {
-  ami           = data.aws_ami.example_ami.id
-  instance_type = "t2.micro"
-  subnet_id     = aws_subnet.example_subnet.id
-}
-```
-
-Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.
-
-### Select an alternate provider configuration
-
-In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
-
-```hcl
-provider "google" {
-  region = "us-central1"
-}
-
-provider "google" {
-  alias  = "europe"
-  region = "europe-west1"
-}
-
-data "google_compute_instance" "example" {
-  provider = google.europe
-  # ...
-}
-```
-
-### Apply custom conditions
-
-The following example includes several configurations that illustrate how to define `precondition` and `postcondition` arguments in the `lifecycle` meta-argument.
-
-The following `data` block instructs Terraform to retrieve the ID of the `ami-abc123` AMI:
-
-```hcl
-data "aws_ami" "example" {
-  owners = ["amazon"]
-  filter {
-    name   = "image-id"
-    values = ["ami-abc123"]
-  }
-}
-```
-
-In the following code, the `precondition` block specifies that the AMI ID retrieved from the `data` block must include `x86_64` as its `architecture` attribute. The `postcondition` block specifies that the EC2 instance must be allocated a public DNS hostname. When either condition is not met, Terraform returns the `error_message` for the failed condition:
-
-```hcl
-resource "aws_instance" "example" {
-  instance_type = "t3.micro"
-  ami           = data.aws_ami.example.id
-
-  lifecycle {
-    precondition {
-      condition     = data.aws_ami.example.architecture == "x86_64"
-      error_message = "The selected AMI must be for the x86_64 architecture."
-    }
-
-    postcondition {
-      condition     = self.public_dns != ""
-      error_message = "EC2 instance must be in a VPC that has public DNS hostnames enabled."
-    }
-  }
-}
-```
-
-The following `data` block retrieves the root storage volume connected to the `aws_instance.example` EC2 instance using the `volume_id` attribute. When a `data` resource verifies the result of a managed resource declared in the same configuration, you must define the check in a `postcondition` block in the resource so that Terraform waits for changes to the managed resource to complete before reading the data resource.
-
-```hcl
-data "aws_ebs_volume" "example" {
-  filter {
-    name = "volume-id"
-    values = [aws_instance.example.root_block_device[0].volume_id]
-  }
-  lifecycle {
-    # The EC2 instance will have an encrypted root volume.
-    postcondition {
-      condition     = self.encrypted
-      error_message = "The server's root volume is not encrypted."
-    }
-  }
-}
-output "api_base_url" {
-  value = "https://${aws_instance.example.private_dns}:8433/"
-}
-```
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/ephemeral.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/ephemeral.mdx
index fe675daa56..87c4960846 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/ephemeral.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/ephemeral.mdx	
@@ -131,19 +131,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 
 </CodeBlockConfig>
 
-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 you set `count`, Terraform exposes an additional `count` object. You can reference the object within the ephemeral block to modify the configuration of each instance. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual instance of an ephemeral resource created using the `count` meta-argument, use the `ephemeral.<TYPE>.<LABEL>[INDEX]` syntax. For example, `ephemeral.random_password.db_password[0]` refers to the first instance of the `random_password` ephemeral resource named `db_password`.
-
-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 ephemeral resources](#create-multiple-ephemeral-resources)
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
@@ -159,18 +147,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 
 </CodeBlockConfig>
 
-When an ephemeral resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating an ephemeral resource, 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 in the same root module or its child modules. 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.
-
-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -196,34 +173,14 @@ ephemeral "<TYPE>" "<LABEL>" {
   for_each = {
     "<KEY>" = "<VALUE>"
   }
+}
 ```
 
 </Tab>
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct ephemeral resource. 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 of the values must be known when Terraform creates a plan. 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.
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the ephemeral resource instance and always discloses it in UI output, so sensitive values are not allowed.
-
-The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific instances of the ephemeral 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 `ephemeral.<TYPE>.<LABEL>[<KEY>]` syntax to access an instance of an ephemeral resource created using `for_each`. For example, `ephemeral.random_password.passwords["admin"]` refers to an instance of the `random_password` ephemeral resource named `passwords` created from the `admin` 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 ephemeral resources](#create-multiple-ephemeral-resources)
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -239,17 +196,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 
 </CodeBlockConfig>
 
-By default, Terraform automatically selects a provider based on the ephemeral resource type, but you can create multiple provider configurations and use a non-default configuration for specific ephemeral resources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument.
-
-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) for more information.
-
-#### Summary
-
-- Data type: Reference
-- Default: None
-- Example: [Use alternate provider configurations](#use-alternate-provider-configurations)
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -274,12 +221,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 You can include both `precondition` and `postcondition` blocks in the same `lifecycle` block, and you can define multiple `precondition` and `postcondition` blocks in the same `lifecycle` block.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Block
-- Default: None
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -296,26 +238,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-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 ephemeral resource's configuration arguments. The `precondition` block errors 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 ephemeral resource.
-
-Refer to [Test and validate](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block
-- Default: None
-- Example: [Validate ephemeral resources](#validate-ephemeral-resources)
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -332,24 +255,7 @@ ephemeral "<TYPE>" "<LABEL>" {
 }
 ```
 
-The following arguments in the `postcondition` block are required:
-
-| Argument | Description | Data type |
-| --- | --- | --- |
-| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
-| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
-
-Terraform evaluates `postcondition` blocks after planning and applying changes to the ephemeral resource. Postcondition failures prevent changes to other resources that depend on the failing ephemeral resource.
-
-You can include a `postcondition` and [`precondition` block](#precondition) in the same ephemeral resource.
-
-Refer to [Test and validate](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block
-- Default: None
-- Example: [Validate ephemeral resources](#validate-ephemeral-resources)
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/import.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/import.mdx
index e7e1706a6b..a5f0e4b67c 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/import.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/import.mdx	
@@ -15,7 +15,7 @@ An `import` block supports the following configuration:
 - [`import`](#import) &nbsp block
   - [`to`](#to) &nbsp address | required
   - [`id`](#id) &nbsp string  
-<!--   - [`identity`](#identity) &nbsp map | mutually exclusive with `id` -->
+  - [`identity`](#identity) &nbsp map | mutually exclusive with `id`
   - [`for_each`](#for_each) &nbsp map or set of strings
   - [`provider`](#provider) &nbsp reference
 
@@ -95,9 +95,7 @@ You must specify a string or an expression that evaluates to a string. The ID mu
 
 The value of the `id` argument depends on the type of resource you are importing. You can only import resources that are supported by the provider. For information on how to import a resource, refer to the provider documentation.
 
-<!--// HIDING INFO ABOUT IDENTITY FOR NOW // 
 You cannot use the `id` argument and [`identity` argument](#identity) in the same `import` block. 
--->
 
 #### Summary
 
@@ -105,7 +103,6 @@ You cannot use the `id` argument and [`identity` argument](#identity) in the sam
 - Default: None
 - Example: [Import a single resource](#import-a-single-resource)
 
-<!-- leave out for now - providers are not using this yet
 ### `identity`
 
 The  `identity` argument specifies a resource identity object that uniquely identifies a resource. 
@@ -120,7 +117,7 @@ import {
 
 The `identity` argument is an object of key-value pairs that uniquely identify a resource. The keys and values are specific to the resource type and provider.
 
-The key-value pair for the `identity` object  depends on the type of resource you are importing. You can only import resources that are supported by the provider. Refer to the provider documentation for information about how to retrieve the `identity`.  
+The key-value pair for the `identity` object depends on the type of resource you are importing. You can only import resources that are supported by the provider. Refer to the provider documentation for information about how to retrieve the `identity`.  
 
 You cannot use the `identity` argument and [`id` argument](#id) in the same `import` block.
 
@@ -130,8 +127,6 @@ You cannot use the `identity` argument and [`id` argument](#id) in the same `imp
 - Default: None
 - Example: [Import a single resource](#import-a-single-resource)
 
--->
-
 ### `for_each`
 
 The `for_each` meta-argument instructs Terraform to import similar resources without requiring separate configuration blocks.
@@ -163,17 +158,7 @@ import {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and imports an instance for each item in that map or set and produces an `each` object. You can use the values stored in `each.key` and `each.value` for the [`id` argument expression](#id). You can also use them in index expressions in the [`to` argument](#to). This allows Terraform to import multiple instances of a resource configuration.
-
-The inputs for the `for_each` argument must be known for the import plan operation to succeed. You cannot use a `for_each` argument when running `terraform plan` with the `-generate-config-out` option. Refer to [Generate configuration](/terraform/language/import/generating-configuration) for more information.
-
-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: [Import multiple resources](#import-multiple-resources) 
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -186,17 +171,7 @@ import {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the resource type, but you can configure multiple instances of the same provider with aliases and use a non-default configuration to import specific resources. 
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. 
-
-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) for more information.
-
-#### Summary
-
-- Data type: String
-- Default: None
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration) 
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/module.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/module.mdx
index 6267f4ade2..28d2aeedc6 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/module.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/module.mdx	
@@ -406,25 +406,7 @@ module "<LABEL>" {
 }
 ```
 
-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 module created using the `count` meta-argument, use the `module.<NAME>[INDEX]` syntax. For example, `module.server[0]` refers to the first instance of the module named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional for creating modules. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three instances of the module resources 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 version of module resources](#create-multiple-versions-of-module-resources)
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `for_each`
 
@@ -457,38 +439,7 @@ module "<LABEL>" {
 
 </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 modules based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the module instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-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 module. 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 `module.<NAME>[<KEY>]` syntax to access an instance of a module created using `for_each`. For example, `module.rg["a_group"]` refers to a module 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 version of module resources](#create-multiple-versions-of-module-resources)
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `providers`
 
@@ -502,17 +453,7 @@ module "<LABEL>" {
 }
 ```
 
-By default, a child module inherits the default provider configuration from its parent module, but you can create multiple provider configurations and use an alternate configuration for each module. Because a module is collection of different resources, some modules also let you specify an alternate configuration for different resources in the module. Refer to the module documentation for details.
-
-The `providers` argument is a map of key-value pairs that reference provider configurations. The key references the provider configuration name used in the child module. Refer to the module documentation for details on how to define keys. The value references the provider configuration name from the parent module. Use the `<PROVIDER>.<ALIAS>` syntax to reference alternate provider configurations in key values.
-
-The `providers` 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.
-- Default: None.
-- Example: [Apply different provider configurations for module resources](#apply-different-provider-configurations-for-module-resource)
+`providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
 
 
 ### `depends_on`
@@ -525,21 +466,7 @@ module "<LABEL>" {
 }
 ```
 
-When a module configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create one resource before creating a module, even though the resource and the module are configured independently.
-
-Use the `depends_on` argument when the resource and module do not reference each other. We recommend always including a comment to explain dependencies when using a `depends_on` argument.
-
-When using the `depends_on` meta-argument, you can only reference other resources or child modules in the same root module. The list cannot include arbitrary expressions. Any values referenced in the `depends_on` list must be known before Terraform begins the operation so that it can evaluate dependencies.
-
-Specifying an entire module in the `depends_on` argument affects the order in which Terraform provisions all of the resources and data modules associated with that module. Refer to [Specify resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and the [data resource dependencies documentation](/terraform/language/data-sources#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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency)
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ## Examples
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/output.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/output.mdx
index 48f7ebf0f1..2415ccb8ba 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/output.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/output.mdx	
@@ -182,14 +182,7 @@ output "unique_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) for additional information.
-
-#### Summary
-
-- Data type: List of references
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `precondition`
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/removed.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/removed.mdx
index b62c97c04a..a1d2241da1 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/removed.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/removed.mdx	
@@ -94,7 +94,7 @@ removed {
 
 By default, Terraform removes the resource from state and destroys the actual resource. Set `destroy` to `false` to remove the resource from state without destroying the actual resource. This allows you to hand off management responsibilities to another tool or team after using Terraform for the initial provisioning.
 
-The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments that control how Terraform creates resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 #### Summary
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/resource.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/resource.mdx
index 72930ed7a1..681d1275f5 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/resource.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/resource.mdx	
@@ -20,9 +20,9 @@ The `resource` block supports the following arguments:
    - [`provider`](#provider) &nbsp; reference
    - [`lifecycle`](#lifecycle) &nbsp; block
       - [`action_trigger`](#action_trigger) &nbsp; block
-        - `events` &nbsp;  list | required to invoke an action
-        - `condition` &nbsp; expression 
-        - `actions` &nbsp;  list | required to invoke an action
+        - [`events`](#action_trigger) &nbsp;  list | required to invoke an action
+        - [`condition`](#action_trigger) &nbsp; expression 
+        - [`actions`](#action_trigger) &nbsp;  list | required to invoke an action
       - [`create_before_destroy`](#create_before_destroy) &nbsp; boolean
       - [`prevent_destroy`](#prevent_destroy) &nbsp; boolean
       - [`ignore_changes`](#ignore_changes) &nbsp; list of attributes
@@ -174,7 +174,7 @@ The provider developer determines which arguments you can define for a resource.
 
 ### `count`
 
-The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration.
+The `count` meta-argument instructs Terraform to provision multiple instances of the same resource with identical or similar configuration. You cannot use both a `count` and ` for_each` argument in the same block.
 
 ```hcl
 resource {
@@ -182,25 +182,7 @@ resource {
 }
 ```
 
-The value must be a whole number. You can reference variables or local values and use expressions to compute the value, but the value must resolve to a whole number.
-
-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).
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `depends_on`
 
@@ -212,22 +194,7 @@ resource {
 }
 ```
 
-When a resource configuration refers to another resource, Terraform identifies the dependency and creates the upstream resource first. In some cases, you may need Terraform to create a resource before creating another, even though the resources are configured independently.
-
-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/resources/configure#specify-resource-dependencies) <!-- placeholder link -->
-and [Data resource dependencies](/terraform/language/resources/configure#specify-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/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: List.
-- Default: None.
-- Example: [Specify a dependency](#specify-a-dependency).
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -260,37 +227,7 @@ resource {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates an instance for each item in that map or set. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-You can use pure functions, such as `toset()` and `tomap()`, to create a map or set for use in the `for_each` argument. Whether iterating over the keys of a map or set of strings, all must be known values. Otherwise, Terraform prints an error message that `for_each` has dependencies that it cannot determine before applying the configuration.
-
-Keys in the `for_each` argument cannot be the result of or rely on the result of impure functions, including `uuid`, `bcrypt`, or `timestamp`, because Terraform defers evaluating impure functions during the main evaluation step.
-
-The `for_each` argument does not implicitly convert lists or tuples to sets. To declare resource instances based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output, so sensitive values are not allowed. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
-
-If you transform a value containing sensitive data into an argument for use in `for_each`, be aware that most functions in Terraform will return a sensitive result if given an argument with any sensitive content. In many cases, you can achieve similar results with a `for` expression. For example, to call `keys(local.map)` where `local.map` is an object with sensitive values, but non-sensitive keys, you can create a value to pass to `for_each` using `toset([for k,v in local.map : k])`.
-
-Refer to [Manage sensitive data](/terraform/language/manage-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).
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `provider`
 
@@ -302,17 +239,7 @@ resource {
 }
 ```
 
-By default, Terraform automatically selects a provider based on the resource type, but you can create multiple provider configurations and use a non-default configuration for specific resources.
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument.
-
-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) for more information.
-
-#### Summary
-
-- Data type: Reference.
-- Default: None.
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration).
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `lifecycle`
 
@@ -328,7 +255,7 @@ resource {
 
 You can specify the following lifecycle rules to manage how Terraform performs operations on the resource:
 
-- [`action_trigger](#action_trigger)`: Specifies a set of arguments that determine which events trigger one or more provider actions, under which conditions the action runs, and which actions Terraform invokes.
+- [`action_trigger`](#action_trigger): Specifies a set of arguments that determine which events trigger one or more provider actions, under which conditions the action runs, and which actions Terraform invokes.
 - [`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. This rule doesn't prevent Terraform from destroying the resource if you remove the resource configuration. For instructions on how to remove a resource from state without destroying the actual resource, refer to [Remove a resource from state](/terraform/language/state/remove).
 - [`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.
@@ -338,7 +265,7 @@ You can specify the following lifecycle rules to manage how Terraform performs o
 
 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/meta-arguments) for more information.
+`lifecycle` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 #### Summary
 
@@ -361,21 +288,7 @@ resource "<TYPE>" "<LABEL>" {
 }
 ```
 
-The `action_trigger` block directs Terraform to automatically invoke actions based on the conditions you specify. Refer to [Invoke an action](/terraform/language/invoke-actions) for more information.
-
-The following table describes the arguments you can configure in the `action_trigger` block:
-
-| Argument | Description | Data type | Required |
-| --- | --- | --- | --- |
-| `events` | Required list of lifecycle events to invoke the action. You can declare the following events: <ul><li>`before_create`: Invokes the specified actions before Terraform creates the resource.</li><li>`after_create`: Invokes the specified actions after Terraform creates the resource.</li><li>`before_update`: Invokes the specified actions before updating the infrastructure to match the configuration.</li><li>`after_update`: Invokes the specified actions after updating the infrastructure to match the configuration.</li></ul> | list | required |
-| `condition` | Optional [expression](/terraform/language/expressions) that must evaluate to `true` to invoke the action | expression | optional |
-| `actions` | Specifies an ordered list of actions to trigger when the `events` and `condition` arguments are met. | list | required |
-
-#### Summary
-
-- Data type: Block
-- Default: None
-- Example: [Invoke an action](#invoke-an-action)
+`action_trigger` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `create_before_destroy`
 
@@ -389,18 +302,7 @@ resource {
 }
 ```
 
-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.
+`create_before_destroy` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `prevent_destroy`
 
@@ -414,14 +316,7 @@ resource {
 }
 ```
 
-Use this argument to prevent team members from accidentally replacing critical infrastructure, such as database instances.
-
-When the `prevent_destroy` argument is set, you must either remove the resource from the configuration or change the `prevent_destroy` argument to `false` to destroy it. Use this argument with caution. The `prevent_destroy` argument can make applying resource changes or destroying resources more complex.
-
-#### Summary
-
-- Data type: Boolean.
-- Default: None.
+`prevent_destroy` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `ignore_changes`
 
@@ -435,19 +330,7 @@ resource {
 }
 ```
 
-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).
+`ignore_changes` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `replace_triggered_by`
 
@@ -461,23 +344,7 @@ resource {
 }
 ```
 
-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)
+`replace_triggered_by` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `precondition`
 
@@ -494,26 +361,7 @@ resource {
 }
 ```
 
-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 [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
-
-#### Summary
-
-- Data type: Block.
-- Default: None.
-- Example: [Apply custom conditions](#apply-custom-conditions)
+`precondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `postcondition`
 
@@ -530,24 +378,7 @@ resource {
 }
 ```
 
-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 [Validate your configuration](/terraform/language/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)
+`postcondition` is a directive available in the `lifecycle` **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details about how the argument works.
 
 ### `connection`
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/component.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/component.mdx
index 0fe2f2b4e2..4c997836b5 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/component.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/component.mdx	
@@ -128,11 +128,7 @@ component "storage" {
 
 The keys in the `providers` map must match the provider names that the source module expects, and the values must reference providers declared in your component configuration. Learn more about [Declaring providers in Stacks](/terraform/language/stacks/component/declare-providers).
 
-#### Summary
-
-- Data type: Map
-- Default: None
-- Required: Yes
+`providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
 
 
 ### `inputs`
@@ -175,13 +171,9 @@ component "app_server" {
   # ...
 }
 ```
-
 You do not need to include the dependant component’s outputs in the `depends_on` list because Terraform automatically recognizes those dependencies.
 
-#### Summary
-
-- Data type: List of references
-- Default: None
+`depends_on` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details about how the argument works.
 
 ### `for_each`
 
@@ -217,10 +209,8 @@ component "<LABEL>" {
 
 When you use `for_each`, Terraform creates one component instance for each item in the collection. You can reference individual instances using `component.<LABEL>[<KEY>]` syntax.
 
-#### Summary
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
-- Data type: Map or Set
-- Default: None
 
 ## Examples
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/provider.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/provider.mdx
index c181603761..d4fdecc607 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/provider.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/provider.mdx	
@@ -111,6 +111,8 @@ provider "<NAME>" "<ALIAS>" {
 
 When you use `for_each`, you can reference individual provider instances using `provider.<PROVIDER_NAME>.<ALIAS>[<KEY>]` syntax in your `component` blocks.
 
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
+
 #### Summary
 
 - Data type: Map or Set
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/removed.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/removed.mdx
index ee910233b7..c920288924 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/removed.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/stack/tfcomponent/removed.mdx	
@@ -104,7 +104,7 @@ removed {
 
 ### `providers`
 
-The `providers` argument maps provider names to the providers that the component you want to remove uses. HCP Terraform needs these provider configurations to properly remove the component's resources.
+The `providers` argument is required. It maps provider names to the providers that the component you want to remove uses. HCP Terraform needs these provider configurations to properly remove the component's resources.
 
 ```hcl
 removed {
@@ -119,11 +119,7 @@ removed {
 
 The provider mapping must include every provider that the component's module requires for resource destruction.
 
-#### Summary
-
-- Data type: Map
-- Default: None
-- Required: Yes
+`providers` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details about how the argument works.
 
 ### `for_each`
 
@@ -158,8 +154,9 @@ removed {
 
 </Tabs>
 
+You can use `for_each` to remove components from specific regions or environments.
 
-The `for_each` meta-argument is useful when you want to remove components from specific regions or environments.
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates and manages resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 #### Summary
 
diff --git a/content/terraform/v1.14.x (beta)/docs/language/block/tfquery/list.mdx b/content/terraform/v1.14.x (beta)/docs/language/block/tfquery/list.mdx
index d7d5804723..dab82ec8ef 100644
--- a/content/terraform/v1.14.x (beta)/docs/language/block/tfquery/list.mdx	
+++ b/content/terraform/v1.14.x (beta)/docs/language/block/tfquery/list.mdx	
@@ -55,7 +55,7 @@ You must set the following arguments for every `list` block:
 
 ### `provider`
 
-The `provider` argument specifies which provider configuration Terraform uses to query infrastructure.
+The `provider` argument is required. It specifies which provider configuration Terraform uses to query infrastructure.
 
 ```hcl
 list "<TYPE>" "<LABEL>" {
@@ -63,20 +63,7 @@ list "<TYPE>" "<LABEL>" {
 }
 ```
 
-Terraform does not implicitly use the default `provider` configuration when querying resources. As a result, the `provider` argument is required. 
-
-You can create multiple provider configurations and use a non-default configuration for specific queries. Refer to the [`provider` block reference](/terraform/language/block/provider) for information about defining alternate provider configurations. 
-
-Use the `<PROVIDER>.<ALIAS>` syntax to reference a provider configuration in the `provider` argument. Refer to [Select an alternate provider configuration](#select-an-alternate-provider-configuration) for an example of 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 queries resources. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
-
-#### Summary
-
-- Data type: Reference
-- Default: None
-- The `provider` argument is required
-- Example: [Select an alternate provider configuration](#select-an-alternate-provider-configuration) 
+`provider` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details about how the argument works.
 
 ### `count`
 
@@ -88,25 +75,7 @@ list "<TYPE>" "<LABEL>" {
 }
 ```
 
-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 list of query results. The `count` object has an `index` attribute starting from `0`.
-
-To refer to an individual list of query results, use the `list.<TYPE>.<NAME>[INDEX]` syntax. For example, `list.aws_instance.server[0]` refers to the first list of query results for the `aws_instance` resource named `server`.
-
-<Tip>
-
-You can use the `count` argument as a conditional for querying resources. For example, setting a `count = var.creator ? 3 : 0` instructs Terraform to create three lists of query results 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 lists of query results](#create-multiple-lists-of-query-results).
+`count` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details about how the argument works.
 
 ### `for_each`
 
@@ -139,37 +108,7 @@ list "<TYPE>" "<LABEL>" {
 
 </Tabs>
 
-The `for_each` meta-argument accepts a map or a set of strings and creates a list of query results for each item in that map or set. Each list is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each list 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 lists of query results based on a nested data structure or combinations of elements from multiple data structures, you can use Terraform expressions and functions to derive a suitable value. Refer to the following examples for more information:
-
-- [Transform a multi-level nested structure into a flat list](/terraform/language/functions/flatten#flattening-nested-structures-for-for_each).
-- [Combine collections to produce a list of element combinations](/terraform/language/functions/setproduct#finding-combinations-for-for_each).
-
-You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Terraform uses the value in `for_each` to identify the list of query results 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 [Manage sensitive data](/terraform/language/manage-sensitive-data) for more information.
-
-The `for_each` argument exposes an `each` object that you can reference within the same block to modify specific lists of query results. The object has the following attributes:
-
-- `each.key`: Map key or list member that corresponds to list.
-- `each.value`: Map value that corresponds to a list.
-
-Use the `list.<TYPE>.<NAME>[<KEY>]` syntax to access an instance of a resource created using `for_each`. For example, `list.azurerm_resource_group.rg["a_group"]` refers to a list of query results for the `azurrm_resource_group` resource named `rg` created from 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 lists of query results](#create-multiple-lists-of-query-results).
+`for_each` is a **meta-argument**. Meta-arguments are built into the Terraform language and control how Terraform creates resources. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details about how the argument works.
 
 ### `include_resource` 
 
@@ -318,4 +257,4 @@ list "aws_instance" "web-bu" {
     count = list.aws_instance.web.data[0].state.length
   }
 }
-```
+```
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments.mdx
deleted file mode 100644
index ba8a5bc6a6..0000000000
--- a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments.mdx	
+++ /dev/null
@@ -1,234 +0,0 @@
----
-page_title: Meta-arguments
-description: Meta-arguments are built-in Terraform arguments that determine how Terraform creates and manages resources.
----
-
-# Meta-arguments
-
-Meta-arguments are a class of arguments built into the Terraform configuration language that control how Terraform creates your infrastructure. This page provides an overview of the meta-arguments included with Terraform.
-
-## Introduction
-
-You can use meta-arguments in any type of resource, including resources created with `data` blocks. You can also use most meta-arguments in `module` blocks.
-
-The provider developer determines resource-specific arguments, but all resources support meta-arguments that let you manage resources' infrastructure lifecycle, including destruction behavior, preventing destruction, and establishing dependencies between resources. Terraform provides the following meta-arguments.
-
-## `depends_on`
-
-The `depends_on` meta-argument establishes dependencies between resources that do not directly reference one another. Use the `depends_on` argument to explicitly set the order in which Terraform creates resources.
-
-### Tutorials
-
-- [Create resource dependencies](/terraform/tutorials/configuration-language/dependencies)
-
-### Examples
-
-- [Specify a dependency during validation](/terraform/language/block/check#resource-dependency)
-- [Specify a dependency when querying a data source](/terraform/language/block/data#specify-a-dependency)
-- [Specify a dependency when calling a module](/terraform/language/block/module#specify-dependencies)
-- [Specify a dependency when outputting values](/terraform/language/block/output#explicit-dependencies)
-- [Specify a dependency during resource creation](/terraform/language/block/resource#specify-a-dependency)
-- [Specify a dependency during the creation of a Stack component](/terraform/language/block/stack/tfcomponent/component#depends_on)
-
-### Guidance
-
- - [Add dependencies](/terraform/language/data-sources#dependencies) when querying a data source
- - [Set dependencies](/terraform/language/modules/configuration#set-dependencies) in your module configuration
-
-### References
-
-- [`depends_on` argument in `check` blocks](/terraform/language/block/check#depends_on)
-- [`depends_on` argument in `data` blocks](/terraform/language/block/data#depends_on)
-- [`depends_on` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#depends_on)
-- [`depends_on` argument in `module` blocks](/terraform/language/block/module#depends_on)
-- [`depends_on` argument in `output` blocks](/terraform/language/block/output#depends_on)
-- [`depends_on` argument in `resource` blocks](/terraform/language/block/resource#depends_on)
-
-## `count`
-
-By default, Terraform manages one infrastructure object for each `resource` block. Terraform also creates single instances of a module per `module` block. You can use the `count` argument in `resource` and `module` blocks to create and manage multiple instances of each without writing a separate block for each instance.
-
-### How to choose between `count` and `for_each`
-
-The [`for_each` meta-argument](#for_each) performs a similar function to `count`, but lets you reference different values for each instance you create. Use the `count` argument when you want to create nearly identical instances. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
-Integer index. You cannot use both a `count` and ` for_each` argument in the same `resource` or `module` block.
-
-### Tutorials
-
-- [Manage similar resources with count](/terraform/tutorials/0-13/count)
-
-### Examples
-
-- [Invoke an action multiple times](/terraform/language/block/action#invoke-an-action-multiple-times)
-- [Create multiple ephemeral resources](/terraform/language/block/ephemeral#create-multiple-ephemeral-resources)
-- [Create multiple instances of module resources](/terraform/language/block/module#create-multiple-instances-of-module-resources)
-- [Create multiple instances of a resource](/terraform/language/block/resource#create-multiple-instances-of-a-resource)
-
-### Guidance
-
- - [Create multiple instances](/terraform/language/data-sources#multiple-instances) when querying a data source
- - [Create multiple instances](/terraform/language/modules/configuration#create-multiple-copies-of-modules) when calling modules
-
-### References
-
-- [`count` argument in `action` block ](/terraform/language/block/action#count)
-- [`count` argument in `data` blocks](/terraform/language/block/data#count)
-- [`count` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#count)
-- [`count` argument in `list` blocks](/terraform/language/block/tfquery/list#count)
-- [`count` argument in `module` blocks](/terraform/language/block/module#count)
-- [`count` argument in `resource` block ](/terraform/language/block/resource#count)
-
-## `for_each`
-
-By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. You can add the `for_each` block to your `resource`, `data`, `module`, and `ephemeral` blocks to create and manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each instance.
-
-The `for_each` accepts a map or a set that resolves to string values, but you can specify pure functions, such as `toset()` and `tomap()`, to create a map or set of string key-value pairs. Each instance is associated with a distinct infrastructure object. Terraform creates, updates, or destroys each instance when applying changes to the configuration.
-
-Whether iterating over the keys of a map or set of strings, all values must be known.
-
-### How to choose between `for_each` and `count`
-
-The [`count` meta-argument](#count) performs a similar operation to `for_each`. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
-integer. Use the `count` argument when you want to create nearly identical instances.
-
-You cannot use both a `count` and ` for_each` argument in the same block.
-
-### Tutorials
-
-- [Manage similar resources with for each](/terraform/tutorials/configuration-language/for-each)
-
-### Examples
-
-- [Invoke an action multiple times](/terraform/language/block/action#invoke-an-action-multiple-times)
-- [Create multiple ephemeral resources](/terraform/language/block/ephemeral#create-multiple-ephemeral-resources)
-- [Import multiple existing resources](/terraform/language/block/import#import-multiple-resources)
-- [Create multiple instances of module resources](/terraform/language/block/module#create-multiple-instances-of-module-resources)
-- [Create multiple instances of a resource](/terraform/language/block/resource#create-multiple-instances-of-a-resource)
-
-### Guidance
-
-- [Creat multiple instances](/terraform/language/data-sources#multiple-instances) when querying a data source
-- [Create multiple instances](/terraform/language/modules/configuration#create-multiple-copies-of-modules) when calling modules
-
-### References
-
-- [`for_each` argument in `action` block ](/terraform/language/block/action#for_each)
-- [`for_each` argument in `data` blocks](/terraform/language/block/data#for_each)
-- [`for_each` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#for_each)
-- [`for_each` argument in `list` blocks](/terraform/language/block/tfquery/list#for_each)
-- [`for_each` argument in `module` blocks](/terraform/language/block/module#for_each)
-- [`for_each` argument in `resource` blocks](/terraform/language/block/resource#for_each)
-- [`for_each` argument in Stack `component` blocks](/terraform/language/block/stack/tfcomponent/component#for_each)
-- [`for_each` argument in Stack `provider` blocks](/terraform/language/block/stack/tfcomponent/provider#for_each)
-- [`for_each` argument in Stack `removed` blocks](/terraform/language/block/stack/tfcomponent/removed#for_each)
-
-## `provider`
-
-By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider .
-
-You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services.
-
-The `provider` argument is distinct from the `provider` block, which contains provider configuration settings. Refer to [Providers](/terraform/language/providers) for more information about the `provider` block.
-
-### Examples
-
-- [Specify an alternate provider configuration](/terraform/language/block/action#select-an-alternate-provider-configuration) for an action
-- [Specify an alternate provider configuration](/terraform/language/block/data#select-an-alternate-provider-configuration) for a data source
-- [Specify an alternate provider configuration](/terraform/language/block/ephemeral#use-alternate-provider-configurations) for an ephemeral resource
-- [Select an alternate provider configuration](/terraform/language/block/import#select-an-alternate-provider-configuration) for imported resources
-- [Select a provider without a default configuration](/terraform/language/block/provider#provider-without-a-default-configuration)
-- [Select an alternative provider configuration](/terraform/language/block/resource#select-an-alternate-provider-configuration) for resources
-
-### Guidance
-
-- [Providers](/terraform/language/providers)
-- [Select an alternate provider configuration](/terraform/language/data-sources#alternate-provider-configurations) when querying a data source
-
-### References
-
-- [`provider` argument in `action` block ](/terraform/language/block/action#provider)
-- [`provider` argument in `check` blocks](/terraform/language/block/check#provider)
-- [`provider` argument in `data` blocks](/terraform/language/block/data#provider)
-- [`provider` argument in `ephemeral` blocks](/terraform/language/block/ephemeral#provider)
-- [`provider` argument in `import` block ](/terraform/language/block/import#provider)
-- [`provider` argument in `list` blocks](/terraform/language/block/tfquery/list#provider)
-- [`provider` argument in `resource` blocks](/terraform/language/block/resource#provider)
-
-## `providers`
-
-By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources.
-
-Some modules may contain resources that require different providers. As a result, you can specify alternate configurations for each provider supported by the module. Refer to the module documentation for details about the providers it supports.
-
-When you add a `providers` argument, child modules only have access to the provider configurations you specify. Use the `providers` argument in the following scenarios:
-
-- To use an alternate provider configuration for a child module.
-- To configure a module that requires multiple configurations of the same provider.
-
-### Examples
-
-- [Apply different provider configurations](/terraform/language/block/module#apply-different-provider-configurations-for-module-resources)  for module resources
-
-### Guidance
-
-- [Provider Aliases Within Modules](/terraform/language/modules/develop/providers#provider-aliases-within-modules)
-
-### Reference
-
-- [`providers` argument in `module` blocks](/terraform/language/block/module#providers)
-- [Providers module development documentation](/terraform/language/modules/develop/providers)
-
-## `lifecycle`
-
-Terraform performs the following operations when you apply a configuration:
-
-1. Creates resources defined in the configuration that are not associated with a real infrastructure object in the state.
-1. Destroys resources that exist in the state but not in the configuration.
-1. Updates in-place resources whose arguments have changed.
-1. Destroys and re-creates resources whose arguments have changed but that Terraform cannot update in-place because of remote API limitations.
-1. Invokes actions that are configured to run during an apply operation.
-
-The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details. 
-
-### State
-
-Except for `create_before_destroy`, Terraform does not explicitly record a resource's `lifecycle` rule to state. As a result, Terraform destroys the actual infrastructure during an apply operation if you remove the resource's configuration, even if `prevent_destroy` is enabled. Refer to [Remove a resource from state](/terraform/language/state/remove) for instructions on how to remove a resource from state without destroying the actual resource. 
-
-Terraform records the results of `precondition` and `postcondition` checks to state, but not the contents of the checks.
-
-### Rules 
-
-The following table describes support for each `lifecycle` rule:
-
-| Rule | Description | Terraform block |
-| --- | --- | --- |
-| `action_trigger` | Terraform runs the configured action when the specified conditions are met. Refer to [Invoke an action](/terraform/language/invoke-actions) for details. | `resource` |
-| `create_before_destroy` | Terraform creates a replacement resource before destroying the current resource. | `resource` |
-| `prevent_destroy` | Terraform rejects operations to destroy the resource and returns an error. This rule doesn't prevent Terraform from destroying a resource if you remove its configuration. Refer to [Remove a resource from state](/terraform/language/state/remove) for instructions on how to remove a resource from state without destroying the actual resource. | `resource` |
-| `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. | `resource` |
-| `replace_triggered_by` | Terraform replaces the resource when any of the referenced resources or specified attributes change. | `resource` |
-| `precondition` | Specifies a condition that Terraform evaluates before creating the resource. | `data`, `ephemeral`, `resource` |
-| `postcondition` | Specifies a condition that Terraform evaluates after creating the resource. | `data`, `ephemeral`, `resource` |
-| `destroy` | Set to `false` to remove a resource from state without destroying the actual infrastructure resource. You can only use this rule in the `removed` block. | `removed` |
-
-### Tutorials
-
-- [Manage resource lifecycle](/terraform/tutorials/state/resource-lifecycle)
-
-### Examples
-
-- [Apply custom conditions to data sources](/terraform/language/block/data#apply-custom-conditions)
-- [Ignore attribute changes](/terraform/language/block/resource#ignore-attribute-changes)
-- [Specify triggers that replace resource](/terraform/language/block/resource#specify-triggers-that-replace-resources)
-- [Apply custom conditions to resources](/terraform/language/block/resource#apply-custom-conditions)
-
-### Guidance
-
-- [Validate your configuration](/terraform/language/validate#preconditions-and-postconditions)
-
-### References
-
-- [`lifecycle` argument in `data` blocks](/terraform/language/block/data#lifecycle)
-- [`lifecycle` argument in `ephemeral` block ](/terraform/language/block/ephemeral#lifecycle)
-- [`lifecycle` argument in `removed` blocks](/terraform/language/block/removed#lifecycle)
-- [`lifecycle` argument in `resource` blocks](/terraform/language/block/resource#lifecycle)
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/count.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/count.mdx
new file mode 100644
index 0000000000..956a7b34c4
--- /dev/null
+++ b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/count.mdx	
@@ -0,0 +1,139 @@
+---
+page_title: count meta-argument reference
+description: Learn how the `count` meta-argument works in Terraform configuration.
+---
+
+# `count` reference
+
+By default, each [`resource` block](/terraform/language/block/resource) and [`ephemeral` block](/terraform/language/block/ephemeral) configures one real infrastructure object. Similarly, a [`module` block](/terraform/language/block/module) includes a child module's contents into the configuration one time and invokes an action defined in an [`action` block](/terraform/language/block/action) once. 
+
+Use the `count` meta-argument to manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each object. When a `resource` or `module` block includes a `count` argument whose value is a whole number, Terraform creates that many instances. When `count` appears in an `action` block, Terraform invokes the action the number of specified times.
+
+## Usage
+
+The `count` meta-argument accepts a whole number and either creates as many instances of the resource or module or invokes an action as many times. 
+
+Each instance has a distinct infrastructure object associated with it, and each is separately created, updated, or destroyed when the configuration is applied. 
+
+<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>
+
+
+In the folllowing example, Terraform creates four `aws_instance.server` resources that use the same AMI and instance type. The `count.index` attribute gives each `aws_instance` a unique `Name` tag:
+
+```hcl
+resource "aws_instance" "server" {
+  count = 4 # create four similar EC2 instances
+
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+
+  tags = {
+    Name = "Server ${count.index}"
+  }
+}
+```
+
+### Expressions in `count`
+
+The `count` meta-argument accepts numeric [expressions](/terraform/language/expressions), but unlike most arguments, the `count` value must be known before Terraform performs any remote resource operations. `count` cannot refer to any resource attributes that are only known after a configuration is applied, such as a unique ID generated by the remote API when an object is created.
+
+### Referring to instances
+
+In blocks where `count` is set, Terraform creates an additional `count` object that you can use in expressions to modify the configuration of each instance. This object has the following attribute:
+
+- `count.index`: The distinct index number starting with `0` corresponding to this instance.
+
+Terraform makes a distinction between the block containing the `count` argument and the instances associated with it. Terraform identifies instances index number starting at `0`.
+
+- `<TYPE>.<NAME>` or `module.<NAME>`, for example, `aws_instance.server` refers to the resource block.
+- `<TYPE>.<NAME>[<INDEX>]` or `module.<NAME>[<INDEX>]`, for example, `aws_instance.server[0]` and
+  `aws_instance.server[1]` refer to individual instances.
+
+This is different from resources and modules without `count` or [`for_each`](/terraform/language/meta-arguments/for_each), which can be referenced without an index or key.
+
+Similarly, resources from child modules with multiple instances are prefixed
+with `module.<NAME>[<KEY>]` when displayed in plan output and elsewhere in the UI.
+For a module without `count` or `for_each`, the address will not contain
+the module index as the module's name suffices to reference the module.
+
+Within nested [`provisioner`](/terraform/language/block/resource#provisioner) or [`connection`](/terraform/language/block/resource#connection) blocks, the special `self` object refers to the current resource instance, not the `resource` block as a whole.
+
+### How to choose between `count` and `for_each`
+
+`count` and [`for_each`](/terraform/language/meta-arguments/for_each) perform a similar function. Use the `count` argument when you want to create nearly identical instances. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
+integer index. You cannot use both a `count` and ` for_each` argument in the same `resource` or `module` block.
+
+## Supported constucts
+
+You can use `count` in the following Terraform configuration blocks:
+
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`resource` blocks](/terraform/language/block/resource)
+
+You can use `count` in the following query configuration blocks:
+
+- [`list` blocks](/terraform/language/block/tfquery/list)
+
+## Example use cases
+
+The following use cases describe common patterns for the `count` argument.
+
+### Create multiple instances of module resources
+
+In the following example, Terraform creates three EC2 instances, each with a unique name from the `instance_names` list:
+
+```hcl
+locals {
+  instance_names = ["web", "api", "batch"]
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  count   = length(local.instance_names)
+
+  name           = local.instance_names[count.index]
+  ami            = data.aws_ami.latest_amazon_linux.id
+  instance_type  = "t2.micro"
+
+  depends_on = [aws_s3_bucket.example]
+}
+
+```
+
+### Create multiple instances of a resource
+
+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}"
+  }
+}
+```
+
+### Invoke an action multiple times
+
+You can use `count` to invoke an action multiple times. Refer to the [`action` block documentation](/terraform/language/block/action#invoke-an-action-multiple-times) for an example.
+
+### Create multiple query lists
+
+You can use `count` to create multiple lists of query results. Refer to the [`list` block documentation](/terraform/language/block/tfquery/list#create-multiple-lists-of-query-results) for an example.
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/depends_on.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/depends_on.mdx
new file mode 100644
index 0000000000..7775a7a71e
--- /dev/null
+++ b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/depends_on.mdx	
@@ -0,0 +1,198 @@
+---
+page_title: depends_on meta-argument reference
+description: Learn how the `depends_on` meta-argument works in Terraform configuration.
+---
+
+# `depends_on` reference
+
+Use the `depends_on` meta-argument to handle hidden resource or module dependencies that Terraform cannot automatically infer. You only need to explicitly specify a dependency when a resource or module relies on another resource's behavior but does not access any of that resource's data in its arguments. 
+
+## Usage
+
+You can use the `depends_on` meta-argument in `module` blocks and in all `resource` blocks, regardless of resource type. 
+
+It requires a list of references to other resources or child modules in the same calling module. This list cannot include arbitrary expressions because the `depends_on` value must be known before Terraform knows resource relationships and thus before it can safely evaluate expressions. 
+
+In the following example, the `depends_on` argument instructs Terraform to handle a hidden dependency on the `aws_iam_instance_profile.example` resource.
+
+```hcl
+resource "aws_iam_role" "example" {
+  name = "example"
+
+  # assume_role_policy is omitted for brevity in this example. Refer to the
+  # documentation for aws_iam_role for a complete example.
+  assume_role_policy = "..."
+}
+
+resource "aws_iam_instance_profile" "example" {
+  # Because this expression refers to the role, Terraform automatically
+  # infers that the role must be created first.
+  role = aws_iam_role.example.name
+}
+
+resource "aws_iam_role_policy" "example" {
+  name   = "example"
+  role   = aws_iam_role.example.name
+  policy = jsonencode({
+    "Statement" = [{
+      # This policy allows software running on the EC2 instance to
+      # access the S3 API.
+      "Action" = "s3:*",
+      "Effect" = "Allow",
+    }],
+  })
+}
+
+resource "aws_instance" "example" {
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+
+  # Terraform can infer from this that the instance profile must
+  # be created before the EC2 instance.
+  iam_instance_profile = aws_iam_instance_profile.example
+
+  # However, if software running in this EC2 instance needs access
+  # to the S3 API in order to boot properly, there is also a 
+  # dependency on the aws_iam_role_policy that Terraform cannot
+  # automatically infer, so you must declare it explicitly:
+  depends_on = [
+    aws_iam_role_policy.example
+  ]
+}
+```
+
+## Processing and planning consequences
+
+The `depends_on` meta-argument instructs Terraform to complete all actions on the dependency object, including read operations, before performing operations on the object declaring the dependency. When the dependency object is an entire module, `depends_on` affects the order in which Terraform processes all of the resources and data sources associated with that module. Refer to the documentation on [specifying resource dependencies](/terraform/language/resources/configure#specify-resource-dependencies) and [data resource dependencies](/terraform/language/data-sources#dependencies) for more details.
+
+You should only use `depends_on` as a last resort because it can cause Terraform to create more conservative plans that replace more resources than necessary. For example, Terraform may treat more values as unknown `"(known after apply)"` because it is uncertain what changes will occur on the upstream object. This is especially likely when you use `depends_on` for modules.
+
+Instead of `depends_on`, we recommend using [expression references](/terraform/language/expressions/references) to imply dependencies when possible. Expression references let Terraform understand which value the reference derives from and avoid planning changes if that particular value hasn’t changed, even if other parts of the upstream object have planned changes.
+
+## Supported constructs
+
+You can use `depends_on` in the following Terraform configuration blocks:
+
+- [`check` blocks](/terraform/language/block/resource)
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`output` blocks](/terraform/language/block/output)
+- [`resource` blocks](/terraform/language/block/resource)
+
+You can use `depends_on` in the following Stack configuration blocks:
+
+- [`component` blocks](/terraform/language/block/stack/tfcomponent/component)
+
+## Example use cases 
+
+The following use cases describe common patterns for the `depends_on` argument.
+
+### Specify a dependency during validation
+
+Add a `depends_on` argument to a `data` block nested in a [`check` block](/terraform/language/block/check) validation when the data source depends on another resource but doesn't reference the resource directly.  
+
+`check` blocks validate infrastructure outside of the typical resource lifecycle. You can nest a `data` block inside a `check` block to fetch information that you can reference in an `assert` block. By adding a `depends_on` argument to the `data` block nested in a `check` block requires, Terraform retrieves the necessary data before running the validation.
+
+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. 
+
+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"
+ }
+}
+```
+
+### Create a database service that other services depend on 
+
+In the following example, Terraform must launch the `aws_db_instance` service first so that `aws_instance` can connect to it:
+
+```hcl
+provider "aws" {
+  region = "us-east-2"
+}
+
+data "aws_ami" "ubuntu" {
+  most_recent = true
+
+  filter {
+    name   = "name"
+    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
+  }
+
+  filter {
+    name   = "virtualization-type"
+    values = ["hvm"]
+  }
+
+  owners = ["099720109477"] # Canonical
+}
+
+resource "aws_db_instance" "api" {
+  allocated_storage   = 10
+  db_name             = "api_db"
+  engine              = "postgres"
+  engine_version      = "17.4"
+  instance_class      = "db.t3.micro"
+  username            = "foo"
+  password            = "foobarbaz"
+  skip_final_snapshot = true
+}
+
+resource "aws_instance" "api" {
+  ami           = data.aws_ami.ubuntu.id
+  instance_type = "t3.micro"
+
+  depends_on = [aws_db_instance.api]
+}
+```
+
+### Specify a dependency on the parent module
+
+In the following example, Terraform only creates the EC2 instance module after creating the S3 bucket resource:
+
+```hcl
+resource "aws_s3_bucket" "example" {
+  bucket = "my-example-bucket-12345"
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  name    = "example-instance"
+  ami           = data.aws_ami.latest_amazon_linux.id
+  instance_type = "t2.micro"
+
+  depends_on = [aws_s3_bucket.example]
+}
+```
+
+### Specify a dependency when outputting values
+
+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.
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/for_each.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/for_each.mdx
new file mode 100644
index 0000000000..466b3a7589
--- /dev/null
+++ b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/for_each.mdx	
@@ -0,0 +1,322 @@
+---
+page_title: for_each meta-argument reference
+description: Learn how the `for_each` meta-argument works in Terraform configuration.
+---
+
+# `for_each` reference
+
+By default, [`resource` block](/terraform/language/block/resource) configures one real infrastructure object. Similarly, a [`module` block](/terraform/language/block/module) includes a child module's contents into the configuration one time and invokes an action defined in an [`action` block](/terraform/language/block/action) once. 
+
+Use the `for_each` meta-argument to manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each object. When a `resource`, `module`, or `ephemeral` block includes a `for_each` argument, Terraform creates an instance for each member of the list or map specified as the value. When `for_each` appears in an `action` block, Terraform invokes the action once for each member of the list or key-value pair in a map.
+
+## Usage
+
+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. All values that the `for_each` argument iterates over must be known before Terraform performs any remote resource operations. Specifying references to resource attributes that are only known after a configuration is applied, such as a unique ID generated by the remote API when an object is created, will result in an error.
+
+The following example creates two `azurerm_resource_group` resources 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 `aws_iam_user` resources 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
+}
+```
+
+### Limitations on values
+
+The keys of the map or all values in a set of strings must be known values. Otherwise, Terraform returns an error message that `for_each` has dependencies that cannot be determined before apply and that a `-target` may be needed.
+
+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.
+
+You cannot use sensitive values, such as [sensitive input variables](/terraform/language/block/variable#sensitive), [sensitive outputs](/terraform/language/block/output#sensitive), or [sensitive resource attributes](/terraform/language/expressions/references#sensitive-resource-attributes), as arguments in `for_each`. Sensitive values are not allowed because Terraform uses the value in `for_each` to identify the resource instance and always discloses it in UI output. Terraform returns an error if you attempt to use sensitive values as `for_each` arguments.
+
+If you transform a value containing sensitive data into an argument for use in `for_each`, most functions in Terraform return a sensitive result when given an argument with any sensitive content. Refer to [Using sensitive data as function arguments](/terraform/language/expressions/function-calls#using-sensitive-data-as-function-arguments) for more information.
+
+In many cases, you can use a `for` expression to achieve similar results. 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` with `toset([for k,v in local.map : k])`. Refer to [Manage sensitive data](/terraform/language/manage-sensitive-data) for more information.
+
+### Expressions in `for_each`
+
+The `for_each` meta-argument accepts map or set [expressions](/terraform/language/expressions), but unlike most arguments, the value must be known before Terraform performs any remote resource actions. As a result, `for_each` can't refer to any resource attributes that aren't known until after a
+configuration is applied, such as a unique ID generated by the remote API when
+an object is created.
+
+The `for_each` value must be a map or set with one element per desired resource
+instance. To use a sequence as the `for_each` value, you must use an expression
+that explicitly returns a set value, such as the [`toset` function](/terraform/language/functions/toset). 
+
+To prevent unexpected behavior during conversion, 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).
+
+### Referring to instances
+
+In blocks where `for_each` is set, Terraform creates an additional `each` object that you can use in expressions to modify the configuration of each instance.
+This object has the following attributes:
+
+- `each.key`: The map key or set member corresponding to this instance.
+- `each.value`: The map value corresponding to this instance. If a set is provided, this is the same as `each.key`.
+
+Terraform makes a distinction between the block containing the `for_each` argument and the instances associated with it. Terraform identifies instances by the map key or set member using the value provided to `for_each`.
+
+- `<TYPE>.<NAME>` or `module.<NAME>`: For example, `azurerm_resource_group.rg` refers to the block.
+- `<TYPE>.<NAME>[<KEY>]` or `module.<NAME>[<KEY>]`: For example, `azurerm_resource_group.rg["a_group"]` and `azurerm_resource_group.rg["another_group"]` refer to individual instances.
+
+This is different from resources and modules without [`count`](/terraform/language/meta-arguments/count) or `for_each`, which can be
+referenced without an index or key.
+
+Similarly, resources from child modules with multiple instances are prefixed
+with `module.<NAME>[<KEY>]` when displayed in plan output and elsewhere in the UI.
+For a module without `count` or `for_each`, the address does not contain
+the module index as the module's name suffices to reference the module.
+
+Within nested [`provisioner`](/terraform/language/block/resource#provisioner) or [`connection`](/terraform/language/block/resource#connection) blocks, the special `self` object refers to the current resource instance, not the resource block as a whole.
+
+### Chain `for_each` between resources
+
+Because a resource using `for_each` appears as a map of objects when used in
+expressions elsewhere, you can directly use one resource as the `for_each`
+of another in situations where there is a one-to-one relationship between
+two sets of objects.
+
+For example, in AWS an `aws_vpc` object is commonly associated with a number
+of other objects that provide additional services to that VPC, such as an
+internet gateway. If you are declaring multiple VPC instances using `for_each`
+then you can chain that `for_each` into another resource to declare an
+internet gateway for each VPC:
+
+```hcl
+variable "vpcs" {
+  type = map(object({
+    cidr_block = string
+  }))
+}
+
+resource "aws_vpc" "example" {
+  # One VPC for each element of var.vpcs
+  for_each = var.vpcs
+
+  # each.value here is a value from var.vpcs
+  cidr_block = each.value.cidr_block
+}
+
+resource "aws_internet_gateway" "example" {
+  # One Internet Gateway per VPC
+  for_each = aws_vpc.example
+
+  # each.value here is a full aws_vpc object
+  vpc_id = each.value.id
+}
+
+output "vpc_ids" {
+  value = {
+    for k, v in aws_vpc.example : k => v.id
+  }
+
+  # The VPCs aren't fully functional until their
+  # internet gateways are running.
+  depends_on = [aws_internet_gateway.example]
+}
+```
+
+This chain pattern explicitly and concisely declares the relationship
+between the internet gateway instances and the VPC instances, which tells
+Terraform to expect the instance keys for both to always change together,
+and typically also makes the configuration easier to understand for human
+maintainers.
+
+### Using sets
+
+The Terraform language doesn't have a literal syntax for [set values](/terraform/language/expressions/type-constraints#collection-types), but you can use the [`toset` function](/terraform/language/functions/toset) to explicitly convert a list of strings to a set:
+
+```hcl
+locals {
+  subnet_ids = toset([
+    "subnet-abcdef",
+    "subnet-012345",
+  ])
+}
+
+resource "aws_instance" "server" {
+  for_each = local.subnet_ids
+
+  ami           = "ami-a1b2c3d4"
+  instance_type = "t2.micro"
+  subnet_id     = each.key # note: each.key and each.value are the same for a set
+
+  tags = {
+    Name = "Server ${each.key}"
+  }
+}
+```
+
+Conversion from list to set discards the ordering of the items in the list and
+removes any duplicate elements. For example, `toset(["b", "a", "b"])` produces a set
+containing only `"a"` and `"b"` in no particular order and discards the second `"b"`.
+
+If you are writing a module with an [input variable](/terraform/language/values/variables) that
+will be used as a set of strings for `for_each`, you can set its type to
+`set(string)` so that you don't need an explicit type conversion:
+
+```hcl
+variable "subnet_ids" {
+  type = set(string)
+}
+
+resource "aws_instance" "server" {
+  for_each = var.subnet_ids
+  #...
+}
+```
+
+### How to choose between `for_each` and `count`
+
+The [`count` meta-argument](#count) performs a similar operation to `for_each`. Use `for_each` when some instance arguments must have distinct values that can't be directly derived from an
+integer. Use the `count` argument when you want to create nearly identical instances.
+
+You cannot use both a `count` and ` for_each` argument in the same block.
+
+## Supported constucts
+
+You can use `for_each` in the following Terraform configuration blocks:
+
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`module` blocks](/terraform/language/block/module)
+- [`resource` blocks](/terraform/language/block/resource)
+
+You can use `for_each` in the following Stack configuration blocks:
+
+- [`component` blocks](/terraform/language/block/stack/tfcomponent/component)
+- [`provider` blocks](/terraform/language/block/stack/tfcomponent/provider)
+- [`removed` blocks](/terraform/language/block/stack/tfcomponent/removed)
+
+You can use `for_each` in the following query configuration blocks:
+
+- [`list` blocks](/terraform/language/block/tfquery/list)
+
+## Examples
+
+The following use cases describe common patterns for the `for_each` argument.
+
+### Create multiple ephemeral resources
+
+In the following example, the `for_each` argument creates multiple passwords for different database environments:
+
+<CodeBlockConfig highlight="6, 18">
+
+```hcl
+locals {
+  environments = toset(["dev", "staging", "prod"])
+}
+
+ephemeral "random_password" "db_passwords" {
+  for_each = local.environments
+
+  length           = 16
+  override_special = "!#$%&*()-_=+[]{}<>:?"
+}
+
+resource "aws_db_instance" "databases" {
+  for_each = local.environments
+
+  identifier                = "${each.key}-database"
+  db_name                   = "${each.key}db"
+  username                  = "dbadmin"
+  password_wo               = ephemeral.random_password.db_passwords[each.key].result
+ # …
+}
+```
+
+</CodeBlockConfig>
+
+The `ephemeral` block creates a `random_password` ephemeral resource for each environment in the `local.environments` set. The `aws_db_instance` resource then uses the generated passwords for each database instance.
+
+Terraform does not store the generated `db_passwords` values, but you can capture them in another resource to ensure those values are not lost. For an example of generating, storing, retrieving, and using an ephemeral password, refer to [write-only arguments](/terraform/language/manage-sensitive-data/write-only#set-and-store-an-ephemeral-password-in-aws-secrets-manager).
+
+### Create multiple instances of module resources
+
+In the following example, Terraform creates one EC2 instance for each key in `local.instance_configs`, allowing you to customize properties per instance:
+
+```hcl
+locals {
+  instance_configs = {
+    "example-instance-1" = { instance_type = "t2.micro" }
+    "example-instance-2" = { instance_type = "t2.small" }
+    "example-instance-3" = { instance_type = "t2.medium" }
+  }
+}
+
+module "ec2_instance" {
+  source  = "terraform-aws-modules/ec2-instance/aws"
+  version = "6.0.2"
+  for_each = local.instance_configs
+
+  name           = each.key
+  ami            = data.aws_ami.latest_amazon_linux.id
+  instance_type  = each.value.instance_type
+
+  depends_on = [aws_s3_bucket.example]
+}
+```
+
+### Create multiple instances of a resource
+
+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>
+
+### Invoke an action multiple times
+
+You can use `for_each` to invoke an action multiple times. Refer to the [`action` block documentation](/terraform/language/block/action#invoke-an-action-multiple-times) for an example.
+
+### Import multiple resources
+
+You can use `for_each` to import multiple resources. Refer to the [`import` block documentation](/terraform/language/block/import#import-multiple-resources) for an example.
+
+### Create multiple query lists
+
+You can use `for_each` to create multiple lists of query results. Refer to the [`list` block documentation](/terraform/language/block/tfquery/list#create-multiple-lists-of-query-results) for an example.
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/index.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/index.mdx
new file mode 100644
index 0000000000..0cf212dcd5
--- /dev/null
+++ b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/index.mdx	
@@ -0,0 +1,43 @@
+---
+page_title: Meta-arguments
+description: Meta-arguments are built-in Terraform arguments that determine how Terraform creates and manages resources.
+---
+
+# Meta-arguments
+
+Meta-arguments are a class of arguments built into the Terraform configuration language that control how Terraform creates and manages your infrastructure. You can use meta-arguments in any type of resource. You can also use most meta-arguments in `module` blocks.
+
+The provider developer determines resource-specific arguments, but all resources support meta-arguments that let you manage resources' infrastructure lifecycle, including destruction behavior, preventing destruction, and establishing dependencies between resources. Terraform provides the following meta-arguments.
+
+## `depends_on`
+
+The `depends_on` meta-argument instructs Terraform to complete all actions on the dependency object, including `read` operations, before performing actions on the object declaring the dependency. Use the `depends_on` argument to explicitly set the order in which Terraform creates resources. Refer to the [`depends_on` reference](/terraform/language/meta-arguments/depends_on) for details.
+
+> **Hands-on**: Complete the [Create resource dependencies](/terraform/tutorials/configuration-language/dependencies) tutorial to learn how to declare dependencies.
+
+## `count`
+
+By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. Terraform also creates single instances of a module per `module` block. You can add the `count` argument to `resource`, `module`, and `ephemeral` blocks to create and manage multiple instances of each without writing a separate block for each instance. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details.
+
+> **Hands-on**: Complete the [Manage similar resources with count](/terraform/tutorials/0-13/count) tutorial to learn how to create multiple instances of a resource.
+
+## `for_each`
+
+By default, Terraform configures one infrastructure object for each `resource`, `module`, and `ephemeral` block. You can add the `for_each` block to your `resource`, `data`, `module`, and `ephemeral` blocks to create and manage several similar objects, such as a fixed pool of compute instances, without writing a separate block for each instance. Refer to the [`for_each` reference](/terraform/language/meta-arguments/for_each) for details.
+
+> **Hands-on**: Complete the [Manage similar resources with for each](/terraform/tutorials/configuration-language/for-each) tutorial to learn how to create multiple instances of a resource.
+
+## `lifecycle`
+
+The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the [`lifecycle` reference](/terraform/language/meta-arguments/lifecycle) for details. 
+
+> **Hands-on**: Complete the [Manage resource lifecycle](/terraform/tutorials/state/resource-lifecycle) tutorial to learn how to manage the lifecycle of your infrastructure resources. 
+
+## `provider`
+
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. Refer to the [`provider` reference](/terraform/language/meta-arguments/provider) for details.
+
+## `providers`
+
+By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details.
+
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/lifecycle.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/lifecycle.mdx
new file mode 100644
index 0000000000..3fe67d398b
--- /dev/null
+++ b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/lifecycle.mdx	
@@ -0,0 +1,347 @@
+---
+page_title: lifecycle meta-argument reference
+description: How to configure the lifecycle meta-argument rules in Terraform--create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by, precondition, postcondition, destroy
+---
+
+# `lifecycle` reference
+ 
+Terraform performs the following operations when you apply a configuration:
+
+1. Creates resources defined in the configuration that are not associated with a real infrastructure object in the state.
+1. Destroys resources that exist in the state but not in the configuration.
+1. Updates in-place resources whose arguments have changed.
+1. Destroys and re-creates resources whose arguments have changed but that Terraform cannot update in-place because of remote API limitations.
+1. Invokes actions that are configured to run during an apply operation.
+
+The `lifecycle` block accepts a rule that customizes how Terraform performs the lifecycle stages for each resource. Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details. 
+
+### State
+
+Except for `create_before_destroy`, Terraform does not explicitly record a resource's `lifecycle` rule to state. As a result, Terraform destroys the actual infrastructure during an apply operation if you remove the resource's configuration, even if `prevent_destroy` is enabled. Refer to [Remove a resource from state](/terraform/language/state/remove) for instructions on how to remove a resource from state without destroying the actual resource. 
+
+Terraform records the results of `precondition` and `postcondition` checks to state, but not the contents of the checks.
+
+## Usage
+
+All `lifecycle` settings affect how Terraform constructs and traverses
+the dependency graph. As a result, only literal values can be used because
+the processing happens too early for arbitrary expression evaluation.
+
+Support for each lifecycle rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details. Depending on the block you are configuring, you may be able to use one or more of the following rules.
+
+### `action_trigger`
+
+`action_trigger` directs Terraform to automatically invoke actions based on the conditions you specify. The `action_trigger` rule is a block that supports the following arguments:
+
+| Argument | Description | Data type | Required |
+| --- | --- | --- | --- |
+| `events` | Required list of lifecycle events to invoke the action. You can declare the following events: <ul><li>`before_create`: Invokes the specified actions before Terraform creates the resource.</li><li>`after_create`: Invokes the specified actions after Terraform creates the resource.</li><li>`before_update`: Invokes the specified actions before updating the infrastructure to match the configuration.</li><li>`after_update`: Invokes the specified actions after updating the infrastructure to match the configuration.</li></ul> | list | required |
+| `condition` | Optional [expression](/terraform/language/expressions) that must evaluate to `true` to invoke the action | expression | optional |
+| `actions` | Specifies an ordered list of actions to trigger when the `events` and `condition` arguments are met. | list | required |
+
+Refer to [Invoke an action](/terraform/language/invoke-actions) for more information. 
+
+You can use `action_trigger` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `create_before_destroy` 
+
+By default, when Terraform must change a resource argument that cannot be updated in-place due to remote API limitations, Terraform destroys the existing object and then create a new replacement object with the new configured arguments. Use the `create_before_destroy` rule to instruct Terraform to create a replacement resource before destroying the current resource. 
+
+This is an opt-in behavior because many remote object types have unique name requirements or other constraints that must be accommodated for both a new and an old object to exist concurrently. Some resource types offer special options to append a random suffix onto each object name to avoid collisions, for example. Terraform CLI cannot automatically activate such features, so you must understand the constraints for each resource type before using `create_before_destroy` with it.
+
+#### `create_before_destroy` and resource dependencies
+
+Terraform propagates and applies `create_before_destroy` behavior to all resource dependencies. For example: 
+
+- `create_before_destroy` is enabled on resource `A` but not on resource `B`.
+- Because resource `A` is dependent on resource `B`, Terraform enables `create_before_destroy` for resource `B` implicitly by default and stores it to the state file. 
+
+As a result, you cannot override `create_before_destroy`
+to `false` on resource `B` because that would imply dependency cycles in the graph.
+
+When the resource contains a provisioner that runs during the `destroy` operation,  setting `create_before_destroy` to `true` also prevents the provisioner from running. 
+
+You can use `create_before_destroy` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `prevent_destroy` 
+
+When `prevent_destroy` is set to `true`, Terraform rejects plans that would destroy the infrastructure object associated with the resource and returns an error. The argument must be present in the configuration. This rule doesn't prevent Terraform from destroying a resource if you remove its configuration. Refer to [Remove a resource from state](/terraform/language/state/remove) for instructions on how to remove a resource from state without destroying the actual resource.
+
+Use this rule as protection against accidentally replacing objects that may be costly to reproduce, such as database instances. Enabling `prevent_destory`, however, makes certain configuration changes impossible to apply
+and prevents the `terraform destroy` command from operating once such objects are created. Use `prevent_destroy` sparingly.
+
+You can use `prevent_destroy` in in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `ignore_changes` 
+
+By default, Terraform detects any difference in the current settings of a real infrastructure object and plans to update the remote object to match configuration. Use the `ignore_changes` argument when a resource is created with references to data that may change in the future, but should not affect the resource after its creation. 
+
+In some rare cases, a remote object's settings are modified by processes outside of Terraform, which Terraform attempts to resolve on the next run. To let Terraform share management responsibilities of a single object with a separate process, the `ignore_changes` meta-argument specifies resource attributes that Terraform should ignore when planning updates to the associated remote object.
+
+Terraform considers the arguments corresponding to the given attribute names when planning a `create` operation, but are ignored when planning an
+`update` operation. The arguments are the relative address of the attributes in the resource. You can reference map and list elements using index notation,
+such as `tags["Name"]` and `list[0]`.
+
+In the following example, Terraform ignores changes to `tags` so that a management agent can update them based on a rule set managed elsewhere:
+
+```hcl
+resource "aws_instance" "example" {
+   # ...
+   lifecycle {
+      ignore_changes = [
+         tags
+      ]  
+   }
+}
+```
+
+Instead of a list of items, you can use the `all` keyword to instruct
+Terraform to ignore all attributes. As a result, Terraform can
+create and destroy the remote object but will never propose updates to it.
+
+Terraform only ignores attributes defined by the resource type. You can't apply 
+`ignore_changes` to itself or to any other meta-arguments.
+
+You can use `ignore_changes` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `replace_triggered_by` 
+
+Terraform replaces the resource when any of the referenced resources or specified attributes change. Supply a list of expressions that reference managed resources, instances, or instance attributes. 
+
+When used in a resource that uses [`count`](/terraform/language/meta-arguments/count) or [`for_each`](/terraform/language/meta-arguments/for_each), you can use `count.index` or `each.key` in the expression to reference specific instances of other resources that are configured with the same count or collection.
+
+References trigger replacement in the following conditions:
+
+- If the reference is to a resource with multiple instances, a plan to
+   update or replace any instance triggers a replacement.
+- If the reference is to a single resource instance, a plan to update or
+   replace that instance triggers a replacement.
+- If the reference is to a single attribute of a resource instance, any
+   change to the attribute value triggers a replacement.
+
+You can only reference managed resources in `replace_triggered_by`
+expressions. This lets you modify these expressions without forcing
+replacement. 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
+      ]
+   }
+}
+```
+
+`replace_triggered_by` allows only resource addresses because the decision is based on the planned actions for all of the given resources. Plain values, such as local values or input variables, do not have planned actions of their own, but you can treat them with a resource-like lifecycle by using them with the [`terraform_data` resource](/terraform/language/resources/terraform-data).
+
+You can use `replace_triggered_by` in [`resource`](/terraform/language/block/resource) blocks. 
+
+### `precondition` 
+
+Specifies a condition that Terraform evaluates before creating the resource. 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`](/terraform/language/meta-arguments/count) and [`for_each`](/terraform/language/meta-arguments/for_each) meta-arguments. As a result, Terraform can evaluate the `precondition` separately for each instance and makes the `each.key` and `count.index` objects available in the conditions.
+
+You can include a `precondition` and [`postcondition` block](#postcondition) in the same resource. Do not add `precondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
+
+Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration. 
+
+You can use `precondition` in the following Terraform configuration blocks:
+
+- [`data`](/terraform/language/block/data)
+- [`ephemeral`](/terraform/language/block/ephemeral)
+- [`resource`](/terraform/language/block/resource) 
+
+### `postcondition` 
+
+Specifies a condition that Terraform evaluates after creating the resource. The following arguments in the `precondition` block are required:
+
+| Argument | Description | Data type |
+| --- | --- | --- |
+| `condition` | Expression that must return `true` for Terraform to perform operations on downstream resources. You can refer to any other object in the same configuration scope unless the reference creates a cyclic dependency. | Expression that can include references, strings, and operators. |
+| `error_message` | Message that Terraform prints to the console if the `condition` returns `false`. | String |
+
+Terraform evaluates `postcondition` blocks after planning and applying changes to the data source. Postcondition failures prevent changes to other resources that depend on the failing resource.
+
+You can include a `postcondition` and [`precondition` block](#precondition) in the same resource. Do not add `postcondition` blocks to a `resource` block and a `data` block that represent the same object in the same configuration. Doing so may cause Terraform to ignore changes to the `data` block that result from changes in the `resource` block.
+
+Refer to [Validate your configuration](/terraform/language/validate) for information about adding validations to your Terraform configuration.
+
+You can use `precondition` in the following Terraform configuration blocks:
+
+- [`data`](/terraform/language/block/data) 
+- [`ephemeral`](/terraform/language/block/ephemeral)
+- [`resource`](/terraform/language/block/resource) 
+
+### `destroy` 
+
+Set to `false` to remove a resource from state without destroying the actual infrastructure resource. You can only use this rule in [`removed`](/terraform/language/block/removed) block.
+
+## Supported constructs
+
+Support for each `lifecycle` rule varies across Terraform configuration blocks. Refer to the reference documentation for the Terraform block you are adding to your configuration for details.
+
+
+## Example use cases
+
+The following use cases describe common patterns for the `lifecycle` argument.
+
+
+### 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
+     ]
+   }
+}
+```
+
+### Validate the AMI for creating instances
+
+In the following example, the `precondition` block ensures that the AMI ID retrieved from the `data` block includes `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
+data "aws_ami" "example" {
+  most_recent= true
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-*"]
+  }
+}
+
+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."
+    }
+  }
+}
+```
+### Validate that a root storage volume is encrypted
+
+In the following example, the `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."
+    }
+  }
+}
+
+data "aws_ami" "example" {
+  most_recent= true
+  owners = ["amazon"]
+  filter {
+    name   = "image-id"
+    values = ["ami-*"]
+  }
+}
+
+resource "aws_instance" "example" {
+  instance_type = "t3.micro"
+  ami           = data.aws_ami.example.id
+}
+
+output "api_base_url" {
+  value = "https://${aws_instance.example.private_dns}:8433/"
+}
+```
+
+The validation fails in this example, so Terraform prints the following message to the console:
+
+```shell-session
+│ Error: Resource postcondition failed
+│
+│   on main.tf line 31, in data "aws_ebs_volume" "example":
+│   31:       condition     = self.encrypted
+│     ├────────────────
+│     │ self.encrypted is false
+│
+│ The server's root volume is not encrypted.
+```
+
+### Validate ephemeral resources
+
+In the following example, the `aws_ssm_parameter` ephemeral resource has a `precondition` to ensure that compliance mode is enabled to secure production secrets, and a `postcondition` to ensure the generated password meets password requirements:
+
+<CodeBlockConfig highlight="15-25">
+
+```hcl
+variable "environment" {
+  description = "Deployment environment"
+  type        = string
+}
+
+variable "compliance_mode" {
+  description = "Enable compliance requirements for production"
+  type        = bool
+  default     = false
+}
+
+ephemeral "aws_ssm_parameter" "database_password" {
+  name = "/secrets/${var.environment}/database/password"
+
+  lifecycle {
+    precondition {
+      condition     = var.environment != "prod" || var.compliance_mode == true
+      error_message = "Enable compliance mode to assess production secrets."
+    }
+
+    postcondition {
+      condition     = can(regex("^[A-Za-z0-9!@#$%^&*()_+=-]{16,}$", self.value))
+      error_message = "Password from external source must meet security requirements."
+    }
+  }
+}
+```
+
+</CodeBlockConfig>
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/provider.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/provider.mdx
new file mode 100644
index 0000000000..3a235c9311
--- /dev/null
+++ b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/provider.mdx	
@@ -0,0 +1,124 @@
+---
+page_title: provider meta-argument reference
+description: Learn how the `provider` meta-argument works in Terraform configuration.
+---
+
+# `provider` reference
+
+The `provider` meta-argument specifies which provider configuration to use for a resource,
+overriding Terraform's default behavior of selecting one based on the resource
+type name. Note that the `provider` argument is distinct from the [`provider` block](/terraform/language/block/provider), which contains provider configuration settings. Refer to [Providers](/terraform/language/providers) for more information.
+
+## Usage
+
+By default, Terraform determines the local name of the provider from the first word in the resource type and uses that provider's default configuration to create the resource. For example, the resource type `google_compute_instance` automatically uses the default configuration for the `google` provider. 
+
+The default behavior does not apply to [`list` blocks](/terraform/language/block/tfquery/list), however, because Terraform does not implicitly use the default `provider` configuration when querying resources.  
+
+You can add multiple `provider` blocks to your configuration and use the `provider` argument to a resource definition to specify which provider it should use. For its value, the `provider` argument expects a reference formatted as `<PROVIDER>.<ALIAS>`. 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
+  # ...
+}
+```
+
+Quotation marks are not required. Arbitrary expressions are not permitted because Terraform must resolve the `provider` value while constructing the dependency graph before Terraform can safely evaluate expressions. 
+
+A resource always has an implicit dependency on its associated provider. This ensures that the provider is fully configured before Terraform takes any actions on resources.
+
+Creating multiple configurations for a single provider is a common pattern for managing resources in different regions of multi-region services. 
+
+## Supported constructs
+
+You can use `provider` in the following Terraform configuration blocks:
+
+- [`check` blocks](/terraform/language/block/check)
+- [`data` blocks](/terraform/language/block/data)
+- [`ephemeral` blocks](/terraform/language/block/ephemeral)
+- [`import` blocks ](/terraform/language/block/import)
+- [`resource` blocks](/terraform/language/block/resource)
+
+You can use `for_each` in the following query configuration blocks:
+
+- [`list` blocks](/terraform/language/block/tfquery/list)
+
+
+## Example use cases
+
+The following use cases describe common patterns for the `provider` argument. Refer to the [examples in the `provider` block reference](/terraform/language/block/provider#examples) for more use cases.
+
+### Query a data source in different region
+
+In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
+
+```hcl
+provider "google" {
+  region = "us-central1"
+}
+
+provider "google" {
+  alias  = "europe"
+  region = "europe-west1"
+}
+
+data "google_compute_instance" "example" {
+  provider = google.europe
+  # ...
+}
+```
+
+### Use alternate provider for an ephemeral resource
+
+In the following example, Terraform uses the `aws.west` provider configuration to create the `aws_secretsmanager_secret_version` resource in the `us-west-2` region:
+
+```hcl
+provider "aws" {
+  region = "us-east-1"
+}
+
+provider "aws" {
+  alias  = "west"
+  region = "us-west-2"
+}
+
+ephemeral "aws_secretsmanager_secret_version" "db_password" {
+  provider  = aws.west
+  secret_id = aws_secretsmanager_secret.db_password.id
+}
+```
+
+### Import resources using an alternate provider configuration
+
+In the following example, Terraform imports the AWS instance with the ID `i-096fba6d03d36d262` to the `aws_instance.web` resource according to the `east` alias.
+
+```hcl
+provider "aws" {
+  region = "us-westl-1"
+}
+
+provider "aws" {
+  alias  = "east"
+  region = "us-east-1"
+}
+
+import {
+  id = "i-096fba6d03d36d262"
+  to = aws_instance.web
+  provider = aws.east
+}
+
+resource "aws_instance" "web" {
+  # ...
+}
+```
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/providers.mdx b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/providers.mdx
new file mode 100644
index 0000000000..38a7ea4e84
--- /dev/null
+++ b/content/terraform/v1.14.x (beta)/docs/language/meta-arguments/providers.mdx	
@@ -0,0 +1,125 @@
+---
+page_title: providers meta-argument reference
+description: Learn how the `providers` meta-argument works in Terraform configuration.
+---
+
+# `providers` reference
+
+By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources.
+
+## Usage
+
+In a [`module` block](/terraform/language/block/module), you can add the optional `providers` meta-argument to specify which [provider configurations](/terraform/language/modules/configuration) from the parent module is available inside the child module.
+
+The value of `providers` is a map, where the keys are the provider configuration names used inside the child module and the values are provider configuration names from the parent module.
+
+Keys and values are unquoted references to provider configurations.
+For default configurations, the reference is the local name of the provider. For
+alternate configurations, the reference uses a `<PROVIDER>.<ALIAS>` format.
+
+Within a child module, either Terraform chooses a default based on the name of the resource
+type, or the resource specifies an alternate configuration with the `provider`
+argument. If the module receives a `providers` map when it's called, the
+provider configuration names used within the module are effectively remapped to
+refer the specified configurations from the parent module.
+
+In the following example, Terraform uses the default `aws` configuration for AWS resources in the root module where no explicit provider instance is selected, but the example child moduleuses the alternate configuration with the alias `usw2`. As a result, any AWS resources the module defines uses the `us-west-2` region.
+
+
+```hcl
+provider "aws" {
+  region = "us-west-1"
+}
+
+provider "aws" {
+  alias  = "usw2"
+  region = "us-west-2"
+}
+
+module "example" {
+  source    = "./example"
+  providers = {
+    aws = aws.usw2
+  }
+}
+```
+
+### Default behavior
+
+The `providers` argument is optional when the child module does not declare a [`configuration_aliases`](/terraform/language/modules/develop/providers#provider-aliases-within-modules). When you omit the argument, a child module inherits all of the default provider configurations from its parent module. Default provider configurations are configurations that don't have an `alias` argument.
+
+Specifying a `providers` argument cancels the default behavior. As a result, the child module only has access to the provider configurations you specify.
+
+### When to specify `providers`
+
+Add the `providers` argument when one of the following conditions apply:
+
+- Using different default provider configurations for a child module.
+- Configuring a module that requires multiple configurations of the same provider.
+
+### Change default provider configurations
+
+Most re-usable modules only use default provider configurations, which they can
+automatically inherit from their caller when `providers` is omitted.
+
+However, in Terraform configurations that use multiple configurations of the same provider, you might want some child modules to use the default provider configuration and others to use an alternate. 
+A common use case is using one configuration to manage resources in multiple different regions of the same cloud provider.
+
+Using `providers` argument lets you accommodate this without needing to edit the child module. Although the code
+within the child module always refers to the default provider configuration, the
+actual configuration of that default can be different for each instance.
+
+
+## Information for module developers
+
+For more details and guidance about working with providers inside a re-usable
+child module, refer to [Providers Within Modules](/terraform/language/modules/develop/providers).
+
+## Supported constructs
+
+You can use `providers` in the following Terraform configuration blocks:
+
+- [`module` blocks](/terraform/language/block/module)
+
+You can use `providers` in the following Stack configuration blocks:
+
+- [`component` blocks](/terraform/language/block/stack/tfcomponent/component)
+- [`removed` blocks](/terraform/language/block/stack/tfcomponent/removed)
+
+### Example use cases
+
+The following use cases describe common patterns for the `providers` argument.
+
+### Modules with alternate provider configurations
+
+In rare cases, a single re-usable module might require multiple configurations
+of the same provider. For example, a module that configures connectivity between
+networks in two AWS regions is likely to need both a `source` and a `destination`
+region. 
+
+In the following example, the `tunnel` module includes resources that support their own provider configuration. As a result, each resource alias maps to a different provider configurations declared in the root module:
+
+```hcl
+provider "aws" {
+  alias  = "usw1"
+  region = "us-west-1"
+}
+
+provider "aws" {
+  alias  = "usw2"
+  region = "us-west-2"
+}
+
+module "tunnel" {
+  source    = "./tunnel"
+  providers = {
+    aws.src = aws.usw1
+    aws.dst = aws.usw2
+  }
+}
+```
+
+Non-default provider configurations are never automatically inherited, so any
+module that works in this manner always requires a `providers` argument. The
+documentation for the module should specify all of the provider configuration
+names it needs.