HashiCorp Certified: Terraform Associate (003) Free Sample Questions

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.

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 }.

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.

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.

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.

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.

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.

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.

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.

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.