diff --git a/content/terraform/v1.14.x (alpha)/data/cli-nav-data.json b/content/terraform/v1.14.x (alpha)/data/cli-nav-data.json
index ab233710c0..3361f7a412 100644
--- a/content/terraform/v1.14.x (alpha)/data/cli-nav-data.json	
+++ b/content/terraform/v1.14.x (alpha)/data/cli-nav-data.json	
@@ -59,8 +59,12 @@
       { "title": "Overview", "path": "import" },
       { "title": "Import existing resources", "path": "import/usage" },
       {
-        "title": "Reference",
+        "title": "import command reference",
         "href": "/cli/commands/import"
+      },
+      { 
+        "title": "query command reference", 
+        "href": "/cli/commands/query"
       }
     ]
   },
@@ -281,6 +285,7 @@
         "title": "<code>providers schema</code>",
         "href": "/cli/commands/providers/schema"
       },
+      { "title": "<code>query</code>", "href": "/cli/commands/query" },
       { "title": "<code>refresh</code>", "href": "/cli/commands/refresh" },
       { "title": "<code>show</code>", "href": "/cli/commands/show" },
       { "title": "<code>state</code>", "href": "/cli/commands/state" },
@@ -370,6 +375,7 @@
           { "title": "providers schema", "path": "commands/providers/schema" }
         ]
       },
+      { "title": "query", "path": "commands/query" },
       { "title": "refresh", "path": "commands/refresh" },
       { "title": "show", "path": "commands/show" },
       {
diff --git a/content/terraform/v1.14.x (alpha)/data/language-nav-data.json b/content/terraform/v1.14.x (alpha)/data/language-nav-data.json
index ebc5f2c523..3011c7b5d8 100644
--- a/content/terraform/v1.14.x (alpha)/data/language-nav-data.json	
+++ b/content/terraform/v1.14.x (alpha)/data/language-nav-data.json	
@@ -30,7 +30,8 @@
       { "title": "Overview", "path": "files" },
       { "title": "Override files", "path": "files/override" },
       { "title": "Dependency lock file", "path": "files/dependency-lock" },
-      { "title": "Test files", "path": "files/tests" }
+      { "title": "Test files", "path": "files/tests" },
+      { "title": "Query files", "path": "files/tfquery" }
     ]
   },
   {
@@ -191,11 +192,16 @@
   {
       "title": "Import existing resources",
       "routes": [
-       { "title": "Import a resource", "path": "import" },
-       {
-         "title": "Generate resource configuration",
-         "path": "import/generating-configuration"
-       }
+        { "title": "Overview", "path": "import"},
+        {
+          "title": "Import resources in bulk",
+          "path": "import/bulk"
+        },
+         { "title": "Import a single resource", "path": "import/single-resource" },
+         {
+           "title": "Generate configuration for single imports",
+           "path": "import/generating-configuration"
+        }
     ]
   },
   {
@@ -326,6 +332,32 @@
       }
     ]
   },
+  {
+    "title": "Query blocks",
+    "routes": [
+      {
+        "title": "list",
+        "path": "block/tfquery/list",
+        "badge": {
+          "text": "BETA",
+          "type": "outlined",
+          "color": "neutral"
+        }
+      },
+      {
+        "title": "locals",
+        "href": "/language/block/locals"
+      },
+      {
+        "title": "provider",
+        "href": "/language/block/provider"
+      },
+      {
+        "title": "variable",
+        "href": "/language/block/variable"
+      }
+    ]
+  },
   {
     "title": "Meta-arguments",
     "path": "meta-arguments"
diff --git a/content/terraform/v1.14.x (alpha)/docs/cli/commands/query.mdx b/content/terraform/v1.14.x (alpha)/docs/cli/commands/query.mdx
new file mode 100644
index 0000000000..41f7333d2c
--- /dev/null
+++ b/content/terraform/v1.14.x (alpha)/docs/cli/commands/query.mdx	
@@ -0,0 +1,86 @@
+---
+page_title: locals block reference for `.tfquery.hcl` files
+description: |-
+ Add the `locals` block to your `.tfquery.hcl` files define values to reuse within the local Terraform module. 
+---
+
+# `terraform query` command
+
+The `terraform query` command queries existing infrastructure for resources according to the `tfquery.hcl` file so that you can import them into your Terraform workspace.
+
+## Usage
+
+```shell-session
+$ terraform query [flags] [options]
+```
+
+## Description
+
+When you run the `terraform query` command, Terraform checks the current configuration directory for files with a `.tfquery.hcl` extension. Then, Terraform queries remote infrastructure for resources that match the `list` blocks defined in the query file and prints the results to the terminal. You can also add the `-generate-config-out` flag to generate configuration that you can use to import the resources. Refer to [Import resources in bulk](/terraform/language/import/bulk) for more information.
+
+## Flags
+
+- `-var '<INPUT-VARIABLE>=<VALUE>'`: Specifies a key-value pair that sets an input variable defined in the `tfquery.hcl` configuration. You can use this flag more than once to set additional input variables.   
+    - Data type: String. 
+    - Example: [Set input variables](#set-input-variabls)
+
+- `-var-file=<FILENAME>`: Specifies a file containing input variable values, in addition to the default `terraform.tfvars` and `*.auto.tfvars` files.  
+    - Data type: Filename 
+    - Example: [Set input variables](#set-input-variabls)
+
+## Options
+
+- `-generate-config-out=<PATH/TO/OUTPUT>`: Instructs Terraform to generate `import` and `resource` blocks for results so that you can import them. Terraform writes the configuration to a new file. The file must not already exist. When used with the `-json` option, Terraform generates the configuration as part of the JSON output instead of writing it to a file. 
+    - Data type: Path 
+    - Example: [Generate import configuration](#generate-import-configuration)
+
+- `-json`: Instructs Terraform to print results to the console in JSON format. 
+     - Data type: Boolean
+     - Example: [Generate import configuration](#generate-import-configuration)
+
+- `-no-color`: Terraform prints monochrome results. 
+     - Data type: Boolean
+## Examples
+
+The following examples show how to use the command for common use cases.
+
+### Set input variables
+
+The following command passes sets the value of the `env` input variable to `prod`:
+
+```shell-session
+$ terraform query -var 'env=prod'
+```
+
+Corresponding `tfquery.hcl` configuration:
+
+```hcl
+list "aws_instance" "instances" {
+  provider = aws
+}
+
+variable "env" {
+  type = string
+  default = "test"
+}
+```
+
+The following command loads variable values defined in `my-vars.tfvars`:
+
+```shell-session
+$ terraform query -var-file=my-vars.tfvars
+```
+
+### Generate import configuration
+
+The following command generates `import` and `resource` blocks for the query results to a file in the `to-import` directory:
+
+```shell-session
+$ terraform query -generate-config=to-import/file.tf
+```
+
+The following command prints `import` and `resource` blocks for the query results as JSON:
+
+```shell-session
+$ terraform query -generate-config=file.tf -json
+```
diff --git a/content/terraform/v1.14.x (alpha)/docs/language/block/tfquery/list.mdx b/content/terraform/v1.14.x (alpha)/docs/language/block/tfquery/list.mdx
new file mode 100644
index 0000000000..d7d5804723
--- /dev/null
+++ b/content/terraform/v1.14.x (alpha)/docs/language/block/tfquery/list.mdx	
@@ -0,0 +1,321 @@
+---
+page_title: list block reference for `.tfquery.hcl` files
+description: |-
+ Add the `list` block to your `.tfquery.hcl` files to declare Terraform providers and configure them when querying existing infrastructure for resources to import. 
+---
+
+# `list` block reference
+
+The `list` block defines a query that reads existing infrastructure and returns resources that you can import to your Terraform workspace. You can only add `list` blocks to configuration files with `.tfquery.hcl` extensions. This topic provides reference information about configuring `list` blocks in `.tfquery.hcl` files. Refer to [Import existing resources in bulk](/terraform/language/import/bulk) for information about querying and importing resources. 
+
+@include 'beta.mdx'
+
+## Configuration model
+
+A `list` block supports the following configuration:
+
+- [`list "<TYPE>" "<LABEL>"`](#list) block
+  - [`provider`](#provider) &nbsp reference | required
+  - [`count`](#count) number &nbsp | mutually exclusive with `for_each`
+  - [`for_each`](#for_each) &nbsp map or set of strings | mutually exclusive with `count`
+  - [`include_resource`](#include_resource)  boolean
+  - [`limit`](#limit) number | `100`
+  - [`config`](#config)  block
+    - [provider-specific arguments](#config) | refer to your provider documentation
+
+## Complete configuration
+
+The following `list` block includes all supported built-in arguments:
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  provider = <provider>.<alias>
+  count = <number> # `count` and `for_each` are mutually exclusive
+  for_each [ # `for_each` and `count` are mutually exclusive
+    <KEY> = <VALUE>
+  ]
+  include_resource = <false>
+  limit = 100
+  config {
+    <provider-specific arguments> # refer to your provider documentation
+  }
+}
+```
+
+## Specification
+
+A `list` block supports the following configuration.
+
+### `list "<TYPE>" "<LABEL>"`
+
+You must set the following arguments for every `list` block:
+
+- `TYPE`: Specifies the type of resource you want to query. Refer to the provider documentation for the available resource types.
+- `LABEL`: Specifies a name for the specific `list` block. The label must be unique in the current directory. Use the `list.<label>.<attribute>` syntax to reference the `list` block. Refer to [References to Named Values](/terraform/language/expressions/references) and [Resource naming](/terraform/language/style#resource-naming) for expression syntax and label recommendations.
+
+### `provider`
+
+The `provider` argument specifies which provider configuration Terraform uses to query infrastructure.
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  provider = <provider>
+}
+```
+
+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) 
+
+### `count`
+
+The `count` meta-argument instructs Terraform to perform multiple queries using the same configuration.
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  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 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).
+
+### `for_each`
+
+The `for_each` meta-argument instructs Terraform to create similar lists of query results without requiring separate configuration blocks for each list.
+
+<Tabs>
+
+<Tab heading="List of values">
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  for_each = [ "<VALUE>" ]
+  # . . .
+}
+```
+
+</Tab>
+
+<Tab heading="Map of key-value pairs">
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  for_each = {
+    "<KEY>" = "<VALUE>"
+  }
+}
+```
+
+</Tab>
+
+</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).
+
+### `include_resource` 
+
+The `include_resource` argument directs Terraform to include all information about a resource in the response.
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  include_resource  = <boolean>
+}
+```
+
+By default, Terraform returns the resource identity in the response, but you can set the `include_resource` argument to `true` so that the provider returns full resource objects.
+
+#### Summary
+
+Data type: Boolean
+Default: None
+
+### `limit` 
+
+The `limit` argument specifies the maximum number of results returned by the query.
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  limit  = <number>
+}
+```
+
+You can specify a reference value that resolves to a number. The default value is `100`.
+
+When the number of results reaches the specified limit, Terraform breaks the connection to the provider and stops reporting results.  
+  
+
+#### Summary
+
+- Data type: Number
+- Default: `100`
+
+### `config`
+
+The `config` block defines configuration, such as filters, tags, or other provider-specific attriubtes, to define query parameters.
+
+```hcl
+list "<TYPE>" "<LABEL>" {
+  config {
+    <provider-specific configuration>
+  }
+}
+```
+
+Refer to your provider documentation for supported arguments and values.
+
+#### Summary
+
+- Data type: Block
+- Default: None
+
+## Examples
+
+The following examples show how to write configuration for common use cases.
+
+### Select an alternate provider configuration
+
+In the following example, Terraform queries for `google_compute_instance` resources using the provider configuration with the `europe` alias.
+
+```hcl
+provider "google" {
+  region = "us-central1"
+}
+
+provider "google" {
+  alias  = "europe"
+  region = "europe-west1"
+}
+
+list "google_compute_instance" "example" {
+  provider = google.europe
+  # ...
+}
+```
+
+### Create multiple lists of query results
+
+You can use either `count` or the `for_each` block to create multiple lists of query results. The `count` argument is most suitable for creating multiple lists that are identical or nearly identical. The `for_each` argument is most suitable for creating multiple lists based on attributes defined in a map or set.
+
+<Tabs>
+
+<Tab heading="count">
+
+The following example creates one list of query results for each subnet provided in the input variable:
+
+```hcl
+variable "subnet_ids" {
+  type = list(string)
+}
+
+list "aws_instance" "server" {
+   provider = aws
+   count = length(var.subnet_ids)
+}
+```
+
+</Tab>
+
+<Tab heading="for_each">
+
+The following example creates two lists that reference a map created using the `tomap()` function:
+
+```hcl
+list "azurerm_resource_group" "rg" {
+   provider = aws
+   for_each = tomap({
+      a_group       = "eastus"
+      another_group = "westus2"
+   })
+}
+```
+
+The following example creates four lists using a set created with the `toset()` function:
+
+```hcl
+list "aws_iam_user" "the-accounts" {
+   provider = aws
+   for_each = toset(["Todd", "James", "Alice", "Dottie"])
+}
+```
+
+</Tab>
+
+</Tabs>
+
+### Reference a list block
+
+In the following example, the `include_resource` argument is set to `true` in the `list.aws_instance.web` block. As a result, the query returns complete resource state information to the list of results for `web`. This lets the `list.aws_instance.web-bu` block reference the `length` attribute from `web` as the value for its `count` argument.
+
+```hcl
+list "aws_instance" "web" {
+  provider = aws
+  include_resource = true
+}
+
+list "aws_instance" "web-bu" {
+  provider = concept
+
+  config {
+    count = list.aws_instance.web.data[0].state.length
+  }
+}
+```
diff --git a/content/terraform/v1.14.x (alpha)/docs/language/files/tfquery.mdx b/content/terraform/v1.14.x (alpha)/docs/language/files/tfquery.mdx
new file mode 100644
index 0000000000..eb7829d3f9
--- /dev/null
+++ b/content/terraform/v1.14.x (alpha)/docs/language/files/tfquery.mdx	
@@ -0,0 +1,25 @@
+---
+page_title: Query files
+description: Learn about tfquery files, which define query parameters for searching existing infrastructure for resources to import and manage with Terraform 
+---
+
+# Query configuration files
+
+The `terraform query` command runs Terraform configuration files with the `.tfquery.hcl` extension. These files contain parameters that search for resources in your existing infrastructure. Use query files to help you find resources that you can import into Terraform state and begin managing as code. Refer to [Import resources in bulk](/terraform/language/import/bulk) for more information.   
+
+## File extension
+
+Terraform query files have the `.tfquery.hcl` file extension. 
+
+## Locations
+
+Terraform loads all query files in your root configuration directory.
+
+## Reference
+
+Query files contain the following configuration blocks:
+
+- [`list` block](/terraform/language/block/tfquery/list)
+- [`provider` block](/terraform/language/block/provider)
+- [`variable` block](/terraform/language/block/variable)
+- [`locals` block](/terraform/language/block/locals)
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (alpha)/docs/language/import/bulk.mdx b/content/terraform/v1.14.x (alpha)/docs/language/import/bulk.mdx
new file mode 100644
index 0000000000..67640c67eb
--- /dev/null
+++ b/content/terraform/v1.14.x (alpha)/docs/language/import/bulk.mdx	
@@ -0,0 +1,123 @@
+---
+page_title: Import existing resources in bulk
+description: Learn how to query existing infrastructure for unmanaged resources so you can import them into Terraform in bulk
+---
+
+# Import existing resources in bulk
+
+You can configure queries that instruct Terraform to search your existing infrastructure for unmanaged resources. Terraform can also generate configuration for importing the resources it finds so that you can import them to your Terraform workspace in bulk. For information about importing single resources or small batches of resources, refer to [Import single resources](/terraform/language/import/single-resource) for instructions.
+
+## Introduction
+
+For organizations with large sets of infrastructure resources, manually identifying and importing them is tedious and labor intensive, even when using third-party tools or custom scripts. To alleviate this burden, you can write HCL-based queries and run them with the Terraform CLI to retrieve unmanaged resources so that you can import them in bulk. 
+
+Complete the following steps to find and import resources in bulk:
+
+- Search for resources: Create `list` blocks to search for existing resources.
+- Generate configuration: Use the Terraform command to generate `resource` and `import` blocks for importing the resources. The configuration also includes the [resource identity](/terraform/language/import#resource-identity). 
+- Import resources: Copy the generated configuration into your main.tf file and run a `terraform apply` command to import the resources.
+- After importing resources, you can remove the generated `import` block or keep it as an historical record.
+
+## Define a query
+
+To search for resources, you must create a standard `.tf` configuration and a `.tfquery.hcl` configuration. 
+
+### Standard configurations
+
+If your `.tf` configuration does not already have a `required_providers` block, add it so that Terraform can install all provider plugins required to create and manage resources specified in the configuration. Refer to the [`required_providers` reference](/terraform/language/block/terraform#required_providers) for details on how to configure this block.
+
+### Query configurations
+
+Create a file with a `.tfquery.hcl` extension and add `list` blocks to define queries that read existing infrastructure and return lists of unmanaged resources. 
+
+Each `list` block requires an inline argument that specifies the type of resource you are querying. The type is specific to your provider. The block also requires an inline argument that declares a local name for the list of results returned by the query. Refer to the [`list` block reference](/terraform/language/block/tfquery/list) for configuration details.  
+
+The following example defines a `list` block named `prod` that queries `aws_instances`:
+
+```hcl
+list "aws_instance" "prod" {
+  # . . .
+}
+```
+
+Add the following arguments to your `list` block:
+
+- `provider`: This argument is required. It specifies which provider configuration Terraform should use to perform the query. The `list` block retrieves the provider configuration from the [`terraform` block](/terraform/language/block/terraform) in your `main.tf` configuration, but you can declare a `provider` block in your query file with an alternate configuration and reference it in the `provider` argument in your `list` block. 
+
+- `config`: Add the `config` block to your `list` block and define provider-specific arguments to build your query. Refer to your provider documentation for supported arguments and values.  
+
+- `include_resource`: By default, Terraform retrieves only resource identities, but you can set the `include_resource` argument to `true` so that Terraform can also retrieve all available resource attributes. To reference resource attributes retrieved by the list block, you must enable the `include_resource` argument. Setting this argument to `true` may affect performance.  
+
+- `limit`: By default, Terraform retrieves up to 100 resources per list block, but you can use the `limit` argument to specify a higher or lower number of results.
+
+The `list` block also supports several Terraform **meta-arguments**, which are arguments built into Terraform configuration language that configure how Terraform creates and manages infrastructure objects. For example, you can use the `count` meta-argument to create multiple instances of the resource list returned by the query. Refer to [Meta-arguments](/terraform/language/meta-arguments) for more information.
+
+In the following example, Terraform applies provder arguments to query for `aws_instance` resources in the `us-east-2` region. The query also filters results prefixed with `prod-` and `stage-` and that are in a `running` state. The `limit` argument, which is not a provider-specific argument, instructs Terraform to return the first 50 results:
+
+```hcl
+list "aws_instance" "prod" {
+  provider = aws
+  limit = 50
+  config {
+    region = "us-east-2"
+    filter {
+      name   = "tag:Name"
+      values = ["prod-*", "staging-*"]
+    }
+    filter {
+        name = "instance-state-name"
+        values = ["running"]
+    }
+  }
+}
+```
+
+### Parameterize your query configuration
+
+You can parameterize your `.tfquery.hcl` file so that you can reuse it with a different set of inputs. Refer to [Set configuration parameters](/terraform/language/parameterize) for instructions on how to parameterize configurations.
+
+Add the following blocks to your query file to parameterize the configuration:
+
+- `variable`: Add the `variable` block to your query file to define variables that people who run the query configuration can provide at runtime. Refer to the [`variable` block reference](/terraform/language/block/variable) for configuration details.
+- `locals`: Add the `locals` block to your query file to define temporary variables scoped to the query configuration. Refer to the [`locals` block reference](/terraform/language/block/locals) for configuration details.
+
+### Specify a custom provider configuration
+
+The query file checks the `main.tf` configuration for provider configurations, but you can also declare one or more `provider` blocks in the query configuration file to define alternate provider configurations. To use one of the alternate provider configurations, add the [`provider` argument](#provider) to your `list` block and reference the name of the provider configuration.  Refer to the [`provider` block reference](/terraform/language/block/provider) for information about how to configure `provider` blocks.
+
+## Query the infrastructure
+
+Run the [`terraform query` command](/terraform/cli/commands/query) to retrieve the resource types specified in your `list` blocks. The command prints the results to your console. By default, each result includes the following information:
+
+- Reference to the `list` block that queried for resources formatted as `list.<type>.<label>`.
+- Identity of a discovered resource.   
+
+The provider may also include other information, such as a description of the resource. Refer to your provider documentation for details.
+
+The number of results depends on the provider, as well as any query constraints you configured in the query configuration file.
+
+To generate machine-readable results, you can include the `-json` flag:
+
+```shell-session
+$ terraform query -json
+```
+
+## Generate configuration for importing results
+
+To generate configuration, run the [`terraform query` command](/terraform/cli/commands/query) and add the `-generate-config-out` flag. The flag expects a path where Terraform stores the generated configuration as a file named `generated.tf`. The `generated.tf` file contains the `resource` and `import` blocks, including resource identities, necessary for importing results.
+
+The following example generates configuration to the working directory:
+
+```shell-session
+$ terraform query -generate-config-out=generated.tf
+```
+ 
+After generating the results file, you must remove the file before rerunning the command to generate a new results file. Rerunning the command when a `generated.tf` already exists at the specified path results in an error. 
+
+## Import resources
+
+Copy the `import` and `resource` blocks from the `generated.tf` file to your `main.tf` configuration and run the [`terraform apply` command](/terraform/cli/commands/apply) to import the resources.  
+  
+## Next steps
+
+After importing your resources, you can discard the query configuration file and the `generated.tf` file, but you can archive them to maintain a historical record of the import.
diff --git a/content/terraform/v1.14.x (alpha)/docs/language/import/index.mdx b/content/terraform/v1.14.x (alpha)/docs/language/import/index.mdx
index ea0aaff1ab..5cb045cdc7 100644
--- a/content/terraform/v1.14.x (alpha)/docs/language/import/index.mdx	
+++ b/content/terraform/v1.14.x (alpha)/docs/language/import/index.mdx	
@@ -1,175 +1,38 @@
 ---
-page_title: Import existing resources into Terraform state
-description: Learn how to import existing resources into Terraform state so that you can manage them as code 
+page_title: Import resources overview
+description: Learn about importing existing infrastructure resources to your Terraform workspace using the bulk import workflow or the single-resource import workflow
 ---
 
-# Import an existing resource
+# Import resources overview
 
-You can import existing infrastructure resources into your Terraform state so that you can begin managing them using Terraform. This page describes how to write Terraform configuration for importing resources, which lets you import multiple resources at the same time and review the import as part of your Terraform workflow. 
+If you have existing infrastructure resources, you can import them to your Terraform workspace so that you can begin managing the resources as code. 
 
-> **Hands-on:** Try the [State Import](/terraform/tutorials/state/state-import?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
+## Workflows
 
-
-## Overview
-
-When you import existing infrastructure into state, you must also define the Terraform configuration corresponding to that resource to manage the rest of its lifecycle. You can manually write all of the configuration or use the Terraform CLI to generate configuration for resources your are importing. When you import resources, Terraform pulls all of the resource's attributes into the state file, but you do not need to define all of them in the `resource` block. 
-
-We recommend manually writing the `resource` block when you know how to configure all or most of the resource's arguments. Use generated configuration when importing multiple resources or a single complex resource that you do not already have the configuration for.
-
-This page describes how to manually write all of your import configuration. Refer to [Generate configuration](/terraform/language/import/generating-configuration) for instructions on how to generate the configuration.
-
-Complete the following steps to import resources:
-
-1. Define a destination resource configuration for each resource you want to import. 
-1. Add a corresponding `import` block for each existing resource you want to import. 
-1. Run `terraform plan` and verify that the import plan meets your needs. 
-1. Apply the configuration to import the resources and update your Terraform state.
-
-You can remove `import` blocks from your configuration after importing resources, but we recommend keeping them as an historical artifact. Refer to [Post import tasks](#post-import-tasks) for more information.
-
-## Define a destination resource 
-
-Terraform reconciles your configuration and state to create an execution plan. As a result, you must define a `resource` block for any resource in state to prevent Terraform from destroying it. The only required arguments to the `resource` block for an imported resource are the inline resource type and resource label, which form the Terraform state address. 
-
-The following example resource is the destination for an AWS instance with a resource address of `aws_instance.example`:
-
-```hcl
-resource "aws_instance" "example" {
-  name = "renderer"
-}
-```
-
-You should include provider-specific resource arguments that have non-default values to prevent Terraform from destroying the imported resource on the next apply operation. Terraform uses default values for arguments you do not include in the `resource` block. If Terraform assigns default values, but the existing resource has non-default attributes, the resource in state will not match the actual infrastructure, and Terraform will plan to update the resource on the next apply operation. Refer to the provider documentation for information about which arguments the resource you are importing supports.
-
-
-### Configure Terraform arguments
-
-You can include [meta-arguments](/terraform/language/meta-arguments) to modify how Terraform manages your resources once imported into state. Meta-arguments are Terraform-specific arguments that establish explicit dependencies between resources and prevent destructive operations. Refer the [`resource` block reference](/terraform/language/block/resource) for details about Terraform meta-arguments you can define. 
-
-## Define an `import` block
-
-Add an `import` block and specify the ID of an existing resource and [destination resource address](#define-a-destination-resource) to import to. Cloud providers use different methods of identifying resources. As a result, the ID depends on your cloud vendor and the kind of resource you are importing. Refer to the provider documentation for the resource you want to import for details.
-
-Use the following syntax to configure the `import` block: 
+Importing unmanaged resources to your workspace requires an `import` block that specifies the unique infrastructure resource ID to import. The block also declares an address for the imported resource in state. Additionally, you must create a destination `resource` block that matches the address declared in the `import` block. The `resource` block represents the resource in the configuration. 
  
-```hcl
-import {
-  to = TYPE.LABEL
-  id = "<RESOURCE-ID>"
-}
-
-resource "<TYPE>" "<LABEL>" {
-  # ...
-}
-```
-
-The `to` argument is the destination resource address, which is formed from the resource type and label. 
-
-The `id` argument is an identifier specific to your cloud provider.
-
-Refer to the [`import` block reference](/terraform/language/block/import) for details.
-
-
-### Import multiple instances
-
-You can configure the destination `resource` block to manage multiple instances of resource using the `count` and `for_each` [meta-arguments](/terraform/language/meta-arguments). You can add a parameter to the value of the `to` argument to specify which instance of the destination resource to import to. 
-
-For example, the `count` block in the destination `resource` block configuration instructs Terraform to import a set number of resource instances. As a result, you can include an index to the `to` argument value to specify which instance to import the resource to. 
-
-In the following example, Terraform imports the resource into the instance at the `0` index:
-
-```hcl
-import {
-  to = aws_instance.example[0]
-  id = "i-abcd1234"
-}
-
-resource "aws_instance" "example {
-  count = 2
-  #. . .
-}
-```
-
-When the destination `resource` block contains a `for_each` argument, Terraform loops through a set of key-value pairs and imports an instance for each pair. In the following example, Terraform imports the resource into the instance with a `env` key:
-
-```hcl
-import {
-  to = aws_instance.example["env"]
-  id = "i-abcd1234"
-}
-
-resource "aws_instance" "example" {
-  ami           = "ami-12345678"   
-  instance_type = "t2.micro"
-  for_each = { 
-    env = "staging"
-    geo = "us"
-  }
-  # . . .
-}
-```
-
-### Import using a custom resource provider
-
-By default, Terraform automatically selects the default provider configuration based on the resource type, but you can configure multiple instances of the same provider with aliases and use a non-default provider configuration to import specific resources. In the following example, Terraform imports to a destination `resource` block that contains multiple instances according to the `europe` provider configuration:
-
-```hcl
-provider "aws" {
-  alias = "europe"
-  region = "eu-west-1"
-}
-
-import {
-  provider = aws.europe
-  to = aws_instance.example["env"]
-  id = "i-abcd1234"
-}
-
-resource "aws_instance" "example" {
-  provider = aws.europe
-  for_each = {
-    env = "staging"
-    geo = "us"
-  }
-}
-```
-
-### Import to a module
-
-When the destination `resource` block is in another module, add the `module.<MODULE-NAME>` prefix to the resource address. In the following example, Terraform imports a resource into a `resource` block in the `instances` module:
-
-
-<CodeBlockConfig filename="main.tf">
-
-```hcl
-import {
-  to = module.instances.aws_instance.example
-  id = "i-abcd1234"
-}
-```
+You can import single resources or small batches of resources or create queries to discover large sets of unmanaged resources to import them in bulk.
 
-</CodeBlockConfig>
+### Import resources in bulk
 
-The following resource appears in the module address specified with the `to` argument in the `import` block:
+When you need to identify and import large sets of infrastructure resources, you can define queries as HCL, add the results to your Terraform configuration, and use the `terraform apply` command to import the discovered resources into your workspace. Refer to [Import resources in bulk](/terraform/language/import/bulk) for more information.  
 
-<CodeBlockConfig filename="instances/main.tf">
+### Import individual resources
 
-```hcl
-resource "aws_instance" "example" {
-  # . . .
-}
-```
+The workflow for importing single resources or small batches of resources works best when you can easily access unique infrastructure resource IDs and other attributes from your cloud provider. In this workflow, manually write `import` and `resource` blocks and run the `terraform apply` command to import the resources. 
 
-</CodeBlockConfig>
+Alternatively, you can write only the `import` block and run the `terraform plan` command with the `generate-config-out` flag to generate the `resource` blocks. Refer to [Import a single resource](/terraform/language/import/single-resource) for more information.  
 
-## Plan and apply an import
+## Resource identity
 
-After configuring the destination `resource` block and the `import` block, run `terraform plan` and review the proposed plan. If Terraform proposes any unexpected changes to the resource, update its configuration until it matches your intended settings. When satisfied with the plan, run `terraform apply` to import the resources and update your state. 
+Terraform uniquely identifies resources according to either the ID assigned by the cloud provider or a collection of specific attributes defined by the provider. To reference a resource identity in Terraform configuration, you can use either `id` or `identity` attribute. 
 
-When you apply a configuration with `import` blocks, Terraform records that it imported the resources and that it did not create them. 
+The `identity` attribute for `s3_bucket` resources available in the AWS provider, for example, uniquely identifies buckets according to the following attributes:
 
-Because the `import` block is idempotent, applying an import action and running another plan does not generate another import action as long as that resource remains in your state. Furthermore, attempting to import a resource into the same address more than once has no impact. 
+- `account_id`
+- `bucket`
+- `region`  
 
-## Post import tasks
+To reference the unique identity of an `aws_instance` resource, you can use the `id` attribute.  
 
-You can either remove `import` blocks after you've imported them or leave them in your configuration as a record of the resource's origin for future module maintainers. For more information on maintaining configurations over time, refer to [Refactoring](/terraform/language/modules/develop/refactoring).
+Refer to your provider documentation for information about how to reference resource identities. For information about referencing resource identities in Terraform configuration, refer to the [`import` block reference](/terraform/language/block/import).
\ No newline at end of file
diff --git a/content/terraform/v1.14.x (alpha)/docs/language/import/single-resource.mdx b/content/terraform/v1.14.x (alpha)/docs/language/import/single-resource.mdx
new file mode 100644
index 0000000000..18bfbc807b
--- /dev/null
+++ b/content/terraform/v1.14.x (alpha)/docs/language/import/single-resource.mdx	
@@ -0,0 +1,175 @@
+---
+page_title: Import existing resources into Terraform state
+description: Learn how to import existing resources into Terraform state so that you can manage them as code 
+---
+
+# Import a single resource
+
+You can import existing infrastructure resources into your Terraform state so that you can begin managing them using Terraform. This page describes how to write Terraform configuration for importing resources, which lets you import multiple resources at the same time and review the import as part of your Terraform workflow. 
+
+> **Hands-on:** Try the [State Import](/terraform/tutorials/state/state-import?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
+
+
+## Overview
+
+When you import existing infrastructure into state, you must also define the Terraform configuration corresponding to that resource to manage the rest of its lifecycle. You can manually write all of the configuration or use the Terraform CLI to generate configuration for resources your are importing. When you import resources, Terraform pulls all of the resource's attributes into the state file, but you do not need to define all of them in the `resource` block. 
+
+We recommend manually writing the `resource` block when you know how to configure all or most of the resource's arguments. Use generated configuration when importing multiple resources or a single complex resource that you do not already have the configuration for.
+
+This page describes how to manually write all of your import configuration. Refer to [Generate configuration](/terraform/language/import/generating-configuration) for instructions on how to generate the configuration.
+
+Complete the following steps to import resources:
+
+1. Define a destination resource configuration for each resource you want to import. 
+1. Add a corresponding `import` block for each existing resource you want to import. 
+1. Run `terraform plan` and verify that the import plan meets your needs. 
+1. Apply the configuration to import the resources and update your Terraform state.
+
+You can remove `import` blocks from your configuration after importing resources, but we recommend keeping them as an historical artifact. Refer to [Post import tasks](#post-import-tasks) for more information.
+
+## Define a destination resource 
+
+Terraform reconciles your configuration and state to create an execution plan. As a result, you must define a `resource` block for any resource in state to prevent Terraform from destroying it. The only required arguments to the `resource` block for an imported resource are the inline resource type and resource label, which form the Terraform state address. 
+
+The following example resource is the destination for an AWS instance with a resource address of `aws_instance.example`:
+
+```hcl
+resource "aws_instance" "example" {
+  name = "renderer"
+}
+```
+
+You should include provider-specific resource arguments that have non-default values to prevent Terraform from destroying the imported resource on the next apply operation. Terraform uses default values for arguments you do not include in the `resource` block. If Terraform assigns default values, but the existing resource has non-default attributes, the resource in state will not match the actual infrastructure, and Terraform will plan to update the resource on the next apply operation. Refer to the provider documentation for information about which arguments the resource you are importing supports.
+
+
+### Configure Terraform arguments
+
+You can include [meta-arguments](/terraform/language/meta-arguments) to modify how Terraform manages your resources once imported into state. Meta-arguments are Terraform-specific arguments that establish explicit dependencies between resources and prevent destructive operations. Refer the [`resource` block reference](/terraform/language/block/resource) for details about Terraform meta-arguments you can define. 
+
+## Define an `import` block
+
+Add an `import` block and specify the [resource identity](/terraform/language/import#resource-identity) of an existing resource and [destination resource address](#define-a-destination-resource) to import to. Cloud providers use different methods of identifying resources. As a result, the identity depends on your cloud vendor and the kind of resource you are importing. Refer to the provider documentation for the resource you want to import for details.
+
+Use the following syntax to configure the `import` block: 
+ 
+```hcl
+import {
+  to = TYPE.LABEL
+  id = "<RESOURCE-ID>"
+}
+
+resource "<TYPE>" "<LABEL>" {
+  # ...
+}
+```
+
+The `to` argument is the destination resource address, which is formed from the resource type and label. 
+
+The `id` argument is an identifier specific to your cloud provider.
+
+Refer to the [`import` block reference](/terraform/language/block/import) for details.
+
+
+### Import multiple instances
+
+You can configure the destination `resource` block to manage multiple instances of resource using the `count` and `for_each` [meta-arguments](/terraform/language/meta-arguments). You can add a parameter to the value of the `to` argument to specify which instance of the destination resource to import to. 
+
+For example, the `count` block in the destination `resource` block configuration instructs Terraform to import a set number of resource instances. As a result, you can include an index to the `to` argument value to specify which instance to import the resource to. 
+
+In the following example, Terraform imports the resource into the instance at the `0` index:
+
+```hcl
+import {
+  to = aws_instance.example[0]
+  id = "i-abcd1234"
+}
+
+resource "aws_instance" "example {
+  count = 2
+  #. . .
+}
+```
+
+When the destination `resource` block contains a `for_each` argument, Terraform loops through a set of key-value pairs and imports an instance for each pair. In the following example, Terraform imports the resource into the instance with a `env` key:
+
+```hcl
+import {
+  to = aws_instance.example["env"]
+  id = "i-abcd1234"
+}
+
+resource "aws_instance" "example" {
+  ami           = "ami-12345678"   
+  instance_type = "t2.micro"
+  for_each = { 
+    env = "staging"
+    geo = "us"
+  }
+  # . . .
+}
+```
+
+### Import using a custom resource provider
+
+By default, Terraform automatically selects the default provider configuration based on the resource type, but you can configure multiple instances of the same provider with aliases and use a non-default provider configuration to import specific resources. In the following example, Terraform imports to a destination `resource` block that contains multiple instances according to the `europe` provider configuration:
+
+```hcl
+provider "aws" {
+  alias = "europe"
+  region = "eu-west-1"
+}
+
+import {
+  provider = aws.europe
+  to = aws_instance.example["env"]
+  id = "i-abcd1234"
+}
+
+resource "aws_instance" "example" {
+  provider = aws.europe
+  for_each = {
+    env = "staging"
+    geo = "us"
+  }
+}
+```
+
+### Import to a module
+
+When the destination `resource` block is in another module, add the `module.<MODULE-NAME>` prefix to the resource address. In the following example, Terraform imports a resource into a `resource` block in the `instances` module:
+
+
+<CodeBlockConfig filename="main.tf">
+
+```hcl
+import {
+  to = module.instances.aws_instance.example
+  id = "i-abcd1234"
+}
+```
+
+</CodeBlockConfig>
+
+The following resource appears in the module address specified with the `to` argument in the `import` block:
+
+<CodeBlockConfig filename="instances/main.tf">
+
+```hcl
+resource "aws_instance" "example" {
+  # . . .
+}
+```
+
+</CodeBlockConfig>
+
+## Plan and apply an import
+
+After configuring the destination `resource` block and the `import` block, run `terraform plan` and review the proposed plan. If Terraform proposes any unexpected changes to the resource, update its configuration until it matches your intended settings. When satisfied with the plan, run `terraform apply` to import the resources and update your state. 
+
+When you apply a configuration with `import` blocks, Terraform records that it imported the resources and that it did not create them. 
+
+Because the `import` block is idempotent, applying an import action and running another plan does not generate another import action as long as that resource remains in your state. Furthermore, attempting to import a resource into the same address more than once has no impact. 
+
+## Post import tasks
+
+You can either remove `import` blocks after you've imported them or leave them in your configuration as a record of the resource's origin for future module maintainers. For more information on maintaining configurations over time, refer to [Refactoring](/terraform/language/modules/develop/refactoring).
diff --git a/content/terraform/v1.14.x (alpha)/docs/language/meta-arguments.mdx b/content/terraform/v1.14.x (alpha)/docs/language/meta-arguments.mdx
index 89298d3f65..d66d3916c1 100644
--- a/content/terraform/v1.14.x (alpha)/docs/language/meta-arguments.mdx	
+++ b/content/terraform/v1.14.x (alpha)/docs/language/meta-arguments.mdx	
@@ -71,6 +71,7 @@ Integer index. You cannot use both a `count` and ` for_each` argument in the sam
 
 - [`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)
 
@@ -109,6 +110,7 @@ You cannot use both a `count` and ` for_each` argument in the same block.
 
 - [`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)
 
@@ -139,6 +141,7 @@ The `provider` argument is distinct from the `provider` block, which contains pr
 - [`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`
diff --git a/content/terraform/v1.14.x (alpha)/docs/partials/beta.mdx b/content/terraform/v1.14.x (alpha)/docs/partials/beta.mdx
new file mode 100644
index 0000000000..8767ca6f5d
--- /dev/null
+++ b/content/terraform/v1.14.x (alpha)/docs/partials/beta.mdx	
@@ -0,0 +1,6 @@
+<!-- Use this partial for general beta callouts -->
+<Note>
+
+This feature is currently in beta. Do not use beta functionality in production environments.
+
+</Note>
\ No newline at end of file