Rarely. HashiCorp documents the target option for exceptional circumstances only, such as recovering from mistakes or working around Terraform limitations. It plans only the addressed resources and what they depend on, so the rest of your configuration is skipped and your real infrastructure can quietly drift away from your code.
What the option does
-target=ADDRESS tells Terraform to focus its planning on the resource instances matching an address, plus any objects those instances depend on. Everything else is left out of that run. It works with both plan and apply.
Note the direction of the dependency. The documentation says the targeted resource and the things it depends on are included. Things that depend on it are not pulled in.
Why it matters for security
Security settings are often separate resources: a policy attachment, a bucket public access block, a security group rule. Suppose a change adds a new service and tightens its network rule in the same commit. If someone applies only the service with a target, the service goes live and the rule does not. The code says one thing, the cloud does another, and the plan looks clean for the part that ran.
That is the real risk: a half applied change that nobody noticed. Targeted runs also bypass the full plan that your review and policy checks looked at.
When it is reasonable
| Situation | Reasonable? | Why |
|---|---|---|
| Recovering from a failed apply with a broken resource | Yes, briefly | Documented exceptional use |
| Replacing one degraded object | Prefer the replace option | Narrower and clearer intent |
| Routine deploys to save time | No | Skips resources and checks |
| Pipeline default | No | Hides drift in every run |
If you do use it, follow the targeted run with a full plan straight away and confirm it shows no unexpected changes.
Better ways to get a smaller blast radius
- Split large configurations into smaller root modules with their own state, so a normal plan is already small.
- Use the replace option for a single resource that needs recreating.
- Keep security controls in the same module as the thing they protect, so they travel together.
- Block the option in pipelines. A simple search for the target flag in pipeline definitions catches most uses.
Quick check
Does the target option include resources that depend on the target?
The documentation describes it as including the addressed instances and the objects they depend on. It does not describe pulling in dependents.
What should I run after a targeted apply?
A full plan. It should come back with no unexpected changes. If it does not, treat the difference as drift to resolve.
Safeguard runs policies and gates on pull requests, so a failed rule can hold a merge, and its dependency and SBOM scanning covers the packages your infrastructure code pulls in. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
