An engineer plans to attach TF_LOG=TRACE output from a failing production apply to a public issue on a provider's GitHub repository. What should the team consider before sharing it?
Select an answer to reveal the explanation.
Short Explanation
Trace logging is Terraform talking in its sleep: it says everything, including things you'd never say on purpose. Provider requests and responses can carry tokens, passwords and resource details, and the sensitive flag doesn't scrub them. So you treat the log like a secret, redact it, and share it through a private channel.
Full Explanation
Setting TF_LOG to TRACE produces the most verbose logging Terraform offers, covering both core and provider plugins, and provider logs often include API request and response details. Those payloads can contain authentication headers, temporary credentials, secrets returned by APIs and internal resource identifiers. The sensitive marking in configuration governs how Terraform renders values in plan and apply output; it does not guarantee that a provider's debug logging omits them. The safe practice is to treat debug logs as sensitive artifacts: reproduce with the lowest useful level, review and redact before sharing, and send them through a private support channel rather than a public issue. Saying sensitive markings make the file safe overstates what the flag does. Claiming only core events are logged is wrong; TF_LOG enables provider logs too, and TF_LOG_CORE and TF_LOG_PROVIDER exist precisely to split the two. TF_LOG_PATH only appends logs to a file; it applies no encryption. Exam caveat: CI systems that set TF_LOG globally can leak secrets into retained job logs, so enable it only for targeted troubleshooting. Operational check: search the log for tokens, keys and passwords before sharing, rotate anything found, and unset TF_LOG afterwards.