Apply suggestions from code review

Co-authored-by: Brian McClain <brianmmcclain@gmail.com>

Author: trujillo-adam

content/terraform/v1.13.x/docs/language/meta-arguments/count.mdx

@@ -5,7 +5,7 @@ description: Learn how the `count` meta-argument works in Terraform configuratio
 
 # `count` 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. 
+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.
 

content/terraform/v1.13.x/docs/language/meta-arguments/depends_on.mdx

@@ -84,7 +84,6 @@ You can use `depends_on` in the following Terraform configuration blocks:
 
 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.  
@@ -113,7 +112,7 @@ check "database_connection" {
 
 ### 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:
+In the following example, Terraform must launch the `aws_db_instance` service first so that `aws_instance` can connect to it:
 
 ```hcl
 provider "aws" {

content/terraform/v1.13.x/docs/language/meta-arguments/for_each.mdx

@@ -13,7 +13,7 @@ Use the `for_each` meta-argument to manage several similar objects, such as a fi
 
 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.
+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:
 
@@ -51,7 +51,7 @@ In many cases, you can use a `for` expression to achieve similar results. For ex
 
 ### 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
+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.
 

content/terraform/v1.13.x/docs/language/meta-arguments/index.mdx

@@ -5,7 +5,7 @@ description: Meta-arguments are built-in Terraform arguments that determine how
 
 # Meta-arguments
 
-Meta-arguments are a class of arguments built into the Terraform configuration language that control how Terraform creates your infrastructure. 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.
+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.
 
@@ -23,7 +23,7 @@ The `depends_on` meta-argument establishes dependencies between resources that d
 
 ## `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. Refer to the [`count` reference](/terraform/language/meta-arguments/count) for details.
+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.
 

content/terraform/v1.13.x/docs/language/meta-arguments/lifecycle.mdx

@@ -29,8 +29,7 @@ This is an opt-in behavior because many remote object types have unique name req
 Note that Terraform propagates and applies the `create_before_destroy` meta-attribute 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 by default and stores it to the state file. You cannot override `create_before_destroy`
 to `false` on resource `B` because that would imply dependency cycles in the graph.
 
-Destroy provisioners of this resource do not run if `create_before_destroy`
-is set to `true`. This [GitHub issue](https://github.com/hashicorp/terraform/issues/13549) contains more details.
+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. 
 
@@ -44,7 +43,6 @@ and prevents the `terraform destroy` command from operating once such objects ar
 
 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. 

content/terraform/v1.13.x/docs/language/meta-arguments/provider.mdx

@@ -13,7 +13,7 @@ type name. Note that the `provider` argument is distinct from the [`provider` bl
 
 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>`](/terraform/language/providers/configuration#referring-to-alternate-provider-configurations). In the following example, the `google_compute_instance` resource selects the provider configuration with the `europe` alias.
+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" {

content/terraform/v1.13.x/docs/language/meta-arguments/providers.mdx

@@ -9,7 +9,7 @@ By default, child modules inherit the default provider configurations of their p
 
 ## Usage
 
-In a [`module` block](/terraform/language/module/syntax), 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.
+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.
 
@@ -50,7 +50,6 @@ The `providers` argument is optional when the child module does not declare a [`
 
 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:
@@ -86,36 +85,14 @@ You can use `providers` in the following Terraform configuration blocks:
 
 The following use cases describe common patterns for the `providers` argument.
 
-### 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
-  }
-}
-```
-
 ### 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. The following example shows possible root module configuration for this use case:
+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" {