Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 56

Terraform CI/CD: Automated Plan and Apply

Recommended resources

Hello! Welcome to the final lesson in our module on "Advanced Infrastructure as Code with Terraform."

In our last lesson, we mastered how to use terraform import to bring existing, manually-created infrastructure under Terraform's control. This was the final piece of the puzzle in managing any infrastructure landscape with code. Now, we'll take the ultimate step in IaC maturity: automating the entire workflow.

This lesson directly addresses the learning outcome: Integrate Terraform into a CI/CD pipeline to automate infrastructure validation (plan) and deployment (apply).

As a DevOps engineer who uses GitHub Actions and Jenkins daily, this lesson will bridge the gap between using existing pipelines and designing them "by heart." We will connect the Terraform skills you've built to the CI/CD platforms you work with, empowering you to create robust, automated infrastructure lifecycle management systems.

We will cover:

  • The standard CI/CD workflow pattern for Terraform.
  • Implementing this pattern in GitHub Actions, including secure authentication with OIDC.
  • Implementing the same pattern in a declarative Jenkins Pipeline.

Let's get started.

1. The Core CI/CD Pattern for Infrastructure as Code

The goal of integrating Terraform with a CI/CD pipeline is to make infrastructure changes as reliable, repeatable, and safe as application code deployments. The industry-standard workflow separates validation from deployment and maps these actions to specific Git events.

Terraform GitOps Workflow with GitHub Actions and Azure
This diagram illustrates a common GitOps workflow. Changes are proposed via pull requests, triggering a "Test + Plan" phase for validation. After an approval process, merging the changes triggers the final deployment.

This workflow translates into two main automation rules:

  1. On Pull Request (to the main branch): The pipeline runs terraform plan.

    • Purpose: To validate the proposed changes and preview their impact. This step should never make actual changes to the infrastructure.
    • Key Commands: terraform init, terraform validate, terraform plan.
    • Outcome: The plan's output is posted as a comment on the pull request for team members to review. The PR is blocked from merging if the plan fails.

  2. On Merge (to the main branch): The pipeline runs terraform apply.

    • Purpose: To deploy the approved changes to the infrastructure.
    • Key Commands: terraform init, terraform apply.
    • Outcome: The infrastructure is updated to match the new state of the main branch. This step often includes a manual approval gate for production environments.

Before we implement this, remember these crucial prerequisites for any automated Terraform workflow:

  • Remote State: You must use a remote backend (like AWS S3) with state locking to prevent concurrent runs from corrupting the state file.
  • Secret Management: Cloud credentials must never be hardcoded. They should be managed by the CI/CD tool's secret store.
  • Non-Interactive Execution: The pipeline must run Terraform in a non-interactive mode using flags like -input=false and -auto-approve where appropriate.

2. Automating Terraform with GitHub Actions

GitHub Actions is a natural fit for automating Terraform workflows. Let's explore a complete, real-world example.

27/30 - Automate AWS Infra Using Terraform and GitHub Actions | Realtime Project

The video 'Automate AWS Infra Using Terraform and GitHub Actions' by Tech Tutorials with Piyush provides a fantastic, in-depth demonstration of building a full CI/CD pipeline. We'll focus on the key configuration and workflow steps.

Please watch the following segments to understand the setup and core logic: Project Overview (00:00 - 03:19): Get familiar with the overall goal and the AWS architecture being deployed. Secrets & Environments (06:32 - 09:50): Pay close attention to how AWS credentials are stored as repository secrets and how GitHub Environments are configured. The 'prod' environment includes a 'Required reviewers' rule, which creates the manual approval gate. The plan Workflow (13:28 - 15:58): Analyze the terraform-plan job in the YAML file. Note the triggers (on: pull_request), the use of actions/checkout and hashicorp/setup-terraform, and the steps for tflint, trivy (security scan), init, validate, and finally plan. The apply Workflow (15:58 - 17:02): See how the terraform-apply job is defined. Notice it's conditioned to run on: push to the main branch and requires the successful completion of the plan job.

The video demonstrates a common, but slightly outdated, method of authentication: storing long-lived AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY pairs as GitHub secrets. A more secure, modern approach is to use OpenID Connect (OIDC).

Security Best Practice: Authenticating with OIDC

OIDC allows your GitHub Actions workflow to assume an IAM role in AWS without needing to store any static keys. The workflow requests a short-lived token from GitHub, which AWS trusts and exchanges for temporary credentials.

Authenticate GitHub Actions with AWS Using OIDC — No Secrets Needed

This short video, 'Authenticate GitHub Actions with AWS Using OIDC' by Integrations Ninjas, clearly explains how to set this up.

Watch these key parts to learn the modern authentication standard: OIDC Explained (00:23 - 01:41): Understand the token-based authentication flow between GitHub and AWS. AWS Configuration (02:52 - 06:42): Learn how to create an 'Identity provider' in IAM for GitHub and an IAM role with a trust policy that specifies your GitHub repository. Workflow Configuration (07:23 - 10:51): See how to modify the GitHub Actions workflow. You add permissions for the ID token and use the aws-actions/configure-aws-credentials action to assume the role. Verification (11:34 - 16:35): Observe how running aws sts get-caller-identity successfully proves that the workflow has assumed the IAM role and is authenticated.

By combining the workflow structure from the first video with the OIDC authentication method from the second, you can build a secure, professional-grade CI/CD pipeline for Terraform in GitHub Actions.

3. Automating Terraform with Jenkins

Now, let's translate the same CI/CD pattern into a Jenkins declarative pipeline. Given your experience, you know the principles are the same, but the syntax (Jenkinsfile) and integration points are different.

How to Set Up Terraform in Jenkins Pipelines

The article 'How to Set Up Terraform in Jenkins Pipelines' provides excellent, practical Jenkinsfile examples that we will analyze.

Please read the first three sections of this article to understand the Jenkins-specific implementation: Installing Terraform on Jenkins Agents: Review the options for making the Terraform binary available to your pipeline. Storing Credentials in Jenkins: Understand how to use the Jenkins credential store for your AWS keys. Basic Declarative Pipeline: This is the most important part. Carefully study the example Jenkinsfile. Notice the parallels to the GitHub Actions workflow: environment block: Injects secrets from the Jenkins credential store. stages: The pipeline is broken into logical stages like Checkout, Init, Validate, and Plan. input step: The Approval stage uses this to pause the pipeline and wait for manual confirmation before proceeding to Apply. This is Jenkins' version of the GitHub Environment protection rule. when directive: Controls whether the Apply or Destroy stage runs based on a build parameter. Plan Artifact: The terraform plan -out=tfplan command saves the plan file, which is then used by terraform apply tfplan. The file is available across stages because they run in the same Jenkins workspace.

This Jenkinsfile provides a solid foundation. For more advanced use cases, the article also covers multi-environment pipelines and using Jenkins Shared Libraries to create reusable pipeline code—a key practice for scaling automation across many projects.

Conclusion

Congratulations on completing the "Advanced Infrastructure as Code with Terraform" module! You've gone from writing Terraform code to building fully automated, secure CI/CD pipelines to manage it.

Key Takeaways:

  • Standard Pattern: The foundational CI/CD pattern for Terraform is to plan on pull requests for validation and apply on merges for deployment.
  • GitHub Actions: Use YAML workflows with on: pull_request and on: push triggers. Pass plan files between jobs using artifacts. Always prefer OIDC for authenticating to AWS over static access keys.
  • Jenkins: Use a declarative Jenkinsfile with distinct stages for each Terraform command. Use the built-in credentials() helper for secrets and the input step for manual approval gates.
  • Automation Flags: Use terraform plan -out=tfplan to save a plan and terraform apply tfplan to apply it exactly. Commands in a pipeline should always be non-interactive.

This skillset is the cornerstone of modern cloud infrastructure management and a critical competency for any DevOps engineer.

What's Next?

So far, we've focused on provisioning the infrastructure—the servers, networks, and databases. But what about configuring what runs on that infrastructure?

In our next module, Configuration Management with Ansible, we will tackle that exact problem. You'll learn how to use Ansible to automate software installation, service configuration, and application deployment on the very servers you can now provision automatically with Terraform. This will connect the two pillars of Infrastructure as Code and Configuration Management.