[datadog_synthetics_global_variable] feat: add write-only value support

[LiuVII]

Follow-up #3210 to show-case how WO argument can be implemented using some WO helpers.

APIR-2446

---

Summary

Adds write-only attribute support to datadog_synthetics_global_variable resource for Terraform 1.11+, enabling secure secret handling without state file exposure.

Changes

• Add value_wo (write-only) and value_wo_version (trigger) attributes alongside existing value
• Use WriteOnlySecretHandler helpers from fwutils package for secret retrieval logic
• Support partial updates: secrets only sent to API when version trigger changes
• Add ValidateConfig to handle mutual exclusion between value/value_wo while allowing neither for FIDO variables
• Add PreferWriteOnlyAttribute warning for secure variables still using plaintext value

Test Plan

• TestAccDatadogSyntheticsGlobalVariableWriteOnly_Basic - create with write-only value
• TestAccDatadogSyntheticsGlobalVariableWriteOnly_Updated - update via version trigger
• TestAccDatadogSyntheticsGlobalVariableWriteOnlySecure_Basic - secure + write-only
• Existing FIDO/TOTP/secure tests pass

[LiuVII]

ℹ️ info: we can't use CreateWriteOnlySecretAttributes because of secure conditional, which is unique to this resource

[Matt-Cam]

Overall code LGTM. Two main questions:

1. Testing
Were these changes validated against a locally spun up terraform-provider hitting staging?

2. Why are we doing this?
Does this provide any benefit over the existing secure attribute behavior, which already keeps secret values out of state? It seems like this mainly gives users option to hide from state a non-secure variable? Is this being done because it's best practice or for demonstration purposes?

[LiuVII]

thank you for the review @Matt-Cam 🙏 about your questions

Were these changes validated against a locally spun up terraform-provider hitting staging?

Validated it locally hitting frog prod org.

Does this provide any benefit over the existing secure attribute behavior, which already keeps secret values out of state? It seems like this mainly gives users option to hide from state a non-secure variable?

Not sure I understand "existing secure attribute behavior, which already keeps secret values out of state" part. The current behavior saves secret to the terraform state file even if the option is secure=true. The only thing we do is masking it from plaintext output with "sensitive".

And so the main benefit of this change is that we are not going to store it in state anymore and we're going to use native terraform framework behavior that ensures this.

[Matt-Cam]

@LiuVII thanks for the response 🙏🏼

Not sure I understand "existing secure attribute behavior, which already keeps secret values out of state" part. The current behavior saves secret to the terraform state file even if the option is secure=true. The only thing we do is masking it from plaintext output with "sensitive".

And so the main benefit of this change is that we are not going to store it in state anymore and we're going to use native terraform framework behavior that ensures this.

Ahh, okay I didn't realize that we were storing in state even when secure=true. Would it make any sense to simply use the t/f value of secure to determine whether or not to store it in state and avoid the new fields altogether? Note: I'm not saying this is best, but am genuinely asking :)

[Matt-Cam]

👍🏼 LGTM with one last question

[LiuVII]

Would it make any sense to simply use the t/f value of secure to determine whether or not to store it in state and avoid the new fields altogether? Note: I'm not saying this is best, but am genuinely asking :)

The main issue is perpetual drift.

Here's what happens if you don't save value to state when secure=true:

1. Config says: value = "my-secret"
2. State says: value = null (because we didn't save it)
3. Every terraform plan: Terraform sees a difference and proposes an update

This means every single plan would show:

~ resource "datadog_synthetics_global_variable" "example" {
    ~ value = null -> "my-secret"  # forces replacement or update
  }

The user would have to either:

• Run terraform apply on every plan (annoying, potentially dangerous)
• Use ignore_changes lifecycle block (defeats the purpose of managing the resource)

Why write-only solves this:
Write-only attributes tell Terraform: "This value is intentionally not stored in state. Don't compare it for drift
detection - just send it on create/update."

[Matt-Cam]

Would it make any sense to simply use the t/f value of secure to determine whether or not to store it in state and avoid the new fields altogether? Note: I'm not saying this is best, but am genuinely asking :)

The main issue is perpetual drift.

Here's what happens if you don't save value to state when secure=true:

1. Config says: value = "my-secret"
2. State says: value = null (because we didn't save it)
3. Every terraform plan: Terraform sees a difference and proposes an update

This means every single plan would show:

~ resource "datadog_synthetics_global_variable" "example" {
    ~ value = null -> "my-secret"  # forces replacement or update
  }

The user would have to either:

• Run terraform apply on every plan (annoying, potentially dangerous)
• Use ignore_changes lifecycle block (defeats the purpose of managing the resource)

Why write-only solves this: Write-only attributes tell Terraform: "This value is intentionally not stored in state. Don't compare it for drift detection - just send it on create/update."

Makes sense, thanks for this! All good on my side 🚀

[LiuVII]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-01-15 15:44:14 UTC ℹ️ Start processing command /merge

---

2026-01-15 15:44:56 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 33m (p90).

---

2026-01-15 15:57:47 UTC ℹ️ MergeQueue: This merge request was merged