A production workspace in HCP Terraform was destroyed overnight, and security needs to establish who queued the destroy run and who confirmed it. Which source should they use?
Select an answer to reveal the explanation.
Short Explanation
When you need to know who pulled the trigger, ask the system that handed out the trigger. HCP Terraform's run history shows who queued and who confirmed a run, and the audit trail keeps an event stream you can pull into your SIEM. Cloud logs will only show the role the run assumed, not the person behind it.
Full Explanation
HCP Terraform records run activity per workspace: each run shows how it was triggered and by whom, and run events show actions such as confirmation or discard with the acting user or token. For organization-wide accountability, the audit trails API exposes a stream of audit events describing changes to workspaces, runs and other entities, and is commonly forwarded to a SIEM; it is available in the Standard and Premium editions and retains a limited window of history, so events should be exported. State lineage is a unique identifier for a state's history and the serial is an incrementing counter; neither records a person. Cloud provider logs show the identity that made each API call, which for a run using dynamic credentials or a shared key is the role or key, not the human who queued the run, so they cannot answer the question on their own. Destroy runs can be queued from the UI, the API or the CLI, not only through commits, so the VCS log is incomplete and often irrelevant. Exam caveat: runs started with team or organization tokens identify the token rather than a person, which is one reason to keep tokens per pipeline. Operational check: open the destroy run's details and the corresponding audit events, and reconcile them with the CloudTrail sessions for the run.