So far, you have worked alone, running apply from your computer. But in a company, infrastructure is managed by a team, and applying changes to the production cloud "by hand" is dangerous. In this subchapter, we close the chapter (and Part III) by seeing how professional teams manage Terraform in a safe and collaborative way: through Pull Requests and plan review.

Imagine five people modifying the same infrastructure from their laptops. Immediate problems arise:

• Who applied that change that broke production? Nobody knows.
• Two people run apply at the same time and corrupt the state (remember subchapter 11.3).
• Someone applies a change without anyone reviewing it, and deletes a database.
• There is no record of what changed, when, or why.

The solution is to treat infrastructure just like application code: with Git, branches, Pull Requests, and peer review.

The professional workflow (often called GitOps) works like this:

The central idea: no one applies changes from their laptop. Everything goes through a reviewed Pull Request, and an automated system (CI/CD) executes apply.

The most valuable piece of this workflow is step 5: reviewing the plan. When you open a Pull Request, an automatic tool (we'll see it in Chapter 22) runs terraform plan and posts the result as a comment in the PR. This way, before approving, everyone sees exactly what will happen:

The reviewer looks at that plan and asks:

• Does it create what the author said they wanted to create?
• Is there any unexpected destroy? (A red flag!)
• Does it touch critical resources like databases?

This is the ultimate safety net. The plan in the PR makes every infrastructure change visible and reviewable. If someone accidentally proposes a change that would destroy the production database, the plan will show it with a - destroy, and the reviewer will stop it before it happens. Remember what we saw in subchapter 11.4: reading the plan carefully prevents disasters; here that habit becomes a mandatory team process.

Imagine that in an e-commerce company, Ana needs to add a second server to handle more traffic. Instead of going into production and creating it by hand:

1. Ana creates a branch feature/second-server and adds the resource in the code.
2. She opens a Pull Request titled "Add second web server for Black Friday."
3. The CI system posts the plan: Plan: 1 to add, 0 to change, 0 to destroy.
4. Carlos, her teammate, reviews the plan. He sees that only one instance is being added, nothing else. All good.
5. Carlos approves the PR. It is merged.
6. CI runs apply automatically. The new server appears.

Result: there is a permanent record (the PR) of what was changed, who proposed it, who reviewed it, and why. If something fails, just revert the PR. Total traceability.

Let's summarize the golden rules, which cover much of what we've learned in Part III:

• In a team, never apply Terraform "by hand" from your laptop: everything goes through Git, Pull Requests, and CI/CD.
• The GitOps workflow: branch → change the code → PR → CI posts the plan → a teammate reviews it → it's approved and merged → CI runs apply.
• The star step is reviewing the plan in the PR: it makes every change visible and allows you to stop dangerous operations (like an unexpected destroy) before they happen.
• This workflow gives total traceability: who changed what, when, why, and who approved it.
• It builds on what you've learned: remote state with locking, fmt/validate, and the habit of reading the plan carefully.

Congratulations! You have completed Part III and have a solid foundation in Terraform: language, providers, state, commands, a real infrastructure built, and the team workflow. In Part IV we'll take a leap: more advanced architectures in AWS, starting with load balancing and auto-scaling (Chapter 13).