From Infrastructure Requests to Infrastructure as Code: What a HashiCorp Training Taught Me About the Future of Enterprise IT

IBM Expert Labs is investing in Terraform. I was part of the first training cohort. Here’s what I learned-and why it matters for every engineer working in enterprise technology today.

Recently, I had the opportunity to participate in a Terraform enablement session conducted by HashiCorp, specifically designed for IBM Expert Labs engineers.

Going in, I understood Terraform at a surface level, an Infrastructure as Code tool, widely adopted, useful for provisioning cloud resources. What the training revealed was something considerably deeper. Terraform has evolved from a provisioning tool into a full platform for standardizing, governing, securing, and scaling infrastructure operations across cloud and on-premises environments.

This article is my attempt to share the most important things I took away from that session-and to explain why IBM Expert Labs is investing in building capability around this technology right now.

Why IBM Expert Labs is Building a Terraform Practice

IBM Expert Labs helps enterprises accelerate their technology transformation journeys. Our clients are navigating cloud modernization, DevOps transformation, platform engineering, and automation at scale, often simultaneously, under real compliance and operational constraints.

As these journeys become more complex, the tools and methodologies that underpin infrastructure management matter more than ever. Terraform has emerged as one of the most widely adopted and strategically important technologies in this space.

We are not yet delivering Terraform engagements at scale. But we are actively building toward that. The HashiCorp training I attended was a direct investment in that direction equipping Expert Labs engineers with the knowledge and hands-on understanding to guide clients confidently through Terraform adoption.

The Shift from Manual Infrastructure to Infrastructure as Code

Traditionally, provisioning infrastructure meant manual processes: ticket-based requests, environment-specific configurations built by hand, and a constant risk of configuration drift where what is actually running quietly diverges from what anyone intended or documented. As cloud footprints grew, these approaches became unsustainable.

Terraform addresses this by enabling infrastructure to be defined using a declarative language called HCL (HashiCorp Configuration Language). Instead of clicking through a cloud console, an engineer writes a file that describes the desired state. Terraform reads that file, compares it to what currently exists, and makes exactly the changes needed.

resource "aws_s3_bucket" "data_bucket" {
  bucket = "expertlabs-client-data"
  tags = {
    Environment = "production"
    Team        = "platform-engineering"
  }
}

Every infrastructure change becomes traceable, reviewable, and repeatable following the same engineering discipline that transformed software development over the last decade.

The advantages compound quickly: repeatability, reduced human error, faster deployments, clearer audit trails, and improved governance. Infrastructure begins to follow the same engineering principles that have long applied to application code.

The HashiCorp Ecosystem: Where Terraform Fits

The training grounded us in the broader HashiCorp ecosystem before diving into Terraform specifics. Products are divided into two strategic pillars.

Infrastructure Lifecycle Management (ILM) covers tools for provisioning and managing infrastructure: HCP Terraform, Terraform Enterprise, HCP Packer, HCP Waypoint, HCP Vagrant, and Nomad Enterprise.

Secure Lifecycle Management (SLM) covers tools for secrets, access, and networking: HCP Vault, Vault Enterprise, HCP Boundary, Boundary Enterprise, HCP Consul, and Consul Enterprise.

For enterprise infrastructure teams, Terraform and Vault are the two most foundational tools and they work best when used together. We will cover Vault in depth in Part 2 of this series.

Two Flavors of Terraform for Enterprise

A critical distinction the training clarified was between the two commercial Terraform products. Choosing the right one depends entirely on the client’s security and compliance posture.

HCP Terraform is a fully managed SaaS platform hosted and operated by HashiCorp. It runs on AWS in both US and EU regions, requires no operational overhead from the customer, and is licensed by Resources Under Management. It is ideal for organizations that can use cloud-hosted tooling without restrictions.

Terraform Enterprise (TFE) is the self-hosted version the same application, deployed inside the customer’s own infrastructure. It runs as a containerized application on Docker, Kubernetes, OpenShift, or Nomad. This is what regulated industries banking, government, healthcare typically require when they cannot let their infrastructure control plane live outside their own network.

As Expert Labs builds this practice, helping clients evaluate which path fits their reality will be one of the first conversations we have on every engagement.

The Maturity Model: A Roadmap for Enterprise Adoption

One of my biggest takeaways from the training was the three-stage maturity model HashiCorp uses to describe how organizations evolve their Terraform practice over time.

Stage 1 — Adopting

Teams begin writing HCL, connecting to version control, and moving away from local state files toward centralized state management. They start securing variables and replacing static credentials with safer alternatives. The objective at this stage is consistency and automation getting infrastructure under code-based management and building the habit.

Stage 2 — Standardizing

As adoption grows, the challenge shifts from can we use Terraform? to how do we use it consistently across teams? This stage introduces a Private Registry an internal, curated library of standardized modules along with Variable Sets, Role-Based Access Control, SSO integration, and Policy as Code. Infrastructure becomes collaborative, reusable, and governed.

Stage 3 — Scaling

At enterprise scale, Terraform becomes the foundation of an internal developer platform. End users can provision infrastructure without writing a single line of Terraform. Self-service workflows, drift detection, continuous validation, and integrations with ServiceNow and CI/CD pipelines all come into play. Terraform stops being a tool individual engineers use and becomes a strategic platform entire organizations operate on top of.

HCP Terraform: The Platform Behind the CLI

Before the training, I primarily thought of Terraform in terms of local execution writing configuration files and running terraform apply from a terminal. The session significantly expanded that picture.

HCP Terraform transforms Terraform into an enterprise-grade collaboration and governance system. The organization hierarchy flows from top-level settings VCS connections, SSO, variable sets, policy sets, and the private registry down through Projects, which are logical groupings representing teams or business units, into Workspaces, which are the fundamental unit of Terraform management.

Each workspace contains the Terraform configuration, variables, state files, run history, health assessments, and RBAC settings for a specific deployment. Projects act as RBAC boundaries a team can self-serve within their project without any risk of touching another team’s infrastructure.

Three Ways to Run Terraform

A particularly practical part of the training covered the three distinct workflows for how Terraform runs are triggered.

VCS-Driven is the most common pattern. The workspace is connected to a VCS repository and branch. A git push or pull request triggers a webhook, which kicks off a Terraform plan or apply in the connected workspace. Infrastructure changes follow the same review and merge process as application code reviewable, auditable, and collaborative.

CLI-Driven allows engineers to run terraform plan and terraform apply from their local terminal or CI/CD pipeline, but execution happens remotely inside HCP Terraform. A cloud block in the Terraform configuration connects the CLI to the right workspace. Ideal for integrating HCP Terraform into an existing pipeline or for local development using speculative plans.

API-Driven uses direct API calls to manage the full Terraform run lifecycle no Terraform CLI involved. Intended for advanced CI/CD pipelines where more control is needed. HashiCorp provides a Dockerized tool called tfci and pipeline templates for GitHub Actions and GitLab to simplify this approach.

RBAC: Access That Mirrors Your Organisation

In HCP Terraform, permissions are entirely team-based. A user has no access unless they belong to a team that has been granted permissions. There are three layers at which permissions can be assigned: organization level, project level, and workspace level.

When integrated with enterprise identity providers like Azure Entra ID or Okta via SAML SSO, team membership syncs automatically from your identity provider. When someone joins or leaves a team in Active Directory, their Terraform access updates without any manual intervention. This is one of the most operationally significant features for large organisations.

The recommended pattern is to create a dedicated platform-team with full organization-level permissions your Terraform administrators and grant application and DevOps teams permissions only at the project or workspace level, keeping them autonomous within their domain without access to anything else.

The Private Registry: Building Reusable Building Blocks

One of the highest-value features discussed was the Private Registry an internal, curated library of approved Terraform modules. The model that works at scale is Producers and Consumers.

Producers :typically the platform or cloud infrastructure team — write, test, version, and publish standardized modules. These are the approved building blocks: VPCs, Kubernetes clusters, databases, storage configurations. They follow the naming convention terraform-<PROVIDER>-<NAME> (e.g. terraform-aws-vpc) and are versioned using git tags following semantic versioning.

Consumers :application teams, DevOps teams discover and use those modules to write and deploy Terraform code without needing to know every implementation detail. They get consistent, governance-approved infrastructure out of the box.

This producers-and-consumers model is one of the clearest examples of how Terraform enables platform engineering at scale.

Key Technical Concepts That Will Shape Real Client Work

Beyond the product overview, the training went deep on specific capabilities I expect to encounter in every enterprise Terraform conversation.

Variable Sets allow commonly used configuration particularly cloud provider credentials to be defined once and applied across multiple projects or workspaces. Instead of setting credentials in dozens of individual workspaces, one Variable Set is created and scoped at the project level. Every workspace in that project automatically inherits those credentials.

Dynamic Provider Credentials take this further by eliminating the need to store long-lived credentials at all. Terraform generates short-lived, just-in-time tokens for each run using a trust relationship between the platform and the cloud provider. The token expires when the run completes no credentials to rotate, no credentials to accidentally expose.

Self-Hosted Agents allow Terraform runs to execute inside the client’s own environment with full access to private, internal endpoints while still being orchestrated by the HCP Terraform control plane. Essential for clients with strict network perimeters or private data center infrastructure.

Health Assessments include drift detection, which continuously checks whether real-world infrastructure matches the Terraform configuration, and continuous validation, which verifies that custom conditions in the configuration continue to pass after provisioning.

Audit Logging gives organizations a full, immutable record of every run, every change, and every user action. For regulated industries, this level of traceability is not optional it is a requirement.

What Shifted in How I Think About Infrastructure

Beyond the specific product capabilities, the training influenced how I think about modern infrastructure engineering more broadly.

Infrastructure is becoming software. The strongest message from the session is that infrastructure should be treated with the same discipline as application code versioned, reviewed, tested, and continuously improved. This is not just a technical shift; it is a cultural one.

Governance matters as much as automation. Many engineers associate Terraform primarily with automation, and rightly so. But the enterprise story is equally about governance: policy enforcement, RBAC, audit logging, module standardization. Scaling Terraform across a large organization without these controls creates new kinds of complexity.

Platform engineering is becoming a core discipline. Terraform is central to the growing practice of building internal platforms that give developers self-service access to infrastructure while maintaining security and operational standards. This is a space where IBM Expert Labs is well-positioned to help clients.

No tool is an island. Understanding Terraform within the broader HashiCorp ecosystem Vault for secrets management, Boundary for zero-trust access, Consul for service networking was one of the most valuable parts of the training. Modern infrastructure platforms are built around integrated workflows, not isolated tools.

Why This Matters for IBM Expert Labs and Our Clients

The biggest lesson I took away from the training is that Infrastructure as Code is no longer just an automation practice. It is becoming the operating model through which enterprises govern, scale, and secure their infrastructure. Understanding Terraform is therefore not just about learning a tool it is about understanding how modern platforms are built.

For me, the training changed how I think about infrastructure engineering. What began as a learning session on Terraform evolved into a broader understanding of platform engineering, governance, and how enterprises scale technology responsibly. It reinforced the idea that successful infrastructure is not defined only by automation, but by the standards, controls, and collaboration that surround it.

IBM Expert Labs is building capability in this space, and I am excited to be part of that journey. I’m looking forward to seeing how these concepts translate into real client outcomes and future engagements.

If you’re an enterprise engineer thinking through Terraform adoption, or navigating the broader shift toward platform engineering, I’d welcome the conversation.

This is Part 1 of a two-part series. Part 2 will cover HashiCorp Vault the secrets management platform that pairs with Terraform to eliminate static credentials and manage access to sensitive data across enterprise environments.

#Terraform #IBM #IBMExpertLabs #HashiCorp #InfrastructureAsCode #DevOps #PlatformEngineering #CloudInfrastructure #LearningInPublic #EnterpriseIT