Free terraform-associate-003 sample questions

Correct answer: Define multiple `provider` blocks in the root module, each with a unique `alias`, and pass the alias name to the `providers` meta-argument in each `module` block.

The correct way to handle multiple configurations for the same provider is by using the `alias` attribute in the `provider` block. This creates distinct provider instances. Each module can then be instructed to use a specific provider instance by passing a map to the `providers` meta-argument within the `module` block, mapping the provider name (e.g., `aws`) to the aliased name (e.g., `aws.tenant_a`). This ensures that each module's resources are managed exclusively by the provider instance configured with that tenant's credentials.

Correct answer: The module must be designed to accept provider configurations in its `providers` map. The module call would look like `providers = { aws.main = aws, aws.logging = aws.security }`.

Modules are encapsulated and do not automatically inherit aliased providers from the calling module. To use multiple provider configurations within a single module, the module must be explicitly designed to accept them. This is done by defining multiple provider requirements within the module's own `terraform` block and then passing the correctly configured provider instances from the root module via the `providers` meta-argument. The root module would map its aliased providers to the provider names expected by the child module, such as `providers = { aws.main = aws, aws.logging = aws.security }`.

Correct answer: `aws_instance.server["app-1"].availability_zone`

When a resource is created using `for_each`, its instances are accessed like a map. The general format is ` . [" "]`. In this case, the resource is `aws_instance.server`, and the key for the desired instance is `"app-1"`. Therefore, `aws_instance.server["app-1"]` references the specific instance object, and `.availability_zone` accesses its attribute.

Correct answer: False

False. The `terraform state replace-provider` command is used when a provider's source address changes (e.g., moving from a community fork to an official version), not for version upgrades. The recommended method for upgrading a provider version is to update the version constraint in the `required_providers` block and then run `terraform init -upgrade` to download the new version and update the lock file.

Correct answer: A `dynamic "ingress"` block with a `for_each` argument.

A `dynamic` block is specifically designed for this purpose. It iterates over a complex type (like a list of objects) and generates a nested block (like `ingress`) for each item in the collection. By setting `for_each` to the variable containing the list of rules, you can use the `iterator` (e.g., `ingress.value`) to access the attributes of each rule object and populate the `content` of the generated block.

Correct answer: ```hcl variable "instance_count" { type = number validation { condition = var.instance_count > 0 && floor(var.instance_count) == var.instance_count error_message = "Instance count must be a positive integer." } }```

This is the correct syntax. The `validation` block (not `validate`) is used within a `variable` block. The `condition` argument must be a boolean expression that is true for the value to be valid. Here, `var.instance_count > 0` checks for positivity, and `floor(var.instance_count) == var.instance_count` is a standard way to check if a number is a whole number (an integer). The `error_message` is returned if the condition is false.

Correct answers: `hashicorp/consul/aws`; `git::https://example.com/infra-modules/vpc.git?ref=v1.2.0`

This is a valid shorthand for a module from the public Terraform Registry. It follows the ` / / ` format.

This is a valid Git source URL. The `git::` prefix indicates the source type, and the `?ref=` argument is used to pin the module to a specific branch, tag, or commit hash.

Correct answer: The `.terraform.lock.hcl` file was generated only on macOS and does not contain the necessary provider hashes for the Linux platform.

The `.terraform.lock.hcl` file records dependency checksums for each provider for each platform (OS and architecture) it has been initialized on. If `terraform init` was only run on macOS, the lock file will only contain hashes for `darwin_amd64` or `darwin_arm64`. When the CI/CD pipeline runs on Linux (`linux_amd64`), it won't find a matching hash, forcing it to select a provider version based on the constraints and add the new platform's hash to the lock file. To prevent this, `terraform providers lock -platform=linux_amd64 -platform=darwin_amd64` should be run.

Correct answer: Use the `terraform_remote_state` data source to read the output values from the colleague's state file.

The `terraform_remote_state` data source is the standard way to share information between separate Terraform configurations. It allows one configuration to access the output values of another. By adding this data source and configuring it to point to the colleague's remote state, the new team member can reference the required values (like a VPC ID or subnet ID) without duplicating resource definitions.

Correct answer: A collection of Terraform configurations, variables, and state files that together represent a distinct environment or component.

In HCP Terraform (and Terraform Cloud), a workspace is a container for everything Terraform needs to manage a collection of infrastructure: the configuration itself (often from a VCS repository), the values for input variables, and most importantly, its own separate state file. This allows teams to manage different environments (dev, staging, prod) or components from the same configuration codebase with isolated state and variables.