TF-003 Use the core Terraform workflow — 30 Questions

Question 1

A team uses Terraform to manage infrastructure. After running 'terraform apply', a developer notices that a new security group rule was added, but then immediately removed. What is the most likely cause?

Accepted Answer

The security group rule was added manually and Terraform removed it to match the configuration.. Option A is correct because Terraform operates on a desired-state model: it compares the configuration in `.tf` files against the real-world infrastructure and the state file. If a security group rule was added manually outside of Terraform, Terraform detects it as a drift during the next `apply` and removes it to reconcile the actual state with the declared configuration. This is the core behavior of Terraform's lifecycle management.

Answer

The state file was corrupted and Terraform performed a refresh.

Answer

The configuration was changed to remove the rule after the apply.

Answer

The developer accidentally ran 'terraform destroy' instead.

Question 2

During a 'terraform plan', you see the following output: 'Plan: 1 to add, 2 to change, 0 to destroy.' However, after running 'terraform apply', the actual number of resources changed is different. What is the most likely reason?

Accepted Answer

The configuration was modified after the plan was generated.. The plan is based on the state and configuration at the time of planning. If someone else applies changes concurrently or if the configuration changes between plan and apply, the plan becomes stale. Option A is wrong because refreshing state doesn't change the plan. Option C is wrong because 'terraform apply' does not modify configuration. Option D is wrong because locking prevents concurrent applies but doesn't cause discrepancy if the plan is still valid.

Answer

Terraform state locking prevented the apply from executing correctly.

Answer

The state file was corrupted during the apply.

Answer

The 'terraform apply' command includes an implicit refresh that changes the plan.

Question 3

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?

Accepted Answer

Use a JSON validator tool to check the policy string in the configuration.. Option C is correct because 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 4

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.. Option D is correct because 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 5

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 6

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.. Option A is correct because `terraform refresh` updates the state file to reflect the current real-world infrastructure, including resources that were deleted outside of Terraform. This ensures the state file accurately represents the actual infrastructure, preventing drift and allowing Terraform to plan correctly.

Answer

To import existing infrastructure into Terraform management.

Answer

To update the Terraform configuration with current resource settings.

Question 7

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.. Option D is correct because 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 8

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. Option D is correct because 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 9

Which TWO of the following are valid steps in the core Terraform workflow?

Accepted Answer

Run terraform init to initialize the working directory and download providers. Option B is correct because `terraform init` is the first step in the core Terraform workflow, which initializes the working directory, downloads the required provider plugins, and sets up the backend configuration. Without this step, subsequent commands like `terraform plan` or `terraform apply` cannot function, as the providers and state backend are not yet configured.

Answer

Run terraform import to bring existing resources under management

Answer

Run terraform output to retrieve output values

Answer

Run terraform destroy to remove resources

Question 10

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 11

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.. Option D is correct because `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 12

A team is adopting Terraform for infrastructure deployment. They want to ensure that the core workflow (write, plan, apply) is followed effectively. Which two practices should they adopt? (Choose two.)

Accepted Answer

Store Terraform configurations in a version control system like Git.. Option A is correct because storing Terraform configurations in a version control system like Git ensures that the 'write' phase is collaborative, auditable, and repeatable. It enables teams to track changes, roll back to previous versions, and enforce code review before applying infrastructure changes, which is a core DevOps practice for the Terraform workflow.

Answer

Require manual confirmation for every terraform plan execution.

Answer

Store state files locally on the engineer's machine.

Answer

Always run terraform apply directly without terraform plan to save time.

Question 13

What is the most likely cause of this error?

Accepted Answer

The AWS credentials used do not have permission to launch EC2 instances.. The error is most likely caused by insufficient AWS permissions because Terraform uses the configured AWS credentials to make API calls. If the IAM user or role lacks the `ec2:RunInstances` permission, the API will return an authorization error, even if the configuration is syntactically correct and the AMI/instance type are valid.

Answer

The Terraform configuration has a syntax error.

Answer

The instance type 't2.micro' is not available in the region.

Answer

The AMI ID is invalid or does not exist in the region.

Question 14

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

Accepted Answer

Run terraform plan to review the execution plan before applying changes.. 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 fmt to automatically fix formatting issues in configuration files.

Answer

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

Answer

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

Question 15

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

Running `terraform plan` is strictly optional before `terraform apply` because apply will automatically generate and execute a plan if none is provided.. 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 16

Drag and drop the steps to import existing infrastructure into Terraform state in the correct order.

Question 17

Match each Terraform workflow stage to its description.

Question 18

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 19

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.. Option D is correct because 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 20

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.