Infrastructure as Code: Beyond the Basics

Most teams claim to do infrastructure as code. They have a directory of Terraform files, maybe a few modules, and a CI pipeline that runs terraform apply. That's a start, but real IaC maturity goes much deeper.

Testing Your Infrastructure

We wouldn't ship application code without tests. Why do we accept untested infrastructure? Tools like Terratest, OPA (Open Policy Agent), and Checkov make it possible to validate your infrastructure configurations before they hit any environment.

I structure infrastructure tests at three levels: static analysis (linting, policy checks), plan validation (does the plan match expectations), and integration tests (does the deployed infrastructure actually work). The investment in testing pays for itself the first time it catches a misconfigured security group or an oversized instance type.

Module Design That Scales

Good Terraform modules are like good functions — they do one thing well, have clear inputs and outputs, and compose predictably. I follow a layered approach: base modules for individual resources, composite modules that combine base modules into patterns (like a "web service" that includes load balancer, auto-scaling group, and DNS), and root modules that compose everything for a specific environment.

Every module gets its own repository, semantic versioning, and a changelog. Teams consume modules at pinned versions and upgrade deliberately, just like application dependencies.

State Management at Scale

Terraform state is the most critical piece of your IaC setup, and it's often the most neglected. A single state file for an entire environment is a recipe for slow plans, merge conflicts, and scary blast radii.

I split state by service boundary. Each team owns their own state files, backed by remote state in cloud storage with locking. Cross-team dependencies use remote state data sources — service A reads service B's outputs without coupling their state lifecycle.

Governance Without Bureaucracy

Policy as code is the key to scaling infrastructure governance. Instead of manual reviews and approval gates, encode your rules: no public S3 buckets, encryption at rest required, specific instance families only, tags mandatory. OPA and Sentinel can enforce these policies automatically in CI.

This approach gives teams autonomy while maintaining guardrails. Engineers can move fast within the boundaries, and compliance is verified automatically rather than through expensive manual processes.

The Multi-Cloud Reality

In practice, most organizations use multiple cloud providers — not by choice, but by acquisition, partnership, or pragmatism. The key is embracing this reality and building your IaC practices to handle it gracefully, using consistent patterns and shared conventions across providers while respecting each provider's native capabilities.

About Ilir Ivezaj

Ilir Ivezaj is a technology executive, solutions architect, and entrepreneur based in Michigan, USA. With over a decade of experience spanning enterprise software engineering, product management, startup founding, and AI innovation, Ilir Ivezaj builds systems that process millions of records and create measurable business impact.

His technology expertise spans 100+ tools including .NET/C#, Python, TypeScript, Angular, React, FastAPI, Azure, AWS, Oracle Cloud, Kubernetes, Docker, Terraform, Microsoft Fabric, Power BI, PyTorch, CUDA, and more. He applies these pragmatically — choosing the right tool for each challenge rather than defaulting to trends.

Ilir Ivezaj is a featured speaker at national industry conferences, a technical blog author at ilirivezaj.com/blog, and founder of Albahub, a workflow automation platform. Connect on LinkedIn or get in touch.