An IAM role used by HCP Terraform dynamic credentials has a trust policy with StringEquals on app.terraform.io:aud and StringLike on app.terraform.io:sub matching organization:acme:*. An auditor notes that any workspace in the acme organization could assume this production role. Only the prod-network workspace in the Networking project, in both plan and apply phases, should be trusted. What change meets this requirement?

The subject claim of an HCP Terraform workload identity token has the form organization:ORG:project:PROJECT:workspace:WORKSPACE:run_phase:PHASE, so the trust policy's sub condition is what decides which workspaces may assume the role. Writing the full path for the Networking project and prod-network workspace, with StringLike and a wildcard only after run_phase, admits that workspace's plan and apply tokens and nothing else; the aud check stays as a second guard. Dropping the sub condition makes things worse, because every token HCP Terraform issues for the role carries the same default audience, so audience alone cannot distinguish workspaces. Setting the role ARN variable in only one workspace is not a control: any user who can edit another workspace's variables can paste the same ARN, and the role would accept that token. The run ID claim changes on every run and does not identify a workspace, so conditioning on it either breaks every future run or admits nothing useful. Exam caveat: project and workspace names in the subject can change, so renames or moves require trust policy updates. Operational check: queue a plan from a different workspace pointing at the role and confirm AWS rejects AssumeRoleWithWebIdentity, then confirm prod-network still plans and applies.