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=<resource_address>
terraform apply -target=<resource_address>

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:

<resource_type>.<resource_name>

Or, if the resource is inside a module:

module.<module_name>.<resource_type>.<resource_name>

⚠️ Note: This is not the Azure Resource ID you see in the Azure Portal.

You can always list all resources and their addresses using:

terraform state list

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.

Chris Pietschmann is a Microsoft MVP, HashiCorp Ambassador, and Microsoft Certified Trainer (MCT) with 20+ years of experience designing and building Cloud & Enterprise systems. He has worked with companies of all sizes from startups to large enterprises. He has a passion for technology and sharing what he learns with others to help enable them to learn faster and be more productive.
Microsoft MVP HashiCorp Ambassador

Discover more from Build5Nines

Subscribe now to keep reading and get access to the full archive.

Continue reading