Resource Targeting

Resource targeting in Terraform lets you limit an operation (plan or apply) to specific resource(s) instead of evaluating the entire configuration. This is an advanced feature intended for exceptional situations such as recovery, debugging, or fixing drift. Misusing it can leave your infrastructure in an inconsistent or unsafe state, so read carefully. What resource targeting does:

Runs Terraform only against the targeted resource(s) and their dependency chain.
Is invoked with the -target flag on terraform plan or terraform apply.
Is not a performance optimization; it skips evaluating unrelated parts of the configuration and can therefore produce incomplete results.

Example command:

terraform apply -target=azurerm_storage_container.container

The image is an infographic titled "Resource Targeting," featuring three sections: "Targeting," "Recovery or Debugging," and "Skip Checks," each with a brief description of their purpose.

Call out the risk: if you skip evaluation of other configuration parts, ensure you are not skipping anything critical that could affect the overall deployment. When to use resource targeting Use resource targeting only in narrow scenarios where you understand the consequences. Common valid use cases include:

Use case	When to use
Retry a failed resource	A transient API error caused a single resource to fail during apply; you want to retry only that resource.
Debugging	A resource repeatedly fails; target it to iterate quickly without evaluating the rest of the configuration.
Drift correction	You know exactly which resource drifted from its Terraform-managed state and want to reapply only that resource.

The image describes "Resource Targeting" with three options: Retry, Debug, and Drift, each with a brief explanation about when to use them.

Example: resource group, storage account, and container Below is a minimal example showing a resource group, a storage account that depends on the group, and a container that depends on the storage account.

resource "azurerm_resource_group" "rg" {
  name     = "target-demo-rg"
  location = "East US"
}

resource "azurerm_storage_account" "sa" {
  name                     = "targetstoragedemo"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_storage_container" "container" {
  name                  = "tfcontainer"
  storage_account_name  = azurerm_storage_account.sa.name
  container_access_type = "private"
}

Under normal operation Terraform evaluates the full dependency graph and creates or updates resources in the correct order. If you run:

terraform apply -target=azurerm_storage_container.container

Terraform will plan and apply only the container resource and any resources required to create it (in this example, the storage account and resource group if they do not already exist). This can be useful when the container creation previously failed and you want to retry only that resource. Why resource targeting is dangerous Resource targeting may skip planned changes to related resources such as account configuration, policy assignments, network rules, or security settings. Even if the targeted resource is created or updated successfully, the overall infrastructure might become inconsistent.

Resource targeting is intended for recovery, debugging, or drift-fix scenarios only. Do not use it for initial deployments, CI/CD pipelines, or regular day-to-day applies. If you care about correctness and safety, run a normal terraform apply (or terraform apply on a saved plan).

Practical scenario: retrying or fixing a single resource after a runtime error Case: you create a storage account, but the chosen account name is globally unique and already taken by another subscription. The plan phase can succeed, because Terraform does not detect the global uniqueness constraint; the failure occurs during apply when Azure rejects the creation. Example HCL that will fail during apply (name intentionally invalid for demonstration):

resource "azurerm_resource_group" "rg" {
  name     = "kodekloud-tf-target-rg"
  location = "eastus"
}

resource "azurerm_storage_account" "sa" {
  name                     = "storage"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

Typical workflow:

Initialize:

terraform init

Create a plan:

terraform plan -out=tfplan

Apply the plan:

terraform apply "tfplan"

You might see an apply-time error like:

Error: creating Storage Account (Subscription: "1b228746-75fd-46ed-8a6b-6a9066d6d3a3"
Resource Group Name: "kodekloud-tf-target-rg"
Storage Account Name: "storage"): performing Create: unexpected status 409 (409 Conflict) with error: StorageAccountAlreadyTaken: The storage account named storage is already taken.

  with azurerm_storage_account.sa,
  on main.tf line 6, in resource "azurerm_storage_account" "sa":
   6: resource "azurerm_storage_account" "sa" {

Fix the configuration by choosing a unique storage account name:

resource "azurerm_storage_account" "sa" {
  name                     = "storagedrt6673623"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

Then apply only the storage account (Terraform will also include any dependencies required to create it):

terraform apply -target=azurerm_storage_account.sa

When you run the targeted apply, Terraform shows a concise plan covering just the targeted resource (and required dependencies). It will also display a warning that the plan was created with -target, for example:

Plan: 1 to add, 0 to change, 0 to destroy.

Warning: Resource targeting is in effect
You are creating a plan with the -target option, which means that the result of this plan may not represent all of the changes requested by the current configuration.
...
Do you want to perform these actions?
Only 'yes' will be accepted to approve.

Best practices and final rules

Use -target only for recovery, debugging, or drift correction—and only when you understand the implications.
Never use resource targeting for:
- Initial provisioning
- CI/CD pipelines
- Regular operations as a performance shortcut
Prefer creating and applying a full plan (terraform plan + terraform apply) when correctness matters.
If you must target, document the action and follow up with a full plan/apply afterward to ensure consistency.

Additional references

HashiCorp: Resource Targeting documentation — https://www.terraform.io/cli/commands/plan#target
Azure naming rules and storage account limitations — https://learn.microsoft.com/en-us/azure/storage/common/storage-account-overview#naming-rules

If you fully understand the impact and need to recover or debug, targeting can be a useful, narrowly scoped tool. Otherwise, rely on Terraform to manage the full dependency graph so your infrastructure remains consistent.

Introduction

Infrastructure as Code Fundamentals

Terraform Cloud

Setting up environment

Azure Context for Terraform

HashiCorp Configuration Language

Terraform Providers

Variables

Outputs and Dependencies

Iteration and Logic

Advanced Constructs

Terraform State Fundamentals

Remote State

Terraform Workspaces

Terraform CLI

Lifecycle Meta-Arguments

Data Sources

Provisioners

Debugging Terraform

Terraform Modules

Azure DevOps Integration

Azure Pipelines for Terraform

Resource Targeting

Watch Video