A security review of an HCP Terraform organization finds AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY stored as sensitive environment variables in dozens of workspaces. The CISO wants no long-lived AWS credentials stored in HCP Terraform at all, with every run receiving short-lived credentials instead. What should the platform team implement?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal: a key you store is a key someone can steal, no matter how nicely you hide it. Dynamic provider credentials let each run show AWS a signed ID badge and get a short-lived role session back, so there's nothing long-lived sitting in your workspace. Don't fall for rotation or ephemeral variables; those still start from a static key.
Full Explanation
HCP Terraform dynamic provider credentials replace stored cloud keys with workload identity. For every plan and apply, HCP Terraform issues a signed OIDC token describing the organization, project, workspace and run phase. AWS is configured to trust HCP Terraform as an OIDC identity provider, and an IAM role's trust policy checks the token's audience and subject. Setting TFC_AWS_PROVIDER_AUTH to true and TFC_AWS_RUN_ROLE_ARN to the role makes the run exchange the token for temporary credentials, which expire on their own. A sensitive variable set only centralizes and hides the same static keys; they remain long-lived secrets stored in the platform. Ephemeral variables keep values out of state and plan files, but the input is still a permanent access key that must be stored somewhere to be supplied. Scheduled rotation shortens exposure yet keeps a long-lived IAM user and adds a pipeline that itself must hold privileged credentials. Exam caveat: dynamic credentials need agents of a supported version when runs execute on self-managed agents, and the trust policy must be scoped tightly. Operational check: remove the AWS key variables, run a plan, and confirm in CloudTrail that the session came from an AssumeRoleWithWebIdentity call on the expected role.