Team Collaboration Guardrails

A pull request modifies modules/network/main.tf and envs/prod/network.tfvars. The first available reviewer approves it in eleven minutes — they own the billing module and cannot name a CIDR range. The merge is technically reviewed and effectively unreviewed. CODEOWNERS is the mechanism that ends this, and it works because it answers one question before the review request is even sent: who is accountable for the blast radius this directory represents?

# .github/CODEOWNERS — patterns behave like gitignore; the LAST match wins
*                             @platform-guild
/.github/                     @platform-guild @security-team
/modules/network/             @network-team
/modules/kubernetes/          @compute-team
/modules/database/            @data-platform
/environments/prod/           @sre-oncall
*.tfvars                      @platform-guild

Design the file around directories, not people's calendars. A directory pattern routes to the team that can actually evaluate the change: the network team reviewing a route table change will ask about BGP sessions, while a well-meaning engineer from another domain rubber-stamps it. Keep ownership granularity at the module level — one owner per module directory — because * fallback owners end up approving everything and become a queue. Two properties catch teams out: the last matching pattern wins, so a specific rule must come after the general one, and a file matching no pattern falls back to * (or to nobody, if you omit the fallback — decide deliberately).

Protect the file itself. Changes to CODEOWNERS must require approval from the platform team — otherwise anyone can add their handle to a pattern and then self-approve their own infrastructure changes. The same meta-rule applies to the workflow files and branch-protection settings: the guardrails are configuration, and whoever edits the guardrails owns the security of the system.

Practical details decide whether the file helps or annoys. When a pull request touches two owned directories — modules/network/ and envs/prod/ — both owner groups must approve; multiple owners raise the bar, they do not let one team vote twice. Name a secondary handle per directory (a team channel qualifies) so one person on leave cannot hold the merge queue hostage. And expect an adjustment period: engineers used to quick informal approvals will complain that routing adds latency. The counter is measurement — median time-to-first-review typically falls, because requests stop landing in inboxes that ignore them.

CODEOWNERS governs the repository; it does not govern Terraform Cloud. Keep the two layers distinct:

A merged pull request and an applied plan are different events, and an organization where every merged change auto-applies to production has quietly deleted the second layer. Give reviewers a response expectation — one working day, escalation after — because ownership without responsiveness turns into a queue where PRs wait on a two-person team. And keep the changes themselves small; the next chapter covers the checks and merge rules that make that possible, starting with what must be green before any of it lands.

The interview framing is direct: "how do you ensure the right people review infrastructure changes?" Answer in three layers — directory ownership routes the review, required checks make the review deterministic, and workspace permissions keep merge rights separate from apply rights. Candidates who mention only code review have missed that production is not changed by merging.

Branch protection turns your pipeline from advice into law. With required status checks configured, a red or missing job makes merging physically impossible — no amount of deadline pressure overrides it. Configure it as code (the GitHub provider, gh api, or your platform's equivalent) so the guardrails themselves go through review:

# enforced via terraform's github_branch_protection or gh api
required_status_checks:
  strict: true
  contexts:
    - "static / fmt-validate"
    - "unit-plan / terraform test"
    - "policy / conftest"
    - "plan / staging"
    - "cost-estimate"
enforce_admins: true
required_pull_request_reviews:
  required_approving_review_count: 1

Each context is a contract with the CI workflow, and two failure modes come from forgetting that. A renamed job is a silent outage: plan / staging becomes plan (staging), branch protection still waits for the old name, no workflow reports it, and every pull request sits pending until someone opens the settings page. Version job names like an API, and update protection config in the same pull request that renames them. The second trap is strict: true being off: a check that ran against yesterday's tip proves nothing about today's main. Two merged PRs can interact in ways neither plan saw — require the branch to be up to date, or use a merge queue that re-plans the merged result, or your green checkmarks certify a codebase that no longer exists.

The cost-estimate context deserves a note: it behaves like any other required check. Attaching a monthly dollar delta to every plan is the mechanism from Cost Estimation on Plans, and making that context required means an accidental instance-class upgrade blocks the merge exactly the way a broken plan does — price becomes another red or green signal reviewers cannot skip.

The plan job itself needs the exit-code mapping from Layering Tests in the Pipeline — -detailed-exitcode returning 2 for "changes present" must count as success — and should post the diff where reviewers read it:

  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: terraform init -input=false
      - run: |
          terraform plan -input=false -out=tfplan -detailed-exitcode
          code=$?
          [ "$code" -eq 0 ] || [ "$code" -eq 2 ]
      - run: terraform show -json tfplan > plan.json
      - uses: actions/upload-artifact@v4
        with:
          name: plan-json
          path: plan.json

One security rule while posting comments: never check out pull-request code inside a pull_request_target workflow that holds a write-capable token. That combination is the classic GitHub supply-chain vulnerability; untrusted code runs with your credentials. Run the plan with a read-only token, or trigger comment posting from a separate trusted workflow that consumes the uploaded artifact. Treat a flaky required check with the same seriousness as a broken one — a job that fails one run in twenty trains engineers to click rerun until green, which is the exact behavior a required check was supposed to prevent. Fix the flake in the same week it appears.

The policy job runs on the plan output, not on the source:

terraform plan -input=false -out=tfplan -detailed-exitcode || [ $? -eq 2 ]
terraform show -json tfplan > plan.json
conftest test -p policy/ plan.json

This is where the standard from policy-as-code review becomes deterministic: the same rule evaluates all four hundred monthly pull requests with the same rigor, instead of depending on whichever reviewer was assigned.

Finally, give drift a place in the same dashboard. A scheduled job runs a refresh-only plan nightly and opens an issue — or fails a weekly required context — when out-of-band changes appear. Drift that surfaces in a separate report gets ignored; drift that competes with your merge gate for attention gets fixed. The merge queue also earns its keep here: by batching and serializing landings, it means your apply runs — serialized against the state lock described next — never queue behind an engineer's forgotten laptop run.

Two engineers merge clean-looking pull requests an hour apart. The first apply succeeds; the second fails with Error acquiring the state lock: Lock Info: ID: ... — or, in the worst configuration, succeeds concurrently and overwrites the first's state updates. Neither engineer did anything unusual. The guardrails that prevent this are variable scoping, locking discipline, and merge hygiene, and they are the last collaboration layer before governance.

Credential scoping separates who can see what by scope, not by trust:

The rule that matters: production credentials exist only in variable sets attached to production workspaces. An engineer with write on a dev workspace must be unable to read prod secrets, and a compromised CI job for dev must have no path to prod credentials. Prefer short-lived federation over static secrets entirely: OIDC tokens scoped by subject claim — repo:org/repo:ref:refs/heads/main — mean the CI role is only assumable from your repository's main branch, with credentials that expire in an hour instead of leaking forever.

State locking is the concurrency control you already have and probably misread. The backend lock (a DynamoDB LockID entry for S3, a blob lease for Azure) makes the second concurrent writer fail fast instead of interleaving. Plans also acquire the lock by default while refreshing — which is why a read-only reporting job against a busy environment runs with -lock=false, and why your CI should serialize applies through the platform's run queue (one active run per workspace) rather than letting four pipelines race. When a run dies mid-apply, the lock survives its owner: force-unlock only after confirming the owning run was cancelled in the UI, because force-unlocking while an apply is genuinely alive invites two writers to the same state — the one failure mode that silently corrupts everything downstream.

Merge hygiene is the cultural half, and infrastructure repos punish violations harder than application repos. In application code, a long-lived branch conflicts in source files. In Terraform, the branch conflicts in source and goes stale against state: a branch written Monday plans clean, two pull requests merge Tuesday and Wednesday, and by Friday your plan output describes a world that no longer exists — while merge conflicts in the .tf files are only half the problem, since resolving them does not refresh your plan. The practices that keep this under control:

• Target merge within one working day; re-plan on every rebase, and treat a stale plan as a failed review.
• Keep module changes additive — adding an attribute or a resource is safe to land under traffic; restructuring addresses belongs in its own pull request with a moved block.
• Split "change the module" from "adopt the new module version" so a consumer's upgrade PR stays a one-line version bump.
• Cap diffs near 400 changed lines; past that, reviewer attention collapses and the required approval becomes a formality.

Scoping keeps credentials away from the wrong eyes, locking keeps two honest runs from corrupting each other, and small merges keep plans meaningful. Together they form the everyday layer of the practice — Enterprise IaC Operating Model turns these pieces into an organization.