-
Configure Remote State Backend
What you're doing: Setting up centralized state storage with locking to enable team collaboration and prevent state conflicts.
Instructions:
1. Enter S3 Bucket Name: tf-state-prod (stores Terraform state files)
2. Enter DynamoDB Table: tf-locks (provides state locking)
3. Click Save Backend to configure remote state
💡 Tip: DynamoDB locking prevents concurrent Terraform runs from corrupting state. Without locking, two people running "terraform apply" simultaneously could cause state corruption.
📘 Real-world context: Remote state backends are critical for team environments. S3 provides durability (99.999999999%) and versioning for state recovery. Always enable versioning on state buckets.
-
Enable Multi-Cloud Providers
What you're doing: Configuring Terraform to manage resources across AWS, Azure, and VMware simultaneously.
Instructions:
1. Check the AWS checkbox
2. Check the Azure checkbox
3. Check the VMware checkbox
4. Select AWS Region: us-east-1 (N. Virginia) from dropdown
5. Select Azure Region: East US from dropdown
6. Click Save Providers
💡 Tip: Multi-cloud strategies provide redundancy and avoid vendor lock-in. Each provider requires authentication (AWS keys, Azure service principals, VMware credentials).
📘 Best practice: Use provider aliases when managing multiple regions or accounts of the same provider. Example: provider "aws" { alias = "west" }
-
Create Production Workspace
What you're doing: Creating an isolated environment for production infrastructure, separate from dev/staging.
Instructions:
1. Enter Workspace Name: production
2. Select Execution Mode (Remote recommended for teams)
3. Click Create Workspace
4. Verify workspace appears as "current workspace" in header
💡 Tip: Workspaces allow using the same Terraform code with different variable files. Each workspace maintains separate state, enabling environment isolation (dev, staging, prod).
📘 Real-world context: Production workspaces should have stricter access controls, approval workflows, and potentially different providers/regions than lower environments.
-
Define Infrastructure Modules
What you're doing: Configuring reusable Terraform modules for VPC networking and compute resources with standardized tagging.
Instructions:
1. Enter VPC Module name (e.g., "vpc-module" or "network-module")
2. Enter Compute Module name (e.g., "compute-module" or "ec2-module")
3. Enter Resource Tags exactly as: env=prod,owner=platform
4. Click Save Modules
💡 Tip: Modules promote DRY (Don't Repeat Yourself) principle. Write infrastructure code once, reuse across projects. Tag format must be key=value pairs for proper resource tagging.
📘 Best practice: Standardized tags enable cost allocation, automation, and resource governance. Common tags: environment, owner, project, cost-center, compliance-scope.
-
Generate and Review Terraform Plan
What you're doing: Running terraform plan to preview infrastructure changes before applying them.
Instructions:
1. Click Run Plan button
2. Wait for plan generation (simulates what will be created/modified/destroyed)
3. Review the output showing resources to add (should show ~15 resources)
4. Verify VPC and Azure resources appear in plan
💡 Tip: ALWAYS review plans before applying! The plan shows: + (create), ~ (modify), - (destroy). Red flags: unexpected deletions or modifications to critical resources.
📘 Real-world context: Save plans for audit trails: terraform plan -out=plan.tfplan. This ensures the applied changes match what was reviewed and approved.
-
Apply with Policy Enforcement (Sentinel)
What you're doing: Applying infrastructure changes with policy-as-code validation to enforce governance rules.
Instructions:
1. Check the Enable Policy Validation checkbox
2. Click Apply Changes
3. Wait for policy checks to pass (validates compliance, security, cost limits)
4. Verify "Policy check passed ✓" message and "Apply complete" confirmation
⚠️ Important: Policy validation MUST be enabled. Sentinel policies prevent non-compliant infrastructure (e.g., unencrypted storage, over-sized instances, missing tags).
📘 Best practice: Implement hard/soft enforcement levels. Soft-mandatory allows overrides with justification, hard-mandatory blocks non-compliant changes entirely.