Use the core Terraform workflow practice questions

Terraform state locking prevented the apply from executing correctly.

Why it fails: State locking is designed to prevent multiple concurrent operations from modifying the state file simultaneously, ensuring data integrity and consistency. If a lock were active, `terraform apply` would typically either block until the lock is released or fail with an explicit locking error, preventing execution. It would not, however, cause the number of planned changes to silently diverge from a previously generated plan; the operation would simply not proceed as intended.

The state file was corrupted during the apply.

Why it fails: State file corruption would manifest as critical errors during `terraform apply`, preventing the operation from proceeding or leading to unpredictable failures due to unreadable or invalid resource definitions. Terraform would likely halt execution, reporting parsing errors or missing resource data, rather than successfully applying a different set of changes. It would not result in a successful apply with a modified count of changes; instead, it would likely abort the execution entirely.

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

Why it fails: `terraform apply` does indeed perform an implicit refresh to update the state file with the current real-world infrastructure status before proposing changes. However, this refresh primarily updates the *known state* of resources; it does not inherently alter the *desired state* defined by the configuration or the *actions* derived from it. A different number of changes would only occur if the configuration itself was modified, not merely due to a state refresh synchronizing the actual infrastructure with the state file.

Run terraform import to bring existing resources under management

Why it fails: Terraform import is a specialized command used to bring existing, manually created infrastructure under Terraform management. It is not considered a part of the *core* iterative workflow, which focuses on provisioning new resources or updating existing ones defined in configuration. Instead, `import` serves as a one-time migration tool for initial adoption or state reconciliation, rather than a regular operational step.

Run terraform output to retrieve output values

Why it fails: Terraform output is an inspection command used to display specific output values defined in the configuration, typically after an `apply` operation has completed. While useful for retrieving information about deployed infrastructure, it does not directly create, update, or destroy resources. Therefore, `terraform output` is not considered a core step in the infrastructure provisioning and management lifecycle itself.

Run terraform destroy to remove resources

Why it fails: Terraform destroy is a distinct and often final command used to explicitly remove all resources managed by a given Terraform configuration. While critical for decommissioning infrastructure, it operates outside the typical iterative cycle of planning and applying changes to *maintain* resources. The core workflow focuses on provisioning and updating, whereas `destroy` represents a separate, deliberate tear-down process.

Require manual confirmation for every terraform plan execution.

Why it fails: Requiring manual confirmation for every `terraform plan` execution is unnecessary and counterproductive. The `terraform plan` command is a read-only operation that merely previews the proposed infrastructure changes without making any modifications. Introducing a manual gate for a non-destructive command adds significant friction to CI/CD pipelines and development workflows without enhancing security or preventing actual infrastructure changes.

Store state files locally on the engineer's machine.

Why it fails: Storing Terraform state files locally on an engineer's machine is highly problematic for team environments. Local state prevents shared visibility of the infrastructure's current status, making it impossible for multiple engineers to collaborate effectively or understand the deployed resources. This approach also introduces a high risk of state drift, conflicts, and data loss if the local machine fails, compromising the integrity of the infrastructure mapping.

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

Why it fails: Always running `terraform apply` directly without first executing `terraform plan` is a dangerous practice that significantly increases the risk of unintended infrastructure changes. The `terraform plan` command provides a crucial preview of all proposed additions, modifications, and destructions, allowing for review and validation before any changes are committed. Skipping this step eliminates the opportunity to catch errors or unwanted alterations, potentially leading to costly outages or data loss.

The Terraform configuration has a syntax error.

Why it fails: A Terraform configuration syntax error would typically manifest during the `terraform plan` or `terraform apply` validation phases, often before any API calls are even attempted against AWS. Such errors are usually reported by Terraform itself, indicating issues with HCL syntax or resource block structure. The "UnauthorizedOperation" error, however, is a direct response from the AWS API, signifying that Terraform successfully parsed the configuration but AWS rejected the provisioning request due to a permission issue.

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

Why it fails: If the 't2.micro' instance type were genuinely unavailable in the specified AWS region or Availability Zone, the error message returned by AWS would explicitly indicate an issue with the instance type itself, such as "UnsupportedInstanceType" or "InsufficientInstanceCapacity". An "UnauthorizedOperation" error does not relate to resource availability but rather to the caller's authority. It implies the user lacks the permission to even check for or request that instance type.

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

Why it fails: An invalid or non-existent AMI ID would typically trigger an AWS API error like "InvalidAMIID.NotFound" or "InvalidAMIID.Malformed", clearly indicating a problem with the image identifier. The "UnauthorizedOperation" error, by contrast, signifies that the AWS credentials used do not possess the necessary IAM permissions to initiate the `ec2:RunInstances` API call, irrespective of the AMI's validity. The system is denying the action itself, not validating its parameters.

1. Run terraform import with the resource address and ID. 2. Write the resource configuration block in a .tf file. 3. Run terraform plan to verify configuration matches the real-world resource.

Why it fails: Running "terraform import" first, without a corresponding resource configuration block, will result in an error. Terraform requires a defined resource address (e.g., `aws_instance.web`) in the `.tf` files to map the external resource's attributes and schema into the state file. Without this pre-existing configuration, the import command lacks the necessary context to process the resource, making this order fundamentally incorrect.

1. Run terraform plan. 2. Write the resource configuration block in a .tf file. 3. Run terraform import with the resource address and ID.

Why it fails: Initiating the import process with "terraform plan" is ineffective because no infrastructure configuration has been defined yet, nor has any existing resource been brought under Terraform management. At this stage, "terraform plan" would simply report "No changes. Your infrastructure matches the configuration." or an error if no `.tf` files exist, providing no actionable feedback relevant to importing an existing resource. This step is premature and yields no useful information for the task.

1. Write the resource configuration block in a .tf file. 2. Run terraform plan. 3. Run terraform import with the resource address and ID.

Why it fails: While defining the resource configuration is the correct initial step, executing "terraform plan" immediately afterward is misplaced in the import workflow. Before "terraform import" is run, the resource, though configured in `.tf` files, is not yet tracked in the Terraform state. Consequently, "terraform plan" would propose creating this resource, indicating it's unmanaged, which contradicts the goal of importing an existing one. The plan should verify the *imported* state, not propose creation.

terraform init: Creates an execution plan to reach the desired state.

Why it fails: This statement incorrectly assigns the responsibility of creating an execution plan to `terraform init`. The primary function of `terraform init` is to prepare the working directory by downloading provider plugins, initializing the backend, and fetching modules. Generating a detailed execution plan, which involves analyzing configuration against current state to propose changes, is a distinct and later stage performed exclusively by the `terraform plan` command.

terraform plan: Executes the actions proposed in a plan.

Why it fails: This statement is incorrect because `terraform plan` is specifically designed to *preview* proposed infrastructure changes, not to *execute* them. The `plan` command generates a speculative execution plan, detailing what actions Terraform *would* take to reach the desired state, without making any actual modifications. The actual execution and application of these changes to the cloud infrastructure is the distinct and subsequent role of the `terraform apply` command.

In the system-wide plugin directory `/usr/share/terraform/plugins`

Why it fails: This is not the default location; the default is the .terraform directory.

In the user's home directory under `~/.terraform.d/plugins`

Why it fails: This is the plugin cache directory, not the default working directory location.

In a temporary directory that is deleted after `terraform init` completes

Why it fails: Plugins persist after init; they are not deleted.

Another user ran `terraform destroy` without the engineer's knowledge

Why it fails: If another user had successfully executed `terraform destroy` for the resource, that resource would have been removed from both the cloud provider and the Terraform state file. A subsequent `terraform plan` would then find no record of the resource in the state and no corresponding resource in the cloud to destroy. Therefore, it would not plan to destroy a resource that no longer exists in either location.

The state file was corrupted and lost the resource

Why it fails: A corrupted or lost state file means Terraform no longer has a record of the managed resource, even if it still exists in the cloud provider. When `terraform plan` is run, it would compare the configuration, which still defines the resource, against an empty or incomplete state. Terraform would then perceive the resource as needing to be *created* to match the configuration, not destroyed, because it's missing from its internal tracking.

The resource was manually deleted from the cloud provider console

Why it fails: If a resource was manually deleted directly from the cloud provider console, Terraform's state file would still indicate that the resource *should* exist. Upon running `terraform plan`, Terraform would detect this drift between its recorded state and the actual infrastructure. It would then propose to *re-create* the missing resource to bring the cloud environment back into alignment with the configuration and state, rather than attempting to destroy something already gone.

Modify the configuration to match the destroyed resource and run `terraform import`

Why it fails: Running `terraform import` is designed to bring *existing* infrastructure resources under Terraform's management by associating them with a configuration block and updating the state file. Since the critical resource was accidentally destroyed, it no longer exists in the cloud provider. Therefore, there is nothing for `terraform import` to attach to, making this action ineffective for recreation.

Use `terraform force-unlock` to unlock the state and then run `terraform plan`

Why it fails: `terraform force-unlock` is specifically used to remove a stale state lock that might be preventing further Terraform operations. This command addresses issues with concurrent access to the state file, not the actual presence or absence of infrastructure resources in the cloud provider. Unlocking the state will not magically restore a destroyed resource, nor will running `terraform plan` afterwards initiate any recovery process for a physically missing resource.

Run `terraform state rm` to remove the destroyed resource from state and then re-import it

Why it fails: Removing the destroyed resource from state with `terraform state rm` and re-importing it fails because the resource is already physically destroyed in the cloud provider — `terraform import` requires the resource to exist in the real infrastructure to attach state to it. This option is tempting because `terraform state rm` is correctly used to detach a resource from state without destroying it, and re-importing works when the resource still exists but state is missing or corrupted.

It can be used to destroy infrastructure if the `-destroy` flag is set

Why it fails: The `terraform plan -destroy` command generates a speculative execution plan that outlines which infrastructure resources would be destroyed if the plan were applied. However, it is crucial to understand that `terraform plan` itself is a read-only operation and never modifies the actual infrastructure. To execute the destruction outlined in such a plan, a subsequent `terraform apply` command, typically referencing the saved destroy plan, is explicitly required.

It applies changes to infrastructure

Why it fails: The `terraform plan` command is designed solely to compute and display the proposed changes to infrastructure based on the current configuration and state. It performs a dry run, showing what *would* happen without actually making any modifications to the real-world resources. The actual application of these changes, including creation, modification, or deletion of resources, is exclusively handled by the `terraform apply` command.

It requires no configuration files in the directory

Why it fails: Terraform requires configuration files, typically ending with the `.tf` extension, to define the desired state of the infrastructure. The `terraform plan` command reads these files to understand the resources and their configurations, comparing them against the current state. Without valid configuration files in the working directory, Terraform cannot determine the intended infrastructure and therefore cannot generate a plan.

Force unlock the state lock

Why it fails: `terraform state` does not include a subcommand for forcing a state unlock. The `terraform force-unlock` command is a top-level command used independently to release an orphaned or stale state lock, often after a failed apply or plan operation. It requires a lock ID to ensure that only specific, known locks are released, preventing unintended concurrent state modifications.

Import an existing resource into state

Why it fails: Importing existing resources into Terraform state is handled by the top-level `terraform import` command, not a subcommand of `terraform state`. The `terraform import` command requires specifying the target resource address in the configuration and the ID of the existing infrastructure object. Its purpose is to bring unmanaged infrastructure under Terraform's control, which is distinct from merely manipulating the state file's contents.

-refresh=false

Why it fails: Although `-refresh=false` is a valid flag for `terraform apply`, it is not among the three options expected by the exam.

Set the environment variable TF_PLUGIN_CACHE_DIR to a shared path.

Why it fails: This works, but the CLI configuration is more reliable and persistent.

Copy the .terraform folder from a previous job.

Why it fails: This is brittle and can lead to incompatible provider versions.

Use terraform providers lock to freeze versions.

Why it fails: This locks provider versions but does not cache the downloads.

When applying a saved plan file, Terraform will still prompt for confirmation unless -auto-approve is also specified.

Why it fails: When you pass a saved plan file to terraform apply, Terraform does not prompt for confirmation. It applies the plan immediately because the plan file already represents an approved set of changes. Adding -auto-approve is unnecessary and has no effect in this context, so this statement is incorrect.

The saved plan file is human-readable and can be edited to remove specific resource changes before applying.

Why it fails: A saved plan file is a binary artifact and is not meant to be edited manually. Modifying it would invalidate its integrity and could cause errors or unexpected behavior. Terraform expects the plan file to be used exactly as generated, so editing it is not a supported practice.

Applying a saved plan file bypasses the need to run terraform init as long as the backend configuration has not changed.

Why it fails: Terraform init is required to initialize the working directory, download providers, and configure the backend. Even if the backend configuration has not changed, init ensures that the environment is properly set up. Skipping init can lead to errors when applying a plan file, so this statement is false.

The state file was corrupted and Terraform performed a refresh.

Why it fails: A `terraform refresh` command, or the implicit refresh during `terraform plan` or `apply`, updates the Terraform state file to reflect the current actual state of resources in the cloud. While a corrupted state file could lead to unexpected behavior, a refresh operation itself is designed to *read* the current infrastructure and update the state, not to *modify* or remove resources from the remote system. Therefore, a refresh alone would not cause a security group rule to be removed.

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

Why it fails: If the Terraform configuration files were modified to remove the security group rule *after* a successful `apply` operation, the rule would not be immediately removed from the infrastructure. The next `terraform plan` would then show that the rule is slated for destruction, and only a subsequent `terraform apply` command, executed *after* the configuration change, would actually perform the removal. The scenario describes the rule being removed *during* an apply, not as a result of a prior configuration change.

The developer accidentally ran 'terraform destroy' instead.

Why it fails: The `terraform destroy` command is specifically designed to tear down *all* resources managed by the current Terraform configuration within the workspace. If `terraform destroy` had been executed, it would have attempted to remove the entire infrastructure defined in the configuration, not just a single, newly added security group rule. The question implies only a specific rule was removed, making a full `destroy` operation an unlikely cause.

Run 'terraform plan' to see the detailed error.

Why it fails: terraform plan primarily focuses on generating an execution plan by comparing the desired state with the current infrastructure and validating HCL syntax. It does not typically perform deep API-level validation of resource attributes like IAM policy JSON content for correctness against the cloud provider's schema or grammar. Policy validation errors, especially those related to malformed JSON or invalid policy statements, are usually encountered during the terraform apply phase when the provider attempts to send the policy to the cloud API.

Use 'terraform console' to test the policy string.

Why it fails: terraform console is an interactive command-line tool designed for evaluating Terraform expressions, interpolating variables, and testing logic within the configuration. While it can confirm if a string is valid JSON from a pure HCL perspective (e.g., jsondecode("...")), it lacks the capability to validate the semantic correctness or API-specific schema of an IAM policy document against a cloud provider's requirements. It cannot simulate the provider's API call to check policy validity.

Upgrade to the latest Terraform version.

Why it fails: Upgrading to the latest Terraform version is unlikely to resolve an issue stemming from a malformed IAM policy string within the configuration. Terraform version updates primarily address core CLI functionality, HCL language features, or provider compatibility, not the correctness of user-supplied data like JSON policy documents. A syntax error in the policy itself is a configuration issue, not a bug or limitation of the Terraform CLI version.

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

Why it fails: Running 'terraform show' merely outputs the current state to the console, providing an ephemeral snapshot. It does not persist this information or create a historical record of changes over time. Manually capturing and storing this output after every run would be inefficient, prone to human error, and would not constitute a reliable, auditable history of Terraform runs.

Add the state file to version control after each run.

Why it fails: Adding the 'terraform.tfstate' file directly to version control is a widely discouraged practice. State files often contain sensitive data and are frequently updated, leading to merge conflicts, unreadable diffs, and potential exposure of secrets. This method lacks the crucial features of state locking, atomicity, and secure storage provided by dedicated remote backends, making it unsuitable for robust team collaboration and historical tracking.

Enable state locking in the backend configuration.

Why it fails: Enabling state locking in a backend configuration is designed to prevent concurrent 'terraform apply' operations from corrupting the state file. Its primary function is to ensure atomicity and consistency during active modifications, not to provide a historical record or versioning of the state itself. While vital for team collaboration, locking does not store previous state versions or offer an audit trail of infrastructure changes over time.

terraform fmt

Why it fails: terraform fmt is a utility command used to rewrite Terraform configuration files to a canonical format and style. While highly recommended for maintaining consistency and readability across a team's codebase, it does not directly interact with the infrastructure state or define the lifecycle of resources. Therefore, terraform fmt is considered a development aid rather than an integral step in the core workflow of provisioning or managing infrastructure.

terraform validate

Why it fails: terraform validate performs checks on the configuration files to ensure they are syntactically valid and internally consistent, verifying correct attribute names, types, and module usage. While essential for catching errors early in the development cycle, it does not interact with the remote state or propose infrastructure changes. Consequently, terraform validate is considered a preparatory command, distinct from the core workflow steps that involve interacting with the actual infrastructure.

terraform destroy

Why it fails: terraform destroy is a command used to tear down all resources managed by a given Terraform configuration, effectively reversing the provisioning process. While it interacts with infrastructure, it represents a distinct and often irreversible workflow for decommissioning resources, rather than being part of the routine creation and management cycle. The core workflow focuses on bringing infrastructure to a desired state, whereas destroy explicitly removes that infrastructure.

To import existing infrastructure into Terraform management.

Why it fails: terraform refresh is designed to synchronize the existing state file with the current reality of resources already managed by Terraform. It does not possess the functionality to bring unmanaged, pre-existing infrastructure into Terraform's control; that specific task is handled exclusively by the terraform import command, which requires mapping existing resources to configuration blocks.

To update the Terraform configuration with current resource settings.

Why it fails: terraform refresh interacts solely with the Terraform state file, updating its contents to reflect the current attributes of managed infrastructure resources. It explicitly does not modify the .tf configuration files. The configuration files are the desired state definition, which users manually author; refresh only ensures the recorded actual state aligns with reality, not that the desired state definition changes.