Apply suggestions from code review

Co-authored-by: Judith Malnick <judith@hashicorp.com>

Author: trujillo-adam

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

@@ -7,7 +7,7 @@ description: Learn how the `for_each` meta-argument works in Terraform configura
 
 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 `count` argument whose value is a whole number, Terraform creates that many instances.
+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
 

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

@@ -33,6 +33,11 @@ By default, Terraform configures one infrastructure object for each `resource`,
 
 > **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`
 
@@ -42,8 +47,3 @@ By default, Terraform determines the local name of the provider from the first w
 
 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.
 
-## `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. 

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

@@ -35,7 +35,7 @@ This is an opt-in behavior because many remote object types have unique name req
 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 `B1, Terraform enables `create_before_destroy` for resource `B` implicitly by default and stores it to the state file. 
+- 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.