HashiCorp Terraform Associate (004) Question 38
Single answer2c Write Terraform configuration using multiple providersYour team manages infrastructure in two AWS regions from a single Terraform root module. Most resources should be created in us-east-1, but an S3 bucket used for cross-region log replication must be created in us-west-2. A developer wrote the following configuration:
provider "aws" { region = "us-east-1" }
provider "aws" { region = "us-west-2" }
resource "aws_instance" "app" { ami = "ami-12345678" instance_type = "t3.micro" }
resource "aws_s3_bucket" "replica" { bucket = "company-replica-logs-example" }
When running terraform plan, Terraform reports a duplicate provider configuration problem. What is the best way to correct this configuration so each resource is managed in the intended region?
- A
Keep one default aws provider for us-east-1, add an aliased aws provider for us-west-2, and set provider = aws.west on the S3 bucket resource.
- B
Add region = "us-west-2" directly inside the aws_s3_bucket resource and keep both provider blocks unchanged.
- C
Create two terraform blocks, one for each region, and move each resource into the matching terraform block.
- D
Remove both provider blocks and instead set the region through variables inside each resource block.
Show answer and explanation
Correct answer: A
Explanation
The correct pattern for using multiple providers of the same type in Terraform is to define one default provider configuration and any additional ones with alias. Then, use the provider meta-argument on resources or modules that should use the non-default provider configuration. For example:
provider "aws" { region = "us-east-1" }
provider "aws" { alias = "west" region = "us-west-2" }
resource "aws_instance" "app" { ami = "ami-12345678" instance_type = "t3.micro" }
resource "aws_s3_bucket" "replica" { provider = aws.west bucket = "company-replica-logs-example" }
This is the recommended and documented approach for multiple provider configurations. HashiCorp documentation covers this under provider configuration, alias, and the provider meta-argument for resources and modules. This is a core Terraform skill because many real-world environments require managing multiple regions, accounts, or endpoints from the same configuration.
- A. Correct.
Correct. When using multiple configurations of the same provider in one module, one provider configuration can remain the default and additional configurations must use the alias meta-argument. Resources that should use the non-default configuration must explicitly reference it with the provider meta-argument, such as provider = aws.west. In this scenario, aws_instance.app would use the default us-east-1 provider automatically, while aws_s3_bucket.replica would be pinned to the aliased us-west-2 provider.
- B. Incorrect.
Incorrect. Terraform resource blocks do not generally accept provider-specific connection settings such as AWS region directly as an argument unless the resource schema defines such an argument, and aws_s3_bucket does not use a region argument in that way. Region selection is handled by the provider configuration, not by setting region ad hoc inside the resource block. This distractor reflects the common misconception that provider settings can be overridden per resource using arbitrary arguments.
- C. Incorrect.
Incorrect. Terraform supports only one terraform block per module conceptually, though multiple terraform blocks can be merged for settings like required_providers. They are not used to scope resources by region or provider configuration. Region targeting is controlled through provider configurations and resource/module provider selection, not separate terraform blocks.
- D. Incorrect.
Incorrect. Resources do not independently configure provider behavior this way. While variables can be used inside provider blocks to parameterize region values, Terraform still requires explicit provider configurations. Removing provider blocks would leave the AWS resources without the required provider setup. This option confuses input variables with provider configuration mechanics.