> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Resource Targeting
> Explains Terraform resource targeting using -target, its use cases for recovery, debugging, and drift fixes, risks of inconsistent state, examples, and best practice guidance.
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:
```bash theme={null}
terraform apply -target=azurerm_storage_container.container
```
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. |
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.
```hcl theme={null}
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:
```bash theme={null}
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):
```hcl theme={null}
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:
1. Initialize:
```bash theme={null}
terraform init
```
2. Create a plan:
```bash theme={null}
terraform plan -out=tfplan
```
3. Apply the plan:
```bash theme={null}
terraform apply "tfplan"
```
You might see an apply-time error like:
```plaintext theme={null}
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:
```hcl theme={null}
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):
```bash theme={null}
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:
```plaintext theme={null}
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](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](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.