Manage IaCM

Configure Terraform workspaces, drift detection, change approval workflows, and cost estimation in Harness Infrastructure as Code Management.

Instructions

Step 1: Establish Scope

Confirm the user’s org, project, cloud provider, and environments.

Call MCP tool: harness_list
Parameters:
  resource_type: "project"
  org_id: "<organization>"

Step 2: Identify the IaCM Task

Determine which workflow the user needs:

1. Workspace and State Management – Workspace structure, remote state, RBAC, module registry
2. Drift Detection – Continuous drift scanning with remediation workflows
3. Change Approval Workflows – Risk-based approval tiers for infrastructure changes
4. Cost Estimation – Pre-deployment cost impact analysis using Infracost

Step 3: Configure Workspaces and State Management

Gather from the user:

• Cloud provider (AWS, GCP, Azure, multi-cloud)
• Environments to manage (dev, staging, prod)
• Workspace naming convention (e.g., {project}-{env}-{region})
• State backend preference (S3+DynamoDB, GCS+Firestore, Azure Blob, Harness built-in)

Design workspace structure:

• One workspace per environment per account
• Remote state backend with encryption at rest and state locking
• State backup with versioning and configurable retention
• RBAC: Developer=plan only, Senior Dev=plan+apply to dev, Team Lead=staging, DevOps=all with prod approval

Configure module registry:

• Semantic versioning for modules
• Security scanning before module publication (Checkov, tfsec, Terrascan)
• Approval workflow for new module versions

Step 4: Set Up Drift Detection

Gather from the user:

• Environments to monitor
• Scan frequency (hourly, every 6 hours, daily)
• Resources to exclude from drift scanning

Configure drift detection:

• Compare actual cloud resources against Terraform state on schedule
• Detect additions, deletions, and modifications outside Terraform control
• Classify drift by severity: critical (security group changes, IAM), warning (tags, descriptions), info (metadata)

Remediation workflows:

• Auto-remediate low-risk drift (tag corrections, description updates)
• Alert and create ticket for medium-risk drift
• Page on-call for critical drift (security-related changes)

Step 5: Design Change Approval Workflows

Gather risk categories from the user:

• Low risk (e.g., tag changes, scaling adjustments) – auto-apply after peer review
• Medium risk (e.g., new resources, config changes) – team lead approval
• High risk (e.g., security groups, IAM, database changes) – security team + CAB approval
• Emergency (break-glass) – post-implementation review required

Call MCP tool: harness_create
Parameters:
  resource_type: "pipeline"
  org_id: "<organization>"
  project_id: "<project>"
  body:
    pipeline:
      name: "terraform-change-approval"
      identifier: "terraform_change_approval"
      stages:
        - stage:
            name: Plan
            type: CI
            spec:
              # terraform plan + output change summary
        - stage:
            name: Cost Estimate
            type: CI
            spec:
              # infracost diff
        - stage:
            name: Approval
            type: Approval
            spec:
              # risk-based approval routing
        - stage:
            name: Apply
            type: CI
            spec:
              # terraform apply

Step 6: Estimate Infrastructure Costs

When asked for cost estimation:

• Identify the workspace and pending Terraform changes (PR or plan output)
• Run Infracost analysis on the plan

Present a cost report with:

• Current monthly cost vs. projected monthly cost
• Per-resource cost breakdown for new/modified resources
• Cost optimization recommendations (right-sizing, reserved instances)
• Budget impact assessment

Examples

• “Set up Terraform workspaces for our AWS environments” – Configure workspace structure with state management and RBAC
• “Enable drift detection for production infrastructure” – Set up scheduled scanning with severity classification and remediation
• “Create an approval workflow for infrastructure changes” – Design risk-based approval tiers with security review for high-risk changes
• “How much will this Terraform change cost?” – Run Infracost analysis and present cost impact report
• “Configure our Terraform module registry” – Set up versioned module registry with security scanning

Performance Notes

• Workspace naming conventions should be established early – renaming workspaces requires state migration.
• Drift detection scans should avoid peak hours to minimize API rate limit conflicts.
• Cost estimation accuracy depends on Infracost having pricing data for all resource types in use.
• Change approval workflows should include a break-glass path for emergencies – blocking all changes can be as dangerous as no controls.

Troubleshooting

State Locking Conflicts

• Check for stuck locks from failed runs – use terraform force-unlock cautiously
• Verify the state backend (DynamoDB, Firestore) is accessible from the runner

Drift Detection False Positives

• Exclude resources managed by auto-scaling groups or Kubernetes operators
• Add ignore rules for metadata fields that change frequently (last-modified timestamps)
• Verify the scan is running against the correct workspace/state file

Cost Estimation Missing Resources

• Infracost may not support all resource types – check supported resource list
• Ensure the Terraform plan output includes all changed resources
• Custom modules may need explicit cost annotations