A security team already runs Vault with the AWS secrets engine and wants every HCP Terraform run to receive AWS credentials generated by that engine, so Vault remains the single place where cloud credential issuance is audited and leases are revoked. No Vault token or AWS key may be stored in HCP Terraform. Which feature fits?
Select an answer to reveal the explanation.
Short Explanation
Think of Vault as the bank teller and your HCP Terraform run as a customer with a photo ID. With Vault-backed dynamic credentials, the run shows its workload identity token, Vault checks it, and the AWS secrets engine hands over short-lived keys. Going straight to AWS skips the teller, and any stored token or secret ID breaks the no-stored-secrets rule.
Full Explanation
Vault-backed dynamic credentials combine HCP Terraform workload identity with Vault secrets engines. The workspace first authenticates to Vault using dynamic credentials for the Vault provider, where a JWT auth role trusts HCP Terraform tokens, and then environment variables tell HCP Terraform which AWS secrets engine mount and role to use. Vault generates short-lived AWS credentials for the run, so issuance, leases and revocation stay in Vault and nothing long-lived is stored in the workspace. Plain AWS dynamic provider credentials are also keyless, but AWS issues the session directly, so Vault would neither audit nor revoke anything, which misses the stated requirement. A data source that reads AWS credentials from Vault depends on a stored Vault token, and its results are written into state, leaking the generated keys. An AppRole secret ID in a variable set is still a stored long-lived secret that grants a Vault login. Exam caveat: on Terraform Enterprise, Vault must reach the instance's OIDC metadata endpoints to verify tokens, and self-managed agents need a supported version. Operational check: queue a plan and confirm a new lease under the AWS secrets engine path in Vault's audit log, with no Vault or AWS secrets listed in the workspace variables.