Terraform generates a plan that reflects all differences between configuration and state before applying changes. In a typical Terraform workflow, the entire dependency graph is evaluated and applied at once. The -target command-line option changes that default behavior by constraining planning and applying to a specific resource, module, or collection of resources. Targeting is presented as a troubleshooting mechanism for recovering from errors, partial failures, or situations where state has become out of sync with real infrastructure due to network failure, upstream cloud platform problems, or bugs in Terraform or its providers. HashiCorp explicitly recommends using resource targeting only for exceptional situations, not as a default deployment strategy.
The option is invoked on terraform plan, terraform apply, and terraform destroy. It tells Terraform to focus on just part of the dependency graph. This focus can accelerate changes in large deployments and isolate one-off fixes, but it also introduces the risk of partial updates, skipped changes, and long-term drift if it becomes part of routine workflows. The warning emitted by Terraform when targeting is active reflects this risk: Resource targeting is in effect, and the result of this plan may be incomplete.
What Is Target in Terraform
The -target flag tells Terraform to plan, apply, or destroy a specific resource or module instead of the entire configuration.
The flag accepts a resource address in the form <module_path>.<resource_identifier>. For a resource defined at the root, the address is type.name. For a resource inside a module, the address is module.module_name.type.name. Terraform will also apply changes to all resources that depend on that module, so the dependency graph is still partially evaluated outward from the targeted node.
The impact for operators is immediate. Teams with large configurations containing hundreds of resources can reduce plan time and apply risk by isolating a single change. In practice, this is useful for troubleshooting errors, accelerating changes in large deployments, and performing one-off fixes. The consequence is also immediate: Terraform will not evaluate resources outside the targeted subgraph, which means changes to those resources will be silently skipped in that run. Skipped changes accumulate as drift.
Contextually, -target sits alongside normal Terraform workflow as an override. Without the -target option, terraform plan, terraform apply or terraform destroy would take the entire configuration into account rather than a specific resource or set of Terraform resources.
How Targeting Works With Dependencies and depends_on
Targeting does not operate in isolation. Terraform must maintain a valid dependency graph.
If the targeted resource contains a depends_on meta-argument, Terraform must also include those dependencies to maintain a valid dependency graph. The depends_on meta-argument forces Terraform to treat the dependency as a required prerequisite, even if the configuration or resource type does not naturally require it.
In HCP Terraform, targeting is expressed via the TF_CLI_ARGS_plan environment variable with the value -target=resource.address. The same address syntax applies to CLI usage.
Behavior of -target with depends_on:
- The user expects only the targeted resource to be created.
- Actual behavior is that Terraform also includes the explicit dependency in the plan, even though only the targeted resource was specified.
Example scenario from reference material:
hcl
resource "random_pet" "name1" {
length = "15"
separator = "-"
depends_on = [ random_pet.name2 ]
}
resource "random_pet" "name2" {
length = "8"
separator = "-"
}
resource "random_pet" "name3" {
length = "8"
separator = "-"
}
If random_pet.name1 is targeted for creation, Terraform will also include random_pet.name2 in the plan because of the explicit depends_on. random_pet.name3 remains untouched because it is not part of the dependency chain.
The impact layer for practitioners is that explicit dependencies expand the targeting scope unexpectedly. An operator who believes they are isolating a single resource can inadvertently create or modify additional resources. This can cause unexpected behavior, especially when combined with explicit dependencies such as depends_on.
Contextually, this reinforces HashiCorp's guidance that targeting is high-risk and intended only for exceptional use cases. The warning about resource targeting being in effect is emitted precisely because the plan result may be incomplete or expanded beyond the user's explicit selection.
Targeting Individual Resources
Targeting individual resources can be useful for troubleshooting errors, but should not be part of your normal workflow.
The format for targeting a resource is the full resource address. For example:
bash
terraform apply -target=azurerm_linux_virtual_machine.example
In this command, azurerm_linux_virtual_machine.example is the resource identifier of the Virtual Machine instance resource. Terraform will plan and apply changes only for that resource and its dependencies.
When targeting a resource defined inside a module, the address includes the module path:
bash
terraform apply -target=module.vm.azurerm_linux_virtual_machine.example
In this command, the module is called vm, and the resource identifier is azurerm_linux_virtual_machine.example. Terraform will apply changes to the VM when defined in that module only and ignore all other resources.
Impact: Operators can recover from a failed apply affecting a single resource without reprocessing unrelated resources. The trade-off is that any resources that depend on the targeted resource may be left in an inconsistent state, and changes to other resources are deferred, increasing drift risk.
Contextually, this aligns with the tutorial workflow where an S3 bucket with objects is provisioned, then changes are applied incrementally with -target. The tutorial demonstrates that targeting is a deviation from the normal apply entire plan at once workflow.
Targeting Multiple Resources and Modules
To target multiple Terraform modules, use the -target flag with each module path explicitly defined during terraform apply or terraform plan.
Each module must be specified with its full resource or module address.
Example:
bash
terraform apply -target=module.network -target=module.database
To target multiple resources in the same run:
bash
terraform apply -target=azurerm_linux_virtual_machine.example -target=azurerm_storage_account.example
Here, azurerm_linux_virtual_machine.example targets the Virtual Machine instance resource, and azurerm_storage_account.example targets the Azure Storage account defined in the Terraform configuration file.
The impact for large deployments is the ability to batch related changes. For example, network and database modules can be updated together while leaving compute untouched. This reduces blast radius during troubleshooting.
Contextually, safe management of multiple modules requires clear module boundaries and the use of workspaces or separate state files when isolation is required. Overusing targeting can cause drift or incomplete state changes, so it is best used for troubleshooting or partial updates.
Targeting With Terraform Plan
The -target option works identically with terraform plan as with terraform apply.
You can also use the -target option with the terraform plan command in the same way as terraform apply, using the -target flag followed by the resource address. Each -target must specify a full resource address. This selectively applies or plans only the listed resources and their dependencies.
Example:
bash
terraform plan -target=azurerm_linux_virtual_machine.example
The impact is that operators can preview the effect of an isolated change before applying it. This is critical when recovering from errors where a full plan would be too broad or risky.
Contextually, planning with targeting still produces the warning about resource targeting being in effect. The plan may not reflect all pending changes, which can mislead teams that rely on plan output for change review.
Targeting Terraform Modules
To target a Terraform module, use the -target option followed by the module path and the resource identifier.
Terraform will also apply changes to all resources that depend on that module, so be sure to understand the dependencies in your Terraform configuration before targeting a module.
The general form is:
bash
terraform apply -target=module.<module_name>
Or with a specific resource inside the module:
bash
terraform apply -target=module.vm.azurerm_linux_virtual_machine.example
Impact: Module targeting allows operators to isolate an entire logical component. This is useful when a module encapsulates a set of related resources and the team wants to test changes within that boundary.
Contextually, targeting a module expands outward to dependents, which means changes may propagate beyond the module itself. This reinforces the need to understand dependency graphs before using -target.
Risks and Constraints of Targeting
Terraform's -target option is a powerful but high-risk mechanism intended only for exceptional use cases — typically for recovering from errors, partial failures, or when specifically instructed by Terraform itself.
Key risks:
- Partial updates: Only the targeted subgraph is evaluated.
- Skipped changes: Resources not in the targeted graph are ignored, leading to drift.
- Dependency expansion: Explicit
depends_onforces inclusion of dependencies even when not naturally required. - Long-term drift: Routine use of
-targetcauses state to diverge from configuration.
HashiCorp explicitly recommends using resource targeting only for exceptional situations, not as your default deployment strategy.
The impact for organizations is operational. Teams that normalize targeting for speed will accumulate hidden state drift, increasing the likelihood of conflicts, failed applies, and manual remediation.
Contextually, targeting interacts with HCP Terraform workflows via TF_CLI_ARGS_plan. The same risks apply in managed execution environments. The recommendation to avoid using it in normal workflow applies equally to HCP Terraform and Terraform Community Edition.
When to Use Targeting
Appropriate scenarios:
- Recovering from errors where state is out of sync due to network failure, upstream cloud platform problem, or bug in Terraform or its providers.
- Troubleshooting a specific resource failure without reprocessing an entire large configuration.
- Performing a one-off fix that must be isolated.
- Accelerating changes in large deployments for a specific resource.
Inappropriate scenarios:
- Routine deployments and CI/CD pipelines.
- Bypassing dependency checks.
- Long-term change management.
The impact is a clear operational boundary: targeting is a recovery tool, not a deployment strategy.
Contextually, the tutorial on resource targeting demonstrates incremental apply of an S3 bucket and objects. This is an educational demonstration, not a recommended production pattern.
Summary of Targeting Syntax and Behavior
The following table summarizes targeting forms.
| Target Type | Example Command | Description |
|---|---|---|
| Single resource at root | terraform apply -target=azurerm_linux_virtual_machine.example |
Plans/applies only that resource and dependencies |
| Resource in module | terraform apply -target=module.vm.azurerm_linux_virtual_machine.example |
Targets resource inside named module |
| Multiple resources | terraform apply -target=azurerm_linux_virtual_machine.example -target=azurerm_storage_account.example |
Targets two resources and their dependencies |
| Multiple modules | terraform apply -target=module.network -target=module.database |
Targets two modules and their dependencies |
| Plan with target | terraform plan -target=azurerm_linux_virtual_machine.example |
Previews isolated changes only |
The table illustrates that each -target flag must specify a full resource address. The impact is that operators must know exact addresses to target correctly. Contextually, this requires consistent naming conventions and module structure across the codebase.
Conclusion
The -target option provides selective planning and applying capabilities in Terraform, allowing operators to focus on a specific resource, module, or collection of resources instead of the entire configuration. It is explicitly designed for exceptional troubleshooting scenarios such as recovering from errors, partial failures, or state desynchronization caused by network failures, upstream platform issues, or Terraform bugs.
Its power is matched by its risk. Targeting tells Terraform to focus on just part of the dependency graph, which can lead to partial updates, skipped changes, and long-term drift if relied upon in routine workflows. Explicit dependencies via depends_on further expand the targeting scope, as Terraform must include required prerequisites to maintain a valid dependency graph. This means targeting random_pet.name1 with depends_on = [ random_pet.name2 ] will also include random_pet.name2 in the plan, even though only name1 was specified.
HashiCorp's guidance is consistent across documentation: use resource targeting only for exceptional situations, not as a default deployment strategy. The warning Resource targeting is in effect is emitted to remind operators that the plan result may be incomplete. In HCP Terraform, targeting is surfaced via the TF_CLI_ARGS_plan environment variable, with the same risks applying in managed execution environments.
Effective use requires understanding dependency graphs, module boundaries, and the potential for drift. Targeting multiple resources or modules is possible via repeated -target flags, but each must be specified with a full resource address. Safe alternatives for routine work include clear module boundaries, workspaces, and separate state files. Targeting remains a high-risk recovery mechanism, not a workflow optimization.