13.2 Collaboration and Governance Features
Key Takeaways
- Users are added to teams; workspace roles Read, Plan, Write, and Admin decide who can view runs, queue plans, and approve applies
- Policy sets attach Sentinel or OPA policies to an organization, project, workspace, or tag; one set uses one framework
- Sentinel is HashiCorp's policy language; OPA policies are written in Rego; Free edition allows one policy set of up to five policies
- Cost estimation is an extra run phase you enable per organization; only Sentinel policy checks (legacy mode) can read the estimate via the tfrun import
- Community CLI alone cannot provide HCP teams, run approvals, policy as code, cost estimates, the private registry, notifications, or SSO-backed team mapping
13.2 Collaboration and Governance Features
Quick Answer: HCP Terraform governs a team by putting users on teams, granting those teams workspace or project roles, requiring apply approval unless auto-apply is on, and evaluating policy sets (Sentinel or OPA) against the plan. Cost estimation, the private registry, notifications, and SSO sit on top of that. Terraform Community has none of this platform.
Objective 8b on Terraform Associate (004) is the collaboration and governance list. Official references: Permission model, Workspace permissions, Policy enforcement, Cost estimation, SSO, and Private registry.
Teams and who may apply
Access is not "share the state file." You add people to a team (or, in HCP Europe, an HCP group) and grant that team permissions at organization, project, and workspace scope. Permissions are additive: the user gets the most permissive grant they hold. Least privilege is the documented recommendation.
Fixed workspace roles you should be able to name:
| Role | Plan | Apply | Write variables | Lock workspace | Change settings / delete |
|---|---|---|---|---|---|
| Read | No | No | No | No | No |
| Plan | Yes | No | No | No | No |
| Write | Yes | Yes | Yes | Yes | No |
| Admin | Yes | Yes | Yes | Yes | Yes |
Plan is the exam role for "can propose, cannot change production." A Plan user queues a run; a Write or Admin user must approve the apply. Even if the workspace has auto-apply enabled, HashiCorp still requires an apply-capable user when the person who queued the run lacks apply permission.
Auto-apply is a workspace setting. It covers runs from the UI, API, and VCS webhooks. It does not automatically apply run-trigger runs unless you also enable the separate Auto-apply run triggers setting. CLI applies use -auto-approve for that one run. Plans with no changes end as "Planned and finished" and do not apply.
You can also lock a workspace so new runs sit until someone unlocks it. Plan-only / speculative runs can still proceed because they do not write state.
Organization-level permissions (owners, manage all workspaces, manage policy overrides, manage VCS) sit above this. Do not memorize every checkbox; do memorize that override of failed policies is its own permission, not a side effect of Write.
Policy as code: Sentinel and OPA
Policies are rules evaluated against a Terraform plan before apply. HCP Terraform supports:
- Sentinel — HashiCorp's policy-as-code framework.
- Open Policy Agent (OPA) — policies written in Rego.
- Terraform policy (newer HCL-native framework). Official docs mark it beta and require Terraform v1.16+, which is newer than the 1.12 product version on 004. Treat Sentinel and OPA as the exam pair.
A policy set is a bundle of policies written in one framework. You attach the set globally, to projects, to workspaces, or (beta) to workspace tags, and you can exclude specific targets. The same workspace may have both a Sentinel set and an OPA set; one set cannot mix languages.
Edition note (sourced, not priced): HCP Terraform Free includes one policy set of up to five policies. Standard and Premium can connect a policy set to a VCS repository or publish versions through the API. HashiCorp recommends storing policies in VCS rather than pasting them only in the UI.
Enforcement levels (remember the names):
| Framework | Levels | Failed policy |
|---|---|---|
| Sentinel | Advisory, Soft mandatory, Hard mandatory | Advisory never blocks. Soft mandatory blocks unless a user with override permission continues. Hard mandatory blocks until the plan changes, unless the set itself allows overrides. |
| OPA | advisory, mandatory | advisory never blocks. mandatory blocks, but a user with Manage Policy Overrides can override. |
Two evaluation engines exist for Sentinel. Policy checks (legacy) can read cost estimation data and are limited to older Sentinel (docs: through 0.40.x). Policy evaluations support newer Sentinel versions and OPA, and they cannot see cost estimates. If a question says "fail the run when monthly delta exceeds $X," the mechanism is a Sentinel check using the tfrun import, not an OPA evaluation.
Cost estimation, registry, notifications, SSO
Cost estimation is disabled until an organization owner enables it under Settings → Cost Estimation. Once on, every run gains a phase between plan and apply that shows hourly/monthly cost and the monthly delta for supported resources on the major clouds. It is an estimate: usage-based resources may be missing. You do not write a cost block in HCL to turn it on.
The private registry is an organization-scoped catalog of modules and providers, with versioning (modules typically versioned from Git tags). Teams browse approved patterns instead of copying folders. You can write Sentinel policies that require modules to come from that registry. Community Terraform can consume the public registry; it does not host your private org catalog.
Notifications are per-workspace (up to 20 destinations) or per-project. Destinations: Slack, Microsoft Teams, email, or a generic webhook (optional HMAC token, X-TFE-Notification-Signature, SHA-512). Events include run created/planning/needs attention/applying/completed/errored. Speculative plans and Local execution mode do not send notifications.
SSO is available to HCP Terraform organizations via SAML. HashiCorp is explicit about Free-tier limits: team management (creating arbitrary teams and mapping IdP groups onto them) is an Essentials / Standard (and higher) capability. On Free, configuring SSO creates an sso team, copies current owners into it, and both owners and sso have full administrative access you cannot slim down. Inviting a user on Free puts them on owners, not sso; the user joins sso by signing in through SSO. Do not claim Free has fine-grained IdP-driven teams. Paid editions can map a SAML attribute (default MemberOf) onto existing team names or SSO Team IDs; the IdP cannot create the owners team that way. Owners can still password-login as a break-glass path.
Remote state sharing
Workspaces share a small contract through root outputs. Another workspace reads them with terraform_remote_state (or, recommended by HashiCorp for HCP, the tfe_outputs data source, which does not need full state). The producing workspace must share state: with the whole organization, with the project, or with a named list. New workspaces default to share with specific workspaces and an empty list — nobody else can read them until you allow it. That access control does not exist for a Community local file you emailed to a teammate.
What Community cannot do alone
Terraform Community can still be disciplined: code review in Git, a CI runner, an S3 backend, hand-written wrapper scripts. It cannot, by itself:
- Host a run queue with apply approvals and an audit log of every plan
- Evaluate Sentinel or OPA policy sets as a platform stage
- Produce the HCP cost-estimate phase
- Provide org teams, project-scoped roles, or SAML SSO
- Host the HCP private module/provider registry
- Fan out Slack/email/webhook run notifications from a workspace
- Offer HCP remote-state sharing checkboxes and run triggers
Those are why 8b exists as a separate objective from 6c (configure a backend).
Scenario: the Friday apply
A contractor has Plan on app-prod. They open a PR (speculative plan is green) and merge. Auto-apply is off. The VCS-driven run plans and sits at Needs attention. A platform engineer with Write reviews the plan, confirms the Sentinel hard-mandatory "no public 0.0.0.0/0 on prod" set passed, and applies. Cost estimation showed a $12 monthly delta; no cost policy fired because the org uses policy evaluations, not checks. The contractor never received apply rights. That split is the 8b answer, not "put AWS keys on the contractor laptop."
004 traps for objective 8b
- Plan role ≠ apply role. Auto-apply does not promote a Plan user.
- Sentinel ≠ OPA. OPA language is Rego. A policy set is one framework.
- Free is not "no policy"; it is one set, five policies, no VCS-backed policy workflow.
- Cost estimates are not visible to OPA or to Sentinel evaluations — only Sentinel checks.
- SSO on Free is not full team management.
- Community plus GitHub Actions is not HCP governance.
A workspace uses an OPA policy set. How are those policies written, and what can a single policy set contain?
Which policy-set capacity does HashiCorp document for HCP Terraform Free edition?
An organization wants a Sentinel rule that fails the run when the monthly cost delta is greater than $100. Which HCP Terraform mechanism can actually see that number?