TF-004 Read, generate and modify configuration — Timed 25 Questions

Question 1

An operator runs 'terraform plan' and sees that a resource will be replaced. They want to avoid destroying the resource, but still apply other changes. What should they do?

Accepted Answer

Set 'ignore_changes' to the attribute causing the replacement.. To avoid destroying the resource while still applying other changes, the operator should use the `ignore_changes` lifecycle argument on the attribute that is causing the replacement. This tells Terraform to ignore changes to that specific attribute, so it will not plan a replacement. Other changes (e.g., to other attributes) can still be applied. Option A (`terraform apply -replace`) explicitly forces the replacement of a resource, which involves destroying the old one, directly contradicting the operator's goal to avoid destruction. Option B (`create_before_destroy`) does not prevent destruction; it only changes the order so the new resource is created before the old one is destroyed, but the old resource is still ultimately destroyed. Option D (`prevent_destroy`) would block any destroy operation, but it would also cause the apply to fail if a replacement is required, preventing other changes from being applied.

Answer

Use 'terraform apply -replace=resource_address' to replace only that resource.

Answer

Add a 'lifecycle' block with 'create_before_destroy = true'.

Answer

Add 'prevent_destroy = true' to the resource.

Question 2

Which THREE statements about Terraform modules are correct?

Accepted Answer

Module sources can be local file paths.. Terraform modules are a fundamental way to organize and reuse configuration. They can be sourced from various locations, including local file paths (Option A), allowing for modular development within a single project using relative or absolute paths (e.g., `source = "./modules/network"`). Additionally, modules can be published to and consumed from the Terraform Registry (Option D), which serves as a central repository for sharing reusable infrastructure code. To allow calling modules to access specific values or resources defined within a module, modules expose output values using `output` blocks (Option E), making them accessible to parent modules or the root configuration.

Answer

Modules must always be in the root directory of the configuration.

Answer

A module can only use one provider.

Question 3

When running terraform apply on a configuration that creates an AWS EIP resource referencing `aws_instance.web.id`, you receive the error: "Error: Missing required argument: The argument "instance" is required, but no definition was found." Given this configuration, what is the most likely cause of this error?

Accepted Answer

The `aws_instance.web` resource has a syntax error in the ami attribute.. The error 'Missing required argument: The argument "instance" is required, but no definition was found.' indicates that the `aws_eip` resource is missing the `instance` argument. Among the given options, the most likely cause is a syntax error in the `ami` attribute of `aws_instance.web`, which would prevent the instance resource from being created. This could lead to a situation where the EIP resource does not have a valid instance to reference, resulting in the missing argument error. While the error message itself points to a missing argument, the root cause can be a syntax error in a dependent resource that causes Terraform to skip or fail to create that resource, thereby leaving the EIP resource without a required input. Other options are incorrect: A refers to an irrelevant output block, B uses non-existent syntax, and C misattributes the error to a missing `depends_on`, which does not affect argument definition.

Answer

The `output` block is referencing a non-existent attribute.

Answer

The `aws_eip` resource must use `self.instance` instead of `aws_instance.web.id`.

Answer

The `depends_on` meta-argument is missing from the aws_eip resource.

Question 4

Which TWO of the following are valid ways to reference a value from a Terraform configuration?

Accepted Answer

var.environment. The explanation for option B states 'locals are accessed using `local.name` only', which is incorrect. If `local.example` is a map or object (e.g., `locals { example = { value = "foo" } }`), then `local.example.value` is a perfectly valid way to reference a value. Therefore, option B should be considered a valid reference.

The explanation for option E dismisses `aws_instance.example.id` by stating it's 'not considered a 'value' from the configuration in the context of this question focusing on input variables, locals, and module outputs.' However, resource attributes are fundamental values derived from a Terraform configuration. While the 'EXAM TRAP' note suggests a focus on specific namespaces (`var`, `local`, `module`, `data`), the stem itself does not define this narrow scope. Syntactically, `aws_instance.example.id` is a valid way to reference a value.

Given that options A (`var.environment`), B (`local.example.value`), C (`module.example.arn`), and E (`aws_instance.example.id`) are all syntactically valid ways to reference a value from a Terraform configuration, the question asking for 'Which TWO' is fundamentally flawed as it has more than two correct answers.

Answer

local.example.value

Answer

provider.aws.region

Answer

aws_instance.example.id

Question 5

A configuration creates multiple AWS instances using count. The developer wants to output the IDs of all instances. Which output block is valid? (Choose the best answer.)

Accepted Answer

All of the above. All three output blocks are valid ways to reference the IDs of instances created with `count`. In Terraform, `aws_instance.web.*.id` uses the legacy splat syntax, `aws_instance.web[*].id` uses the newer splat expression, and `[for i in aws_instance.web : i.id]` uses a `for` loop to iterate over the list of resources. All three produce the same result: a list of instance IDs.

Answer

output "ids" { value = aws_instance.web.*.id }

Answer

output "ids" { value = aws_instance.web[*].id }

Answer

output "ids" { value = [for i in aws_instance.web : i.id] }

Question 6

A team has an existing S3 bucket created outside Terraform. They want to manage it with Terraform by importing its state. Which of the following is the correct sequence of commands to read the bucket's configuration and avoid drift?

Accepted Answer

Write a minimal resource configuration, run terraform import, then terraform plan, then adjust configuration to match state.. Importing an existing S3 bucket into Terraform requires first writing a minimal resource configuration (e.g., `resource "aws_s3_bucket" "example" { bucket = "existing-bucket-name" }`), then running `terraform import` to link the real-world bucket to the state file. After import, running `terraform plan` reveals any configuration-to-state mismatches, allowing you to adjust the resource block (e.g., adding `acl`, `versioning`, or `tags`) to match the actual bucket configuration, thereby avoiding drift. This workflow ensures the Terraform configuration accurately reflects the existing infrastructure before making changes.

Answer

Run terraform refresh, then terraform state pull to generate configuration.

Answer

Run terraform plan, note the resource address, then run terraform import.

Answer

Run terraform import, then terraform state show to generate configuration.

Question 7

A team stores sensitive secrets in AWS Secrets Manager and wants to reference them in Terraform without exposing the values. Which approach is most secure and recommended?

Accepted Answer

Use an aws_secretsmanager_secret_version data source and mark the variable as sensitive.. Using an `aws_secretsmanager_secret_version` data source retrieves the secret value directly from AWS Secrets Manager at plan/apply time, and marking the variable as `sensitive` prevents Terraform from displaying the value in logs or state output. This approach ensures the secret is never stored in plaintext in configuration files, version control, or environment variables, aligning with the principle of least privilege and secure secret management.

Answer

Set the secret as an environment variable and reference it in the configuration.

Answer

Store the secret in a variables.tf file with a default value.

Answer

Define the secret in a locals block with a default.

Question 8

A team runs terraform plan and sees changes that are unexpected. Which TWO actions should they take to investigate before applying?

Accepted Answer

Save the plan with terraform plan -out=plan.tfplan and then use terraform show plan.tfplan to examine details.. The original explanation for Option A is incorrect. `terraform providers mirror` is used to create or update a local directory of provider binaries, typically for air-gapped environments or specific distribution strategies. It is not an investigation step for diagnosing unexpected plan changes or verifying provider version consistency across a team. To ensure consistent provider versions across a team, the `.terraform.lock.hcl` file should be committed and all team members should run `terraform init`. To investigate potential provider version drift causing unexpected changes, one would typically inspect the `.terraform.lock.hcl` file, check `terraform version` output, or run `terraform init -upgrade`. Option B is correctly explained as a fundamental and essential step to inspect every resource change in detail, including attribute diffs and sensitivity, which is crucial for diagnosing unexpected modifications before applying.

Answer

Run terraform providers mirror to ensure provider versions are consistent.

Answer

Delete the state and re-import all resources.

Answer

Manually edit the state file to match the configuration.

Answer

Revert the configuration to the previous commit and re-run plan.

Question 9

An organization wants to reference outputs from a root module in another Terraform configuration. Which THREE methods are valid for reading those outputs?

Accepted Answer

Store outputs in a remote state backend and use terraform_remote_state with appropriate configuration.. `terraform_remote_state` is a dedicated data source that retrieves root module outputs from a remote state backend (e.g., S3, Terraform Cloud). This allows one configuration to consume outputs from another configuration without duplicating infrastructure or manually parsing state files. It is the standard, supported method for cross-configuration output sharing.

Answer

Use a module block with source = "./path/to/other-config" and reference its outputs.

Answer

Read the state file directly using terraform state pull and parse in HCL.

Question 10

Which THREE of the following are valid ways to modify a Terraform configuration to rename a resource without destroying and recreating it? (Select THREE.)

Accepted Answer

Run `terraform state mv` to rename the resource in state, then update the config.. Options A, B, and D are correct. Using `terraform state mv` (A) updates the state without destroying the resource. Adding a `moved` block (B) is the recommended way to rename a resource in Terraform 1.1+. Using a `removed` block with `import` (D) involves adding configuration blocks to remove the old resource from state and import the existing infrastructure under a new address, without destroying the underlying infrastructure. Option C (simply changing the name in config) causes Terraform to see the old resource as removed and the new as created, leading to destroy and recreate. Option E (state rm then import) involves running two separate CLI commands (`terraform state rm` and `terraform import`). While this sequence can achieve the outcome of managing an existing resource under a new name without destroying it, it does not involve modifying the Terraform *configuration files* (HCL) directly to declare the rename, unlike options B and D which use configuration blocks. The question asks for valid ways to modify a Terraform configuration, and while CLI state commands affect the configuration's state, options B and D represent direct modifications to the declarative configuration itself.

Answer

Simply change the resource name in the configuration and run `terraform apply`.

Answer

Run `terraform state rm` then `terraform import` with the new address.

Question 11

A large organization uses Terraform to manage hundreds of AWS resources across multiple accounts. They have a central repository with modules for common patterns. A new engineer is tasked with adding a new feature that requires modifying the configuration of an existing S3 bucket to enable server-side encryption. The current configuration for the bucket is defined in a module that is used by many other teams. The engineer adds an `aws_s3_bucket_server_side_encryption_configuration` resource as recommended by the latest AWS provider. After running `terraform plan`, they see that the plan will create the new encryption resource but also shows an in-place update to the bucket itself. They check the bucket resource and see that it has a `server_side_encryption_configuration` argument that is deprecated. The engineer wants to ensure backward compatibility and avoid breaking other teams' configurations. What is the best course of action?

Accepted Answer

Coordinate with the module maintainers to update the module, using the new encryption resource and removing the deprecated argument in a later release.. The best course because it ensures backward compatibility and avoids breaking other teams. Using the deprecated `server_side_encryption_configuration` argument (A) is not recommended as it may be removed in future provider versions. Proceeding with the plan as is (C) might cause disruption because the in-place update could affect other teams using the module. Adding a `lifecycle` block with `create_before_destroy` (D) does not address the need for coordination; the update is in-place, not a destroy/create. The correct approach is to coordinate with module maintainers to update the module, add the new encryption resource, and remove the deprecated argument in a later release after teams have migrated.

Answer

Use the deprecated `server_side_encryption_configuration` argument in the bucket resource to avoid adding a new resource.

Answer

Proceed with the plan as is, since the in-place update is expected during migration.

Answer

Add a `lifecycle` block with `create_before_destroy` to the new encryption resource to prevent destruction.

Question 12

A startup uses Terraform to manage their cloud infrastructure. They have a single configuration file that defines an AWS EC2 instance. They want to add an Elastic IP (EIP) and associate it with the instance. The engineer modifies the configuration to add an `aws_eip` resource and references the instance ID. They run `terraform plan` and it shows that the EIP will be created. However, when they run `terraform apply`, they get an error: "Error: Error associating EIP: ... The instance ID 'i-1234567890abcdef0' does not exist." The instance was created successfully in a previous apply. What is the most likely cause?

Accepted Answer

The instance was terminated manually outside Terraform.. The plan succeeded, indicating the Terraform state is intact and recognizes the existing instance. The error 'The instance ID does not exist' suggests that when Terraform attempted to associate the EIP, the instance was no longer present. This is consistent with manual termination of the instance outside of Terraform, which removes the AWS resource but leaves the state file unchanged. State loss or corruption would have caused the plan to show both the instance and EIP as new resources, not just the EIP.

Answer

The Terraform state file was lost or corrupted, so the instance is not in state.

Answer

The `aws_eip` resource is referencing the wrong instance attribute.

Answer

The instance type has changed causing a new instance to be created.

Question 13

A team wants to use Terraform to provision infrastructure across multiple cloud providers. Which configuration approach best supports this goal?

Accepted Answer

Define multiple provider blocks, one for each cloud provider.. Terraform uses multiple provider blocks to manage resources from different cloud providers within a single configuration. Each provider block configures a separate provider (e.g., aws, azurerm, google) with its own authentication and region settings, allowing Terraform to provision and manage infrastructure across AWS, Azure, GCP, and others in the same state file and execution plan.

Answer

Use a single provider block that supports multiple clouds.

Answer

Terraform cannot manage multiple clouds in one configuration.

Answer

Create separate workspaces for each cloud provider.

Question 14

A Terraform configuration uses a module from the Terraform Registry. After updating the module version in the configuration, the operator runs 'terraform plan' but does not see the changes expected from the new version. What is the most likely cause?

Accepted Answer

The operator did not run 'terraform init' after changing the version.. When you change a module version in the configuration, Terraform must re-initialize the working directory to download the new version and update the dependency lock file (.terraform.lock.hcl). Running 'terraform plan' without first running 'terraform init' will use the previously cached module version, so the expected changes from the new version will not appear. 'terraform init' is the required command to fetch and lock the updated module source.

Answer

The operator did not run 'terraform get' to update modules.

Answer

The operator did not run 'terraform refresh' to update state.

Answer

The module version constraint is stored in the state file and must be updated.

Question 15

A developer wants to conditionally create a resource based on a variable that is a boolean. Which syntax should they use?

Accepted Answer

Use 'count = var.create ? 1 : 0'. In Terraform, the `count` meta-argument accepts a number, and the ternary expression `var.create ? 1 : 0` evaluates to 1 (true) to create one instance of the resource or 0 (false) to create none. This is the standard pattern for conditionally creating a single resource based on a boolean variable.

Answer

Use 'if var.create' inside the resource block

Answer

Use 'for_each = var.create ? [1] : []'

Answer

Use 'count = var.create'

Question 16

An operator wants to pass output values from one Terraform configuration to another as input variables. Which approach is recommended?

Accepted Answer

Use a remote state data source to read the outputs from the first configuration's state.. Terraform's remote state data source (e.g., `terraform_remote_state`) allows one configuration to securely read output values from another configuration's state file stored in a shared backend (like S3, Azure Storage, or Consul). This avoids duplication, manual errors, and ensures that the second configuration always uses the latest outputs from the first, without requiring direct file access or environment variables.

Answer

Hardcode the output values in a variables file for the second configuration.

Answer

Store outputs in a shared file and use 'file()' function to read them.

Answer

Use environment variables to pass the output values.

Question 17

A Terraform configuration includes a resource block with a 'lifecycle' block that has 'create_before_destroy = true'. During an apply, the create step succeeds but the destroy step fails. What is the resulting state?

Accepted Answer

Both the old and new resources are in state.. When `create_before_destroy = true` is set, Terraform creates the new resource first, then destroys the old one. If the destroy step fails after the new resource is created, both resources exist in the state file because Terraform does not remove the old resource from state until the destroy operation completes successfully. The state retains both resource instances at the same address, which is why option D is correct.

Answer

Only the new resource remains in state, old resource is destroyed.

Answer

The state is empty for that resource address.

Answer

Only the old resource remains in state.

Question 18

A configuration uses variables defined in a 'variables.tf' file. The operator wants to override these variables for a specific run without modifying the file. Which method should they use?

Accepted Answer

Use the '-var' flag with 'terraform plan' or 'terraform apply'.. The `-var` flag on `terraform plan` or `terraform apply` allows operators to override variable values for a single run without modifying any files. This is the correct method because it provides a temporary override that does not persist across runs, unlike file-based or environment variable approaches.

Answer

Edit the state file directly.

Answer

Set environment variables with the same name as the variables.

Answer

Create a 'terraform.tfvars' file.

Question 19

Which TWO statements about Terraform provisioners are correct?

Accepted Answer

Provisioners should be used as a last resort when no other Terraform resource or data source fits.. Terraform provisioners are considered a last resort for tasks that cannot be accomplished with Terraform's declarative resource model. The official Terraform documentation explicitly states that provisioners should be used sparingly, as they introduce procedural logic and can cause state drift or failures that are hard to debug. This aligns with the principle of keeping configurations idempotent and relying on native resource attributes or data sources first.

Answer

Provisioners can only be used with the 'local-exec' and 'remote-exec' provisioners.

Answer

Provisioners are the primary way to configure resources after creation.

Answer

Provisioners run only once during initial creation by default.

Question 20

You are managing a Terraform configuration for a multi-tier application that includes AWS EC2 instances, an RDS database, and an Application Load Balancer. The configuration uses multiple modules and remote state stored in an S3 bucket with DynamoDB locking. Recently, a colleague made changes to the configuration and applied them successfully. However, you now need to make additional changes and, when you run 'terraform plan', you receive an error: "Error: Error acquiring the state lock". The error message indicates that the lock is held by a different user. You have confirmed that your colleague is not currently running Terraform. What is the most appropriate course of action to proceed with your changes?

Accepted Answer

Run 'terraform force-unlock ' to remove the stale lock.. Terraform uses DynamoDB for state locking to prevent concurrent modifications. When a lock becomes stale (e.g., due to a crash or network interruption), `terraform force-unlock ` is the proper command to manually release it. This preserves the integrity of the state file and avoids manual S3 or DynamoDB edits, which could corrupt the state or break the locking mechanism.

Answer

Edit the state file to remove the lock metadata.

Answer

Run 'terraform init -reconfigure' to reset the backend and release the lock.

Answer

Delete the lock file from the S3 bucket manually.