Sync 1.14.x with any changes from 1.13.x

content/terraform/v1.14.x/docs/cli/import/index.mdx

@@ -10,7 +10,6 @@ This topic provides an overview of the Terraform commands that let you import ex
 
 > **Hands-on:** Try the [Import Terraform Configuration](/terraform/tutorials/state/state-import?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
 
-
 ## Workflows
 
 You can import an existing resource to state from the Terraform CLI. You can also perform import operations using HCP Terraform. To import multiple resources, use the `import` block.  

content/terraform/v1.14.x/docs/language/block/moved.mdx

@@ -34,7 +34,7 @@ This section provides details about the fields you can configure in the `moved`
 
 The `moved` block specifies the previous address and the new address for the resource. The following table describes the arguments you can set in the `moved` block.
 
-| Arbument | Description | Type | Required |
+| Argument | Description | Type | Required |
 | ---   | ---         | ---  | ---      |
 | `from` | Specifies a resource's previous address. The syntax allows Terraform to select modules, resources, and resources inside child modules. | string | required |
 | `to` | Specifies the new address to relocate the resource to. The syntax allows Terraform to select modules, resources, and resources inside child modules. | string | required |
@@ -50,4 +50,4 @@ moved {
   from = aws_instance.a
   to   = aws_instance.b
 }
-```
+```

content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/component.mdx

@@ -130,6 +130,12 @@ The keys in the `providers` map must match the provider names that the source mo
 
 `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
+- Default: None
+- Required: Yes
+
 
 ### `inputs`
 
@@ -171,6 +177,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.
 
 `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.
@@ -211,7 +218,6 @@ When you use `for_each`, Terraform creates one component instance for each item
 
 `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
 
 The following examples demonstrate common use cases for `component` blocks.

content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/provider.mdx

@@ -113,11 +113,6 @@ When you use `for_each`, you can reference individual provider instances using `
 
 `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
-- Default: None
-
 ## Examples
 
 The following examples demonstrate common use cases for `provider` blocks in Stacks.

content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/removed.mdx

@@ -154,7 +154,8 @@ 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.
 

content/terraform/v1.14.x/docs/language/block/stack/tfcomponent/variable.mdx

@@ -59,7 +59,7 @@ The `variable` block supports the following arguments:
 | `description` | A description of the variable's purpose and the value it expects. | String | Optional |
 | `sensitive` | Specifies if Terraform hides this value in UI and logs. | Boolean | Optional |
 | `nullable` | Specifies if the value of a variable can be `null`. | Boolean | Optional |
-| `ephemeral` | Specifies whether Terraform excludes this value from plans and state. | Boolean | Boolean | Optional |
+| `ephemeral` | Specifies whether Terraform excludes this value from plans and state. | Boolean | Optional |
 
 ### `type`
 

content/terraform/v1.14.x/docs/language/data-sources/index.mdx

@@ -68,7 +68,7 @@ data "aws_ami" "example" {
 }
 ```
 
-The `data` block instructs Terraform to read from the `aws_ami` data source and export the result to an object named `example`. To reference the returned data, use the `data.<TYPE>.<LABEL>.<ATTRIBUTE>` syntax, for example, `data.aws_ami.example.id`. Refer to [Reference queried data](#referenece-queried-data) for more information.
+The `data` block instructs Terraform to read from the `aws_ami` data source and export the result to an object named `example`. To reference the returned data, use the `data.<TYPE>.<LABEL>.<ATTRIBUTE>` syntax, for example, `data.aws_ami.example.id`. Refer to [Reference queried data](#reference-queried-data) for more information.
 
 ## Configure query constraints
 
@@ -113,7 +113,7 @@ data "aws_ami" "example" {
 }
 ```
 
-Custom conditions return useful information about errors earlier and in context so that you can more easily diagnose configuration issues. They also help future maintainers understand the configuration design and intent. Refer to [Custom Condition Checks](/terraform/language/expressions/custom-conditions#preconditions-and-postconditions) for more details.
+Custom conditions return useful information about errors earlier and in context so that you can more easily diagnose configuration issues. They also help future maintainers understand the configuration design and intent. Refer to [Custom Condition Checks](/terraform/language/expressions/conditionals#conditions) for more details.
 
 ### Multiple instances
 
@@ -187,4 +187,4 @@ resource "aws_instance" "web" {
 }
 ```
 
-The `filter` blocks, and the arguments within them, and the `most_recent` argument are specific to the `aws_ami` provider. Refer to the [AWS provider documenation](https://registry.terraform.io/providers/hashicorp/aws/latest) in the Terraform registry for details. 
+The `filter` blocks, and the arguments within them, and the `most_recent` argument are specific to the `aws_ami` provider. Refer to the [AWS provider documenation](https://registry.terraform.io/providers/hashicorp/aws/latest) in the Terraform registry for details. 

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

@@ -13,8 +13,6 @@ 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. 
 
-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
@@ -46,14 +44,9 @@ 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)
+- [`import` block ](/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.

content/terraform/v1.14.x/docs/language/modules/configuration.mdx

@@ -44,6 +44,7 @@ In the following example, Terraform selects the module version from a Git reposi
 module "vpc" {
   source = "git::https://example.com/vpc.git?ref=v1.2.0"
 }
+```
 
 You can also source a module using its SHA-1 hash: 
 
@@ -66,7 +67,7 @@ Add the `depth` query parameter to the `source` URL and specify how many commits
 
 The following module sources support shallow clones:
 
-- [GitHub repositoris](/terraform/language/block/module#github-repository)
+- [GitHub repositories](/terraform/language/block/module#github-repository)
 - [Git repositories](/terraform/language/block/module#git-repository)
 - [BitBucket repositories](/terraform/language/block/module#bitbucket-repository)
 
@@ -179,4 +180,4 @@ removed {
 }
 ```
 
-Refer to [`moved` block reference](/terraform/language/block/removed) for more information.
+Refer to [`moved` block reference](/terraform/language/block/removed) for more information.

content/terraform/v1.14.x/docs/language/modules/develop/refactoring.mdx

@@ -22,7 +22,7 @@ You can use `moved` blocks for the following use cases:
 - [Rename a module call](#rename-a-module-call)
 - [Split a module](#split-a-module)
 
-When the module or resource is no longer necessary, you can [remove `moved` blocks](#remove-a-move-block) from the configuration. Note that removing a `moved` block is a breaking change.
+When the module or resource is no longer necessary, you can [remove `moved` blocks](#remove-a-moved-block) from the configuration. Note that removing a `moved` block is a breaking change.
 
 ## Requirements
 
@@ -109,7 +109,7 @@ resource (a `data` block).
 
 ## Create multiple instances
 
-You can use a `moved` block when creating mulitple instances of a resource or module call while preserving the original instance.
+You can use a `moved` block when creating multiple instances of a resource or module call while preserving the original instance.
 
 ### Enable `count` or `for_each` for a resource
 
@@ -416,7 +416,7 @@ moved {
 }
 ```
 
-## Remove a `move` block
+## Remove a `moved` block
 
 Over time, a long-lasting module may accumulate many `moved` blocks.
 

content/terraform/v1.14.x/docs/language/resources/configure.mdx

@@ -105,7 +105,7 @@ The following examples describe some common ways you can use meta-arguments in y
 
 ### Custom conditions
 
-Add `precondition` and `postcondition` blocks to specify assumptions and guarantees about how the resource operates. These blocks help avoid common misconfigurations and can help future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context so that consumers can diagnose issues in their configuration. Refer to [Validate your configuration](/terraform/language/test-and-validate/validate) for instructions on creating custom condition checks.
+Add `precondition` and `postcondition` blocks to specify assumptions and guarantees about how the resource operates. These blocks help avoid common misconfigurations and can help future maintainers understand the configuration design and intent. They also return useful information about errors earlier and in context so that consumers can diagnose issues in their configuration. Refer to [Validate your configuration](/terraform/language/validate) for instructions on creating custom condition checks.
 
 For an example configuration, refer to [Apply custom conditions](/terraform/language/block/resource#apply-custom-conditions).
 

content/terraform/v1.14.x/docs/language/stacks/deploy/pass-data.mdx

@@ -20,8 +20,8 @@ To consume the data exported by the upstream Stack, declare an `upstream_input`
 Downstream Stacks must reside in the same project as their upstream Stacks.
 
 The following limitations apply to passing data between Stacks:
-- Stacks can link to up to 20 other upstream Stacks. [Learn more about passing data between Stacks](/terraform/language/stacks/deploy/pass-data).
-- Stacks can expose values to up to 25 downstream Stacks. [Learn more about passing data between Stacks](/terraform/language/stacks/deploy/pass-data).
+- Stacks can link to up to 20 other upstream Stacks.
+- Stacks can expose values to up to 25 downstream Stacks.
 
 ## Expose outputs to another Stack
 

content/terraform/v1.14.x/docs/language/stacks/design.mdx

@@ -27,7 +27,7 @@ Before writing your component configuration, we recommend assessing your current
 
 Each Stack should represent a single system or application with a shared lifecycle. Start by analyzing your current infrastructure and identifying the components HCP Terraform should manage together. Components are typically groups of related resources, such as an application’s backend, frontend, or database layer, deployed and scaled together.
 
-We recommend structuring your Stacks along technical boundaries to keep them modular and manageable. For example, you can create a dedicated Stack for shared services, such as networking infrastructure for VPCs, subnets, or routing tables, and separate Stacks for application components that consume those shared services. This separation lets you to manage shared services independently while passing information between Stacks. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
+We recommend structuring your Stacks along technical boundaries to keep them modular and manageable. For example, you can create a dedicated Stack for shared services, such as networking infrastructure for VPCs, subnets, or routing tables, and separate Stacks for application components that consume those shared services. This separation lets you manage shared services independently while passing information between Stacks. For more details, refer to [Pass data from one Stack to another](/terraform/language/stacks/deploy/pass-data).
 
 ### Sketch out your configuration
 

content/terraform/v1.14.x/docs/language/stacks/update-GA.mdx

@@ -22,11 +22,11 @@ The general availability release of Stacks introduced a few backward-incompatibl
 - Stacks no longer support the `<NAME>.tfstack.hcl` file extension.
   - The new extension for configuring your Stack components is `<NAME>.tfcomponent.hcl`. The file name change better reflects the mental model of a component-based configuration.
 
-## Billing Changes
+## Billing changes
 
 The Stacks public beta did not count toward your HCP Terraform organization's Resources Under Management (RUM). With the GA release, Stacks RUM is aggregated with your workspace RUM for billing purposes.
 
-### Billing Dashboard
+### Billing dashboard
 
 The HCP Terraform usage page has been updated to reflect the new billing metrics, including:
 
@@ -37,6 +37,13 @@ The HCP Terraform usage page has been updated to reflect the new billing metrics
 
 For more information on billing, refer to the [HCP Terraform pricing page](https://www.hashicorp.com/en/pricing).
 
+
+## UI changes
+
+You can no longer destroy Stack deployments and their resources from the HCP Terraform UI. To destroy a Stack deployment, add the [`destroy` argument](/terraform/language/block/stack/tfdeploy/deployment#destroy) to a `deployment` block, then trigger a new deployment run.
+
+To learn more about destroying Stacks and their deployments, refer to [Destroy a Stack](/terraform/cloud-docs/stacks/destroy).
+
 ## Steps for migration
 
 If you used Stacks during the public beta, you need to take a few steps to transition your existing configurations to the GA release.
@@ -108,4 +115,4 @@ For more information about deployment groups and auto-approval rules, refer to [
 
 ### Fetch your configuration
 
-Trigger a new configuration fetch for each of your Stacks. The fetching process pulls your configuration from your Version Control System (VCS) and reinitializes your Stack. You can do this by using the [`terraform stacks fetch`](/terraform/cli/commands/stacks/configuration/fetch) command in the new CLI, or by triggering a deployment run in the HCP Terraform UI.
+Trigger a new configuration fetch for each of your Stacks. The fetching process pulls your configuration from your Version Control System (VCS) and reinitializes your Stack. You can do this by using the [`terraform stacks configuration fetch`](/terraform/cli/commands/stacks/configuration/fetch) command in the new CLI, or by triggering a deployment run in the HCP Terraform UI.

content/terraform/v1.14.x/docs/language/validate/index.mdx

@@ -123,6 +123,7 @@ data "aws_ami" "example" {
   executable_users = ["self"]
   most_recent      = true
   owners           = ["self"]
+
   filter {
     name   = "name"
     values = ["myami-*"]

content/terraform/v1.14.x/docs/partials/premium-deployment-groups.mdx

@@ -1,5 +1,5 @@
 <Note title="Premium tier">
 
-Running orchestration rules for deployment groups is available in the HCP Terraform **Plus** Edition. Refer to [HCP Terraform pricing](https://www.hashicorp.com/products/terraform/pricing) for details.
+Running orchestration rules for deployment groups is available in the HCP Terraform **Premium** Edition. Refer to [HCP Terraform pricing](https://www.hashicorp.com/products/terraform/pricing) for details.
 
 </Note>