TF-004 Practice Test 19 — 15 Questions

Question 1

A team uses Terraform to manage infrastructure. They have multiple configuration directories for different environments (dev, staging, prod). They want to reuse common modules across environments. Which approach aligns with the core Terraform workflow best practices?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use a single configuration with separate state files and variable files for each environment. It follows the core Terraform workflow of separating configuration from state and using variable files to manage environment-specific differences. By maintaining a single configuration directory with separate state files (e.g., via different backends or state file paths) and variable files (e.g., `dev.tfvars`, `prod.tfvars`), the team avoids duplication and ensures that all environments use the same module versions and resource definitions, which is a best practice for consistency and maintainability.

Answer

Use workspaces with state stored in a local backend

Answer

Copy the configuration into each environment directory and modify as needed

Answer

Create separate Terraform configurations for each environment with hardcoded values

Question 2

A developer accidentally deletes the local terraform.tfstate file. The backend is configured to store state remotely in an S3 bucket. What is the effect on Terraform operations?

Accepted Answer

Terraform will automatically recover the state from the remote backend on the next plan or apply.. When a remote backend (e.g., S3) is configured, Terraform stores the state file in the remote location and maintains a local copy as a cache. Deleting the local terraform.tfstate file does not affect the remote state. On the next plan or apply, Terraform automatically pulls the latest state from the remote backend, effectively recovering it without data loss or manual intervention.

Answer

Terraform will create a new empty state file, losing all existing managed resources.

Answer

Terraform will fail with an error because the local state is missing.

Answer

Terraform will prompt the user to confirm whether to use the remote state.

Question 3

An organization stores state files in an S3 backend with encryption. However, some resource attributes (e.g., database passwords) are stored in plaintext within the state. What is the recommended approach to avoid storing sensitive values in state?

Accepted Answer

Use a secrets backend like Vault to retrieve secrets at runtime and store only references in state. Terraform state stores resource attributes in plaintext, including sensitive values like database passwords, even when the backend is encrypted at rest. The recommended approach is to never store the secret itself in state — instead, retrieve it at runtime from a secrets manager (Vault, AWS Secrets Manager) and store only a reference (e.g., the secret ARN or path) in state. This keeps the sensitive value out of state entirely.

Answer

Set the `sensitive` parameter on all resources

Answer

Enable state encryption with a stronger algorithm

Answer

Use the `terraform state rm` command after apply to remove sensitive attributes

Question 4

A team is using a shared backend for Terraform state. After running terraform apply, the state file is locked for an extended period, causing other team members to fail with 'Error acquiring the state lock'. What is the most likely cause?

Accepted Answer

A previous terraform apply command was interrupted or crashed, leaving a stale lock.. Terraform uses a locking mechanism (typically via DynamoDB for AWS S3 backends) to prevent concurrent state modifications. If a `terraform apply` is interrupted or crashes, the lock may not be released, leaving a stale lock entry. This causes subsequent operations to fail with 'Error acquiring the state lock' until the lock is manually removed or expires (if TTL is configured).

Answer

Another team member is actively running terraform apply on the same state.

Answer

The backend configuration was changed without running terraform init.

Answer

The state file contains resources that no longer exist in the cloud provider.

Question 5

In the configuration, what is the likely result of the resource block 'aws_flow_log'?

Accepted Answer

It will create one flow log per network module instance, using the vpc_id output from each.. `for_each` in Terraform iterates over each element in a map or set, creating one resource instance per element. When `for_each` is used with `module.networks`, it iterates over each module instance, and `each.value.vpc_id` references the `vpc_id` output from that specific module instance. This results in one `aws_flow_log` resource per network module instance, each associated with its respective VPC.

Answer

Terraform will error because for_each cannot be used with module outputs.

Answer

The resource will be created only for the last module instance due to overwriting.

Answer

It will create one flow log for each VPC using a count based on length of module.networks.

Question 6

Which TWO of the following are valid methods to share data between Terraform configurations?

Accepted Answer

Store shared data in a common backend and read it via data sources. Storing shared data in a common backend (e.g., an S3 bucket with DynamoDB locking) and reading it via data sources (like the `terraform_remote_state` data source) allows different Terraform configurations to consume outputs from one another without duplicating state or breaking isolation. This pattern is the recommended way to share data across configurations because it leverages the backend's locking and consistency guarantees.

Answer

Use output variables across configurations

Answer

Use modules to share state

Answer

Use depends_on to pass values

Question 7

You have a list of VPC configurations and want to create multiple VPCs using a single module block with for_each. Which statement is true?

Accepted Answer

When using for_each, the module's outputs will be a map of output values for each instance.. When you use `for_each` on a module block, Terraform creates multiple instances of the module, and the module's outputs become a map of output values keyed by the `for_each` key. This allows you to access each instance's outputs via the map, enabling iteration over the created resources.

Answer

for_each on a module is not supported.

Answer

You can use for_each on a module block only if the module is published in the registry.

Answer

for_each on a module block requires the module to support count.

Question 8

A team is using Terraform to manage a multi-tier application on AWS. The configuration includes resources for VPC, subnets, security groups, and EC2 instances. Recently, a developer manually created an additional security group in the AWS console for testing, and now the team wants to manage it via Terraform. They have updated the configuration to include this security group with the same name and rules. When they run `terraform plan`, it shows that the security group will be created, but the existing one is not detected. They want to bring the existing security group under Terraform management without recreating it. The team is using a remote backend with state locking. What should they do?

Accepted Answer

Use `terraform import` to import the existing security group into state.. `terraform import` is the purpose-built command for adopting resources that already exist outside of Terraform into the state file without destroying and recreating them. Running `terraform import aws_security_group.example sg-xxxxxxxx` maps the real AWS security group to the resource address in configuration, after which `terraform plan` shows no changes if the config matches reality. This preserves the existing security group's ID and any references to it, avoiding downtime or broken dependencies.

Answer

Run `terraform apply` and then modify the state to remove the duplicate.

Answer

Manually edit the Terraform state file to add the security group.

Answer

Run `terraform refresh` to update the state with the existing resource.

Question 9

Which THREE are valid methods to manage Terraform state files? (Choose three.)

Accepted Answer

Local state file. Option B (Local state file) is correct because Terraform's default behavior stores state in a local file named terraform.tfstate in the working directory, which is a fully valid way to manage state for solo or simple workflows. Option C (Terraform Cloud state storage) is correct because Terraform Cloud (and Terraform Enterprise) provides a managed remote backend that stores state, supports locking, versioning, and team collaboration, making it a legitimate state management method. Option E (Remote backends such as S3, AzureRM, GCS) is correct because configuring a backend block (e.g., backend "s3", "azurerm", or "gcs") stores the state file remotely and enables locking and shared access, which is the recommended approach for teams. Options A (terraform state push) and D (terraform state mv) are not state management methods but rather state manipulation subcommands: terraform state push manually uploads a local state to a remote backend, and terraform state mv moves resources within state, so neither constitutes a method of storing or managing the state file itself.

Answer

terraform state push

Answer

terraform state mv

Question 10

Which two statements accurately describe the difference between declarative and imperative IaC approaches? (Choose two.)

Accepted Answer

Declarative focuses on the desired outcome, while imperative specifies step-by-step commands. Option C is correct because declarative IaC (e.g., Terraform HCL, CloudFormation templates) defines the desired end state of the infrastructure and lets the tool determine the execution path, whereas imperative IaC (e.g., shell scripts, AWS CLI command sequences) explicitly lists the ordered commands needed to reach that state. Option D is correct because imperative approaches execute fixed steps without inherently reconciling actual versus desired state, so re-running or partially failing scripts can leave resources in unintended configurations, producing configuration drift. Option A is wrong because imperative techniques are widely used in IaC, such as provisioning with AWS CLI or Ansible ad-hoc commands. Option B is wrong because speed depends on implementation, provider APIs, and parallelism, not on whether the approach is declarative or imperative. Option E is wrong because declarative tools still rely on idempotency mechanisms (state files, resource providers, or reconciliation loops) to avoid duplicate changes; declarative syntax alone does not eliminate the need for idempotent behavior.

Answer

Imperative is only used for scripting, not IaC

Answer

Declarative tools are always faster than imperative tools

Answer

Declarative eliminates the need for idempotency

Question 11

After applying a module that creates a VPC, a user wants to use the VPC ID in another resource within the root configuration. How should they reference the output from the module?

Accepted Answer

vpc_id = module.vpc.vpc_id. In Terraform, module outputs are accessed using the syntax `module..`. Since the module is named `vpc` and it exposes an output called `vpc_id`, the correct reference is `module.vpc.vpc_id`. This allows the root configuration to consume the VPC ID created by the module.

Answer

vpc_id = module_vpc.vpc_id

Answer

vpc_id = data.module.vpc.vpc_id

Answer

vpc_id = local.vpc_id

Question 12

A team wants to use a networking module from the public Terraform Registry. They need to ensure they always get the latest patch version within the 1.2.x series. Which version constraint should they use in the module block?

Accepted Answer

version = "~> 1.2". Uses the pessimistic version constraint operator `~>`, which in Terraform allows only the rightmost version component to increment. When written as `~> 1.2`, it permits any version `>= 1.2.0` and `< 1.3.0`, effectively locking to the 1.2.x series while allowing patch updates. This matches the requirement to always get the latest patch within 1.2.x without accidentally upgrading to 1.3.0 or 2.0.0.

Answer

version = "= 1.2.0"

Answer

version = ">= 1.2.0, < 2.0.0"

Answer

version = ">= 1.2.0"

Question 13

A team is using Terraform Cloud and wants to enforce that all AWS resources created by Terraform have a specific tag. Which feature should they use?

Accepted Answer

Sentinel policies. Sentinel policies are Terraform Cloud's policy-as-code framework that allows teams to enforce mandatory rules on infrastructure configurations before they are applied. By writing a Sentinel policy that checks for the presence and value of a specific tag on all AWS resources, the team can reject any run that does not comply, ensuring consistent tagging across all resources created by Terraform.

Answer

Cost estimation

Answer

Workspace variables

Answer

Run tasks

Question 14

You are a platform engineer at a large enterprise that uses Terraform Cloud with a VCS-backed workflow for all infrastructure. Your team manages a configuration that provisions AWS EC2 instances for a critical application. Recently, a junior team member accidentally committed a change that removed a required tag from the EC2 instance resource. The change passed the plan stage but was blocked by a Sentinel policy during the apply, preventing the infrastructure from being updated. The team needs to fix the configuration and apply the change. However, the repository is configured to automatically trigger runs on every push to the main branch. The team wants to avoid triggering an unwanted run while they work on the fix. What should the team do?

Accepted Answer

Create a feature branch, fix the configuration, and merge via pull request. Using a feature branch and pull request allows the team to fix the configuration without triggering a run on the main branch, since Terraform Cloud’s VCS integration only auto-triggers runs on pushes to the configured branch (typically main). Once the fix is merged via pull request, the change will be applied through the normal VCS-backed workflow, maintaining audit trails and policy enforcement. This approach avoids disrupting the VCS connection or bypassing Terraform Cloud’s governance.

Answer

Temporarily disable the VCS connection in Terraform Cloud to prevent runs

Answer

Run terraform apply locally with the fixed configuration to bypass Terraform Cloud

Answer

Amend the commit on main and force push to overwrite history

Question 15

A team is using Terraform to manage infrastructure across multiple environments (dev, test, prod). They want to reuse the same configuration but vary resource configurations like instance size and number of instances. Which Terraform feature should they use?

Accepted Answer

Terraform modules with variables. Terraform modules with variables let the team define a single reusable configuration and pass environment-specific values (instance size, instance count) as input variables, avoiding duplication while keeping one source of truth. This is the idiomatic Terraform pattern for multi-environment deployments.

Answer

Separate directories with symlinks

Answer

Remote backends with different state files

Answer

Terraform workspaces