TF-004 Practice Test 20 — 15 Questions

Question 1

A team uses an S3 backend with DynamoDB locking. They accidentally delete the DynamoDB table used for state locking. What is the immediate consequence?

Accepted Answer

Terraform commands that require state locking will fail with a locking error.. Terraform's S3 backend with DynamoDB locking requires the lock table to exist for any operation that acquires a state lock (plan with refresh, apply, destroy). If the table is deleted, Terraform returns an error such as 'Error acquiring the state lock' or a ResourceNotFoundException, and the operation aborts rather than proceeding without locking.

Answer

State operations will continue without locking, risking corruption.

Answer

Terraform will automatically create a new DynamoDB table.

Answer

The state file will be migrated to local storage.

Question 2

Match each Terraform error code to its meaning.

Accepted Answer

Exit code 0: Command succeeded without any error. Terraform exit codes indicate the result of command execution. Exit code 0 means success, 1 means general error, and 2 means usage error. The other codes are not defined by Terraform.

Answer

Exit code 0: General error during execution

Answer

Exit code 2: Command succeeded without any error

Answer

Exit code 3: State lock error

Question 3

A team of five engineers uses Terraform with a remote backend in AWS S3 with DynamoDB state locking. One engineer runs 'terraform apply' but it hangs at 'Acquiring state lock'. What is the most likely cause?

Accepted Answer

Another engineer has an active lock from a previous run that was not released.. The most likely cause is that another engineer has an active lock from a previous run that was not released. Terraform uses DynamoDB state locking to prevent concurrent modifications to the state file. When `terraform apply` hangs at 'Acquiring state lock', it indicates that the lock item in the DynamoDB table is still present, meaning a prior operation either crashed, was interrupted, or the lock was not explicitly released via `force-unlock`.

Answer

The S3 bucket policy denies the request.

Answer

A recent 'terraform init' was run without the proper backend configuration.

Answer

The DynamoDB table is in a different AWS region.

Question 4

Which of the following is a primary benefit of using Infrastructure as Code?

Accepted Answer

Faster provisioning through automation. Infrastructure as Code (IaC) defines infrastructure in declarative templates or scripts that can be version-controlled and applied automatically, which dramatically speeds up provisioning compared to manual portal or CLI setup. Tools like Terraform, Bicep, and CloudFormation can deploy entire environments in minutes and reproduce them consistently. Faster provisioning through automation is the primary, universally cited benefit of IaC.

Answer

Removes dependency on cloud providers

Answer

Guarantees zero downtime during updates

Answer

Eliminates the need for cloud credentials

Question 5

A team is evaluating Terraform and Ansible for infrastructure provisioning. They note that Terraform describes the desired end state, while Ansible defines steps to reach that state. This difference is best described as:

Accepted Answer

Declarative vs imperative. Terraform is declarative — you describe the desired end state and Terraform computes the actions to reach it. Ansible playbooks are imperative — you list ordered tasks that execute step by step. This is the classic declarative-versus-imperative distinction the question describes.

Answer

Client-server vs agentless

Answer

Immutable vs mutable

Answer

Push vs pull

Question 6

Which TWO statements correctly describe Infrastructure as Code principles?

Accepted Answer

IaC enables version control of infrastructure configurations.. A and E are correct. A is correct because IaC enables version control of infrastructure configurations using tools like Git, allowing tracking and rollback. E is correct because IaC automates provisioning and configuration, ensuring repeatable and consistent deployments. B is incorrect because IaC often automates changes without requiring manual approval for every change, though approval workflows can be integrated. C is incorrect because IaC applies to on-premises, hybrid, and multi-cloud environments, not just public cloud. D is incorrect because IaC does not eliminate configuration management tools; they complement each other (e.g., Terraform for provisioning, Ansible for configuration).

Answer

IaC requires manual approval for every infrastructure change.

Answer

IaC is only applicable to public cloud environments.

Answer

IaC eliminates the need for configuration management tools.

Question 7

A new developer joins a project that uses Terraform with a remote backend in GCS (Google Cloud Storage). They clone the repository and run `terraform init` successfully. However, when they run `terraform plan`, they get an error: "Error loading state: AccessDenied: 403 my-project-terraform-state@my-project.iam.gserviceaccount.com does not have storage.objects.get access to the Google Cloud Storage bucket." What is the most likely resolution?

Accepted Answer

Grant the `Storage Object Viewer` role to the service account on the GCS bucket. The error 'AccessDenied: 403 ... does not have storage.objects.get access' indicates that the service account used by Terraform lacks read permissions on the GCS bucket. Granting the 'Storage Object Viewer' role to that service account on the bucket provides the necessary `storage.objects.get` permission, allowing Terraform to read the state file. Option C is correct; options A, B, and D are not appropriate solutions.

Answer

Disable access control on the bucket temporarily

Answer

Run `terraform init -reconfigure` to regenerate the backend configuration

Answer

Change the backend to local state and commit the state to the repository

Question 8

A company uses Terraform Cloud with a remote state backend and runs infrastructure as code through a CI/CD pipeline (GitHub Actions). The pipeline executes 'terraform plan' and 'terraform apply' using a service account with appropriate permissions. Recently, the team introduced a Sentinel policy to enforce that all AWS resources have mandatory tags (Environment, Owner, Project). The policy passes when runs are triggered manually from the Terraform Cloud UI, but fails consistently when the CI/CD pipeline runs the plan. The infrastructure configuration files are identical in both cases. The team verifies that the service account used by CI/CD has the same workspace permissions as the UI user. What is the most likely cause of the failure?

Accepted Answer

The CI/CD pipeline is using a different set of variables that override the tags.. The Sentinel policy enforces mandatory tags on AWS resources. When the CI/CD pipeline runs, it may use different variable definitions (e.g., from environment variables or variable files) that override the Terraform variables for tags. If the pipeline sets missing or incorrect tag values, the policy fails. Manual UI runs likely use the workspace's default variable values, which satisfy the policy. Since the configuration files are identical, the discrepancy is due to variable overrides from the pipeline, making Option B correct.

Answer

The Sentinel policy is checking the wrong workspace.

Answer

The Sentinel policy is configured to fail on all plans regardless of compliance.

Answer

The CI/CD pipeline is using an older version of Terraform that does not support Sentinel.

Question 9

A company manages multiple microservices across AWS accounts. Each service has its own Terraform configuration and state file stored in a shared S3 bucket. The team uses `terraform_remote_state` data sources to read outputs from other services' state files. A service team recently changed the output structure in their state, breaking the `terraform_remote_state` calls from other services. The affected services now show errors during plan. What is the best practice to avoid such cross-service dependency issues?

Accepted Answer

Publish service outputs to a dedicated data store (e.g., AWS SSM Parameter Store or Consul) and have other services consume those values instead of reading state directly. The best practice is to decouple services by using a dedicated data store (e.g., AWS SSM Parameter Store or Consul) as a service registry or contract. This avoids tight coupling to the internal state representation of another service. Option A correctly implements this pattern. Option D (CMDB) is overly generic and not specifically designed for Terraform state outputs. Options B and C are reactive measures, not proactive best practices.

Answer

Use versioning on the S3 bucket and revert to a previous state version

Answer

Lock the state files and require approval for any changes

Answer

Store outputs in a configuration management database and read from there

Question 10

A company uses Terraform with a remote backend (AWS S3). They want to ensure that the state file is encrypted at rest. Which configuration approach guarantees this?

Accepted Answer

Configure the S3 backend with server-side encryption enabled (e.g., 'encrypt = true' and 'kms_key_id').. The S3 backend configuration block supports the `encrypt` and `kms_key_id` arguments, which enable server-side encryption (SSE-S3 or SSE-KMS) for the state file stored in the S3 bucket. This ensures that the state file is encrypted at rest, meeting the requirement without any additional steps or external commands.

Answer

Enable encryption in the AWS provider block.

Answer

Use 'terraform state encrypt' command.

Answer

Use 'terraform init -encrypt-state' flag.

Question 11

Refer to the exhibit. A developer updates the network state and runs terraform apply. The aws_instance.web is not recreated. Which statement explains this behavior?

Accepted Answer

The instance resource does not reference the remote state data source, so changes to the remote state do not trigger recreation.. In Terraform, a resource is only recreated when its own configuration or a dependency it references changes. If aws_instance.web does not reference the terraform_remote_state data source in its arguments, changes to the remote state's outputs have no effect on the instance's desired state, so no recreation occurs.

Answer

Terraform automatically locks the remote state to prevent changes during apply.

Answer

The security group resource depends on the remote state, and it was updated, but the instance was not affected.

Answer

The remote state data source is cached and only refreshes every hour.

Question 12

An organization uses Terraform modules to provision multiple environments. They have a module 'vpc' that uses a for_each argument in the root module to create VPCs per environment. Each VPC requires a unique CIDR block passed via variable. What is the best practice to pass different CIDRs per instance?

Accepted Answer

Define a map variable with environment names as keys and CIDRs as values, then pass the entire map to the module.. The best practice is to define a map variable with environment names as keys and CIDRs as values, then pass the entire map to the module. This allows the module to use for_each over the map, creating one VPC per environment with the correct CIDR, and keeps the configuration DRY and scalable.

Answer

Hardcode the CIDR within each module block.

Answer

Use a list variable for CIDRs and reference them with count.index and element().

Answer

Use a module output to fetch the CIDR from a data source.

Question 13

A DevOps team manages Terraform configurations for a multi-environment infrastructure (dev, staging, prod). They maintain a central repository of reusable modules stored in a Git repository. Developers often update modules in the master branch to add features or fix bugs. Recently, after a developer updated the 'vpc' module in the master branch, the staging environment's infrastructure was destroyed and recreated during a terraform apply, causing an outage. The team needs to prevent such unintended changes across environments. They currently reference modules using the source argument with a git URL pointing to the master branch: source = "git::https://github.com/org/terraform-modules//vpc?ref=master". The team is looking for a solution that allows controlled updates and ensures each environment uses a fixed version of a module until explicitly upgraded.

Accepted Answer

Use module version constraints in the configuration, such as source = "git::https://github.com/org/terraform-modules//vpc?ref=v1.0.0" and update the ref tag when ready.. Pinning the module source to an immutable Git tag (e.g., ref=v1.0.0) instead of a mutable branch (ref=master) ensures each environment uses a fixed, known version of the module until the team explicitly bumps the tag. This gives controlled updates: staging and prod stay on v1.0.0 while dev can test v1.1.0, and promotion is a deliberate change to the ref. It directly prevents the outage scenario where a master-branch commit silently changed the vpc module and caused terraform apply to destroy/recreate resources.

Answer

Create separate Git branches for each environment and reference the branch in the module source.

Answer

Use Terragrunt to manage module dependencies and lock versions.

Answer

Use the Terraform Registry to host modules with semantic versioning and pin versions.

Question 14

Refer to the exhibit. An engineer runs terraform plan and sees this output. Which statement about the planned change is true?

Accepted Answer

The change will replace the existing ingress rule with a new one.. When Terraform's plan output shows an ingress rule being replaced — typically indicated by a `-/+` symbol or a `~` with a `# forces replacement` annotation on the ingress block — it means the existing rule cannot be updated in place and must be destroyed and recreated. This happens because the ingress attribute is a set of objects, and changing a set element's identity forces Terraform to remove the old element and add the new one. The security group itself remains, only the rule is swapped.

Answer

The security group will be destroyed and recreated.

Answer

Terraform will add a new ingress rule without removing the old one.

Answer

The security group will be updated but the ingress rule will remain unchanged.

Question 15

Refer to the exhibit. What is the primary purpose of the version constraint '~> 4.0'?

Accepted Answer

Allows any version in the 4.0 range including patch updates.. The version constraint '~> 4.0' uses the pessimistic version constraint operator in Terraform. It allows any version in the 4.x range, meaning versions >= 4.0 and < 5.0, including patch updates like 4.1, 4.2, etc. Therefore, option A is correct. Option B is incorrect because '= 4.0' would pin to only exact 4.0. Option C is incorrect because it includes 5.0, which is not allowed. Option D is incorrect because it allows any version 4.0 or higher, including 5.0 and beyond, which is too broad.

Answer

Allows only exact version 4.0.

Answer

Allows versions 4.0 through 5.0.

Answer

Allows any version 4.0 or higher.