TF-004 Practice Test 22 — 15 Questions

Question 1

Your team is developing a custom module for creating EC2 instances with attached EBS volumes. The module variables are: instance_type (default "t2.micro"), ami (required), volume_size (default 8), volume_type (default "gp2"). Another team uses this module to create a web server. In their root module, they call the module without any explicit instance_type override, but they do set other variables. After applying, the web server is created with instance_type "t2.nano" instead of the expected "t2.micro". They confirm that the module still has the default "t2.micro". What is the most likely explanation?

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

Accepted Answer

The root module has a variable called instance_type set to "t2.nano" that is being passed to the module.. In Terraform, when a module is called, any variable with the same name in the root module that is explicitly passed to the module block (e.g., instance_type = var.instance_type) will override the module's default value, even if the module itself has a default. The root module likely declared a variable instance_type with a default of 't2.nano' and is passing it to the module call. Option A is incorrect because the module's default is 't2.micro', not 't2.nano'. Option B is incorrect because if the variable is not defined in the module's variables.tf, passing it would cause an error; it cannot fall back to an AWS provider default. Option D is incorrect because the scenario explicitly states the module default remains 't2.micro'.

Answer

The module's instance_type variable uses a default that is "t2.nano" but the root module overrode it with a variable from its own context.

Answer

The instance_type variable is not defined in the module's variables.tf, so it uses a default from the AWS provider.

Answer

The module's variable default was changed to "t2.nano" in a new version.

Question 2

Which THREE of the following are best practices for managing Terraform state?

Accepted Answer

Use remote backends to store state files. Remote backends (e.g., S3, Azure Storage, Terraform Cloud) store state outside the local filesystem, enabling team collaboration, durability, and integration with state locking and encryption. This prevents loss of state due to local machine failure and ensures all team members work from the same state file, which is critical for consistent infrastructure management.

Answer

Edit state files directly to fix drift

Answer

Store state files locally to avoid network latency

Question 3

A developer has a Terraform configuration that includes an output block. They run `terraform apply` and then want to quickly retrieve the output value without re-running the entire apply. Which command should they use?

Accepted Answer

terraform output. The `terraform output` command is specifically designed to retrieve the values of output variables from the state file without re-running the entire `terraform apply` operation. It reads the outputs stored in the Terraform state after a successful apply, making it the fastest and most direct way to access those values. This command supports flags like `-json` for structured output and can target a specific output by name.

Answer

terraform plan

Answer

terraform state list

Answer

terraform show

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

A developer runs `terraform apply` and receives the error: 'Error acquiring the state lock'. Another engineer is currently running `terraform plan`. What should the developer do?

Accepted Answer

Wait for the lock to be released automatically. Terraform uses a state locking mechanism to prevent concurrent modifications that could corrupt the state file. When another engineer is running `terraform plan`, the lock is held for the duration of the plan to ensure consistency. The lock will be automatically released once the plan completes or times out, so waiting is the appropriate action.

Answer

Run terraform init to reinitialize the backend

Answer

Run terraform force-unlock with the lock ID

Answer

Run terraform plan with -lock=false to bypass the lock

Answer

Delete the lock file from the S3 bucket

Question 8

You are a DevOps engineer at a large e-commerce company. The infrastructure team uses Terraform to manage AWS resources across multiple accounts. Recently, they introduced a new module that creates an S3 bucket with a bucket policy. The module is used in several environments (dev, staging, prod). After merging a pull request that updates the bucket policy to grant cross-account access to a new partner account, the 'terraform apply' in the dev environment fails with: 'Error: Error putting S3 policy: AccessDenied: Access Denied'. The team is using a remote backend (S3) with DynamoDB locking. The CI/CD pipeline runs as an IAM role with permissions to manage infrastructure. The module uses 'aws_iam_policy_document' data source to construct the policy. The error occurs only in dev, not staging or prod. What is the most likely cause and the correct course of action?

Accepted Answer

Check the IAM permissions associated with the dev environment's role to ensure it has 's3:PutBucketPolicy' on the bucket.. The error 'AccessDenied' when calling 's3:PutBucketPolicy' indicates the IAM role used by the CI/CD pipeline in the dev environment lacks the necessary permission to apply the bucket policy. The module uses 'aws_iam_policy_document' to construct the policy, which is validated at plan time, so syntax errors would surface earlier. The fact that the error occurs only in dev, not staging or prod, points to an environment-specific IAM permissions issue rather than a policy syntax or state locking problem.

Answer

Verify that DynamoDB state locking is not causing the error.

Answer

Run 'terraform validate' to check the policy document syntax.

Answer

Check the bucket policy for syntax errors by comparing with staging and prod.

Question 9

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.. Use `terraform import` to import the existing security group into state. `terraform import` is the proper way to bring existing resources under Terraform management. Option A is incorrect because running `terraform apply` would attempt to create a duplicate security group, resulting in an error or duplicate resource. Option B is incorrect because manually editing the Terraform state file is error-prone and not recommended. Option C is incorrect because `terraform refresh` updates the state with the current state of resources already in the state file, but does not import new resources; it would not detect the manually created security group.

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 10

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 11

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 12

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 13

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 14

Refer to the exhibit. A user runs 'terraform plan' and sees this output. However, when they run 'terraform apply', they get an error: 'Error creating EC2 instance: UnauthorizedOperation: You are not authorized to perform this operation.' The user's IAM permissions allow ec2:RunInstances. What is the most likely missing permission?

Accepted Answer

ec2:CreateNetworkInterface. Creating an EC2 instance often requires permissions for related resources like network interfaces, security groups, etc. The error 'UnauthorizedOperation' despite having ec2:RunInstances suggests missing permissions for other actions. Option A is correct because the instance might require a subnet and network interface, and without ec2:CreateNetworkInterface permission, the operation fails.

Answer

iam:PassRole

Answer

ec2:TerminateInstances

Answer

ec2:DescribeInstances

Question 15

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.