In a Terraform pipeline, what cloud credentials should the plan job hold compared with the apply job, and why is a single long-lived access key stored in CI a poor choice for both?

## Two jobs, two permission sets The pipeline's two halves are asymmetric and their credentials should be too. **The plan job** reads. It parses the configuration, downloads providers, reads the current state from the backend, and calls provider APIs to check what the recorded resources look like now. It creates nothing. A read-only role over the relevant services is enough — plus two things people forget: - **Write access to the backend's lock.** Terraform locks state before planning, so a role with read-only access to the backend fails immediately with a lock error. Whatever your backend uses for locking must be writable by the plan role. - **Read access to the state object itself**, which is a different permission from reading the resources it describes. **The apply job** writes. It needs create, update and delete on everything the configuration manages, plus write access to the state. This is the powerful role, and its value is that exactly one code path can reach it: the job that runs after a merge to the protected branch. Splitting them buys containment. A pull request from any branch — including, in some setups, an untrusted contributor's fork — can trigger a plan. If the plan job's credentials could write, that trigger is a path to production, because a plan job runs code from the branch: the configuration itself, and anything the pipeline evaluates. With a read-only plan role, the worst outcome is disclosure, which is serious but bounded. Be honest about that bound in an interview: a read-only role can still read a lot. Plan output describes your infrastructure, and a plan can be made to read a data source that surfaces something sensitive. Read-only is a reduction in blast radius, not a guarantee of harmlessness. ## Why one static key is the wrong shape A single long-lived key stored as a CI secret has four properties you do not want: 1. **No separation.** One key means the plan job and the apply job have identical power, so the containment above does not exist. Every plan run is a potential write. 2. **No expiry.** A key that never expires is exploitable from the moment it leaks until someone notices — which, for a credential nobody rotates, can be years. Leaks are mundane: a `terraform apply` run with debug logging on, a crash dump, an error message echoed into a public build log. 3. **A secret at rest.** It exists in the CI secret store, in whatever spreadsheet or vault it was copied from, and on the laptop of whoever created it. Every copy is an exposure. 4. **Painful rotation.** Because rotating means editing every pipeline that references it, rotation slips, which is why these keys are old. ## What replaces it OIDC federation. The CI system issues each job a short-lived, signed identity token describing the run — the repository, the branch or environment, the workflow. The cloud provider is configured to trust that issuer and to exchange the token for temporary credentials against a specific role, with conditions on the token's claims. Nothing is stored: the token is minted for the job, the credentials it yields expire in minutes, and there is no secret to leak, rotate or exfiltrate. Terraform picks the resulting credentials up through the provider's ordinary environment-based authentication, so the configuration itself needs no change. The conditions on the trust relationship are what make the split enforceable rather than merely conventional. The apply role's trust policy names the specific repository and restricts it to runs from the protected branch or a protected deployment environment; the plan role trusts a broader set of runs but grants only reads. A job on a feature branch that asks for the apply role is refused by the cloud provider, not by a convention in the pipeline file. ## Practical points - **One role per environment, not one for the estate.** The pipeline that applies staging should not be able to touch production. - **The apply role's permissions should still be scoped.** "Administrator" is easy and wrong; scope to the services the configuration actually manages, accepting that Terraform's need to create IAM constructs makes this genuinely hard and worth deliberate design. - **Match run length to credential lifetime.** A long apply against a large estate can outlive a short session, so the session duration must cover the slowest realistic run. - **Do not let the plan role read secret stores** unless the configuration genuinely needs it; that is the most common way a read-only plan job becomes a disclosure incident.