Terraform 1.17.0 Release Candidates: Policy Goes GA and Query Checks Land

Infrastructure teams that want rules enforced on Terraform runs have often had to treat policy evaluation as an experimental add-on. The two release candidates for Terraform 1.17.0 change that. According to the Release v1.17.0-rc1 notes, Terraform Policy is now generally available, and the -policies flag no longer needs an experimental build or the -allow-experimental-features flag. The later Release v1.17.0-rc2 notes keep that change and add several fixes and behavior changes on top.

This article follows one coherent story: how policy evaluation now fits into the plan, apply, and query workflow, and what changed between the two candidates. Everything below comes from those two release notes, so it describes what the notes state rather than measured behavior.

How the policy flow works, step by step #

1. You pass the -policies flag to plan, apply, or query. As of the rc1 notes, this no longer requires an experimental build.
2. For query runs, Terraform discovers resources through list blocks.
3. The policy engine evaluates each discovered resource against the policies you supplied.
4. Terraform reports the outcome as human-readable output or as JSON.
5. Results that cannot be determined are reported explicitly as Unknown or N/A, rather than being dropped.
6. If the path given to terraform query -policies is not a directory, the command rejects it before the policy engine sees it.

Each step maps to a specific change in the release notes. The sections below expand them in order.

Step 1: Policy is no longer gated behind experimental flags #

The rc1 notes list "policy: Terraform Policy is now generally available" under new features. The change is about access, not new evaluation logic. Before this, teams had to opt into experimental behavior to use the flag. Now the same -policies flag is available on plan, apply, and query without extra opt-in switches. Both candidates carry this wording, so it is the most stable part of the 1.17.0 story across the two releases.

Step 2: Query policies start from discovered resources #

The rc1 notes explain that query policies evaluate resources discovered by list blocks. That is the key difference from plan-time checks. A query run is about what already exists, so the input to the policy is the set of discovered resources, not only the proposed changes in a plan. The notes say results can be shown in human-readable form or JSON, which gives you two ways to consume the same evaluation: a person reading a terminal, or a tool parsing structured output.

The official policy documentation is referenced in both notes, but the release notes themselves do not describe policy syntax, so this article does not go into policy authoring.

Step 3: Reporting Unknown and N/A results #

Both candidates include the fix "query: report Unknown and N/A results for policy evaluations of discovered resources." In practice, this means that when the evaluation for a discovered resource cannot produce a pass or fail verdict, the output says so. For an audit-style workflow, that distinction matters. A silent gap in coverage is harder to notice than a line that clearly says a result is unknown or not applicable.

Step 4: Validating the path #

The rc1 notes say "terraform query -policies now rejects a path that is not a directory, instead of passing it on to the policy engine." This is a input-validation change. Rather than handing a bad path to the engine and getting a confusing downstream error, Terraform stops early. Teams that script query runs should check that their policy path points to a directory, because a file path will now be rejected.

What changed between rc1 and rc2 #

The rc2 notes, dated October 14, 2026, add several items that do not appear in rc1. The main ones are:

• Variables and locals in provider requirements is listed in both notes, so it is not new in rc2. It is part of the feature set in both candidates.
• Logarithm and power functions: the rc2 notes say log and pow now raise errors when they would return positive or negative infinity, because that result is not usable in downstream code.
• Showing a local plan: show now reads variable values from the plan file when showing a local plan.
• Ephemeral renewal diagnostics appear in both candidates. The notes warn that warnings may appear that were previously lost, and they expect that any error diagnostics that were lost would have caused confusing downstream errors.

The rc2 notes also list the -minimal-refresh option, which was already in rc1. It refreshes only resources that have proposed changes. Here is a minimal invocation that uses it, taken directly from the flag name in the notes:

terraform plan -minimal-refresh

This command only reflects the flag's documented purpose, not a benchmark of its speed. The notes do not quantify any savings, so you should measure against your own state before relying on it.

JSON format_version and tooling #

Both candidates include a note that terraform version JSON output now has a format_version field. The notes say this enables safer future changes to the output format. They also assume existing tooling ignores unknown fields, so the change should not break consumers on its own. Still, the notes advise checking format_version in future releases and using current versions of the HashiCorp tooling that handles it. If your pipeline parses that output, it is worth adding a check now.

Practical checklist for release candidate testing #

If you plan to evaluate these candidates, the release notes suggest several places to focus:

1. Remove any experimental flags from scripts that call plan, apply, or query with -policies.
2. Confirm that -policies arguments point to directories.
3. Review how your tooling handles Unknown and N/A policy results.
4. Check any parser of version JSON output for the new format_version field.
5. Watch for new ephemeral renewal warnings in logs.