Use the core Terraform workflow practice questions

Terraform state locking prevented the apply from executing correctly.

Why wrong: 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 wrong: 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 wrong: `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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

terraform state push

Why wrong: The `terraform state push` command is an operational utility used to manually upload a local state file to a configured remote backend. It is not a method for *managing* where the state file is stored or how it's accessed by Terraform itself. Instead, it's a specific action performed *on* an existing state management configuration, typically for recovery or explicit synchronization, assuming a backend is already in place.

terraform state mv

Why wrong: The `terraform state mv` command is used to move or rename resources *within* the Terraform state file, or to move resources between different state files. It is an administrative command for refactoring infrastructure managed by Terraform, not a method for defining how or where the state file itself is stored or managed by Terraform's backend configuration. It operates on the contents of the state, not its storage mechanism.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: `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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: This option is incorrect because `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 wrong: This option is incorrect because 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.

Validate the configuration.

Why wrong: While `terraform init` performs initial parsing of configuration files to identify providers and modules, its core responsibility does not include comprehensive validation. The detailed syntax and semantic checks, such as verifying resource arguments, variable declarations, and output references, are specifically handled by the `terraform validate` command. `init` primarily focuses on preparing the environment rather than ensuring the correctness of the infrastructure definition itself.

Create the state file.

Why wrong: The `terraform.tfstate` file, which records the mapping between real-world infrastructure and your configuration, is not created by `terraform init`. Instead, this crucial file is generated and populated during the execution of `terraform apply`, once resources have been successfully provisioned or modified. `init` merely prepares the *location* or *backend* where this state file will eventually be stored or retrieved from, ensuring the mechanism for state management is ready.

Generate a plan.

Why wrong: Generating an execution plan is a distinct and complex operation performed exclusively by the `terraform plan` command. This process involves refreshing the state, comparing the desired configuration with the current infrastructure, and outlining the precise actions (create, update, delete) Terraform proposes to take. `terraform init` establishes the foundational environment, but it does not perform the resource reconciliation or change detection necessary to produce an execution plan.

-refresh=false

Why wrong: 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 wrong: This works, but the CLI configuration is more reliable and persistent.

Copy the .terraform folder from a previous job.

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

Use terraform providers lock to freeze versions.

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

The state file was corrupted and Terraform performed a refresh.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Verify that DynamoDB state locking is not causing the error.

Why wrong: Locking errors would show a different message about acquiring lock.

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

Why wrong: The error is an API access denied, not a syntax error.

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

Why wrong: Staging and prod succeeded, so syntax is likely correct.