Terraform prepares remote runs for resource targeting

A command-line option that works locally needs an explicit protocol representation when execution moves to a service. Resource targeting illustrates that boundary in Terraform. The local CLI can parse an address, but a remote run must receive that address and agree to use it when constructing the plan.

Terraform 0.12.26 adds that client-side support on May 27. The release notes qualify the announcement with server support, and the versioned changelog says Terraform Cloud and Enterprise support will follow in forthcoming releases. Installing this CLI therefore does not establish that a particular hosted workspace can already execute targeted plans.

I appreciate Terraform's common workflow across different execution arrangements. The condition in this release is part of making that workflow dependable. A CLI needs to distinguish an option it understands from an operation its selected server can actually perform.

Replacing unconditional rejection with a capability check

The implementation in pull request 24834 replaces the remote backend's unconditional rejection of resource targeting. When target addresses are present, the revised code inspects the server's declared API version. It requires at least version 2.3 for remote targeting.

Older servers may return no version string. The code treats a missing or unparsable version as insufficient support, just as it treats an explicitly older version. That gives the client a defined result for services predating the version advertisement, instead of assuming that the absence of information means the operation is safe to submit.

The server version comes from an HTTP response header collected by the API client during setup. This is a service API version, separate from the Terraform executable version. An engineer can have a CLI with the new option forwarding while connecting to a server that still fails the capability check.

The patch's tests also inspect the created mock run. They check that its target addresses match the requested addresses. That verifies the meaningful handoff, because merely removing a local rejection would not prove the server receives the selection.

What the target address selects

The 0.12.26 plan documentation describes targeting as focusing Terraform on a subset of resources. The option takes a resource address and can appear more than once.

terraform plan -target=aws_instance.example
terraform plan -target=module.network

These examples illustrate the documented address forms for a configuration containing the named objects. A resource address selects that resource. For a resource using count, an unindexed address selects all instances sharing the resource name. A module path selects resources in that module and its descendants.

This means the address is operational input, not simply a display filter over a completed plan. The remote service needs it before planning. Showing only selected lines from a full plan would not reproduce the behavior requested by -target.

The module form also deserves attention when describing the scope of a run. A module path can cover descendants, so the compact spelling does not imply that only the directly declared resources in one file are involved. The address semantics remain relevant regardless of where Terraform executes.

Partial planning affects surrounding services

The patch adds handling for a cost-estimate status named skipped_due_to_targeting. When the server returns that status, the CLI reports that the estimate is unavailable because the plan used the target option. This is a concrete example of a surrounding service needing to understand partial planning.

A targeted run may be valid for its intended recovery task while supplying less information than a normal whole-configuration run. An unavailable cost estimate in that situation has a specific explanation. It should not be mistaken for a general estimation outage or silently presented as a complete estimate.

That distinction reinforces why remote targeting requires coordinated client and server work. The run request carries the target selection, and the response lifecycle can include outcomes associated with that selection. Support is broader than accepting a familiar flag at the terminal.

Targeting remains an exceptional operation

The plan documentation recommends targeting for exceptional circumstances, including recovery from mistakes and workarounds for Terraform limitations. It warns that routine targeting can leave configuration drift undetected and confuse the relationship between real resources and configuration.

For large configurations with independently operated parts, the documented alternative is separate smaller configurations. Data sources can supply information about objects created elsewhere. That arrangement gives each normal plan a defined scope instead of depending on operators to remember the correct subset of one larger configuration.

I see remote targeting as a useful recovery capability within that model. It lets a supporting execution service represent an exceptional operation explicitly. It does not change the architectural reasons for giving independently managed infrastructure separate configuration boundaries.

The distinction also affects interpretation of a successful run. Success answers whether the selected operation completed, within the target scope understood by the planner. It does not provide the same evidence about the whole configuration as an ordinary plan. The May release establishes the client-side request and compatibility checks needed to make that scoped operation available through a supporting remote service.