Real-World Terraform Projects

# CHAPTER 19

Real-World Terraform Projects #

1. Introduction #

In the DevOps engineering landscape, theoretical knowledge gets you past the recruiter, but a demonstrated portfolio of functional automation gets you the job offer. Employers want to see that you can synthesize Terraform providers, modules, remote state, and CI/CD pipelines into cohesive, production-grade architectures. In this chapter, we outline five robust, professional-grade Infrastructure as Code projects. These projects are designed to prove your mastery of cloud provisioning, network security, and declarative orchestration.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Architect a complete, secure AWS network infrastructure.

• Build a multi-cloud high-availability architecture.

• Orchestrate a Kubernetes deployment utilizing multiple Terraform providers.

• Design an Enterprise-grade Reusable Module.

• Document and present infrastructure projects professionally for a portfolio.

3. Project 1: The Production-Ready AWS Network #

The Goal: Prove you understand core cloud networking and security boundaries. The Architecture:

1. 1. Source: A GitHub repository containing your Terraform code.

1. 2. The Workflow: Use the official terraform-aws-modules/vpc/aws module.

1. 3. The Components:

• Define a custom CIDR block (e.g., 10.5.0.0/16).

• Create 2 Public Subnets (for Web Servers/Load Balancers).

• Create 2 Private Subnets (for Application Servers).

• Create 2 Secure Database Subnets (isolated, with NAT Gateways).

• Provision a Bastion Host (EC2) in the public subnet to allow secure SSH access into the private subnets.

1. 4. The Proof: Create an architecture diagram using Draw.io showing the VPC boundaries. Provide the terraform plan output proving the dynamic creation of route tables and internet gateways.

4. Project 2: Highly Available Web Application (Auto Scaling) #

The Goal: Prove you understand elastic infrastructure and load balancing. The Architecture:

1. 1. The Infrastructure: Build upon Project 1.

1. 2. The Components:

• Create an AWS Application Load Balancer (ALB) facing the public internet.

• Create an Auto Scaling Group (ASG) in the Private Subnets.

• Use a data block to fetch the latest Amazon Linux AMI.

• Use userdata in the Launch Template to automatically install Apache/Nginx on the servers as they boot.

1. 3. The Proof: Document the pipeline output showing the successful deployment. Provide a screenshot showing the Load Balancer DNS successfully returning the default Nginx webpage, proving traffic is routing from the public ALB to the private ASG instances.

5. Project 3: The Multi-Cloud Disaster Recovery Solution #

The Goal: Prove you understand Terraform's cloud-agnostic orchestration capabilities. The Architecture:

1. 1. The Infrastructure: A single Terraform workspace defining two providers: aws and google.

1. 2. The Components:

• Provision an AWS S3 Bucket containing critical application data.

• Provision a Google Cloud Storage (GCS) Bucket.

• Create an AWS IAM Role and a GCP Service Account allowing cross-cloud read/write permissions.

• *Bonus:* Use a nullresource or local-exec provisioner to trigger an automated script that copies data from the S3 bucket to the GCS bucket upon deployment.

1. 3. The Proof: Provide the code showing the configuration of both providers within the same main.tf file, and screenshots of both the AWS and GCP consoles showing the successfully provisioned, identically named storage buckets.

6. Project 4: Kubernetes Infrastructure & Application Deployment (GitOps) #

The Goal: Prove you understand container orchestration and multi-provider sequencing. The Architecture:

1. 1. Phase 1 (Hardware): Use the AWS provider to build an Elastic Kubernetes Service (EKS) cluster.

1. 2. Phase 2 (Software): Use the Kubernetes provider (authenticating dynamically to the newly created EKS cluster) to deploy a Namespace, a Deployment (e.g., 3 replicas of a Node.js app), and a LoadBalancer Service to expose it to the internet.

1. 3. The Proof: Provide the complex Terraform code highlighting the implicit dependencies between the AWS module and the Kubernetes provider. Provide a screenshot of the terminal running kubectl get pods -n my-namespace showing the running containers, and the accessible public IP of the application.

7. Project 5: The Enterprise Reusable Module #

The Goal: Prove you understand the DRY principle and developer-experience engineering. The Architecture:

1. 1. The Module: Create a separate repository named terraform-aws-secure-database.

1. 2. The Code: Write a highly parameterized module (variables.tf heavily utilized) that provisions an AWS RDS MySQL Database.

• Hardcode security standards: storageencrypted = true, publiclyaccessible = false.

• Use randompassword provider to generate a secure master password dynamically.

• Store the generated password automatically in AWS Secrets Manager.

1. 3. The Implementation: In a different "Root" repository, call the module: source = "git::https://github.com/your-name/terraform-aws-secure-database.git".

1. 4. The Proof: Highlight how the complex encryption and secret management logic was abstracted away from the caller, ensuring absolute organizational compliance while requiring only 5 lines of code from the developer.

8. How to Document Your Infrastructure Portfolio #

An Infrastructure portfolio is different from a Web Developer's portfolio. You aren't showing pretty websites; you are showing secure systems.

• Architecture Diagrams: An IaC project without an architecture diagram is incomplete. Use tools like Draw.io or Lucidchart to visualize the VPC, Subnets, and Resource relationships. Place this at the top of your README.md.

• The "Why": Explain your architectural decisions. "I utilized a foreach loop over a count index to prevent state file shifting when dynamically generating subnets."

• Security Posture: Explicitly document your security implementations. Highlight the usage of Checkov SAST scanning, private subnets, and remote backend state encryption.

9. Summary #

In Chapter 19, we transitioned from learners to practicing Cloud Architects. We designed five capstone projects that synthesize the entire infrastructure lifecycle. From foundational networking and auto-scaling compute, to advanced multi-cloud orchestration and secure module abstraction, these projects demand the practical application of declarative HCL, secure state management, and CI/CD automation. By executing these projects and documenting the architectural decisions behind them, you construct a professional portfolio that undeniably proves your engineering capability.

10. Next Chapter Recommendation #

Your portfolio is built, and your cloud skills are validated. It is time to prepare for the technical screening and plan your career trajectory. Proceed to the final chapter: Chapter 20: Terraform Interview Questions and Career Roadmap.