TF-004 Use the core Terraform workflow Practice Test 2 — 15 Questions

Question 1

A DevOps engineer is troubleshooting a failed 'terraform apply'. The error message says: 'Error: Error applying IAM policy: The policy failed validation'. The IAM policy is defined using HCL in a JSON-encoded string. What is the most efficient way to debug this issue?

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

Accepted Answer

Use a JSON validator tool to check the policy string in the configuration.. The error 'The policy failed validation' indicates that the JSON-encoded IAM policy string in the Terraform configuration is malformed or violates AWS IAM policy syntax. Using a JSON validator tool (e.g., `jq`, online validator, or `aws iam simulate-custom-policy`) directly checks the string's structure and compliance with AWS IAM policy schema, which is the most efficient first step before re-running Terraform. This isolates the issue from Terraform's execution logic and avoids unnecessary plan/apply cycles.

Answer

Run 'terraform plan' to see the detailed error.

Answer

Use 'terraform console' to test the policy string.

Answer

Upgrade to the latest Terraform version.

Question 2

A team wants to ensure that all Terraform runs are recorded for audit purposes. Which practice should they implement?

Accepted Answer

Configure a remote backend that supports state versioning.. Configuring a remote backend that supports state versioning (e.g., Terraform Cloud, S3 with versioning enabled) automatically records every state change, providing a complete audit trail of all Terraform runs. This ensures that previous state snapshots are preserved and can be reviewed or restored if needed, meeting audit requirements without manual intervention.

Answer

Run 'terraform show' after every apply to capture state.

Answer

Add the state file to version control after each run.

Answer

Enable state locking in the backend configuration.

Question 3

Which TWO actions are part of the core Terraform workflow? (Choose two.)

Accepted Answer

terraform plan. The core Terraform workflow consists of three main steps: `terraform init` to initialize the working directory, `terraform plan` to preview changes, and `terraform apply` to execute those changes. Option B (`terraform plan`) is correct because it creates an execution plan showing what actions Terraform will take to reach the desired state defined in configuration files. Option D (`terraform apply`) is correct because it applies the changes required to reach the desired state, either by using a previously generated plan or by creating a new plan and prompting for approval.

Answer

terraform fmt

Answer

terraform validate

Answer

terraform destroy

Question 4

Which THREE of the following are valid reasons to use 'terraform refresh'? (Choose three.)

Accepted Answer

To update the state file when resources were deleted outside of Terraform.. The `terraform refresh` command updates the state file to match real-world infrastructure. Option A is correct because if resources were deleted outside Terraform, refresh removes them from state. Option B is correct because refresh detects drift by comparing state with actual infrastructure. Option D is correct because manual changes to resources are recorded in state after refresh. Option C is incorrect because importing infrastructure requires `terraform import`, not refresh. Option E is incorrect because refresh updates the state file, not the Terraform configuration.

Answer

To import existing infrastructure into Terraform management.

Answer

To update the Terraform configuration with current resource settings.

Question 5

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 6

A team is using Terraform for infrastructure as code. They want to ensure that the state file is stored securely and can be accessed by multiple team members. Which backend type should they use?

Accepted Answer

Remote backend such as Amazon S3 with DynamoDB state locking. A remote backend like Amazon S3 with DynamoDB state locking provides secure, centralized storage for the Terraform state file and enables state locking to prevent concurrent modifications. This setup ensures that multiple team members can safely access and update the state without conflicts, while S3 offers encryption and access control. Local backends or network shares lack these locking and security features, making them unsuitable for team collaboration.

Answer

The -state flag pointing to a network share

Answer

Using the -lock=false flag

Answer

Local backend with .terraform directory version-controlled

Question 7

An operator runs terraform apply and receives the exhibit error. The instance was created but Terraform reports a failure. What is the most likely cause?

Accepted Answer

A provisioner block is configured to wait for SSH, but the instance is not reachable. The error indicates that the instance was created successfully but Terraform reports a failure during the apply phase. This typically occurs when a provisioner block (e.g., file or remote-exec) is configured to wait for SSH connectivity, but the instance is not reachable within the timeout period. Terraform marks the resource as 'tainted' and reports a failure, even though the cloud resource itself was provisioned.

Answer

The state file is locked and cannot be updated

Answer

The AMI ID is incorrect and the instance failed to boot

Answer

The AWS API returned an error during instance creation

Question 8

A company uses Terraform to manage infrastructure in multiple AWS accounts. An engineer runs terraform plan and sees that a security group rule will be updated, but the change is not intended. The engineer wants to understand why Terraform is proposing the change without affecting other resources. Which approach should the engineer take to troubleshoot?

Accepted Answer

Run terraform plan -out=plan.tfplan and then terraform show plan.tfplan.. `terraform plan -out=plan.tfplan` saves the plan to a binary file, and `terraform show plan.tfplan` then displays the full plan details, including the exact attribute-level diff and the reason for the change (e.g., a drift between the configuration and the state). This allows the engineer to inspect the proposed change without applying it, isolating the root cause without affecting other resources.

Answer

Run terraform state list to review the current state.

Answer

Run terraform show to display the current state.

Answer

Run terraform validate to check for configuration errors.

Question 9

Which three of the following are required steps in the core Terraform workflow for managing infrastructure? (Choose three.)

Accepted Answer

Write Terraform configuration files that define the desired state of resources.. The core Terraform workflow consists of three essential steps: writing configuration files to define the desired state, running `terraform init` to initialize the working directory and download provider plugins, and running `terraform plan` to review the execution plan before applying changes. These steps form the fundamental 'write, plan, apply' cycle that Terraform uses to manage infrastructure declaratively. Without these, you cannot safely or correctly provision resources.

Answer

Run terraform validate to check configuration syntax before initializing the backend.

Answer

Run terraform destroy to remove all managed resources after every apply.

Answer

Run terraform fmt to automatically fix formatting issues in configuration files.

Question 10

Which of the following statements about the core Terraform workflow (Write, Plan, Apply) are correct? (Choose all that apply. There are four correct answers.)

Accepted Answer

The `terraform plan` command creates an execution plan showing what actions Terraform will take to reach the desired state described in the configuration.. The core Terraform workflow consists of three phases: Write, Plan, and Apply. During the Write phase, you define your desired infrastructure in `.tf` configuration files, which can include variables, data sources, and modules. The `terraform plan` command creates an execution plan that shows what actions Terraform will take to reach that desired state. The `terraform apply` command can use a saved plan from `terraform plan -out` without additional flags, or if no plan is provided, it will automatically generate and execute a new plan. This workflow ensures that changes are reviewed before being applied, reducing the risk of unintended modifications.

Answer

If a `terraform plan` shows that a resource will be destroyed and recreated, the state file is immediately updated to reflect this planned change before apply.

Answer

The `terraform apply` command can be used to destroy infrastructure by passing a plan that includes only destroy operations, but the more common approach is to use `terraform destroy`.

Question 11

A user runs 'terraform plan' and the output includes a change that adds a new resource. However, the user expected the change to modify an existing resource. What is the most likely cause?

Accepted Answer

The resource name or type was changed in the configuration.. When a resource's name or type is changed in the configuration, Terraform interprets it as a request to destroy the old resource and create a new one, because Terraform maps each resource block to a state entry using its resource type and name (e.g., `aws_instance.web`). The plan output will show a `+` (create) for the new resource and a `-` (destroy) for the old one, rather than a `~` (update in-place). This matches the user's observation of a new resource being added instead of the expected modification.

Answer

The provider version was updated.

Answer

A required attribute was added to the resource block.

Answer

The state file was manually deleted.

Question 12

During 'terraform apply', a user receives an error: 'Error: Error creating resource: Resource already exists'. The resource does not appear in the Terraform state. What is the most likely cause?

Accepted Answer

The resource was manually created outside of Terraform before the apply.. The error 'Resource already exists' indicates that the resource was created outside of Terraform's management (e.g., manually via the cloud console or CLI). Since the resource does not appear in the Terraform state, Terraform attempts to create it during 'terraform apply', but the underlying API rejects the request because the resource already exists in the cloud provider. This is a common state drift scenario where the real-world infrastructure is out of sync with the Terraform state.

Answer

The state file was migrated from a different backend and the resource is duplicated.

Answer

The resource was removed from the configuration but not from state.

Answer

The user forgot to run terraform refresh before apply.

Question 13

A team is using Terraform with multiple environments (dev, staging, prod) and wants to use separate state files. They are considering workspaces. A senior engineer suggests using separate directory structures instead of workspaces for prod. What is the strongest reason for this recommendation?

Accepted Answer

Workspaces share the same backend configuration, increasing the risk of accidental changes to production.. Workspaces share the same backend configuration, meaning all workspaces (including prod) use the same state storage location and access controls. This increases the risk of accidental changes to production because a single backend misconfiguration or a mistaken workspace switch can lead to unintended modifications to the production state file. Separate directory structures allow for independent backend configurations, enabling stricter access controls and isolation for production.

Answer

Workspaces cannot isolate state files.

Answer

Workspaces make it harder to refactor configurations.

Answer

Workspaces do not support state locking.

Question 14

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.. 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 15

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.