This set builds vocabulary for centralized remote Terraform execution and governance.
0 / 5 completed
1 / 5
At standup, a dev mentions a hosted service that runs Terraform plans and applies remotely, keeping state centralized instead of on individual laptops. What is this service called?
Terraform Cloud is a hosted platform that runs plan and apply operations remotely and stores state centrally, avoiding the risks of running Terraform from individual laptops with locally stored state files that could conflict or go out of sync. This centralization is essential for teams collaborating on shared infrastructure. It also adds features like policy enforcement and run history on top of the open-source CLI workflow.
2 / 5
During a design review, the team wants to require a policy check, like disallowing public S3 buckets, before any Terraform plan can be applied. Which capability supports this?
Policy-as-code enforcement, using a framework like Sentinel or OPA, automatically evaluates a Terraform plan against defined rules, like disallowing public storage buckets, and can block an apply that violates them before it ever reaches real infrastructure. This shifts governance left into the deployment pipeline rather than relying solely on manual review. It's especially valuable for enforcing security and compliance rules consistently across many teams.
3 / 5
In a code review, a dev configures remote state locking so two team members can't apply conflicting changes to the same infrastructure simultaneously. What does this prevent?
State locking prevents two people from applying changes to the same infrastructure state simultaneously, which could otherwise corrupt the state file or produce conflicting, unpredictable infrastructure changes. This coordination mechanism is essential once more than one person can trigger applies against shared infrastructure. Centralized remote state with locking is a core reason teams move beyond purely local Terraform usage.
4 / 5
An incident report shows a Terraform apply destroyed a production resource because a plan wasn't carefully reviewed before approval. What practice would reduce this risk?
Reviewing a Terraform plan's diff before approving an apply, paying particular attention to any resource marked for destruction, catches unintended destructive changes before they're executed against real infrastructure. Skipping this review step to save time removes the primary safeguard against exactly this kind of costly mistake. This review discipline is standard practice for any infrastructure-as-code workflow touching production.
5 / 5
During a PR review, a teammate asks why the team uses a remote execution platform instead of running terraform apply locally from each engineer's machine. What is the reasoning?
Running terraform apply locally from each engineer's machine risks state conflicts and makes changes harder to audit consistently, while a remote execution platform centralizes state, enforces policy, and keeps a clear run history. This tradeoff favors centralization once more than one person manages shared infrastructure. The added platform cost and process overhead is generally justified by the reduced risk of state corruption or untracked changes.