Skill

Automate Infrastructure with Terraform/OpenTofu

Expert Terraform/OpenTofu specialist for module design, state management, multi-cloud IaC, policy as code, and CI/CD automation.

Works with terraformopentofugithubgitlabazure devops

78
Spark score
out of 100
Updated 17 days ago
Version 15.3.0

Add to Favorites

Why it matters

Leverage advanced Infrastructure as Code (IaC) practices to design, deploy, and manage complex, multi-cloud infrastructure environments using Terraform or OpenTofu.

Outcomes

What it gets done

01

Design and implement reusable Terraform/OpenTofu modules.

02

Configure secure remote state backends and manage state lifecycles.

03

Integrate IaC into CI/CD pipelines for automated deployments and policy enforcement.

04

Perform drift detection, cost validation, and implement rollback strategies.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-terraform-specialist | bash

Overview

Terraform Specialist

An expert Terraform/OpenTofu skill covering module design, state management and security, multi-environment and multi-cloud strategies, policy as code, CI/CD automation, and enterprise governance for infrastructure as code. Use it when designing modules or environments, managing state backends and workspaces, or building policy-as-code/CI/CD automation - not for a one-off manual change or when locked into a different IaC tool.

What it does

This skill acts as an expert Infrastructure as Code specialist covering Terraform, OpenTofu, and the modern IaC ecosystem, with mastery of advanced module design, state management, provider development, and enterprise-scale infrastructure automation, including GitOps workflows, policy as code, and multi-cloud deployments.

Its capabilities span: core and advanced Terraform/OpenTofu features (dynamic blocks, for_each loops, conditional expressions, complex type constraints, Terraform-to-OpenTofu migration); module design (hierarchical/root/child module architecture, composition patterns, dependency injection, Terratest-based testing, semantic versioning); state management and security (S3/Azure Storage/GCS/Terraform Cloud/Consul/etcd backends, state encryption and locking via DynamoDB/Azure Storage/GCS/Redis, state import/move/remove operations, automated backups and point-in-time recovery); multi-environment strategies (workspaces vs separate backends, environment isolation, blue/green promotion, GitOps branch-based deployment); provider and resource management (version constraints, provider aliases, drift detection and correction, resource dependency graphs); and advanced configuration techniques (templating, variable validation, precondition/postcondition checks, error handling and retries, resource parallelization).

For CI/CD it covers pipeline integration with GitHub Actions, GitLab CI, Azure DevOps, and Jenkins; automated plan validation and security scanning with tfsec, Checkov, and Terrascan; policy as code via Open Policy Agent (OPA) and Sentinel; and pre-commit quality gates. For multi-cloud and hybrid work it covers provider abstraction, cloud-agnostic modules, cross-provider resource sharing, cost estimation/tagging, and cloud-to-cloud migration. It's also aware of the broader modern IaC ecosystem - Pulumi, AWS CDK, Azure Bicep, Google Deployment Manager as alternatives, and Helm/Kustomize/Ansible/ArgoCD/Flux as complementary tools. For enterprise governance it covers RBAC and team-based access, SOC2/PCI-DSS/HIPAA compliance, audit trails, cost allocation, and self-service module catalogs, plus troubleshooting: state corruption recovery, failed-apply resolution, drift monitoring, and provider/module upgrade management.

When to use - and when NOT to

Use it when designing Terraform/OpenTofu modules or environments, managing state backends, workspaces, or multi-cloud stacks, or implementing policy-as-code and CI/CD automation for infrastructure. Its behavioral defaults: follow DRY principles with reusable, composable modules; treat state files as critical infrastructure requiring protection; always plan before applying with thorough change review; pin version constraints for reproducible deployments; prefer data sources over hardcoded values; and build automated testing, security scanning, and documentation into every workflow.

Do not use it for a one-off manual infrastructure change, when locked into a different IaC tool or platform, or when remote state cannot be stored and secured - these fall outside its safe operating assumptions. It always reviews plans before applying and protects state files from exposing secrets.

Inputs and outputs

Input is an infrastructure requirement - a module to design, a state backend to configure, a CI/CD pipeline to build, or an existing Terraform codebase needing migration or troubleshooting. Its response approach: analyze requirements for the right IaC pattern, design a modular architecture with proper abstraction, configure a secure backend with locking and encryption, implement testing and security validation, set up automation with approval workflows, document thoroughly with examples, plan for long-term maintenance and upgrades, and account for compliance and cost. Example interactions include designing a reusable three-tier web application module with testing, setting up encrypted multi-team remote state, building a security-scanned CI/CD deployment pipeline, migrating Terraform to OpenTofu, implementing policy-as-code compliance checks, designing multi-cloud provider abstraction, and recovering from state corruption.

Who it's for

Platform and infrastructure engineers building or operating Terraform/OpenTofu infrastructure at scale - module design, secure state management, multi-cloud architecture, policy as code, and CI/CD automation for infrastructure changes.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.