From bb0338307ca6d5f46f03a778f40a2f1f201b4faa Mon Sep 17 00:00:00 2001
From: rkoron007 <rkoron007@gmail.com>
Date: Wed, 9 Jul 2025 17:44:30 -0700
Subject: [PATCH 1/3] First try

---
 .../v1.12.x/data/language-nav-data.json       |   8 +-
 .../v1.12.x/docs/language/block/data.mdx      |  66 ++--
 .../v1.12.x/docs/language/block/provider.mdx  | 366 ++++++++++++++++++
 .../v1.12.x/docs/language/block/resource.mdx  |   2 +-
 .../meta-arguments/module-providers.mdx       |   2 +-
 .../meta-arguments/resource-provider.mdx      |   4 +-
 .../language/modules/develop/providers.mdx    |   6 +-
 .../docs/language/providers/configuration.mdx | 198 ----------
 .../v1.12.x/docs/language/providers/index.mdx |  18 +-
 .../docs/language/providers/requirements.mdx  |   5 +-
 .../docs/language/resources/syntax.mdx        |   2 +-
 .../v1.12.x/docs/language/tests/index.mdx     |   2 +-
 .../language/v1-compatibility-promises.mdx    |   2 +-
 13 files changed, 426 insertions(+), 255 deletions(-)
 create mode 100644 content/terraform/v1.12.x/docs/language/block/provider.mdx
 delete mode 100644 content/terraform/v1.12.x/docs/language/providers/configuration.mdx

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 95ac8bd6c..fc6bf6652 100644
--- a/content/terraform/v1.12.x/data/language-nav-data.json
+++ b/content/terraform/v1.12.x/data/language-nav-data.json
@@ -193,8 +193,8 @@
     "routes": [
       { "title": "Overview", "path": "providers" },
       {
-        "title": "Provider Configuration",
-        "path": "providers/configuration"
+        "title": "Provider block",
+        "href": "/terraform/language/block/provider"
       },
       {
         "title": "Provider Requirements",
@@ -1143,6 +1143,10 @@
         "title": "output",
         "path": "block/output"
       },
+      {
+        "title": "provider",
+        "path": "block/provider"
+      },
       {
         "title": "removed",
         "path": "block/removed"
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 72c193d6e..af78df29f 100644
--- a/content/terraform/v1.12.x/docs/language/block/data.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/data.mdx
@@ -16,7 +16,7 @@ The `data` block supports the following configuration:
 - [`data "<TYPE>" "<LABEL>"`](#data) &nbsp block
   - [provider-specific arguments](#provider-specific-arguments) &nbsp block | refer to your provider documentation
   - [`count`](#count) &nbsp number | mutually exclusive with `for_each`
-  - [`depends_on`](#depends_on) &nbsp list of references 
+  - [`depends_on`](#depends_on) &nbsp list of references
   - [`for_each`](#for_each) &nbsp map or set of strings | mutually exclusive with `count`
   - [`provider`](#provider) &nbsp reference
   - [`lifecycle`](#lifecycle) &nbsp block
@@ -36,11 +36,11 @@ data "<TYPE>" "<LABEL>" {
    <PROVIDER-SPECIFIC ARGUMENTS>
    count = <NUMBER>      # `count` and `for_each` are mutually exclusive
    depends_on = [ <RESOURCE.ADDRESS.EXPRESSION> ]
-   for_each = {          # `for_each` and `count` are mutually exclusive 
+   for_each = {          # `for_each` and `count` are mutually exclusive
       <KEY> = <VALUE>
    }
-   for_each = [       # `for_each` accepts a map or a set of strings 
-    "<VALUE>", 
+   for_each = [       # `for_each` accepts a map or a set of strings
+    "<VALUE>",
     "<VALUE>"
    ]
    provider = <REFERENCE.TO.ALIAS>
@@ -65,16 +65,16 @@ A `data` block supports the following configuration.
 
 You must set the following arguments for every `data` block:
 
-- `TYPE`: Specifies the data source type. Provider developers define the support data sources. Refer to the provider documentation for details. Terraform also includes the [`terraform_remote_state` data source](/terraform/language/state/remote-state-data), which lets you access state data from other workspaces. 
+- `TYPE`: Specifies the data source type. Provider developers define the support data sources. Refer to the provider documentation for details. Terraform also includes the [`terraform_remote_state` data source](/terraform/language/state/remote-state-data), which lets you access state data from other workspaces.
 - `LABEL`: Specifies a name for the data source. Use the `data.<label>.<attribute>` syntax to reference the data. 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-specific arguments
 
-The provider developer determines which arguments you can define for a data source. Refer to the provider documentation for details. 
+The provider developer determines which arguments you can define for a data source. Refer to the provider documentation for details.
 
 ### `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.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -137,7 +137,7 @@ The `for_each` meta-argument instructs Terraform to provision similar resources
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
-  for_each = [ "<VALUE>" ] 
+  for_each = [ "<VALUE>" ]
   # . . .
 }
 ```
@@ -173,12 +173,12 @@ You cannot use sensitive values, such as [sensitive input variables](/terraform/
 
 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 [Sensitive Data in State](/terraform/language/state/sensitive-data) for more information. 
+Refer to [Sensitive Data in State](/terraform/language/state/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. 
+- `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.
 
@@ -188,11 +188,11 @@ The `for_each` argument is a meta-argument, which is built into Terraform and co
 #### Summary
 
 - Data type: Map or set of strings.
-- Default: None.  
+- 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.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
@@ -200,24 +200,24 @@ 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. 
+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 [Multiple Provider Configurations](/terraform/language/providers/configuration#alias-multiple-provider-configurations) for instructions on how to reference a specific provider configuration.     
+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/concepts/meta-arguments) for more information.
 
 #### Summary
 
 - Data type: Reference.
-- Default: None. 
+- Default: None.
 
 ### `lifecycle`
 
-The `lifecycle` block defines lifecycle rules for how Terraform operates on your data source. 
+The `lifecycle` block defines lifecycle rules for how Terraform operates on your data source.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
-  lifecycle { 
+  lifecycle {
     <lifecycle>
   }
 }
@@ -230,7 +230,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/concepts/meta-arguments) for more information. 
+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/concepts/meta-arguments) for more information.
 
 #### Summary
 
@@ -239,11 +239,11 @@ The `lifecycle` block is a meta-argument. Meta-arguments are built-in arguments
 
 ### `precondition`
 
-The `precondition` block specifies a condition that must return `true` before Terraform evaluates and performs operations on the data source. You can also specify an error message for Terraform to print when the condition returns `false`. 
+The `precondition` block specifies a condition that must return `true` before Terraform evaluates and performs operations on the data source. You can also specify an error message for Terraform to print when the condition returns `false`.
 
 ```hcl
 resource {
-  lifecycle { 
+  lifecycle {
     precondition {
       condition = <expression>
       error_message = "<message>"
@@ -261,9 +261,9 @@ The following arguments in the `precondition` block are required:
 
 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. 
+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. 
+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 [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.
 
@@ -275,11 +275,11 @@ Refer to [Test and validate](/terraform/language/test-and-validate) for informat
 
 ### `postcondition`
 
-The `postcondition` block specifies a condition that must return `true` after Terraform performs operations on the data source. You can also specify an error message for Terraform to print to the console when the condition returns `false`. 
+The `postcondition` block specifies a condition that must return `true` after Terraform performs operations on the data source. You can also specify an error message for Terraform to print to the console when the condition returns `false`.
 
 ```hcl
 data "<TYPE>" "<LABEL>" {
-  lifecycle { 
+  lifecycle {
     postcondition {
       condition = <expression>
       error_message = "<message>"
@@ -297,7 +297,7 @@ The following arguments in the `precondition` block are required:
 
 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. 
+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 [Test and validate](/terraform/language/test-and-validate) for information about adding validations to your Terraform configuration.
 
@@ -313,9 +313,9 @@ 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:   
+In the following example, Terraform gets an AMI for use in the `aws_instance` resource after creating the `aws_subnet.example_subnet` resource:
 
-```hcl 
+```hcl
 resource "aws_vpc" "example_vpc" {
   cidr_block = "10.0.0.0/16"
 }
@@ -336,7 +336,7 @@ data "aws_ami" "example_ami" {
     name   = "architecture"
     values = ["x86_64"]
   }
-  depends_on = [aws_subnet.example_subnet]  
+  depends_on = [aws_subnet.example_subnet]
 }
 
 resource "aws_instance" "example_instance" {
@@ -346,11 +346,11 @@ resource "aws_instance" "example_instance" {
 }
 ```
 
-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.  
+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. 
+In the following example, the `google_compute_instance` data source selects the provider configuration with the `europe` alias.
 
 ```hcl
 provider "google" {
@@ -362,7 +362,7 @@ provider "google" {
   region = "europe-west1"
 }
 
-data "google_compute_instance" "example" {  
+data "google_compute_instance" "example" {
   provider = google.europe
   # ...
 }
@@ -370,7 +370,7 @@ data "google_compute_instance" "example" {
 
 ### 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 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:
 
@@ -424,4 +424,4 @@ data "aws_ebs_volume" "example" {
 output "api_base_url" {
   value = "https://${aws_instance.example.private_dns}:8433/"
 }
-```
\ No newline at end of file
+```
diff --git a/content/terraform/v1.12.x/docs/language/block/provider.mdx b/content/terraform/v1.12.x/docs/language/block/provider.mdx
new file mode 100644
index 000000000..8d03e9f18
--- /dev/null
+++ b/content/terraform/v1.12.x/docs/language/block/provider.mdx
@@ -0,0 +1,366 @@
+---
+page_title: Provider block reference for the Terraform configuration language
+description: Use the `provider` block to declare and configure Terraform plugins, called providers. Providers let Terraform manage real-world infrastructure with provider-defined resources and data sources.
+---
+
+# `provider` block reference
+
+Use the `provider` block to declare and configure Terraform plugins, called providers. Providers let Terraform manage real-world infrastructure with provider-defined resources and data sources.
+
+> **Hands-on:** Try the [Perform CRUD Operations with Providers](/terraform/tutorials/configuration-language/provider-use) tutorial.
+
+## Background
+
+The `provider` block configures a named provider, which is a plugin that lets Terraform interact with cloud providers, SaaS providers, and other APIs.
+
+HashiCorp's public [Terraform registry](https://registry.terraform.io/browse/providers) distributes providers separately from Terraform itself, and each provider has its own release cadence, documentation, and versions. If you are using HCP Terraform, you can use the [private registry](/terraform/cloud-docs/registry) to share providers within an organization.
+
+Anyone can develop a Terraform provider and use it locally or publish it to the Terraform public registry, or HCP Terraform private registry. To learn more about authoring providers, refer to the [Plugin framework](/terraform/plugin/framework).
+
+Each Terraform module must declare which providers it requires, so that Terraform can install and use them. To declare a provider in a module perform the following three steps:
+
+1. Define the provider's source, local name, and version in the [`required_providers` block](/terraform/language/block/terraform#required_providers) inside your top-level `terraform` block.
+2. Add a top-level `provider` block to your configuration to configure a provider with authentication, region, and other provider-specific arguments.
+3. Install your provider.
+   1. Running `terraform init` locally installs a provider and updates the [Dependency lock file](/terraform/language/files/dependency-lock) file with the version you installed.
+   2. HCP Terraform and Terraform Enterprise install providers as part of every run.
+
+If you are running Terraform locally, your plan and apply operations use the provider versions specified in the dependency lock file. You can upgrade a provider version in your lock file by changing the value in your configuration and re-running `terraform init`. To learn more about declaring providers, refer to [Provider requirements](/terraform/language/providers/requirements).
+
+Define provider configurations in the root module of your Terraform configuration. Child modules receive their provider configurations from their parent modules, so do not define `provider` blocks in child modules. To learn more about passing providers to child modules, refer to [The `providers` meta-argument](/terraform/language/meta-arguments/module-providers).
+
+## Configuration model
+
+The `provider` block supports the following arguments:
+
+- [`provider "<PROVIDER_NAME>"`](#provider) &nbsp; block
+  - [`<PROVIDER_ARGUMENTS>`](#provider_arguments) &nbsp; various
+  - [`alias`](#alias) &nbsp; string
+  - [`version`](#version) &nbsp; string (**Deprecated**)
+
+## Complete configuration
+
+All available arguments are defined in the following `provider` block. The `alias` and `version` arguments are optional, and you cannot use both in the same block.
+
+```hcl
+provider "<PROVIDER_NAME>" {
+  <PROVIDER_ARGUMENTS>
+  alias   = "<ALIAS_NAME>"
+  version = "<VERSION_CONSTRAINT>"  # Deprecated
+}
+```
+
+## Specification
+
+A `provider` block supports the following configuration.
+
+### `provider "<PROVIDER_NAME>"`
+
+The name given in the block header specifies the [local name](/terraform/language/providers/requirements#local-names) of the provider to configure.
+
+The following arguments are supported in a `provider` block:
+
+| Argument | Description | Type | Required? |
+| --- | --- | --- | --- |
+| Provider-specific arguments | Configuration arguments that the provider developer defined. | Various | Varies by provider |
+| `alias` | An additional name segment for this configuration, allowing multiple configurations for the same provider. | String | Optional |
+| `version` | A version constraint for the provider. This argument is deprecated. | String | Optional |
+
+### Provider-specific arguments
+
+The body of the `provider` block contains configuration arguments for the provider, which are defined by the provider itself.
+
+```hcl
+provider "<PROVIDER_NAME>" {
+  <PROVIDER_ARGUMENTS>
+}
+```
+
+For example, both the `project` and `region` arguments are defined by the `google` provider.
+
+```hcl
+provider "google" {
+  project = "acme-app"
+  region  = "us-central1"
+}
+```
+
+A provider's documentation lists which configuration arguments it expects. For providers distributed on the [Terraform registry](https://registry.terraform.io), versioned documentation is available on each provider's page.
+
+If you do not explicitly define a `provider` block, Terraform assumes and creates an empty default configuration for that provider. However, if a provider has required arguments, Terraform raises an error because it can't create that provider without the required values.
+
+You can use [expressions](/terraform/language/expressions) to configure provider arguments, but you can only reference values that Terraform knows before it applies your configuration. Meaning, you can reference input variables and arguments that you specify directly in your configuration, but not any computed resource attributes, such as `google.web.public_ip`.
+
+Many providers support shell environment variables or other alternate sources for their configuration values, which helps keep credentials out of your version-controlled Terraform code. Refer to a provider's documentation to learn more about the assignment methods each argument supports.
+
+#### Summary
+
+- Data type: Various, depending on the provider
+- Default: None, but requirements vary by provider
+- Required: Varies by provider
+
+### `alias`
+
+Optionally use the `alias` argument to define multiple configurations for the same provider. Defining multiple provider aliases lets you specify which provider configuration to use for individual resources, data sources, or modules.
+
+To create multiple configurations for a given provider, include multiple `provider` blocks with the same provider name, then add the `alias` argument to each additional provider configuration to give it a unique identifier.
+
+```hcl
+provider "example" {
+  region = "us-east-1"
+}
+
+provider "example" {
+  alias  = "west"
+  region = "west"
+}
+```
+
+To refer to a provider alias, use `<PROVIDER_NAME>.<ALIAS>` in the `provider` argument of the following blocks:
+
+- `resource` blocks
+- `data` blocks
+- `module` blocks
+
+If there are multiple aliases for a provider, the `provider` block without an `alias` argument is the default configuration for that provider. Resources, data sources, and modules that don't specify the [`provider` meta-argument](/terraform/language/block/resource#provider) use the default provider configuration that matches the resource type name. For examples, refer to [using an alternate provider configuration](#using-an-alternate-provider-configuration) and [Provider without a default configuration](#provider-without-a-default-configuration).
+
+#### Summary
+
+- Data type: String
+- Default: None
+- Refer to the following examples to learn more about aliasing providers:
+  - [Multiple provider configurations](#multiple-provider-configurations)
+  - [Using an alternate provider configuration](#using-an-alternate-provider-configuration)
+  - [Provider without a default configuration](#provider-without-a-default-configuration)
+  - [Using an alternate provider configuration in a child module](#using-an-alternate-provider-configuration-in-a-child-module)
+
+### `version`
+
+The `version` argument in provider configurations is deprecated, and Terraform will remove it in a future version. Instead, declare provider version constraints in [the `terraform` block's `required_providers` argument](/terraform/language/providers/requirements).
+
+#### Summary
+
+- Data type: String
+- Default: None
+- Deprecated
+
+## Examples
+
+The following examples demonstrate common use cases for `provider` blocks.
+
+### Basic provider configuration
+
+The following example configures the `google` provider with a specific project and region. In the `terraform` block's `required_providers` block you define the provider version you want to use, where to source the provider from, and the local name of the provider:
+
+```hcl
+terraform {
+  required_providers {
+    google = {
+      source  = "hashicorp/google"
+      version = "~> 4.0"
+    }
+  }
+}
+```
+
+You can further configure a provider with the `provider` block in the root module of your configuration.
+
+```hcl
+provider "google" {
+  project = "acme-app"
+  region  = "us-central1"
+}
+```
+
+### Multiple provider configurations
+
+In the following example, two configurations for the AWS provider support different regions. The default configuration targets the east coast, and the aliased configuration targets the west coast:
+
+```hcl
+provider "aws" {
+  region = "us-east-1"
+}
+
+provider "aws" {
+  alias  = "west"
+  region = "us-west-2"
+}
+```
+
+Resources that begin with `aws_` use the default `aws` provider configuration unless you supply the [`provider` argument](/terraform/language/block/resource#provider).
+
+### Using an alternate provider configuration
+
+You can make a resource, data source, or module use an alternate provider configuration by setting the `provider` meta-argument to a `<PROVIDER_NAME>.<ALIAS>` reference.
+
+In the following example, the `aws_instance.foo` resource uses the `aws.west` provider configuration, and `aws_instance.bar` uses the default `aws` provider configuration:
+
+```hcl
+provider "aws" {
+  region = "us-east-1"
+}
+
+provider "aws" {
+  alias  = "west"
+  region = "us-west-2"
+}
+
+resource "aws_instance" "foo" {
+  provider = aws.west
+  # …
+}
+
+resource "aws_instance" "bar" {
+   # …
+}
+```
+
+### Provider without a default configuration
+
+If there are multiple aliases for a provider in your configuration, the `provider` block without an `alias` argument is the default configuration for that provider. If every `provider` block in your configuration uses an alias, Terraform creates an implied empty default configuration for that provider. Any resource that does not specify a `provider` meta-argument uses the empty default configuration.
+
+In the following example, both AWS provider configurations use aliases, but the `aws_s3_bucket` does not specify a `provider` argument:
+
+```hcl
+provider "aws" {
+  alias  = "east"
+  region = "us-east-1"
+}
+
+provider "aws" {
+  alias  = "west"
+  region = "us-west-2"
+}
+
+resource "aws_s3_bucket" "default_provider" {
+  bucket = "uses-implied-empty-config"
+}
+```
+
+Terraform uses the implied empty default configuration for the `aws_s3_bucket` resource because the resource doesn't specify a `provider` argument. If a provider requires specific arguments, Terraform returns an error when resources try to use the default configuration because the default is not properly configured.
+
+### Pass provider configurations to a child module
+
+We recommend defining providers in root modules, and passing those provider configurations from parent modules to child modules to ensure your modules all use the same provider configurations. You can pass provider configurations from a root module to child modules using the [`providers` argument](/terraform/language/meta-arguments/module-providers).
+
+In the following example, the root module defines an AWS provider configuration and passes it to a child module:
+
+```hcl
+provider "aws" {
+  region = "us-west-2"
+}
+
+module "vpc" {
+  source = "./modules/vpc"
+  providers = {
+    aws = aws
+  }
+}
+```
+
+The child module uses the provider configuration passed from the root module:
+
+```hcl
+terraform {
+  required_providers {
+    aws = {
+      source = "hashicorp/aws"
+    }
+  }
+}
+
+resource "aws_vpc" "main" {
+  cidr_block = "10.0.0.0/16"
+
+  tags = {
+    Name = "Main VPC"
+  }
+}
+```
+
+The `aws_vpc` resource uses the same AWS provider configuration from the root module, and Terraform creates it in the `us-west-2` region.
+
+### Using an alternate provider configuration in a child module
+
+We recommend defining provider configuration blocks in root modules, and passing those configurations from parent modules to child modules. To use aliased provider configurations in a child module, the child module must declare aliases using the `configuration_aliases` argument in the `required_providers` block.
+
+In the following example, the root module the passes its `aws.west` alias to its child module:
+
+```hcl
+provider "aws" {
+  region = "us-east-1"
+}
+
+provider "aws" {
+  alias  = "west"
+  region = "us-west-2"
+}
+
+module "web_server" {
+  source = "./modules/web-server"
+  providers = {
+    aws.west = aws.west
+  }
+}
+```
+
+The following `configuration_aliases` argument in the child module declares that the child module expects to receive a provider configuration it can reference as `aws.west`. Without this declaration, Terraform raises an error when the module tries to reference `aws.west` in its resources.
+
+```hcl
+terraform {
+  required_providers {
+    aws = {
+      source  = "hashicorp/aws"
+      version = "~> 5.0"
+      configuration_aliases = [aws.west]
+    }
+  }
+}
+
+data "aws_ami" "amazon_linux" {
+  provider = aws.west
+
+  #...
+}
+```
+
+Modules have special requirements for providers, refer to [The providers meta-argument](https://developer.hashicorp.com/terraform/language/meta-arguments/module-providers) to learn more.
+
+### Provider configuration with expressions
+
+In the following example, the provider configuration uses input variables and local values to set its arguments:
+
+```hcl
+variable "aws_region" {
+  description = "The AWS region to deploy resources in"
+  type        = string
+  default     = "us-west-2"
+}
+
+locals {
+  common_tags = {
+    Environment = "production"
+    Project     = "web-app"
+  }
+}
+
+provider "aws" {
+  region = var.aws_region
+
+  default_tags {
+    tags = local.common_tags
+  }
+}
+```
+
+### Provider configuration without arguments
+
+In the following example, the provider block defines an empty configuration for the `random` provider. Terraform also assumes an empty default configuration for any provider that you do not explicitly configure with a `provider` block:
+
+```hcl
+provider "random" {
+
+}
+```
+
+You can choose to omit this block entirely if you don't need to configure any provider-specific arguments.
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 849402090..b5878dc4a 100644
--- a/content/terraform/v1.12.x/docs/language/block/resource.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/resource.mdx
@@ -290,7 +290,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. Refer to [Multiple Provider Configurations](/terraform/language/providers/configuration#alias-multiple-provider-configurations) for instructions on how to reference a specific provider configuration.
+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/concepts/meta-arguments) for more information.
 
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/module-providers.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/module-providers.mdx
index 3b7339cfd..f6864d866 100644
--- a/content/terraform/v1.12.x/docs/language/meta-arguments/module-providers.mdx
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/module-providers.mdx
@@ -9,7 +9,7 @@ description: >-
 
 In a [module call](/terraform/language/modules/syntax) block, the
 optional `providers` meta-argument specifies which
-[provider configurations](/terraform/language/providers/configuration) from the parent
+[provider configurations](/terraform/language/block/provider) from the parent
 module will be available inside the child module.
 
 ```hcl
diff --git a/content/terraform/v1.12.x/docs/language/meta-arguments/resource-provider.mdx b/content/terraform/v1.12.x/docs/language/meta-arguments/resource-provider.mdx
index a4b72a0b6..67433462e 100644
--- a/content/terraform/v1.12.x/docs/language/meta-arguments/resource-provider.mdx
+++ b/content/terraform/v1.12.x/docs/language/meta-arguments/resource-provider.mdx
@@ -11,7 +11,7 @@ The `provider` meta-argument specifies which provider configuration to use for a
 overriding Terraform's default behavior of selecting one based on the resource
 type name. Its value should be an unquoted `<PROVIDER>.<ALIAS>` reference.
 
-As described in [Provider Configuration](/terraform/language/providers/configuration), you can optionally
+As described in [`provider` block reference](/terraform/language/block/provider), you can optionally
 create multiple configurations for a single provider (usually to manage
 resources in different regions of multi-region services). Each provider can have
 one default configuration, and any number of alternate configurations that
@@ -53,7 +53,7 @@ ensure that the provider is fully configured before any resource actions
 are taken.
 
 The `provider` meta-argument expects
-[a `<PROVIDER>.<ALIAS>` reference](/terraform/language/providers/configuration#referring-to-alternate-provider-configurations),
+[a `<PROVIDER>.<ALIAS>` reference](/terraform/language/block/provider#using-an-alternate-provider-configuration),
 which does not need to be quoted. Arbitrary expressions are not permitted for
 `provider` because it must be resolved while Terraform is constructing the
 dependency graph, before it is safe to evaluate expressions.
diff --git a/content/terraform/v1.12.x/docs/language/modules/develop/providers.mdx b/content/terraform/v1.12.x/docs/language/modules/develop/providers.mdx
index 393ff1948..a6062ace7 100644
--- a/content/terraform/v1.12.x/docs/language/modules/develop/providers.mdx
+++ b/content/terraform/v1.12.x/docs/language/modules/develop/providers.mdx
@@ -72,7 +72,7 @@ however, specify any of the configuration settings that determine what remote
 endpoints the provider will access, such as an AWS region; configuration
 settings come from provider _configurations_, and a particular overall Terraform
 configuration can potentially have
-[several different configurations for the same provider](/terraform/language/providers/configuration#alias-multiple-provider-configurations).
+[several different configurations for the same provider](/terraform/language/block/provider#using-an-alternate-provider-configuration).
 
 ## Provider Aliases Within Modules
 
@@ -104,7 +104,7 @@ features are needed by other parts of their overall configuration.
 ## Implicit Provider Inheritance
 
 For convenience in simple configurations, a child module automatically inherits
-[default provider configurations](/terraform/language/providers/configuration#default-provider-configurations) from its parent. This means that
+[default provider configurations](/terraform/language/block/provider#alias) from its parent. This means that
 explicit `provider` blocks appear only in the root module, and downstream
 modules can simply declare resources for that provider and have them
 automatically associated with the root provider configurations.
@@ -137,7 +137,7 @@ is sufficient for an entire configuration.
 ~> **Note:** Only provider configurations are inherited by child modules, not provider source or version requirements. Each module must [declare its own provider requirements](/terraform/language/providers/requirements). This is especially important for non-HashiCorp providers.
 
 In more complex situations there may be
-[multiple provider configurations](/terraform/language/providers/configuration#alias-multiple-provider-configurations),
+[multiple provider configurations](/terraform/language/block/provider#using-an-alternate-provider-configuration),
 or a child module may need to use different provider settings than
 its parent. For such situations, you must pass providers explicitly.
 
diff --git a/content/terraform/v1.12.x/docs/language/providers/configuration.mdx b/content/terraform/v1.12.x/docs/language/providers/configuration.mdx
deleted file mode 100644
index f3cce651e..000000000
--- a/content/terraform/v1.12.x/docs/language/providers/configuration.mdx
+++ /dev/null
@@ -1,198 +0,0 @@
----
-page_title: Provider Configuration - Configuration Language
-description: >-
-  Learn how to set up providers, including how to use the alias meta-argument to
-  specify multiple configurations for a single provider.
----
-
-# Provider Configuration
-
-Providers allow Terraform to interact with cloud providers, SaaS providers, and
-other APIs.
-
-Some providers require you to configure them with endpoint URLs, cloud regions,
-or other settings before Terraform can use them. This page documents how to
-configure settings for providers.
-
-Additionally, all Terraform configurations must declare which providers they
-require so that Terraform can install and use them. The
-[Provider Requirements](/terraform/language/providers/requirements)
-page documents how to declare providers so Terraform can install them.
-
-## Provider Configuration
-
-Provider configurations belong in the root module of a Terraform configuration.
-(Child modules receive their provider configurations from the root module; for
-more information, see
-[The Module `providers` Meta-Argument](/terraform/language/meta-arguments/module-providers)
-and [Module Development: Providers Within Modules](/terraform/language/modules/develop/providers).)
-
-A provider configuration is created using a `provider` block:
-
-```hcl
-provider "google" {
-  project = "acme-app"
-  region  = "us-central1"
-}
-```
-
-The name given in the block header (`"google"` in this example) is the
-[local name](/terraform/language/providers/requirements#local-names) of the provider to
-configure. This provider should already be included in a `required_providers`
-block.
-
-The body of the block (between `{` and `}`) contains configuration arguments for
-the provider. Most arguments in this section are defined by the provider itself;
-in this example both `project` and `region` are specific to the `google`
-provider.
-
-You can use [expressions](/terraform/language/expressions) in the values of these
-configuration arguments, but can only reference values that are known before the
-configuration is applied. This means you can safely reference input variables,
-but not attributes exported by resources (with an exception for resource
-arguments that are specified directly in the configuration).
-
-A provider's documentation should list which configuration arguments it expects.
-For providers distributed on the
-[Terraform Registry](https://registry.terraform.io), versioned documentation is
-available on each provider's page, via the "Documentation" link in the
-provider's header.
-
-Some providers can use shell environment variables (or other alternate sources,
-like VM instance profiles) as values for some of their arguments; when
-available, we recommend using this as a way to keep credentials out of your
-version-controlled Terraform code.
-
-There are also two "meta-arguments" that are defined by Terraform itself
-and available for all `provider` blocks:
-
-- [`alias`, for using the same provider with different configurations for different resources][inpage-alias]
-- [`version`, which we no longer recommend][inpage-versions] (use
-  [provider requirements](/terraform/language/providers/requirements) instead)
-
-Unlike many other objects in the Terraform language, a `provider` block may
-be omitted if its contents would otherwise be empty. Terraform assumes an
-empty default configuration for any provider that is not explicitly configured.
-
-## `alias`: Multiple Provider Configurations
-
-[inpage-alias]: #alias-multiple-provider-configurations
-
-You can optionally define multiple configurations for the same provider, and
-select which one to use on a per-resource or per-module basis. The primary
-reason for this is to support multiple regions for a cloud platform; other
-examples include targeting multiple Docker hosts, multiple Consul hosts, etc.
-
-To create multiple configurations for a given provider, include multiple
-`provider` blocks with the same provider name. For each additional non-default
-configuration, use the `alias` meta-argument to provide an extra name segment.
-For example:
-
-```hcl
-# The default provider configuration; resources that begin with `aws_` will use
-# it as the default, and it can be referenced as `aws`.
-provider "aws" {
-  region = "us-east-1"
-}
-
-# Additional provider configuration for west coast region; resources can
-# reference this as `aws.west`.
-provider "aws" {
-  alias  = "west"
-  region = "us-west-2"
-}
-```
-
-To declare a configuration alias within a module in order to receive an
-alternate provider configuration from the parent module, add the
-`configuration_aliases` argument to that provider's `required_providers`
-entry. The following example declares both the `mycloud` and
-`mycloud.alternate` provider configuration names within the containing module:
-
-```hcl
-terraform {
-  required_providers {
-    mycloud = {
-      source  = "mycorp/mycloud"
-      version = "~> 1.0"
-      configuration_aliases = [ mycloud.alternate ]
-    }
-  }
-}
-```
-
-### Default Provider Configurations
-
-A `provider` block without an `alias` argument is the _default_ configuration
-for that provider. Resources that don't set the `provider` meta-argument will
-use the default provider configuration that matches the first word of the
-resource type name. (For example, an `aws_instance` resource uses the default
-`aws` provider configuration unless otherwise stated.)
-
-If every explicit configuration of a provider has an alias, Terraform uses the
-implied empty configuration as that provider's default configuration. (If the
-provider has any required configuration arguments, Terraform will raise an error
-when resources default to the empty configuration.)
-
-### Referring to Alternate Provider Configurations
-
-When Terraform needs the name of a provider configuration, it expects a
-reference of the form `<PROVIDER NAME>.<ALIAS>`. In the example above,
-`aws.west` would refer to the provider with the `us-west-2` region.
-
-These references are special expressions. Like references to other named
-entities (for example, `var.image_id`), they aren't strings and don't need to be
-quoted. But they are only valid in specific meta-arguments of `resource`,
-`data`, and `module` blocks, and can't be used in arbitrary expressions.
-
-### Selecting Alternate Provider Configurations
-
-By default, resources use a default provider configuration (one without an
-`alias` argument) inferred from the first word of the resource type name.
-
-To use an alternate provider configuration for a resource or data source, set
-its `provider` meta-argument to a `<PROVIDER NAME>.<ALIAS>` reference:
-
-```hcl
-resource "aws_instance" "foo" {
-  provider = aws.west
-
-  # ...
-}
-```
-
-To select alternate provider configurations for a child module, use its
-`providers` meta-argument to specify which provider configurations should be
-mapped to which local provider names inside the module:
-
-```hcl
-module "aws_vpc" {
-  source = "./aws_vpc"
-  providers = {
-    aws = aws.west
-  }
-}
-```
-
-Modules have some special requirements when passing in providers; see
-[The Module `providers` Meta-Argument](/terraform/language/meta-arguments/module-providers)
-for more details. In most cases, only _root modules_ should define provider
-configurations, with all child modules obtaining their provider configurations
-from their parents.
-
-<a id="provider-versions"></a>
-
-## `version` (Deprecated)
-
-[inpage-versions]: #provider-versions
-
-The `version` meta-argument specifies a version constraint for a provider, and
-works the same way as the `version` argument in a
-[`required_providers` block](/terraform/language/providers/requirements). The version
-constraint in a provider configuration is only used if `required_providers`
-does not include one for that provider.
-
-~**Warning:** The `version` argument in provider configurations is deprecated, and we will remove it in a future Terraform version.
-
-In Terraform 0.13 and later, always declare provider version constraints in
-[the `required_providers` block](/terraform/language/providers/requirements). 
diff --git a/content/terraform/v1.12.x/docs/language/providers/index.mdx b/content/terraform/v1.12.x/docs/language/providers/index.mdx
index 49b68ad6b..7b2ed01a5 100644
--- a/content/terraform/v1.12.x/docs/language/providers/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/providers/index.mdx
@@ -63,7 +63,7 @@ about it in your configuration. See the following pages for details:
 - [Provider Requirements](/terraform/language/providers/requirements)
   documents how to declare providers so Terraform can install them.
 
-- [Provider Configuration](/terraform/language/providers/configuration)
+- [The `provider` block reference](/terraform/language/block/provider)
   documents how to configure settings for providers.
 
 - [Dependency Lock File](/terraform/language/files/dependency-lock)
@@ -95,17 +95,17 @@ installing providers.
 
 ### Private Providers
 
-If you are using a provider that is not in a Hashicorp-hosted registry, you may 
-need to attach additional credentials to your requests to external registries. 
+If you are using a provider that is not in a Hashicorp-hosted registry, you may
+need to attach additional credentials to your requests to external registries.
 You do not need these credentials if your provider is in the Terraform public
 registry or the HCP Terraform private registry.
 
-By default, Terraform only authenticates the opening request from a provider to 
-the registry. The registry responds with 
-[follow-up URLs](/terraform/internals/provider-registry-protocol#find-a-provider-package) 
-that Terraform makes requests to, such as telling Terraform to download the 
-provider or the `SHASUMS` file. Hashicorp-hosted registries do not require 
-additional authentication for these follow-up requests. If your registry does 
+By default, Terraform only authenticates the opening request from a provider to
+the registry. The registry responds with
+[follow-up URLs](/terraform/internals/provider-registry-protocol#find-a-provider-package)
+that Terraform makes requests to, such as telling Terraform to download the
+provider or the `SHASUMS` file. Hashicorp-hosted registries do not require
+additional authentication for these follow-up requests. If your registry does
 require additional credentials for follow-up requests, you can use a `.netrc`
 file to provide those credentials.
 
diff --git a/content/terraform/v1.12.x/docs/language/providers/requirements.mdx b/content/terraform/v1.12.x/docs/language/providers/requirements.mdx
index 171aa9294..b3a7948d3 100644
--- a/content/terraform/v1.12.x/docs/language/providers/requirements.mdx
+++ b/content/terraform/v1.12.x/docs/language/providers/requirements.mdx
@@ -13,8 +13,7 @@ Terraform can install and use them. This page documents how to declare providers
 so Terraform can install them.
 
 Additionally, some providers require configuration (like endpoint URLs or cloud
-regions) before they can be used. The [Provider
-Configuration](/terraform/language/providers/configuration) page documents how
+regions) before they can be used. The [`provider` block reference](/terraform/language/block/provider) documents how
 to configure settings for providers.
 
 -> **Note:** This page is about a feature of Terraform 0.13 and later; it also
@@ -79,7 +78,7 @@ Local names must be unique per-module.
 Outside of the `required_providers` block, Terraform configurations always refer
 to providers by their local names. For example, the following configuration
 declares `mycloud` as the local name for `mycorp/mycloud`, then uses that local
-name when [configuring the provider](/terraform/language/providers/configuration):
+name when [configuring the provider](/terraform/language/block/provider#using-an-alternate-provider-configuration):
 
 ```hcl
 terraform {
diff --git a/content/terraform/v1.12.x/docs/language/resources/syntax.mdx b/content/terraform/v1.12.x/docs/language/resources/syntax.mdx
index 8fda3efaa..a8c80f1a4 100644
--- a/content/terraform/v1.12.x/docs/language/resources/syntax.mdx
+++ b/content/terraform/v1.12.x/docs/language/resources/syntax.mdx
@@ -65,7 +65,7 @@ To manage resources, a Terraform module must specify the required providers. Ref
 
 Most providers need some configuration to access their remote API,
 which is provided by the root module. Refer to
-[Provider Configuration](/terraform/language/providers/configuration) for additional information.
+[the `provider` block reference](/terraform/language/block/provider) for additional information.
 
 Based on a resource type's name, Terraform can usually determine which provider to use.
 By convention, resource type names start with their provider's preferred local name.
diff --git a/content/terraform/v1.12.x/docs/language/tests/index.mdx b/content/terraform/v1.12.x/docs/language/tests/index.mdx
index 9dc47bb30..bc754e569 100644
--- a/content/terraform/v1.12.x/docs/language/tests/index.mdx
+++ b/content/terraform/v1.12.x/docs/language/tests/index.mdx
@@ -276,7 +276,7 @@ In comparison, `local_value` in `run_block_two` takes its value from the output
 
 You can set or override the required providers within the main configuration from your testing files by using `provider` and `providers` blocks and attributes.
 
-At the root level of a Terraform testing file, you can define [`provider` blocks](/terraform/language/providers/configuration) as if Terraform were creating them [within the main configuration](/terraform/language/providers). Terraform will then pass these provider blocks into its configuration as each `run` block executes.
+At the root level of a Terraform testing file, you can define [`provider` blocks](/terraform/language/block/provider) as if Terraform were creating them [within the main configuration](/terraform/language/providers). Terraform will then pass these provider blocks into its configuration as each `run` block executes.
 
 By default, each provider you specify is directly available within each `run` block. You can customize the availability of providers within a given `run` block by using a `providers` attribute. The behavior and syntax for this block match the behavior of [providers meta-argument](/terraform/language/meta-arguments/module-providers).
 
diff --git a/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx b/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx
index 3a3b35f56..08325d4f8 100644
--- a/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx
+++ b/content/terraform/v1.12.x/docs/language/v1-compatibility-promises.mdx
@@ -76,7 +76,7 @@ providers) will retain their current functionality:
   [`for_each`](/terraform/language/meta-arguments/for_each), and
   [`depends_on`](/terraform/language/meta-arguments/depends_on) meta-arguments
   in `resource`, `data`, and `module` blocks.
-* [`provider`](/terraform/language/providers/configuration) blocks to configure
+* [`provider`](/terraform/language/block/provider) blocks to configure
   providers, and the `alias` meta-argument.
 * [`variable`](/terraform/language/block/variable),
   [`output`](/terraform/language/block/output), and

From 109d3c59c2a59368a7a9b295eb8e26bf3ec9ea3e Mon Sep 17 00:00:00 2001
From: rkoron007 <rkoron007@gmail.com>
Date: Thu, 10 Jul 2025 15:21:45 -0700
Subject: [PATCH 2/3] Fix small things and ready to review

---
 .../v1.12.x/docs/language/block/provider.mdx  | 95 +++++++++++++++----
 1 file changed, 74 insertions(+), 21 deletions(-)

diff --git a/content/terraform/v1.12.x/docs/language/block/provider.mdx b/content/terraform/v1.12.x/docs/language/block/provider.mdx
index 8d03e9f18..c8b121160 100644
--- a/content/terraform/v1.12.x/docs/language/block/provider.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/provider.mdx
@@ -15,19 +15,19 @@ The `provider` block configures a named provider, which is a plugin that lets Te
 
 HashiCorp's public [Terraform registry](https://registry.terraform.io/browse/providers) distributes providers separately from Terraform itself, and each provider has its own release cadence, documentation, and versions. If you are using HCP Terraform, you can use the [private registry](/terraform/cloud-docs/registry) to share providers within an organization.
 
-Anyone can develop a Terraform provider and use it locally or publish it to the Terraform public registry, or HCP Terraform private registry. To learn more about authoring providers, refer to the [Plugin framework](/terraform/plugin/framework).
+Anyone can develop a Terraform provider and use it locally, or publish it to the Terraform public registry or HCP Terraform private registry. To learn more about authoring providers, refer to the [Plugin framework](/terraform/plugin/framework).
 
-Each Terraform module must declare which providers it requires, so that Terraform can install and use them. To declare a provider in a module perform the following three steps:
+Each Terraform module must declare which providers it requires, so that Terraform can install and use them. To declare a provider in a module, perform the following three steps:
 
 1. Define the provider's source, local name, and version in the [`required_providers` block](/terraform/language/block/terraform#required_providers) inside your top-level `terraform` block.
-2. Add a top-level `provider` block to your configuration to configure a provider with authentication, region, and other provider-specific arguments.
-3. Install your provider.
-   1. Running `terraform init` locally installs a provider and updates the [Dependency lock file](/terraform/language/files/dependency-lock) file with the version you installed.
-   2. HCP Terraform and Terraform Enterprise install providers as part of every run.
+1. Add a top-level `provider` block to your configuration to configure a provider with authentication, a region, and other provider-specific arguments.
+1. Install your provider.
+   - Running `terraform init` locally installs a provider and updates the [Dependency lock file](/terraform/language/files/dependency-lock) with the version you specified in your configuration.
+   - HCP Terraform and Terraform Enterprise install providers as part of every run.
 
 If you are running Terraform locally, your plan and apply operations use the provider versions specified in the dependency lock file. You can upgrade a provider version in your lock file by changing the value in your configuration and re-running `terraform init`. To learn more about declaring providers, refer to [Provider requirements](/terraform/language/providers/requirements).
 
-Define provider configurations in the root module of your Terraform configuration. Child modules receive their provider configurations from their parent modules, so do not define `provider` blocks in child modules. To learn more about passing providers to child modules, refer to [The `providers` meta-argument](/terraform/language/meta-arguments/module-providers).
+Define provider configurations in the root module of your Terraform configuration. Child modules receive their provider configurations from their parent modules, so we strongly recommend against defining `provider` blocks in child modules. To learn more about passing providers to child modules, refer to [The `providers` meta-argument](/terraform/language/meta-arguments/module-providers).
 
 ## Configuration model
 
@@ -42,6 +42,8 @@ The `provider` block supports the following arguments:
 
 All available arguments are defined in the following `provider` block. The `alias` and `version` arguments are optional, and you cannot use both in the same block.
 
+<CodeBlockConfig hideClipboard>
+
 ```hcl
 provider "<PROVIDER_NAME>" {
   <PROVIDER_ARGUMENTS>
@@ -50,6 +52,9 @@ provider "<PROVIDER_NAME>" {
 }
 ```
 
+</CodeBlockConfig>
+
+
 ## Specification
 
 A `provider` block supports the following configuration.
@@ -63,21 +68,27 @@ The following arguments are supported in a `provider` block:
 | Argument | Description | Type | Required? |
 | --- | --- | --- | --- |
 | Provider-specific arguments | Configuration arguments that the provider developer defined. | Various | Varies by provider |
-| `alias` | An additional name segment for this configuration, allowing multiple configurations for the same provider. | String | Optional |
+| `alias` | A unique identifier for a specific provider configuration, letting you use multiple configurations for the same provider. | String | Optional |
 | `version` | A version constraint for the provider. This argument is deprecated. | String | Optional |
 
 ### Provider-specific arguments
 
 The body of the `provider` block contains configuration arguments for the provider, which are defined by the provider itself.
 
+<CodeBlockConfig hideClipboard>
+
 ```hcl
 provider "<PROVIDER_NAME>" {
   <PROVIDER_ARGUMENTS>
 }
 ```
 
+</CodeBlockConfig>
+
 For example, both the `project` and `region` arguments are defined by the `google` provider.
 
+<CodeBlockConfig hideClipboard>
+
 ```hcl
 provider "google" {
   project = "acme-app"
@@ -85,6 +96,8 @@ provider "google" {
 }
 ```
 
+</CodeBlockConfig>
+
 A provider's documentation lists which configuration arguments it expects. For providers distributed on the [Terraform registry](https://registry.terraform.io), versioned documentation is available on each provider's page.
 
 If you do not explicitly define a `provider` block, Terraform assumes and creates an empty default configuration for that provider. However, if a provider has required arguments, Terraform raises an error because it can't create that provider without the required values.
@@ -105,24 +118,28 @@ Optionally use the `alias` argument to define multiple configurations for the sa
 
 To create multiple configurations for a given provider, include multiple `provider` blocks with the same provider name, then add the `alias` argument to each additional provider configuration to give it a unique identifier.
 
+<CodeBlockConfig highlight="6" hideClipboard>
+
 ```hcl
-provider "example" {
+provider "exampleName" {
   region = "us-east-1"
 }
 
-provider "example" {
+provider "exampleName" {
   alias  = "west"
-  region = "west"
+  region = "us-west-1"
 }
 ```
 
+</CodeBlockConfig>
+
 To refer to a provider alias, use `<PROVIDER_NAME>.<ALIAS>` in the `provider` argument of the following blocks:
 
-- `resource` blocks
-- `data` blocks
-- `module` blocks
+- [`resource` blocks](/terraform/language/block/resource)
+- [`data` blocks](/terraform/language/block/data)
+- [`module` blocks](/terraform/language/block/module)
 
-If there are multiple aliases for a provider, the `provider` block without an `alias` argument is the default configuration for that provider. Resources, data sources, and modules that don't specify the [`provider` meta-argument](/terraform/language/block/resource#provider) use the default provider configuration that matches the resource type name. For examples, refer to [using an alternate provider configuration](#using-an-alternate-provider-configuration) and [Provider without a default configuration](#provider-without-a-default-configuration).
+If there are multiple aliases for a provider, the `provider` block without an `alias` argument is the default configuration for that provider. Resources, data sources, and modules that don't specify the [`provider` meta-argument](/terraform/language/block/resource#provider) use the default provider configuration that matches the resource type name.
 
 #### Summary
 
@@ -152,6 +169,8 @@ The following examples demonstrate common use cases for `provider` blocks.
 
 The following example configures the `google` provider with a specific project and region. In the `terraform` block's `required_providers` block you define the provider version you want to use, where to source the provider from, and the local name of the provider:
 
+<CodeBlockConfig filename="terraform.tf">
+
 ```hcl
 terraform {
   required_providers {
@@ -163,8 +182,12 @@ terraform {
 }
 ```
 
+</CodeBlockConfig>
+
 You can further configure a provider with the `provider` block in the root module of your configuration.
 
+<CodeBlockConfig filename="main.tf">
+
 ```hcl
 provider "google" {
   project = "acme-app"
@@ -172,10 +195,14 @@ provider "google" {
 }
 ```
 
+</CodeBlockConfig>
+
 ### Multiple provider configurations
 
 In the following example, two configurations for the AWS provider support different regions. The default configuration targets the east coast, and the aliased configuration targets the west coast:
 
+<CodeBlockConfig filename="main.tf">
+
 ```hcl
 provider "aws" {
   region = "us-east-1"
@@ -187,6 +214,8 @@ provider "aws" {
 }
 ```
 
+</CodeBlockConfig>
+
 Resources that begin with `aws_` use the default `aws` provider configuration unless you supply the [`provider` argument](/terraform/language/block/resource#provider).
 
 ### Using an alternate provider configuration
@@ -195,6 +224,8 @@ You can make a resource, data source, or module use an alternate provider config
 
 In the following example, the `aws_instance.foo` resource uses the `aws.west` provider configuration, and `aws_instance.bar` uses the default `aws` provider configuration:
 
+<CodeBlockConfig highlight="6,11">
+
 ```hcl
 provider "aws" {
   region = "us-east-1"
@@ -215,6 +246,8 @@ resource "aws_instance" "bar" {
 }
 ```
 
+</CodeBlockConfig>
+
 ### Provider without a default configuration
 
 If there are multiple aliases for a provider in your configuration, the `provider` block without an `alias` argument is the default configuration for that provider. If every `provider` block in your configuration uses an alias, Terraform creates an implied empty default configuration for that provider. Any resource that does not specify a `provider` meta-argument uses the empty default configuration.
@@ -245,6 +278,8 @@ We recommend defining providers in root modules, and passing those provider conf
 
 In the following example, the root module defines an AWS provider configuration and passes it to a child module:
 
+<CodeBlockConfig highlight="8" filename="main.tf">
+
 ```hcl
 provider "aws" {
   region = "us-west-2"
@@ -258,8 +293,12 @@ module "vpc" {
 }
 ```
 
+</CodeBlockConfig>
+
 The child module uses the provider configuration passed from the root module:
 
+<CodeBlockConfig filename="modules/vpc/main.tf">
+
 ```hcl
 terraform {
   required_providers {
@@ -278,13 +317,17 @@ resource "aws_vpc" "main" {
 }
 ```
 
-The `aws_vpc` resource uses the same AWS provider configuration from the root module, and Terraform creates it in the `us-west-2` region.
+</CodeBlockConfig>
+
+The `aws_vpc` resource inherits the same AWS provider configuration from the root module, and Terraform creates the `aws_vpc` resource in the `us-west-2` region. Child modules do not inherit provider source or version requirements, so you must explicitly define those within a child module. Learn more about [inheriting providers in modules](/terraform/language/modules/develop/providers#implicit-provider-inheritance).
 
 ### Using an alternate provider configuration in a child module
 
-We recommend defining provider configuration blocks in root modules, and passing those configurations from parent modules to child modules. To use aliased provider configurations in a child module, the child module must declare aliases using the `configuration_aliases` argument in the `required_providers` block.
+To use an aliased provider configurations in a child module, the child module must declare the alias using the `configuration_aliases` argument in the `required_providers` block.
 
-In the following example, the root module the passes its `aws.west` alias to its child module:
+In the following example, the root module passes the `aws.west` alias to the `web-server` child module:
+
+<CodeBlockConfig highlight="13" filename="main.tf">
 
 ```hcl
 provider "aws" {
@@ -296,7 +339,7 @@ provider "aws" {
   region = "us-west-2"
 }
 
-module "web_server" {
+module "web-server" {
   source = "./modules/web-server"
   providers = {
     aws.west = aws.west
@@ -304,7 +347,11 @@ module "web_server" {
 }
 ```
 
-The following `configuration_aliases` argument in the child module declares that the child module expects to receive a provider configuration it can reference as `aws.west`. Without this declaration, Terraform raises an error when the module tries to reference `aws.west` in its resources.
+</CodeBlockConfig>
+
+The following `configuration_aliases` argument declares that the child module expects to receive a provider configuration it can reference as `aws.west`. Without this declaration, Terraform raises an error when the module tries to reference `aws.west` in its resources.
+
+<CodeBlockConfig highlight="6, 12" filename="modules/web-server/main.tf">
 
 ```hcl
 terraform {
@@ -324,12 +371,16 @@ data "aws_ami" "amazon_linux" {
 }
 ```
 
-Modules have special requirements for providers, refer to [The providers meta-argument](https://developer.hashicorp.com/terraform/language/meta-arguments/module-providers) to learn more.
+</CodeBlockConfig>
+
+Modules have special requirements for providers, refer to [Providers within modules](/language/modules/develop/providers) to learn more.
 
 ### Provider configuration with expressions
 
 In the following example, the provider configuration uses input variables and local values to set its arguments:
 
+<CodeBlockConfig highlight="15,18">
+
 ```hcl
 variable "aws_region" {
   description = "The AWS region to deploy resources in"
@@ -353,6 +404,8 @@ provider "aws" {
 }
 ```
 
+</CodeBlockConfig>
+
 ### Provider configuration without arguments
 
 In the following example, the provider block defines an empty configuration for the `random` provider. Terraform also assumes an empty default configuration for any provider that you do not explicitly configure with a `provider` block:

From 99f6513aa9009ae59f0b23ed87cc82a36bc0cdc8 Mon Sep 17 00:00:00 2001
From: rkoron007 <rkoron007@gmail.com>
Date: Thu, 10 Jul 2025 15:51:47 -0700
Subject: [PATCH 3/3] Fix the module block link for now

---
 content/terraform/v1.12.x/docs/language/block/provider.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/terraform/v1.12.x/docs/language/block/provider.mdx b/content/terraform/v1.12.x/docs/language/block/provider.mdx
index c8b121160..56a988355 100644
--- a/content/terraform/v1.12.x/docs/language/block/provider.mdx
+++ b/content/terraform/v1.12.x/docs/language/block/provider.mdx
@@ -137,7 +137,7 @@ To refer to a provider alias, use `<PROVIDER_NAME>.<ALIAS>` in the `provider` ar
 
 - [`resource` blocks](/terraform/language/block/resource)
 - [`data` blocks](/terraform/language/block/data)
-- [`module` blocks](/terraform/language/block/module)
+- [`module` blocks](/terraform/language/modules/syntax)
 
 If there are multiple aliases for a provider, the `provider` block without an `alias` argument is the default configuration for that provider. Resources, data sources, and modules that don't specify the [`provider` meta-argument](/terraform/language/block/resource#provider) use the default provider configuration that matches the resource type name.