TF-003 Read, generate and modify configuration — Timed 30 Questions

Question 1

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.. Option A is correct because 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 2

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

Add a 'lifecycle' block with 'create_before_destroy = true'.. Option B is correct because adding a `lifecycle` block with `create_before_destroy = true` instructs Terraform to create the new resource before destroying the old one, which avoids downtime but does not prevent the resource from being replaced. However, the question asks how to avoid destroying the resource entirely while still applying other changes. The correct approach is to use `ignore_changes` to exclude the attribute that triggers the replacement, so Terraform will not attempt to modify that attribute and thus will not schedule a destroy. Option B is marked as correct in the provided answer key, but this is a common exam trap: `create_before_destroy` does not prevent destruction; it only reorders the lifecycle. The actual solution to avoid destruction is to use `ignore_changes` or `prevent_destroy` depending on the goal.

Answer

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

Answer

Set 'ignore_changes' to the attribute causing the replacement.

Answer

Add 'prevent_destroy = true' to the resource.

Question 3

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 4

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'. Option D is correct because 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 5

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.. Option C is correct because 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 6

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 7

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 8

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.. Option B is correct because 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 9

Which THREE statements about Terraform modules are correct?

Accepted Answer

Module sources can be local file paths.. Option A is correct because Terraform modules can be sourced from local file paths using a relative or absolute path (e.g., `source = "./modules/network"`). This allows you to reuse configuration stored in subdirectories without needing a remote repository or registry. The `source` argument supports local paths as one of its valid source types, enabling modular development within a single project.

Answer

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

Answer

A module can only use one provider.

Question 10

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.. Option D is correct because 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.

Question 11

A team is writing Terraform configurations for a multi-region deployment. They want to use a module from the public Terraform Registry that provisions AWS VPCs. The module has been updated recently, but the team wants to ensure that all deployments use the same version of the module to avoid unexpected changes. Which configuration approach should they take to lock the module version?

Accepted Answer

Use the 'version' argument in the module block to specify the exact version.. Option B is correct because the 'version' argument in a module block is the standard Terraform mechanism for pinning a module from the Terraform Registry to a specific semantic version. This ensures that all deployments use the exact same module version, preventing unexpected changes from newer releases. The version constraint is evaluated against the registry's metadata and enforces the specified version during 'terraform init'.

Answer

Run 'terraform lock' on the module to record its version in the dependency lock file.

Answer

Reference the module source with a git URL and tag, such as 'git::https://github.com/...?ref=v1.0'.

Answer

Set the 'required_version' argument in the root module to match the module's version.

Question 12

Which of the following are valid ways to pass input variables to a Terraform configuration? (Select all that apply.)

Accepted Answer

Use the '-var' flag on the command line to set a single variable.. Option B is correct because Terraform automatically loads variable definitions from a file named 'terraform.tfvars' (or 'terraform.tfvars.json') in the current directory when you run a plan or apply. This allows you to define input variables in a structured, reusable way without needing to specify them on every command invocation.

Question 13

Refer to the exhibit. A developer runs 'terraform plan' and receives the following error: 'Error: InvalidAMIID.NotFound: The image id '[ami-0c55b159cbfafe1f0]' does not exist'. What is the most likely cause?

Accepted Answer

The AMI is not available in the region specified in the provider configuration.. Option B is correct because the error 'InvalidAMIID.NotFound' indicates that the specified AMI ID does not exist in the AWS region configured in the Terraform provider block. AMI IDs are region-specific; an AMI available in us-east-1 may not exist in eu-west-2. Terraform validates the AMI against the region's EC2 API, and if the ID is not found, it throws this exact error.

Answer

The 'tags' block is missing a required 'ami' tag.

Answer

The 'ami' argument is misspelled; it should be 'image_id'.

Answer

The AMI ID is malformed; it should start with 'ami-' but the rest is incorrect.

Question 14

You are a DevOps engineer at a company that manages infrastructure for multiple environments (dev, staging, prod) using Terraform. Each environment has its own state file stored in an S3 backend with DynamoDB locking. The team recently adopted a policy of running 'terraform plan' in CI/CD pipelines to review changes before applying. However, developers have reported that sometimes the plan output shows that Terraform wants to destroy and recreate resources that were not modified in their code changes. For example, a developer added a new tag to an S3 bucket in the staging environment, but the plan also showed that an unrelated EC2 instance would be replaced. Upon investigation, you notice that the state file for staging was last modified two days ago, but the developer's branch is based on a commit from one week ago. Which action is most likely to resolve the issue and ensure that plans only reflect changes from the current configuration changes?

Accepted Answer

Run 'terraform init -reconfigure' to ensure the local state is synchronized with the remote backend before planning.. Option A is correct because `terraform init -reconfigure` forces Terraform to reinitialize the backend and re-download the latest state file from the remote S3 backend, discarding any stale local copy. The developer's local state was based on a week-old commit, while the actual remote state had been updated two days ago, causing Terraform to detect spurious differences (e.g., an unrelated EC2 instance) due to state drift. This command ensures the local state matches the remote state before planning, so the plan only reflects changes from the current configuration.

Answer

Set the 'skip_metadata_api_check' option in the provider to avoid changes.

Answer

Use 'terraform plan -target=aws_s3_bucket.bucket' to limit the plan to only the S3 bucket.

Answer

Run 'terraform plan -refresh=true' to refresh the state before planning.

Question 15

What is the most likely cause of this error?

Accepted Answer

The `depends_on` meta-argument is missing from the aws_eip resource.. Option C is correct because the `aws_eip` resource depends on the `aws_instance.web` resource to ensure the instance is created before the Elastic IP is allocated. Without an explicit `depends_on` meta-argument, Terraform may attempt to create the EIP before the instance, causing an error if the instance ID is not yet available. The error message typically indicates that the `aws_eip` resource cannot resolve the `instance` argument because the instance resource has not been created yet.

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 `aws_instance.web` resource has a syntax error in the ami attribute.

Question 16

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

Accepted Answer

var.environment. Option A is correct because `var.environment` is the standard syntax to reference an input variable defined in a Terraform configuration. Input variables are declared with a `variable` block and accessed using the `var.` prefix, making this a valid reference within any Terraform configuration file.

Answer

local.example.value

Answer

module.example.arn

Answer

provider.aws.region

Question 17

You are managing a multi-environment Terraform configuration using separate workspaces for 'dev', 'staging', and 'prod'. Each workspace uses the same root module but different variable values stored in terraform.tfvars files per workspace. Your team reports that after a recent change to the root module, running `terraform plan` in the 'dev' workspace shows that it will destroy and recreate a critical RDS database instance, even though no changes were made to the database configuration. The state file for 'dev' is stored in a remote S3 backend with DynamoDB locking. You suspect the issue is related to how Terraform generates and reads configuration. What is the most likely cause?

Accepted Answer

A new variable with a default value that forces recreation of the database was added to the root module, but the 'dev' workspace's tfvars file does not override it, so Terraform uses the default which differs from the current state.. Option B is correct because when a new variable with a default value is added to the root module, and the 'dev' workspace's terraform.tfvars does not override it, Terraform uses the default value. If that default differs from the value currently tracked in the state (e.g., a database engine version or instance class), Terraform interprets this as a configuration change and plans to destroy and recreate the resource to match the new default. This is a common pitfall when variables are introduced without updating all workspace-specific variable files.

Answer

The S3 backend is misconfigured, causing the 'dev' workspace to use the 'prod' state file.

Answer

The root module was changed to use a different Terraform provider version that is incompatible with the existing state.

Answer

The DynamoDB lock is not being released after previous operations, causing state corruption.

Question 18

Which three of the following are valid methods for reading, generating, or modifying Terraform configuration? (Choose three.)

Accepted Answer

Using the `terraform fmt` command to automatically update configuration files to a canonical format and style.. The `terraform fmt` command rewrites configuration files to a canonical format and style, which is a valid method for modifying configuration. The `templatefile` function reads a template file and renders it with supplied variables, enabling dynamic configuration generation. The `terraform console` command provides an interactive shell for evaluating expressions and inspecting resource attributes, which is a valid way to read and test configuration logic.

Answer

Using the `terraform state push` command to directly edit the state file and then reflect those changes back into the configuration.

Answer

Using the `merge` function to combine multiple map values, but only when the source maps are defined in separate Terraform modules.

Answer

Using the `terraform plan -generate-config-out` flag to automatically create configuration from existing infrastructure.

Question 19

Which four of the following are valid techniques for reading, generating, or modifying Terraform configuration? (Choose all that apply. There are four correct answers.)

Accepted Answer

Using `terraform validate` to check configuration syntax and internal consistency before applying changes.. The `templatefile` function is a valid technique for reading and generating configuration because it reads an external template file and renders it with variables from the current Terraform configuration, producing a string that can be used in resource arguments or other expressions. This is a core feature for dynamic configuration generation, such as injecting user data into cloud-init scripts or generating complex configuration files for provisioned resources.

Answer

Using `terraform console` to evaluate expressions and generate valid HCL configuration output.

Answer

Using `terraform state pull` to retrieve remote state and then using `terraform state mv` to rename a resource address in the local state file before pushing it back.

Question 20

Drag and drop the steps to handle sensitive data in Terraform outputs in the correct order.