Managing Infrastructure as Code (IaC) with Terraform is as common as CI/CD pipelines and incident response playbooks. However, there are moments when you don’t want Terraform to touch everything. Maybe you need to quickly redeploy an Azure Function App, or perhaps a specific Storage Account needs an urgent configuration change without disturbing unrelated resources. The good news? Terraform’s -target argument for the plan and apply commands allows you to focus on just the resources you need.
This article walks through how to use -target in the real world, with examples focused on Azure Function Apps, but equally applicable to any Terraform-managed resource regardless if it’s cloud or on-prem. Also included is a slightly deeper look at the implications of this approach—both its power and its pitfalls—from an SRE and DevOps perspective.
What is -target? – The Power of Selectivity
The -target argument is a Terraform CLI option that tells Terraform to limit its actions to specific resources, ignoring everything else during that particular plan or apply cycle.
Basic Syntax:
terraform plan -target=
terraform apply -target=
Terraform will still load the full state and configuration, but will plan and apply changes only to the targeted resources. This is immensely helpful when you need to:
- Speed up development or testing workflows.
- Apply emergency fixes to production.
- Avoid triggering long-running or disruptive updates.
Understanding the Terraform Resource Address
The resource identifier used with -target is technically called a resource address. This is the unique path Terraform uses to reference resources within your state file and configuration.
The basic format is:
Or, if the resource is inside a module:
⚠️ Note: This is not the Azure Resource ID you see in the Azure Portal.
You can always list all resources and their addresses using:
Example: Targeting an Azure Function App
Imagine you have the following resource (an Azure Function App in this example, but this could be anything) defined:
resource "azurerm_function_app" "my_function" {
name = "my-func-app"
location = azurerm_resource_group.my_rg.location
resource_group_name = azurerm_resource_group.my_rg.name
app_service_plan_id = azurerm_app_service_plan.my_plan.id
storage_account_name = azurerm_storage_account.my_storage.name
storage_account_access_key = azurerm_storage_account.my_storage.primary_access_key
version = "~4"
}
The resource address is simply:
azurerm_function_app.my_function
To plan and apply changes only to this specific resource:
terraform plan -target=azurerm_function_app.my_function
terraform apply -target=azurerm_function_app.my_function
This will only check and modify the my_function Function App, leaving all other resources untouched for now.
Targeting Multiple Resources
Need to update more than one resource at once? Simply use multiple -target flags:
terraform plan -target=azurerm_function_app.my_function -target=azurerm_storage_account.my_storage
terraform apply -target=azurerm_function_app.my_function -target=azurerm_storage_account.my_storage
This ensures both the Function App and the Storage Account will be evaluated and updated, while everything else stays idle.
Best Practices for SREs and DevOps
The -target flag is undeniably powerful, but like any sharp tool, it should be used carefully. Here’s what you should consider:
Use it Sparingly
Relying too much on -target can lead to infrastructure drift and fragmented workflows. It should be treated as a surgical tool, not your daily driver.
Favor Modular Design
If you frequently find yourself wanting to apply changes to only a subset of resources, it may be time to refactor your Terraform configuration into smaller, independent modules.
For example:
module "function_app" { ... }
module "storage" { ... }
This allows for easier, more targeted applies without depending on -target.
Verify Dependencies Manually
Terraform will not automatically resolve or update dependencies outside of the targeted resources. As an SRE or DevOps engineer, you are responsible for checking whether skipped resources might still need attention.
Always Review Plans
Even when using -target, always review the terraform plan output thoroughly before applying changes.
Pitfalls to Avoid
⚠️ Hidden Dependency Problems
If your targeted resource depends on another resource that requires changes, but you didn’t include it in the target list, you could end up with a partial or broken deployment.
⚠️ False Sense of Safety
It may look like you’re “only updating one thing,” but changes might cascade if you misidentify dependencies.
⚠️ Unintended Drift
Overusing -target without periodically running full plans and applies can lead to unmanaged drift between code and actual infrastructure.
When to Use -target (and When Not To)
Here are several usage scenarios where the use of -target are good or bad, to help steer you in the right direction on when and when not to use this:
✅ Good Scenarios
- Emergency patches to a single Function App.
- Testing changes to a new, non-production resource.
- Experimenting during development.
❌ Bad Scenarios
- Routine production changes.
- Large-scale infrastructure updates.
- Skipping updates to dependent resources.
Remember, -target is an advanced feature. HashiCorp themselves note that it is not intended for everyday usage.
Conclusion
The -target argument is a valuable ally when used responsibly, especially in the hands of skilled SREs and DevOps engineers who understand both the tooling and the system they’re managing. It can be the difference between quickly fixing an issue and triggering an unnecessary hours-long deployment.
However, like all powerful tools, it comes with trade-offs. Use it wisely, respect its limitations, and always think holistically about the systems you’re managing.
Original Article Source: Applying Terraform Changes to Specific Resources using the -target Argument written by Chris Pietschmann (If you’re reading this somewhere other than Build5Nines.com, it was republished without permission.)
