TECH **Terraform Cloud/Enterprise Workspaces & VCS-Driven Plans: Zero-Fluff Study Guide**

Terraform Cloud/Enterprise Workspaces & VCS-Driven Plans: Zero-Fluff Study Guide

1. What This Is & Why It Matters

Terraform Cloud (TFC) and Terraform Enterprise (TFE) are managed services that provide collaboration, governance, and automation for Terraform workflows. Workspaces are the core unit of organization—they map to environments (dev, staging, prod) or components (networking, databases). VCS-driven plans (Version Control System) automate Terraform runs when code is pushed to a repo (GitHub, GitLab, Bitbucket).

Why This Matters in Production

• Without TFC/TFE: You’re manually running terraform apply in your terminal, risking:
• Human error (fat-fingered commands, wrong environment).
• No audit trail (who changed what, when?).
• No approval gates (anyone can deploy to prod).
• No drift detection (if someone manually changes AWS resources, Terraform won’t know).
• With TFC/TFE:
• Automated, repeatable deployments (VCS triggers runs on PRs).
• Role-based access control (RBAC) (only admins can approve prod changes).
• State management (no more terraform.tfstate files lost in Slack).
• Cost visibility (track cloud spend per workspace).

Real-World Scenario

You’re a cloud engineer at a fintech startup. Your team uses Terraform to manage AWS infrastructure, but: - Developers keep breaking staging by running terraform apply locally. - Prod deployments require manual approvals, but there’s no record of who approved what. - Someone accidentally deleted an S3 bucket in prod, and you have no way to track who did it.

Solution: Migrate to Terraform Cloud, set up workspaces for each environment, and enforce VCS-driven plans with approval gates.

2. Core Concepts & Components

3. Step-by-Step: Setting Up VCS-Driven Workspaces

Prerequisites

✅ Terraform Cloud account (sign up here) ✅ GitHub/GitLab/Bitbucket repo with Terraform code ✅ AWS credentials (or other cloud provider) stored as TFC variables

Step 1: Connect TFC to Your VCS Provider

1. Go to Settings → Version Control in TFC.
2. Click Connect to VCS and select your provider (e.g., GitHub).
3. Authorize TFC to access your repos.
4. Production Insight: Use a dedicated GitHub machine user (not your personal account) for TFC.

Step 2: Create a Workspace

1. Click Workspaces → New Workspace.
2. Select Version Control Workflow.
3. Choose your repo (e.g., my-org/terraform-aws-infra).
4. Set Workspace Name (e.g., aws-prod-networking).
5. Advanced Options:
6. Terraform Working Directory: /terraform/networking (if your code is in a subfolder).
7. VCS Branch: main (or prod if using GitFlow).
8. Automatic Runs: Enable Auto-apply (for dev) or Manual apply (for prod).
9. Click Create Workspace.

Step 3: Configure Variables

1. Go to Variables → Workspace Variables.
2. Add Terraform Variables (e.g., aws_region = "us-east-1").
3. Add Environment Variables (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY).
4. ⚠️ Mark sensitive variables as "Sensitive" (they won’t be logged).
5. Production Insight: Use Variable Sets for global configs (e.g., aws_region).

Step 4: Trigger a Run via VCS

1. Make a change to your Terraform code (e.g., add an aws_instance).
2. Commit and push to the repo.
3. In TFC:
4. A new run will appear under Runs.
5. If Auto-apply is enabled, it will run terraform apply automatically.
6. If Manual apply is enabled, you’ll see a Plan and must click Confirm & Apply.
7. Verify:
8. Check the Logs tab for errors.
9. Go to AWS Console to confirm the resource was created.

Step 5: Set Up Approval Gates (Prod Workspaces)

1. Go to Workspace Settings → Run Triggers.
2. Under Apply Method, select Manual apply.
3. Under Approval, enable Require approval for all applies.
4. Add approvers (e.g., [email protected]).
5. Production Insight: Use Teams in TFC to manage permissions (e.g., dev-team can only plan, ops-team can approve).

Step 6: Enable Drift Detection

1. Go to Workspace Settings → General.
2. Under Drift Detection, enable Automatic drift detection.
3. Set Frequency (e.g., daily).
4. Production Insight: If drift is detected, TFC will show a Drift tab with details.

4. ? Production-Ready Best Practices

Security

• Least Privilege IAM: Use AWS IAM roles (not long-lived keys) for TFC.
  hcl # Example: Assume an IAM role in Terraform provider "aws" {
assume_role {
role_arn = "arn:aws:iam::123456789012:role/terraform-cloud-role"
} }
• Sensitive Variables: Mark secrets as Sensitive in TFC.
• Private Module Registry: Host modules in TFC (not public GitHub).
• Branch Protection: Require PR approvals before Terraform runs.

Cost Optimization

• Cost Estimation: Always review the Cost Estimate tab before applying.
• Right-Sizing: Use t3.micro for dev, m5.large for prod.
• Auto-Shutdown: Use aws_instance user_data to shut down non-prod instances at night.
  hcl resource "aws_instance" "dev" {
user_data = <<-EOF
#!/bin/bash
shutdown -h 20:00
EOF }

Reliability & Maintainability

• Workspace Naming: Use <cloud>-<env>-<component> (e.g., aws-prod-networking).
• Tagging: Enforce tags (e.g., Environment, Owner, CostCenter).
  hcl resource "aws_instance" "web" {
tags = {
Environment = "prod"
Owner = "team-infra"
} }
• Idempotency: Ensure terraform apply is safe to run multiple times.
• Rollback Strategy: Use TFC Run History to revert to a previous state.

Observability

• Logging: Enable TFC Audit Logs (Settings → Audit Logging).
• Alerts: Set up Slack/Email notifications for failed runs.
• Metrics: Monitor Run Duration and Cost Estimation trends.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "Which TFC feature enforces compliance policies before applying changes?"
2. ✅ Sentinel (Policy as Code)
3. ❌ Cost Estimation

4. ❌ Drift Detection

5. "You need to deploy a change to prod but require approval. Which TFC setting should you configure?"

6. ✅ Manual apply + Approval gates
7. ❌ Auto-apply

8. ❌ VCS branch protection

9. "What happens if you push a Terraform change to a repo connected to TFC with auto-apply enabled?"

10. ✅ TFC automatically runs terraform apply
11. ❌ TFC only runs terraform plan
12. ❌ You must manually trigger the run

Key ⚠️ Trap Distinctions

• Workspace vs. Environment:
• A workspace is a TFC construct (e.g., aws-prod-networking).
• An environment is a logical concept (e.g., "prod").

• ⚠️ One workspace per environment—don’t mix them!

• Auto-apply vs. Manual apply:

• Auto-apply: Good for dev/staging (fast feedback).

• Manual apply: Required for prod (safety first).

• VCS Integration:

• GitHub/GitLab/Bitbucket: TFC supports all three.
• ⚠️ Branch protection is critical—prevents unauthorized runs.

7. ? Hands-On Challenge

Challenge

You have a GitHub repo (my-org/terraform-aws) with Terraform code for an S3 bucket. Configure TFC to: 1. Auto-apply changes in dev (branch: dev).
2. Require manual approval in prod (branch: main).
3. Use a variable set for aws_region = "us-east-1".

Solution

1. Create two workspaces:
2. aws-dev-s3 (branch: dev, auto-apply: enabled).
3. aws-prod-s3 (branch: main, auto-apply: disabled, approval: required).
4. Create a variable set:
5. Go to Settings → Variable Sets → Create Variable Set.
6. Add aws_region = "us-east-1".
7. Apply to both workspaces.
8. Test:
9. Push a change to dev → TFC auto-applies.
10. Push a change to main → TFC waits for approval.

Why It Works:
- Workspaces isolate environments (no cross-contamination).
- Variable sets avoid duplication (DRY principle).
- Approval gates prevent prod outages.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Terraform Cloud Docs – Official documentation.
2. TFC Workspaces Best Practices – Hands-on tutorial.
3. Sentinel Policy Examples – Real-world policy code.
4. Terraform Cloud Pricing – Understand costs (free tier available).