Practice Free Terraform Associate 004 Exam Online Questions
Changing the Terraform backend from the default "local" backend to a different one after performing your first terrafom apply is:
- A . Optional
- B . Impossible
- C . Mandatory
- D . Discouraged
D
Explanation:
Changing the Terraform backend after performing the initial terraform apply is technically possible but strongly discouraged. This is because changing backends can lead to complexities in state management, requiring manual intervention such as state migration to ensure consistency. Terraform’s documentation and best practices advise planning the backend configuration carefully before applying Terraform configurations to avoid such changes.
Reference = This guidance is consistent with Terraform’s official documentation, which recommends careful consideration and planning of backend configurations to avoid the need for changes.
Variables declared within a module are accessible outside of the module.
- A . True
- B . False
B
Explanation:
Variables declared within a module are only accessible within that module, unless they are explicitly exposed as output values1.
You have multiple team members collaborating on infrastructure as code (IaC) using Terraform, and want to apply formatting standards for readability.
How can you format Terraform HCL (HashiCorp Configuration Language) code according to standard Terraform style convention?
- A . Run the terraform fmt command during the code linting phase of your CI/CD process Most Voted
- B . Designate one person in each team to review and format everyone’s code
- C . Manually apply two spaces indentation and align equal sign "=" characters in every Terraform file (*.tf)
- D . Write a shell script to transform Terraform files using tools such as AWK, Python, and sed
A
Explanation:
The terraform fmt command is used to rewrite Terraform configuration files to a canonical format and style. This command applies a subset of the Terraform language style conventions, along with other minor adjustments for readability. Running this command on your configuration files before committing them to source control can help ensure consistency of style between different Terraform codebases, and can also make diffs easier to read. You can also use the -check and -diff options to check if the files are formatted and display the formatting changes respectively2. Running the terraform fmt command during the code linting phase of your CI/CD process can help automate this process and enforce the formatting standards for your team.
Reference = [Command: fmt]2
When you use a remote backend that needs authentication, HashiCorp recommends that you:
- A . Write the authentication credentials in the Terraform configuration files
- B . Keep the Terraform configuration files in a secret store
- C . Push your Terraform configuration to an encrypted git repository
- D . Use partial configuration to load the authentication credentials outside of the Terraform code
D
Explanation:
This is the recommended way to use a remote backend that needs authentication, as it allows you to provide the credentials via environment variables, command-line arguments, or interactive prompts, without storing them in the Terraform configuration files.
You’ve enabled DEBUG-level logging for Terraform, and you’d like to send the log data to a file.
Which action should you take?
- A . Set the TF_LOG_PATH environment variable.
- B . Update the Terraform CLI configuration file.
- C . Add a path argument to the terraform block.
- D . Run the terraform output command.
A
Explanation:
Rationale for Correct Answer
Terraform logging is controlled via environment variables. TF_LOG sets the verbosity (e.g., DEBUG), and TF_LOG_PATH directs Terraform to write those logs to a specified file path. This is part of Terraform CLI troubleshooting and operational usage.
Analysis of Incorrect Options (Distractors):
B (Update the Terraform CLI configuration file): The CLI config can control some behaviors (credentials helpers, plugin cache, etc.), but log-to-file is specifically handled by TF_LOG_PATH.
C (Add a path argument to the terraform block): The terraform block configures required versions, required providers, and backends―not CLI logging output.
D (Run the terraform output command): terraform output displays output values from state; it has nothing to do with logging.
Key Concept: Terraform debugging and logging via environment variables (TF_LOG, TF_LOG_PATH).
Reference: Terraform Objectives ― Understand Terraform Basics and CLI (CLI workflow, troubleshooting/logging).
You use a cloud provider account that is shared with other team members. You previously used Terraform to create a load balancer that listens on port 80. After application changes, you updated the Terraform code to change the port to 443.
You run terraform plan and see that the execution plan shows the port changing from 80 to 443 like you intended and step away to grab some coffee.
In the meantime, another team member manually changes the load balancer port to 443 through the cloud provider console before you get back to your desk.
What will happen when you run terraform apply upon returning to your desk?
- A . Terraform will recreate the load balancer.
- B . Terraform will fail with an error because the state file is no longer accurate.
- C . Terraform will change the load balancer port to 80, and then change it back to 443.
- D . Terraform will not make any changes to the load balancer and will update the state file to reflect the manual change.
B
Explanation:
Terraform keeps track of the infrastructure state via the state file. When you initially ran terraform plan, Terraform determined that the port should be changed from80 to 443. However, since another team member manually modified the load balancer, Terraform’s local state file is now outdated.
When you run terraform apply, Terraform willcompare the expected state (from the plan) with the actual state (from the provider API).
Since the port is already set to443, but the local state file still shows80, Terraform willfail with an
errordue to the state mismatch.
To resolve this, you should run terraform refresh or use terraform apply -refresh-only to update the local state before applying changes.
Official Terraform Documentation
Reference: State Management – HashiCorp Documentation
Managing Drift in Terraform
Setting the TF_LOG environment variable to DEBUG causes debug messages to be logged into stdout.
- A . True
- B . False
A
Explanation:
Setting the TF_LOG environment variable to DEBUG causes debug messages to be logged into stdout, along with other log levels such as TRACE, INFO, WARN, and ERROR. This can be useful for troubleshooting or debugging purposes.
You add a new resource to an existing Terraform configuration, but do not update the version constraint in the configuration. The existing and new resources use the same provider. The working contains a.terraform.lock, hc1 file.
How will Terraform choose which version of the provider to use?
- A . Terraform will use the version recorded in your lock file
- B . Terraform will use the latest version of the provider for the new resource and the version recorded in the lock file to manage existing resources
- C . Terraform will check your state file to determine the provider version to use
- D . Terraform will use the latest version of the provider available at the time you provision your new resource
A
Explanation:
This is how Terraform chooses which version of the provider to use, when you add a new resource to an existing Terraform configuration, but do not update the version constraint in the configuration. The lock file records the exact version of each provider that was installed in your working directory, and ensures that Terraform will always use the same provider versions until you run terraform init – upgrade to update them.
Which of the following should you add in the required_providers block to define a provider version constraint?
- A . version
- B . version = "3.1"
- C . version: 3.1
- D . version – 3.1
B
Explanation:
Rationale for Correct Answer (B):
Provider version constraints in Terraform are specified using the version argument in the required_providers block, e.g.:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "3.1"
}
}
}
This ensures Terraform always uses a specific provider version (or constraint expression).
Analysis of Incorrect Options:
What is a Terraform provider not responsible for?
- A . Provisioning infrastructure in multiple cloud providers.
- B . Managing actions to take based on resource differences.
- C . Managing resources and data sources based on an API.
- D . Understanding API interactions with a hosted service.
A
Explanation:
Rationale for Correct Answer (A):
Providers only interact with one specific platform or API. Terraform itself can work with multiple providers in one configuration, but a single provider is not responsible for provisioning across multiple cloud providers.
Analysis of Incorrect Options:
B. Managing actions to take based on resource differences: This is a provider responsibility (through the resource schema).
C. Managing resources and data sources based on an API: Correct ― providers define resources/data sources and map them to API calls.
D. Understanding API interactions with a hosted service: Correct ― providers encapsulate API logic to allow Terraform to manage resources.
Key Concept:
Providers are API adapters. They handle CRUD operations for resources in their own ecosystem but do not span across multiple cloud platforms.
Reference: Terraform Exam Objective C Manage Terraform Resources and Providers.
