Practice Free Terraform Associate 004 Exam Online Questions
Which provider authentication method prevents credentials from being stored in the state file?
- A . Using environment variables
- B . Specifying the login credentials in the provider block
- C . Setting credentials as Terraform variables
- D . None of the above
D
Explanation:
None of the above methods prevent credentials from being stored in the state file. Terraform stores the provider configuration in the state file, which may include sensitive information such as credentials. This is a potential security risk and should be avoided if possible.
To prevent credentials from being stored in the state file, you can use one of the following methods:
Use environment variables to pass credentials to the provider. This way, the credentials are not part of the provider configuration and are not stored in the state file. However, this method may not work for some providers that require credentials to be set in the provider block.
Use dynamic credentials to authenticate with your cloud provider. This way, Terraform Cloud or Enterprise will request temporary credentials from your cloud provider for each run and use them to provision your resources. The credentials are not stored in the state file and are revoked after the run is completed. This method is supported for AWS, Google Cloud Platform, Azure, and
Vault.
Reference =: [Sensitive Values in State]: Authenticate providers with dynamic credentials
You’ve used Terraform to deploy a virtual machine and a database. You want to replace this virtual machine instance with an identical one without affecting the database.
What is the best way to achieve this using Terraform?
- A . Use the terraform state rm command to remove the VM from state file
- B . Use the terraform taint command targeting the VMs then run terraform plan and terraform apply
- C . Use the terraform apply command targeting the VM resources only
- D . Delete the Terraform VM resources from your Terraform code then run terraform plan and terraform apply
B
Explanation:
The terraform taint command marks a resource as tainted, which means it will be destroyed and recreated on the next apply. This way, you can replace the VM instance without affecting the database or other resources.
Reference = [Terraform Taint]
You have just developed a new Terraform configuration for two virtual machines with a cloud provider. You would like to create the infrastructure for the first time.
Which Terraform command should you run first?
- A . terraform apply
- B . terraform init
- C . terraform plan
- D . terraform show
B
Explanation:
B (terraform init)CMust be run first to initialize the Terraform working directory, download providers, and configure the backend.
A (terraform apply)C Requires initialization first, so itcannotbe run before terraform init.
C (terraform plan)C Also requires terraform init first to generate a plan.
D (terraform show)C Displays the state,not relevantfor first-time deployment. Official Terraform Documentation
Reference: terraform init – HashiCorp Documentation
You are writing a child Terraform module that provisions an AWS instance. You want to reference the IP address returned by the child module in the root configuration. You name the instance resource "main’.
Which of these is the correct way to define the output value?
- A . Option A
- B . Option B
- C . Option C
- D . Option D
A
Explanation:
According to the official Terraform documentation here:
Terraform Docs C Declaring an Output Value
In Terraform 0.12 and later, you can directly use expressions in outputs without interpolation syntax:
output "instance_ip_addr" {
value = aws_instance.server.private_ip
}
This aligns perfectly withOption A:
output "instance_ip_addr" {
value = aws_instance.main.private_ip
}
Why not the others?
❌ Option B: Incorrect syntax. "${main.private_ip}" is referencing main as if it were a global variable or resource, but it isn’t defined. Plus, the output name is oddly written as aws_instance.instance_ip_addr, which is not a valid identifier format.
❌ Option C: Although valid in older versions (<= 0.11), interpolation with "${}" isdeprecatedin Terraform 0.12+. The docs clearly advise using direct expressions instead.
❌ Option D: Terraform hasno return statement; this is syntactically invalid in Terraform’s HCL.
You are writing a child Terraform module that provisions an AWS instance. You want to reference the IP address returned by the child module in the root configuration. You name the instance resource "main’.
Which of these is the correct way to define the output value?
- A . Option A
- B . Option B
- C . Option C
- D . Option D
A
Explanation:
According to the official Terraform documentation here:
Terraform Docs C Declaring an Output Value
In Terraform 0.12 and later, you can directly use expressions in outputs without interpolation syntax:
output "instance_ip_addr" {
value = aws_instance.server.private_ip
}
This aligns perfectly withOption A:
output "instance_ip_addr" {
value = aws_instance.main.private_ip
}
Why not the others?
❌ Option B: Incorrect syntax. "${main.private_ip}" is referencing main as if it were a global variable or resource, but it isn’t defined. Plus, the output name is oddly written as aws_instance.instance_ip_addr, which is not a valid identifier format.
❌ Option C: Although valid in older versions (<= 0.11), interpolation with "${}" isdeprecatedin Terraform 0.12+. The docs clearly advise using direct expressions instead.
❌ Option D: Terraform hasno return statement; this is syntactically invalid in Terraform’s HCL.
When you initialize Terraform, where does it cache modules from the public Terraform Registry?
- A . In the /tmp directory.
- B . In the .terraform sub-directory.
- C . In memory.
- D . They are not cached.
B
Explanation:
Terraform downloads modules and providers into the .terraform directory inside the working directory.
A (/tmp/)C Incorrect; modules are not stored temporarily. C (In memory)C Incorrect; modules persist on disk.
D (Not cached)C Incorrect; Terraform does cache modules for efficiency. Official Terraform Documentation
Reference: Terraform Module Caching
How would you reference the volume IDs associated with the ebs_block_device blocks in this configuration?
- A . aws_instance.example.ebs_block_device[sda2,sda3).volume_id
- B . aws_lnstance.example.ebs_block_device.[*].volume_id
- C . aws_lnstance.example.ebs_block_device.volume_ids
- D . aws_instance.example-ebs_block_device.*.volume_id
D
Explanation:
This is the correct way to reference the volume IDs associated with the ebs_block_device blocks in this configuration, using the splat expression syntax. The other options are either invalid or incomplete.
You modified your Terraform configuration and run Terraform plan to review the changes. Simultaneously, your teammate manually modified the infrastructure component you are working on. Since you already ran terraform plan locally, the execution plan for terraform apply will be the same.
- A . True
- B . False
B
Explanation:
The execution plan for terraform apply will not be the same as the one you ran locally with terraform plan, if your teammate manually modified the infrastructure component you are working on. This is because Terraform will refresh the state file before applying any changes, and will detect any
differences between the state and the real resources.
Exhibit.
You need to deploy resources into two different regions in the same Terraform configuration. To do this, you declare multiple provider configurations as shown in the Exhibit space on this page.
What meta-argument do you need to configure in a resource block to deploy the resource to the us-west-2 AWS region?
- A . provider = aws.west
- B . alias = aws.west
- C . provider = west
- D . alias = west
A
Explanation:
When multiple provider configurations are defined using an alias, Terraform requires the provider meta-argument inside the resource block to explicitly reference the aliased provider.
In this case, the provider is defined as aws with alias = "west", so resources targeting us-west-2 must specify:
provider = aws.west
This tells Terraform exactly which provider configuration to use.
Analysis of Incorrect Options (Distractors):
B. alias = aws.west: Incorrect ― alias is only used inside the provider block, not in resources.
C. provider = west: Incorrect ― Terraform requires the full provider name (aws.west), not just the alias.
D. alias = west: Incorrect ― resources do not support an alias meta-argument.
Key Concept:
Using aliased provider configurations and the provider meta-argument to deploy resources across multiple regions or accounts.
Reference: Terraform Exam Objective C Manage Terraform Resources and Providers
Which of the following does terraform apply change after you approve the execution plan? (Choose two.)
- A . Cloud infrastructure
- B . The .terraform directory
- C . The execution plan
- D . State file
- E . Terraform code
A,D
Explanation:
The terraform apply command changes both the cloud infrastructure and the state file after you approve the execution plan. The command creates, updates, or destroys the infrastructure resources to match the configuration. It also updates the state file to reflect the new state of the infrastructure. The .terraform directory, the execution plan, and the Terraform code are not changed by the terraform apply command.
Reference = Command: apply and Purpose of Terraform State