TF-003 Practice Test 34 — 15 Questions

Question 1

You are a DevOps engineer for a company that uses Terraform to manage infrastructure across multiple AWS accounts (production, staging, development). Each account has its own Terraform configuration and remote state stored in an S3 bucket with DynamoDB locking. Recently, the production deployment pipeline failed with the error: 'Error: Error loading state: AccessDenied: Access Denied'. The pipeline runs under an IAM role that has been working for months. The S3 bucket policy and IAM role permissions have not been changed. However, the team did recently enable S3 bucket versioning and added a lifecycle policy to transition objects to Glacier after 30 days. The state file was last modified 35 days ago. What is the most likely cause of the error?

Accepted Answer

The state file was transitioned to Amazon S3 Glacier by the lifecycle policy, and Terraform cannot read it without restoration.. D is correct because the S3 lifecycle policy transitions objects to the Glacier storage class after 30 days. The state file was last modified 35 days ago, so it has been moved to Glacier. Terraform cannot read objects in the Glacier storage class directly; it requires a restoration (e.g., using `aws s3api restore-object`) before the state can be accessed, resulting in the 'AccessDenied' error.

Answer

The DynamoDB lock table has a stale lock from a previous deployment that is blocking read access.

Answer

The IAM role's permissions were inadvertently revoked due to a recent AWS policy change.

Answer

The S3 bucket policy now denies access to objects older than 30 days due to a new condition key.

Question 2

A company is adopting Terraform to manage its multi-cloud infrastructure on AWS and Azure. The infrastructure team has written several Terraform configurations stored in a Git repository. Each configuration is applied by different team members using their local machines. Recently, the team has been experiencing state file conflicts and inconsistencies, leading to infrastructure drift. The team currently stores the state file locally. They want to ensure that only one person can apply changes at a time and that the state file is always up-to-date. They also want to be able to collaborate effectively without overwriting each other's changes. Which approach should they implement?

Accepted Answer

Use Terraform Cloud to manage state and provide remote operations with locking.. Option A is correct because Terraform Cloud provides a managed remote state backend with built-in state locking and remote operations. This ensures that only one person can apply changes at a time (via the locking mechanism), the state file is always up-to-date (stored centrally), and team members can collaborate without overwriting each other's changes. It directly addresses the team's need for exclusive apply access and consistent state.

Answer

Have only one team member run terraform apply from a dedicated machine.

Answer

Store the state file in a shared Git repository and use git pull/push to sync changes.

Answer

Use a remote backend such as Amazon S3 with DynamoDB for state locking.

Question 3

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 4

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.. Option C is correct because `terraform import` is the proper way to bring existing resources into Terraform state. Option A is wrong because simply running apply would try to create a duplicate. Option B is wrong because manually editing the state file is error-prone and not recommended. Option D is wrong because `terraform refresh` refreshes state, but does not import new resources.

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 5

A team uses Terraform to manage infrastructure in AWS. They have a single workspace and store state in an S3 bucket with DynamoDB locking. After a recent apply, the state file became corrupted due to a network interruption during the state write. The team needs to recover the state and prevent future corruption. They have not enabled any backup or versioning. What should they do?

Accepted Answer

Enable S3 bucket versioning and DynamoDB point-in-time recovery, then use terraform state pull to retrieve a previous state version.. Option B is correct: enabling S3 bucket versioning and DynamoDB point-in-time recovery provides backup and restoration capabilities. With versioning, they can revert to a previous state version. Point-in-time recovery for DynamoDB helps recover the lock table. Then 'terraform state pull' can retrieve the good state. Option A is risky and not recommended. Option C is overly destructive and loses all state. Option D does not fix corruption.

Answer

Use terraform force-unlock to release the lock and reapply the configuration.

Answer

Manually edit the state file in S3 to fix the corruption.

Answer

Delete the state file and run terraform import for all resources.

Question 6

A developer wants to use Terraform in a CI pipeline where the pipeline runs on pull requests. They need to preview infrastructure changes without applying them. Which command should be used?

Accepted Answer

terraform plan. Option A is correct because `terraform plan` creates an execution plan that shows what actions Terraform will take to change infrastructure to match the configuration, without actually applying any changes. This is the standard command for previewing infrastructure changes in a CI pipeline triggered by pull requests, enabling developers to review proposed modifications before merging.

Answer

terraform validate

Answer

terraform init

Answer

terraform apply

Question 7

A company uses Terraform with a backend configured to store state in Azure Blob Storage. They want to view the current state of resources without performing a plan or apply. Which command should be used?

Accepted Answer

terraform state list. Option C (terraform state list) is correct because it directly queries the Terraform state file stored in Azure Blob Storage and lists all resources tracked in that state without triggering a plan or apply. This command is part of the 'terraform state' family, designed specifically for inspecting state outside the core workflow, and it requires no infrastructure changes or API calls to cloud providers.

Answer

terraform output

Answer

terraform show

Answer

terraform plan

Question 8

A team using a remote S3 backend with DynamoDB locking is experiencing frequent 'Error acquiring the state lock' messages in their CI/CD pipeline. The pipeline runs multiple concurrent jobs for different workspaces. What is the most likely cause and solution?

Accepted Answer

The same workspace is being used for concurrent runs; use separate workspaces per environment.. The error 'Error acquiring the state lock' occurs when Terraform cannot obtain a lock on the state file for a specific workspace. In this scenario, the pipeline runs multiple concurrent jobs for different workspaces, but if the same workspace is inadvertently used across concurrent runs, Terraform's DynamoDB-based locking mechanism will prevent simultaneous access to that workspace's state. The solution is to ensure each environment (e.g., dev, staging, prod) uses a separate workspace, avoiding lock contention. Option B correctly identifies this as the most likely cause and solution.

Answer

The DynamoDB table lacks sufficient read/write capacity; increase it.

Answer

The pipeline is running too many jobs; increase the lock wait time.

Answer

The S3 bucket is not versioned; enable versioning.

Question 9

After modifying a Terraform configuration file, a user runs 'terraform plan' and sees 'No changes. Infrastructure is up-to-date.' What is the most likely reason?

Accepted Answer

The configuration changes were made in a different directory.. Option D is correct because Terraform operates on the configuration files in the current working directory. If the user modified a Terraform configuration file in a different directory and then ran 'terraform plan' from the original directory, Terraform would compare the state against the unchanged configuration in the current directory, resulting in 'No changes. Infrastructure is up-to-date.'

Answer

The user forgot to run terraform init.

Answer

The configuration changes were not committed to version control.

Answer

The state is stored remotely and the user does not have access.

Question 10

Which THREE of the following are necessary steps to configure OIDC (OpenID Connect) for authenticating Terraform in a CI/CD pipeline?

Accepted Answer

Set up an OIDC provider in the target cloud (e.g., AWS IAM OIDC provider).. Option B is correct because to authenticate Terraform in a CI/CD pipeline using OIDC, you must first establish trust between the CI platform and the cloud provider by creating an OIDC identity provider (e.g., an AWS IAM OIDC provider). This provider validates the JSON Web Token (JWT) issued by the CI platform (e.g., GitHub Actions, GitLab CI) and maps it to an IAM role, enabling token-based authentication without long-lived secrets.

Answer

Generate a long-lived API token and store it as a secret.

Answer

Configure remote backend with static credentials.

Question 11

What is the purpose of the 'terraform validate' command?

Accepted Answer

To check syntax and internal consistency of configuration files.. The 'terraform validate' command checks the syntax and internal consistency of Terraform configuration files, ensuring that the code is syntactically valid and that references between resources, data sources, and variables are correctly formed. It does not interact with providers or cloud APIs, so it cannot verify credentials or run tests.

Answer

To check the validity of provider credentials.

Answer

To format Terraform configuration files.

Answer

To run unit tests on Terraform modules.

Question 12

Which TWO are benefits of using Terraform Cloud's remote operations with a CLI-driven run workflow?

Accepted Answer

Integration with version control systems for automatic plan and apply. Option A is correct because Terraform Cloud's CLI-driven run workflow allows users to trigger remote operations from the CLI, which can be integrated with version control systems (VCS) via webhooks. When a VCS repository is connected, any push to a configured branch automatically triggers a remote plan and apply, enabling continuous delivery pipelines without manual intervention.

Answer

Support for multiple cloud providers in a single workspace

Answer

Reduced dependency on local environment variables for provider authentication

Answer

Ability to execute `terraform plan -refresh-only` without a run

Question 13

A user runs 'terraform plan' and it shows 'No changes. Infrastructure is up-to-date.' However, the user knows they added a new resource block to the configuration. What could explain this?

Accepted Answer

The resource block has a count parameter set to 0.. When a resource block has `count = 0`, Terraform evaluates the count meta-argument and determines that zero instances of that resource should be created. As a result, the resource is effectively absent from the state, and `terraform plan` sees no changes because there is nothing to add, modify, or remove. This is a common cause of a 'No changes' result despite adding a new resource block.

Answer

The resource block is inside an output block.

Answer

The user ran terraform validate before plan.

Answer

The resource block was added after running terraform fmt.

Question 14

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?

Accepted Answer

Use a single configuration with separate state files and variable files for each environment. Option A is correct because 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 15

An organization uses a remote backend (S3) with DynamoDB for state locking. A developer runs `terraform plan` and gets the error: "Error acquiring the state lock: ConditionalCheckFailedException". What is the most likely cause?

Accepted Answer

Another Terraform process is currently holding the state lock. The error 'ConditionalCheckFailedException' occurs when Terraform attempts to acquire a lock in DynamoDB but the conditional write fails because the lock item already exists with a different lock ID. This indicates another Terraform process (or a stale lock) is currently holding the state lock, preventing concurrent operations to protect state integrity.

Answer

The S3 bucket does not exist

Answer

The DynamoDB table is not yet created

Answer

The Terraform version is incompatible with the backend