A security team requires that HCP Terraform plans in the payments workspace run with an AWS role that can only read resources, while applies use a separate role that can modify them. The workspace already uses dynamic provider credentials with TFC_AWS_RUN_ROLE_ARN. How should the team configure this?
Select an answer to reveal the explanation.
Short Explanation
Picture two keys on your ring: one opens the filing cabinet to look, the other opens the vault to change things. Dynamic credentials let you hand out the look-only key during plan and the change key only during apply, and each role's trust policy checks which phase is knocking. Manual approval is nice, but it doesn't shrink what the plan can touch.
Full Explanation
AWS dynamic provider credentials support phase-specific roles. TFC_AWS_PLAN_ROLE_ARN names the role assumed during the plan phase and TFC_AWS_APPLY_ROLE_ARN the role assumed during apply; when both are set, TFC_AWS_RUN_ROLE_ARN is no longer needed. Because the workload identity token's subject ends in run_phase:plan or run_phase:apply, each role's trust policy can use StringEquals on its own phase, so a plan token cannot assume the write role even if someone swaps the ARNs. Keeping a single role and requiring confirmation delays the apply but leaves the plan phase, including any data source or provider call, running with full write permissions. Splitting plan and apply across two workspaces does not work, because a run's plan is applied in the same workspace that produced it and the second workspace would compute its own plan. A permissions boundary cannot see whether a run is speculative; IAM has no such condition, so the boundary would either block every write or none. Exam caveat: the read-only role still needs every read permission that refresh and data sources require, or plans fail. Operational check: compare the CloudTrail sessions for one run and confirm the plan used the read-only role and the apply used the write role.