A company's dev and prod Terraform pipelines both assume one cloud role with administrator permissions. A compromised job in the dev pipeline could therefore change production. What is the recommended remediation?
Select an answer to reveal the explanation.
Short Explanation
When you share one admin role across dev and prod, you're giving the intern and the CFO the same badge. Split it: each environment's pipeline gets its own role with only that environment's permissions, and each role trusts only its own pipeline. Approvals and rotation are nice, but they don't stop a dev job from reaching prod.
Full Explanation
Least privilege for automation means separate identities per environment and per function. The dev pipeline assumes a dev role whose permissions cover only dev accounts or resources, and the prod pipeline assumes a prod role; each role's trust policy accepts only its own pipeline's identity, such as a specific HCP Terraform project and workspace subject or a CI environment claim. A compromise of the dev pipeline then yields only dev access. Requiring approval before applies does not constrain the credentials: a compromised dev job can call cloud APIs directly with the shared admin role without running an apply at all. Daily rotation shortens how long a stolen credential works, but within that window it still grants administrator access to production, and short-lived federated credentials already provide this property. Skipping refresh affects only what Terraform reads during planning; the role's permissions are unchanged, so the exposure is identical. Exam caveat: separate state backends or workspaces per environment are part of the same isolation, because a shared state bucket is another cross-environment path. Operational check: from a dev pipeline run, attempt a read or write against a production resource and confirm it is denied.