Terraform Cloud centralizes infrastructure-as-code execution, which means workspace-level access control and variable handling carry more weight than they would for a single developer running Terraform locally.
Workspace-level access control
Terraform Cloud supports team-based permissions scoped per workspace — read, plan, write, and admin levels. Avoid granting broad organization-wide admin access by default; scope permissions so a team only has write access to the specific workspaces their infrastructure actually lives in.
Sensitive variable handling
Mark credentials and other sensitive values as "sensitive" variables, which makes them write-only through the UI after being set — they can't be read back, only overwritten. This doesn't replace an external secret manager for genuinely high-value credentials, but it's a meaningful baseline protection for workspace-level configuration.
Separate workspaces by environment and trust level
Don't manage production and staging infrastructure through the same workspace with shared variables. Separate workspaces per environment limits the blast radius if a workspace's credentials or configuration are ever compromised, and allows different approval requirements per environment.
Require manual approval for production applies
Terraform Cloud supports requiring manual approval before an apply actually executes, even if the plan step runs automatically. For workspaces managing production infrastructure, this human checkpoint catches unexpected or unintended changes before they take effect — automatic apply is a meaningful convenience tradeoff worth reserving for lower-stakes environments.
Use Sentinel or OPA policies as a gate
Policy-as-code tools integrated with Terraform Cloud can block a plan from being applied if it violates defined policies — for example, preventing a plan that would create a publicly accessible storage bucket, regardless of who submitted it or whether they have workspace access.
VCS-driven runs and branch protection
If Terraform Cloud is connected to a VCS repository for triggering runs, apply the same branch protection principles as any other CI/CD pipeline — changes to the infrastructure code that triggers applies should go through the same review requirements as application code, arguably with more scrutiny given the blast radius.
Audit logging
Enable and retain audit logs for workspace access, variable changes, and run history — infrastructure changes need the same "who did what, when" reconstruction capability as any other sensitive system during an incident investigation.